Detecting concurrent logins

[Josh More]

Have any of you used Security Onion (or OSSEC) to detect concurrent
logins from different IP addresses within a specified timeframe?

I've never had to address this requirement before and googling isn't
being all that helpful.

Thanks,

-Josh More

[Wes]

I would imagine this would be done through writing an OSSEC HIDS rule. I've never done it myself, but this would seem to me how it would be done.

You may want to check out the rules syntax here:

http://ossec-docs.readthedocs.org/en/latest/syntax/head_rules.html

Also, a PDF about working with OSSEC rules can be found here:

http://www.ossec.net/ossec-docs/OSSEC-book-ch4.pdf

Again, this is just a suggestion.

Thanks,

Wes

[Brian Kellogg]

This is difficult to do out of the box from what I've found.

I collect login logs with OSSEC and then I have a script that runs ELSA searches and correlates some of that information. It looks at the username and the source IP and then uses a time window for alerting.

For Windows:
To do this correctly you need to look at 4624 events for at least Type 2(console logins) and 10s(RDP). These are for interactive logins and 3s are for network resource logins(tracking by type 3s could raise a lot of FPs). There are also Type 8s which you will see with IIS and the like. You should also look at the Windows logoff events which are 4634s and 4647s to know how long the account was logged into a specific device. To correlate 4624s to the 4634s and 4647s definitively use the Login ID as that number is unique between a server's reboots for each login. There is a lot of work to do here. Use the ELSA time stamp as the time source as it will always be UTC.

This gets tricky if you have someone VPN in and then RDP to another device; this would be two simultaneous logins from different IPs. You would have to correlate the source IPs and from the work I've done the source IP is not always included in the login log; sometimes its set to 127.0.0.1 even for RDP logins. I wonder if this is a RDP login emulating a console login.

So to sum it up for Windows, I am still trying to crack this nut and would love to hear what others have to say on it. I have not found a way of doing this with OSSEC. I've thought of creating an active response that writes login/logoff data to a file or DB and checks the data to see if any other login from the user was recorded in a given time window. I hope I am missing a much simpler way of doing this. Sorry if I told you a lot of information you already knew.

For VPN:
Depends on your VPN and the auth backend. But this should be easier than Windows as you have less log types to worry about and you can also GeoIP the source of the VPN login. I've done a lot of work with this in my environment and it is far simpler than Tracking Windows logins.

Account behavioral monitoring and benchmarking are excellent security measures to use I've found.

There is a paid for solution that I've demoed that I found quite useful. http://www.rapid7.com/products/userinsight/

[namobud...@gmail.com]

Brian,

This is awesome; any chance you could share redacted code?

Thanks for sharing.

[Brian Kellogg]

I'll see what I can do. The stuff I share is the stuff I do on my own time as I love to code. I can share stuff that would make my job harder if it were not integrated into SOs updates or is not proprietary. Not sure I can share this stuff.

For this particular issue with Windows I don't have a good working solution yet. For Windows I also attack the problem from another side, mostly, as that side is easier and I haven't the time to develop what I described in the above to any production worthy level of maturity. Take advantage of OSSEC CDBs and track your elevated accounts' behavior with OSSEC rules being alerted on in Sguil. Try to find ways to push security back onto the account owners. Help them to realize they have skin in the game. Start by identifying your most vulnerable/desirable accounts and don't forget about service accounts. If one of those account logs in, automatically notify the account owner somehow (source, destination, time, ...). Include process information if you can or out of the ordinary processes run by the logged in account. Do a GeoIP lookup on any Inet IPs and include that information. ...

I'll see if I can come up with a Python solution in my own time. The VPN portion shouldn't be too hard but there is always the problem where logs will be different between different VPN vendors so any Python code I share would have to be tweaked, possibly, to read the logs of your specific VPN vendor.

For Windows: I need to determine the best method for tracking Windows logins; as I stated I'm still arguing with myself on this one. I welcome any input as I'm sure someone has a better idea. My hammer is coding and everything tends to look like a script/programming/algorithm problem from my biased perspective.

[James Taylor]

This is something I am trying to solve also thanks for asking the question.

Brian, thanks for sharing you have givin me some ideas!

I am still trying to wrap my brain around a method to track "all" user authentication activity and I am leaning towards querying ELSA via cron and using python and mysql to extract this information and building a reporting front end that allows me to understand authentication behavior. I want to be able to at anytime search a user and know all logins primarily 2 and 10 that user has recently logged into displaying possible concurrent logins etc..

