What We Do When Waiting for Windows to Boot…
Welcome to the new series-based blog that provides our consultants s
omething to do when powering up lab and analysis systems running *certain versions of operating systems. These are quick-hitting blogs that provide insight to current things we’re investigation or analyzing, or neat tricks and solutions we have come up with to answer sometimes crazy problems, or really any musings that are appropriate. Our goal: is it really possible to finish a blog before a system reboots? So, when you’re waiting on your system to cycle, jump on a Linux box and read a blog!
Begin Blog: 1:58pm EST, Shutting down Windows 7 Ultimate
On our plate today: analyze an entire month of two-way packet captures crossing the core switch for “anything suspicious”; no joke, we get tasks like this so it can be challenging and fun to tackle. We’re not going to talk about running the pcaps through network IOCs or tcpreplay (although, yes, do this), we are instead going to talk about one area that is often missed when reviewing logs: is data being sent across your protected boundary?
Make the Logs Manageable
Start to combine each separate pcap files into one for each day. This is very simple, just do a recursive loop for each day’s logs and merge into one master log per day:
for I in `find /logs/ -type d`;
do
mergecap –w $i-merged.cap *.cap
done;
Determine Data Direction
We want to now begin to look at the pcap files from a very high level, identifying the bytes sent and received. A super simple, yet widely underused, ‘tshark’ command can handle this:
tshark –r <output-path-filename> -qz conv,ip
The output will show bytes in both directions and total bytes. The bytes “<-“ pointing to any IP that is not your internal IP or IP’s in the internal network will show the outbound bytes. For example, can you spot that 179.90.1.133 received more bytes than 10.1.0.238? This is what we look for:
NOTE: Even if it does not appear more data is sent outbound than inbound, do look at the bytes sent nonetheless (for example, if the internal IP sends 500 megs to external source, but external source sent 510 megs). The rule does not always fit, but the internal system is still sending lots of data so I like to threshold at around 25 megs per every hour or two hours – make up your own baseline threshold. Therefore, piping a simple grep along with the ‘tshark’ command can filter results to those matching a data threshold of your choosing. For instance, a simple grep –B 6 ‘[0-9]\{8\}’ would return only those matching a byte count exceeding 20+ megs.
Gather Your Suspects
Last thing: based on the output above across all pcaps, gather your suspect TCP conversations for review; this way we are not trying to analyze every conversation IP’s have inside wireshark (let your IDS replay and IOC’s handle those anomalies), just the ones that are sending data outbound. Really, once you have organized and filtered your data, you can begin to analyze and parse this data in some many ways to meet your objectives – sky is the limit. So, let’s do a quiz then based on this simple approach.
So what am I doing just by reviewing the below stats?
1. Who is likely sending data?
2. Who is likely receiving the data?
3. What data is likely being sent?
Conclusion
End Blog: 02:02pm EST: Time elapsed, 4 minutes, Winner: Blog.