Do you like your Cisco ASA with a side of ExtraBacon ?
There was a little ruckus on the internet last week about some tools that may or may not be associated with Equation Group. Regardless of their origin, some of those tools were tested and were confirmed to do be effective. I figured that it might be an interesting training exercise to see what could be done with NetWitness packets to locate one of those exploits called ExtraBacon (which now has a Cisco CVE).
Hunting the internets for a suitable PCAP, I found one here to test with: xorcat: equationgroup
wireshark looks like this and matching the description from the blog post from xorcat we can see that the first 4 are the probe and auth disable and the last two are the auth re-enable.
Taking that pcap and writing an import script to replay it into my packet decoder to so I could see what it looks like got me this which relates to the first two line in wireshark.
So lets turn that into an application rule to warn us when we see those three snmp.oid values being queried together along with get and response actions.
snmp.oid='220.127.116.11.18.104.22.168.0' && snmp.oid='22.214.171.124.126.96.36.199.0' && snmp.oid='188.8.131.52.184.108.40.206.0' && action='get' && action='response'
and for the second two lines in the wireshark output
action='get' && action='response' && snmp.oid='220.127.116.11.18.104.22.168','22.214.171.124.126.96.36.199.4188.8.131.52.184.108.40.206.220.127.116.11.18.104.22.168.22.214.171.124.126.96.36.199.188.8.131.52.184.108.40.206.220.127.116.11.18.104.22.168.22.214.171.124.247.165.165.165.126.96.36.199.188.8.131.52.0.4.53.255.184.108.40.206.220.127.116.11.144.144'
Add those to your packet decoder, alert into a metakey of your choice (I used alert)
Run the pcap, and check for output into the alert metakey for hits on the application rules
So it looks like we now have something to alert on for this potential exploit. Hopefully your SNMP and admin is done via a segmented management network which helps to mitigate this threat but if you don't....
What if we wanted to take this and use ESA to create a correlation rule to take these application rules and link them together ?
which looks for the probe snmp command followed by the exploit snmp command for the same ip.src within one minute. You could choose to alert as a cef log message to either NetWitness Logs or another SIEM product for further correlation, alerting or archiving.
How have you implemented alerting for this expoit ? discuss below ...
- Community Thread
- Forum Thread
- RSA NetWitness
- RSA NetWitness Platform
Great post Eric.
I have just added this to a production system and will update if I run across any hits.
I would point out to others looking to implement these alerts, you need to make sure you have the SNMP_lua parser installed from Live as well as making the snmp.oid key searchable by adding the following to your index-concentrator-custom.xml file on your concentrator(s):
<key description="SNMP OID" level="IndexValues" name="snmp.oid" format="Text" valueMax="1000000"/>
SNMP OID only needs to be indexed at values if you want to do drills and perform more than exists type queries (snmp.oid = 18.104.22.168.5 for example). For this use case the application rule doesn't require that key to be indexed to perform the matching on those particular OID values.
That is the beauty of application rules, you can access and perform logic on keys that are otherwise not indexed (and maybe for good performance reasons you wouldn't want to index certain keys that might be useful for specific application rules).