Was hoping to get this up after the course in the evening after some time to reflect, but I had to do battle with a lawn mower XD. Today there was a 20 minute pre show banter going over Metasploit/Meterpreter as it was used the other day and some information with lanman and NTLM password hashes before moving on into all the fun with LOGS (Do you have the log theme from Ren and Stimpy stuck in your head? I hope so)

While that was only a part of the topics we covered they were egress traffic monitoring/visibility before moving into user entity behavior analytics (Or for you acronym types UEBA…and for you QRadar types, the UBA). Lots of stuff was covered, the thing that made me happy was no “YOU NEED FIREWALL LOGS!!!!!” (Sure maybe in a log aggregator with more critical events going to the SIEM, but to flood it with single SSH connections….talk about a log toilet for your SIEM). The egress traffic mostly dealt with flows and PCAPS to look for long connections/beconing (or heart beats/jitter to C2/C&C servers) and looking at how big of a pain it is to set up proper logging with Windows, or you know…use sysmon and save yourself. There was also a breif talk about Sigma rules (which I also found uncoder.io to help translate sigma rules or other SIEM Rules (for the quick TL;DR)

The first key point we talked again was the egress traffic monitoring, which helps fit the bill if you are using the c2/C&C (Command and control) and exfiltration on MITRE ATT&CK. We need more than alerts (it really isn’t enough without the proper context, As someone that works in a SIEM a lot…can I get an amen?). by properly monitoring/logging of the egress traffic you can help see other OT/IoT/Shadow IT devices that is egressing so you can see what you mgiht be missing with an asset inventory or to spot check where NAC (network access controls) Might be failing. When you think Egress traffic a lot of people think “The firewalls” which is nice to see that traffic, however do you really want to fill your SIEM with just Firewall logs? Because it’s what you are likely going to do. That being said you need a balanced mix of network and host based data. A good example of this would be having your IDS alerts, any threat logs from Firewalls, a network flow (like Cisco’s netflow) to see the simple traffic (Ip/mac/port/basic packet info), and logs from the end point or server. Another helpful tool we talked about it Zeek (formally Bro) which is an open source network analysis frame work. Helps with constancy, and because open source has a lot of support. It also Helps with timestamps, which are key when doing analysis/network forensics and helps get proper log files and to see what is really going on versus waiting for the typical signatures (aka last weeks attack). Zeek can also takes full PCAPS for analysis (which you can look at if you want to use other tools which we covered later).

There was a brief on Hunt teaming (red team) with actively looking for threats and the joys of going though Logs (see above image) and using Active Countermeasures free tool RITA (Real Intelligence Threat Analytics) to look for long connections/beacons and can even check for Blacklist DNS as well. We than talked about Full PCAPS (which can put a lot of strain on network traffic if not being done carefully with the right tools). Everything supports PCAPS, there is a learning curve (a good course is the Security Blue Team intro to network analysis course which covers both Wireshark and TCP Dump and gives you PCAP’s to play with LINK I am sure there are others as well). It was nice that they showed an example of how to set up RITA to capture the traffic.

From this we pivoted into User agent string examples that you might see with some of the traffic captures that might be long/repetitive connections to Microsoft services for example or web browser and JA3 for profiling SSL/TLS clients. Because security does involve math (yay…)Long Tail analysis was brought up to look for anomalies and outliers (If you went to school for Cyber/Information security and thought taking a statistics class, I got news for you, you use it a lot). never try and find the “needle in the haystack” but look for the odd traffic and possible anomalies. John than gave a shot out to Security Onion, which is the next thing I plan on setting up for a lab to help monitor what will be going on with my purple team lab and my normal home network). Comes with Zeek, Suricata, ELK and other useful features.