Also Brian, thanks for posting the earlier python code that helps automate generating some of this stuff I have just not been able to get around to it.

I thought ELSA sub search with has() might work but have not been able to figure it out.

[Brian Kellogg]

No worries, I share what I can as I know how frustrating it is starting from scratch. I beg for what I can as well.

I've been thinking about the ELSA cron query approach too but I'm concerned about the overhead that may produce depending on how often the cron job runs. Bigger environments may have more concern here given how many accounts they would have to track.

The active response option really intrigues me as this means the DB is updated very quickly from the second link in the log chain, at least for me. ELSA would be the third link in the chain for me. Then you could run correlation scripts against that DB and/or use stored procedures.

I need to get better with the more advanced ELSA searches too. Something I've been trying to work on.

I'm open to creating a GitHub repository for any code and ideas on doing this collaboratively.

I've worked with a Web frontend for quickly developing web DB integrations called Xataface a bit. For me, it makes Web enabling DBs much quicker as I am not a web programmer. http://xataface.com/

[James Taylor]

Brian, you might be right about the ELSA overhead in larger environments I already started a project in my spare time dealing with Sysmon events and I am approaching it using the Flask and ELSA api with cron and will see how that goes.

Active response sounds like a great approach to this I am going to be thinking about this more so if you have any breakthroughs or decide to start something would love to hear about it and would be willing to "help" when time allows.

Josh sorry to hijack your thread, if you come up with a solution would love to hear your approach.

[Josh More]

By all means, hijack away. That's how we get better. The answer I'm
getting is:

1) It's hard.
2) It's not been solved by the community yet.

So this client will likely go for one of the paid solutions and then
tie in whatever the community comes up with once it's ready (largely
due to lack of time around this issue).

> --
> You received this message because you are subscribed to the Google Groups "security-onion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to security-onio...@googlegroups.com.
> To post to this group, send email to securit...@googlegroups.com.
> Visit this group at http://groups.google.com/group/security-onion.
> For more options, visit https://groups.google.com/d/optout.

[Brian Kellogg]

Thanks everyone. That's the problem across the board we're all understaffed. Thus why SO and its community is such an excellent resource.

I'll start with type 2 and 10 logins and see what can be done here when I get a chance. Need to spend some good time designing the DB.

I've not used Flask.

[Brian Kellogg]

I keep forgetting that with OSSEC AR you can't pass the entire log to the script you call with it. So this is out.

So another option is to create a script to monitor the OSSEC alerts log or main ossec agent log file for the events we are interested in.

You could also create OSSEC rules to funnel all logins to Sguil and then query the Sguil DB.

And we have ELSA query API that we could use.

Trying to think of all the ways to tackle this.

[namobud...@gmail.com]

I found a article detailing windows login levels:
http://www.windowsecurity.com/articles-tutorials/misc_network_security/Logon-Types.html

It looks like if I was a attacker moving laterally I might use Type 3 Logins as well (accessing from over the network), and I wonder if console logins are less common because most attackers know better then to RDP into a live box. I'm trying to defend against a incident on one box spreading out throughout the network.

I like the idea of identifying higher value accounts and boxes and paying closer attention to them. I.E. within the automation we're all trying to create because (active defenses and automation seem to be the flavor of the month at the moment), maybe it makes sense to pay attention to the higher value accounts and login types and include deeper scripts for these. I'm learning python, powershell and bash, can anyone point towards some good security scripts to learn more from.

I'm also trying to understand ELSA dashboards better.

[Brian Kellogg]

Type 3s are important but a much harder nut to crack. RDP is still used extensively by attackers as well; path of least resistance and all. Same with remote task scheduling with at.exe.

Going through Python scripts on github is a good learning experience. Violent Oython is a good book for security scripting.

[James Taylor]

For lateral movement if using a domain account I *think* the following might be good indicators.

New BRO kerberos will give you hints via service=cifs/whatever.

The other events I am looking at right now are audit 5145 and 5140 on the clients this will show any c$ and IPC$ etc.

I sadly have not been able to spend the time I would like with this so they may be completely wrong.

Brian spent some time on the concurrent logins I have nothing better at this point.

[James Taylor]

And one more thing for lateral movement

http://defensivedepth.com/2015/03/27/using-sysmon-to-enrich-security-onions-host-level-capabilities/

^ that is amazing coupled with security onion when it comes to host detection.