Venator vs Recent macOS Malware

I want to demonstrate some of the data provided by Venator and how it fairs against recent macOS malware. This will show how the data assists in finding malicious activity, along with providing the additional context needed to start triage in the event something noteworthy is found.

OSX.WindTail

Below is a snippet of Venator’s output after it was run on a host infected with OSX.WindTail.

Note: Venator provides signing information for each application. “Unsigned” will appear if the application is unsigned, ad-hoc signed, or if the certificate has been revoked.

WindTail is associated with the APT group WindShift, who uses custom URL scheme handlers to trick users into installing and opening malicious applications. One such application is Final_Presentation.app which persists as a Login Item. Venator provides the name of the application, its associated executable and the hash of the executable via the “login_items” module. During a hunt you might determine that Final_Presentation.app is a weird name for an application designed to start upon user login. You then pivot off of the hash, which takes you to the following virustotal result: https://www.virustotal.com/#/file/ceebf77899d2676193dbb79e660ad62d97220fd0a54380804bc3737c77407d2f/detection

Let’s take a look at another example, one more in-line with a common mac malware technique.

OSX.AppleJeus

OSX.AppleJeus is associated with APT Lazarus Group. The application is disguised as a cryptocurrency trading application and serves as the 1st stage of their implant. CelasTradePro.app persists via a Launch Daemon, mapped back to an executable by the name of “Updater” with a label of “com.celastradepro”. This is visible via the launch_daemons module and is sure to stick out when grouping all Launch Daemons across a fleet and conducting least frequency analysis. A pivot on the hash of Updater confirms that the application has a negative reputation and is likely malicious. https://www.virustotal.com/#/file/5e54bccbd4d93447e79cda0558b0b308a186c2be571c739e5460a3cb6ef665c0/detection

Because infection involved application installation via a package, Venator also provides details about when the application was installed through the the install_history module.

Example of Venator’s logs being pushed into a SIEM

Once Venator is executed, you’re then able to ingest the resulting JSON file into the SIEM of your choice. For example, if you are using HELK or something similar, you can use Filebeat to ship the log(s) to Kafka and through the pipeline to Kibana.

An ideal scenario for enterprise use would be to run Venator, specifying a directory to output the JSON file. Your log shipper could then monitor the directory specified for your .json files. You may also decide to run Venator on a continual basis which could be done by creating a cron job, for example.

Future Work

Ability to run specific modules as needed. Currently, all modules are run.

Support for direct JSON upload to S3 bucket.

Additional artifacts: Document/URL handlers, startup items, bash profile, files in /tmp and Downloads folders.

At Bsides Charm 2019, I’ll be presenting on Venator in more detail, expanding on various modules and how the data provided can be useful in hunting engagements.