UEBA, Hurray! (which means if you were in the course, this blog is almost done XD). Just a reminder. There is no “YOU GOT PWNED” Log and only 5% of detects come from logs and traditional windows logs are not super useful for security. You can use tools from JPCert Tools to try and help, but that can be a lot of extra overhead and different tool usage. Why do this? These logs can help tell the story with AD, Exchange, OWA and other system/system access. News flash: This requires Tuning, as security professionals not red teaming this is our job. If you just set up a blinky box and expect it to do all your work its not. things are going to get missed (because blinky boxes like signatures or certain events). A good example is internal password spray. One ID, accessing multiple systems However this brings into view the “False Positives” (which is a rant I have with Qradar with the tuning calling things False Positives” its not really a thing, it’s not normal traffic and not tuned properly, think system/service accounts trying to log into multiple services (think that internal password spray example). System admins, scripts *Groan* and back ups. It is why tuning is so critical, if your managers, CISCO/CIO don’t think it is important, there are tons of resources that point to the need of this, and is what a security team should be doing, and with that I’ll get off my soap box.

UEBA can works by stacking, like cards. a user log on +1, log off -1. Set a threshold (6) so if the user tries to log in 7 times or uses bloodhound they get A lot of log on attempts and should be some sort of alert generated. As much as I have a dislike with AI, UEBA can use AI to help learn what is normal and help with baselines, so it can have the basic logs of account log ins or data transfers and when user pulls a gig of files and is now pulling 5…you might got a problem (and can help with USB connections and other things). Now that we have logs, how do we get them. All of them, systems, servers, services, network *insert log theme here*. Getting the right logs takes time and is a pain and there are many factors that need to be taking in that can align with risk (data classification of data on asset, critical business assets among other factors). John brought up a good point with getting AD/Powershell/Command line logs. Its hard and its noisy, but what’s even harder? Not having UEBA or not having it at all. The logs can be used with tools like Logon Tracer to help see the movement across the network. Other helpful tools are DeepBlueCLI to help with a portable UEBA logs, while sucks for a full enterprise deployment, it can be useful in a lab setting to see what logs you need, or a nice tool for your DFIR toolkit. Same with DeepWhiteCLI, which works with parsing Sysmon event logs and grabbing the SHA256 hases to get process creation, driver load, and image load events. There was discussion with enabling windows event logging with important event ID’s but discussed setting up Command Line Logs/Powershell logs….a long procces, which to TL;DR is a long process. OR you can make your life easy with installing sysmon. You can install it locally (and SwiftOnSecurtiy default config install is a prime example). There is a great article from syspanda (https://www.syspanda.com/index.php/2017/02/28/deploying-sysmon-through-gpo/). To help deploy it enterprise wide via GPO. Another helpful service if your using ELK/Elastic is winlogbeat which does a nice and useful thing and sends all this info over to elk! And it can be messy going between different SIEM rules which is why Sigma is brought up briefly for sigma rules (which you can convert to the SIEM flavor of your choice, though Sigma is meant to be a non-vendor specific SIEM Rule). There was also a slide on exchange loging (and a best practice to enable log file and ETW event and the max size). We than did the Deep Blue CLI lab. I cannot remember if we talked about it but there was a slide from logon Tracer that focuses around 6 even ID’s

• 4624-Loggin Success
• 4625-Logon Failure
• 4768-Kerberos Authentication (TGT Request)
• 4769-Kerberos Service Ticket (ST Request)
• 4776-NTLM Authentication
• 4672-Assing special privileges

While I started zoning out as my system admin experience is limited but with the in detail how to log AD, Command Line (as a lot of malware/bad things run ping, tracert, and netstat), and powershell I was in the firehose effect and there was some about about Kerberorusting and other attacks as we started with Password Spraying.

I got a little lost at the end as I was trying to help out and there were SIEM questions and I’ll admit I was over logging at this point and agreeing with John’s point of view of SIEM and not fully knowing how much you log, and where you log from, who tells you what to log and finally what percent of those logs have an alert/signature for them. As someone who knew the SIEM at $employeer was a dumpster fire, I jumped in and got my hands dirty trying my best to fix the charlie foxtrot and learning a lot along the way as there are a lot of questions like this and I am trying to be more active with giving back and really seeing how much I know (and help my learn it better by trying to teach it)

Time to get get a little pump of coffee to get ready for today’s pre-show backdoor and breaches demo!