I run this SOC!

Credit to Author: dmitryc| Date: Tue, 05 Sep 2017 19:35:20 +0000

Want to get paid for a vulnerability similar to this one?
Contact us at: sxsxdx@xbxexyxoxnxdxsxexcxuxrxixtxy.xcom

I don’t actually run this SOC (or any other) πŸ™‚ But…but, as a certified “blue team” member, I’m pretty excited with the crop of new companies and ideas that are springing up in the area of SOC analysis, Deception technology, Lateral/external movement, etc. Some of the cool new(ish) vendors that I am falling deeply in love with will be briefly enumerated below…If I was running a SOC, here are some vendors (or technologies) that I would have to add on top of the existing players (centralized logging, scan vuln data, IDS/IPS data, firewall/proxy data, etc.)

Awake Security. While I have not demo’ed their stuff (yet), I have reached out and chatted with them a bit. What do they do, you ask? Well, they aggreate and shrink down your SOC data to what really matters. They have some demo videos on their web site that show their tool in action. Imagine if you could take all your internal user data and find the machines that are worth taking a deep dive into. In a previous life, I had 30k internal users and I had to prioritize which ones were worthy of a second (or third) look. This is that tool. This is the automation that you absolutely must have as networks *EXPLODE* with BYOD, IoT, SCADA/ICS, etc. machines.

Cymmetria. I have demo’ed their community edition. Cymmetria is a Deception technology that allows you to spin up virtual machines in minutes. You can deploy these virtual machines in your network, on the edge, in your DMZ, in your data center, wherever you need to…If an attacker (internal or external) attempts movement across these machines, they will be sucked into a virtual honeypot that allows the analyst to ID the attacker and see their methods. This can then be used to develop IOCs that can be deployed across IDS/IPS machines. If you’re not running some deception technology on your network today, you need to do so immediately. Also, in this space is Thinkst (Thinkst) Canary tokens and a bunch of other vendors. I, personally, like when vendors give back to the community. Vendors like Cymmetria and Thinkst do this today.

Cryptonite NXT. No demo of this product (yet). What do they do? In a word (well, 3 words) – “lateral movement detection”. So, I’ve blogged about it before but there are the well-known steps of compromise. Infiltration (spear phish, remote exploit, whatever), local beach head (embed yourself on a system and hide, basically), recon (find your next target), move (exploit your next target and repeat). Ideally, we block the Infiltration phase and don’t have to worry about the rest. In truth, steps 1 and 2 are going to happen – prepare yourself for the inevitable. Cryptonite NXT tells you when an internal player is attempting recon and/or exploitation. Unlike a honeypot, you don’t have to wait for the intruder to happen upon your honeypot, you detect this passively via the network. I don’t have details on how they do this, but if I was doing it I would learn a set S of valid IP:PORT services on a network and then just flag on !S. It sounds simplistic, but, really, how many organizations can even define S????? And, these same organizations then want a report on anomalous traffic. You need to know what is valid before you can know what is invalid. Knowing S and alerting on !S is very simple and very useful.

So, if I was running a SOC, I would have to add the 3 technologies from above. All 3 of these would ease the work load of my analysts. I don’t need them chasing down every flow that looks funny. Or, G-d forbid, have them looking through flows manually to “find the needle”. I need some supporting data that gives me a confidence that the machine that is under investigation has a high probability of being a high-value target. Nothing burns you out quicker than going through 100 tracefiles only to find one (or none) of interest.

What else would I like to see? I know there must be some vendor who does DNS IR work. I should look at them closer. DNS data coupled with traffic flows is very, very useful, imo. As a simple example, show me all the IPs that connected off-network without a DNS lookup. That’s interesting data. For kicks, I threw together a tool using libpcap that does this. This led me to an app that kept calling out without a DNS lookup (Zoom video). Examining closer, it appears that whenever I crank up a zoom video call, there is an attempt to connect to the RFC1918 IP of the person who is hosting the call. So, not a security flaw (well, it also passed out what appears to be a license ID in plain text…) but that is interesting…that is the kind of data that I would like to see. Also, stuff like short time-to-live DNS records, hostnames that are quickly changing IP, hostnames that fit into a DGA format, etc. etc. There’s a bunch here, and I hope that if such a tool exists, someone will ping me on that. Oh, and one more thing on DNS. DNS is kind of like road signs. For a valid internal client, DNS instructs them where to direct their traffic. Most valid internal users aren’t memorizing IP addrs or building out their own hosts file. Most people, on a day-to-day basis, connect to hostname.server.corp.whoever under the covers. Internal apps use FQDN. What if???? WHat if I could automate flipping these FQDN/IP addrs around? What if on Monday at 9 AM foo.server.com points to 192.168.1.1 and then Tuesday at 9 AM, foo.server.com points to 192.168.2.1 and 192.168.1.0/24 now points to a honeynet???? valid users shouldn’t have an issue with this. THey are using foo.server.com and DNS. An attacker is probably building a lateral movement ‘target list’ based on IP addr. If you suddenly change the road signs around, the folks who are actually driving don’t have a problem – the folks who have hard-coded a path to server will now be parked in a bog. Of course, goes without saying, don’t try this on hosts where long, nailed-up connections are the norm and also do this in a change control window, blah blah…be safe…

Salesforce recently released their JA3 hashing algorithm. See blog post here. That’s very interesting as well. Imagine you have a server farm of critical machines. Imagine that you can passively watch this cluster and analyze all the JA3 hashes that the server uses when connecting out. This should be a small list of hashes. I don’t expect a lot of change there. Now, I want to see an alert when there is a new JA3 hash for any of these servers. For kicks, I also wrote a quick tool in libpcap that passively sits and maintains a chain of all detected JA3 hashes on a small network. For days, I didn’t have a single alert. THen, one day, it went crazy with new hashes. Well, turns out that a server had done a Chrome update and those new JA3 hashes were all related to that update. Again, not a security alert, but really, really good info. And, if one of those servers did get infected and connected out to C2 over TLS, boom there’s my new JA3 hash and I can pivot on the server and start pulling in the related info. That’s good data.

I have a lot more thoughts, but this blog post is already getting out of hand πŸ™‚

Lastly, I’m dipping my toes into the job market next month (October 2017). If anyone is looking for a “blue team” member, please don’t hesitate to ping me at dmitry.chan@gmail.com . I’m like a super chill, very helpful, very passionate team mate … but, I’m biased πŸ˜‰

Peace,

!Dmitry

Print Friendly, PDF & Email

https://blogs.securiteam.com/index.php/feed