How the Gigamon SOC Responds to Attacks Like WannaCry and NotPetya

When the Wannacry ransomware outbreak happened in May, the Gigamon Security Operations Center (SOC) responded on several fronts. Our first step was to collect accurate technical analysis of the malware. Often, there’s a lot of FUD and guesswork at the beginning of these incidents, and acting without understanding the threat can cause you to make mistakes, break things and think you’re secure when you’re not.

Once we’d read credible analysis, we went to our runbooks and started down the path to securing the network. We opened tickets to our IT department with links to MS17-010 and requested they apply emergency patches on all the servers. We had them confirm they were not running SMBv1 and that no SMB was allowed past the firewall.

We then did a quick check to see if any of our servers would respond to SMBv1. We scanned our networks with NMAP using smb-vuln17-010.nse, made a change to our Splunk inputs.conf and started indexing traffic matching dest_port = 135, 139 and 445 to catch scanning. We also looked at our IPFIX URL data to see if any hosts had tried for the kill switch domain. Once we were patched and felt good, we went back to work.

Same Procedure as Last Time

When the next salvo, NotPetya, was spotted, we followed the same procedure. We waited for good data and responded. This time, the attack looked a little more serious because when one machine is infected, the malware dumps a part of memory that can hold cached administrator credentials. With those credentials, the malware can – and does –  wreak havoc.

Fortunately, we had taken the first outbreak seriously and while we felt good, there’s zero room for complacency in the SOC. To monitor for this attack, we turned to our GigaVUE-HC2 and Bro. We were already sending traffic to Bro, but we wanted SMB. I’m not a big believer in scanning things – it’s too easy to miss something. I’d rather take the sum total of all network traffic and look in that. Fortunately, I’m the CISO at Gigamon and get to do that here.

For this, the team enabled the SMB policy that ships with Bro. My hope was that it would look at the traffic and call out SMBv1 versus SMBv2 or 3, which indeed it did.

To enable SMB:CmdInfo in your Bro instance head to: /bro/policy/protocols/smb/main.bro and changing line 161 F to T “const write_cmd_log = T &redef;”

So, what did we find? Three machines on the network – two 2 end-user machines and one server on the DMZ – were speaking SMBv1! Turns out the machine on the DMZ is a Linux box running Samba. We submitted tickets to get the affected Linux boxes patched and have SMB1 turned off.

For more information, please read the Microsoft Malware Protection Center blog “New ransomware, old techniques: Petya adds worm capabilities,” which provides a technical analysis of the malware.

Stay safe out there.