Let’s briefly review what we accomplished in the first post:
- Understood the capabilities and design of MIDAS
- Deployed MIDAS on a Mac OS X endpoint
- installed the MIDAS plugin in AlienVault USM
- Verified the integration by running MIDAS and confirming the events in the SIEM
How does this make us safer? More generally, what does this mean?
To answer these questions we need to understand what plists and kexts mean from a security perspective.
Plists
Property list files contain configuration data for a variety of system components including applications, volumes, sessions, daemons, etc. Plists use the XML format but can also be binary. Often, malware and exploits leave behind traces of evidence in the form of plists. An attacker that wants to achieve persistence on your system will likely need to create or modify a plist to do so. Monitoring new, changed, and removed plists has a variety of uses:
- malware infections
- exploits
- company policy violations
- behavioral analysis
Kexts
Kernel extensions (kext in Apple lingo) are code libraries that get attached to and run in kernel mode. Legitimate kexts are often device drivers for external hardware. Due to their privileged execution and direct access to the kernel, kexts are important to keep track of from a security perspective. While there aren’t a wide variety of use cases for kext monitoring, the few that exist are of great importance to organizations that take security seriously:
- rootkit detection
We can define directives to detect all the behaviors above. Plists (and kexts) provide an opportunity to identify known malicious characteristics and detect the infections automatically. In fact, you can define more complex cross-correlation directives that correlate a MIDAS event with a Snort event, or any other data source USM has access to.
Now that we understand how MIDAS can help us detect malware, let’s look at a concrete example. I will be working with a piece of malware called OSX/leverage.a (VirusTotal) that one of my teammates recently did a blog post on, so the hard work is finished. OSX/Leverage.a has allegedly been used recently by the Syrian Electronic Army in phishing campaigns. Looking at his work we can see the C&C relies upon a plist to achieve persistence. That’s a perfect place to start, because MIDAS can detect new plists being added to the system. The plist it will create is:
~/Library/LaunchAgents/UserEvent.System.plist
We can use the FIND: method in the userdata1 value to match on the plist name. So here’s a correlation rule to detect the OSX/Leverage.a malware:
<directive id="41073" name="MacOSX Malware detected - Leverage.A" priority="10">
<rule type="detector" name="test" reliability="5" occurrence="1" from="ANY" to="ANY" port_from="ANY" port_to="ANY" plugin_id="1987" plugin_sid="8" protocol="ANY" userdata1="FIND:UserEvent.System.plist"/>
</directive>
The relevant fields are name — the alarm name to use when triggered, plugin_id and plugin_sid — taken from alienvault_integration/midas.sql, and the expected value for userdata1. We can add this directive in Configuration > Threat Intelligence > Directives > AlienVault Malware:
Back at the top of the page, you can run ‘Test rules’ to make sure your newly defined correlation directive is valid. Run MIDAS once to process the baseline for the system before the infection. You should see the events come through in the SIEM. Now we can infect the OS X system. Let’s unzip the sample and open the malicious image:
Now if we run MIDAS again and watch syslog on the USM instance, we will see MIDAS properly detects the plist created by the malware. Here is the exact log line that serves as evidence of a system compromise, which we've built out correlation directive to trigger on:
Feb 22 06:32:12 r00ts-Mac.local launcher.py[517]: 2014-02-22T14:32:11-0800 r00ts-Mac.local ty[example_analyzeplist]: ty_name="plist" keepalive="None"hash="e27cd6bee4f1e6e8661b7bc1911053045cf23f44"date="Sat, 22 Feb 2014 14:32:12"runatload="None"name="/Users/r00t/Library/LaunchAgents/UserEvent.System.plist"
This gets imported into the SIEM and we can confirm the fields have been populated properly:
Now if we navigate to Analysis > Alarms, we will find our alarm was generated:
If we click ‘View Details’, we will get more info about this alarm:
The last step to deploying MIDAS is configure it to run as a LaunchDaemon. This will enable MIDAS to run on a scheduled basis (currently set to run every 60min). To do this, we will add a property list (plist) to the ~/Library/LaunchDaemons/ directory. We have provided a plist that you can use, but you should never install a plist from an untrusted source without scrutinizing it. The plist is located at
alienvault_integration/com.labs.alienvault.midas.cron.plist
Take a look at the plist we've provided, you may need to edit the paths to the executables in the plist and runscript. Once you are confident in what the plist does you can install it on your system.
Resources
loading and unloading a plist
converting a plist from xml to binary
