The Flashback trojan has been all over the news lately, but it is not the only Mac malware threat out there at the moment. A few weeks ago, we published a technical analysis of OSX/Lamadai.A, the Mac OS X payload of a multi-platform attack exploiting the Java vulnerability CVE-2011-3544 to infect its victims. OSX/Lamadai.A has built-in features typical of a backdoor: namely download and execution of an arbitrary file, uploading of local files to the operator’s Command and Control (C&C) server, and spawning of a command-line shell.
After the technical analysis was done, we began the monitoring phase. This phase is very important because it allows for tracking of how the malware is used by its operator. We can catch new variants of the threat early on, or even a totally different malware family (as often seen in pay-per-install schemes), or see the operator launch Denial-of-Service attacks (or any other kind of malicious activity) from the infected systems.
The monitoring phase allowed us to witness a short, live dialog between our infected machine and the malware operator that we published this dialog in our initial analysis of OSX/Lamadai.A. This experience gave us some new ideas that we could put in place in order to gather more knowledge about this threat and the person or people behind it.
What we did is this: we planted some fake files in the home directory of our test “infected user” and waited for the operator to come back. About one week later, we got our first connection. Here are the highlights of the dialog that took place over a period of about 10 days. It started with a little reconnaissance in the ~/Documents directory. The Unix command ls is used to list directory content:
Then we see the theft of some Tibetan army status documents and a little porn for added value.
Now more reconnaissance and file theft, this time in the ~/Downloads directory.
It is quite interesting to see that the operator did not steal all the files we had put out for him. He left these three untouched:
- 2012_report.doc
- application.zip
- im5744.jpg
A few days went by during which the operator was only connecting to the system to issue some basic commands, most likely with a view to determining whether this was a newly infected system or not. The Unix command id returns the current user's identity and the sw_vers command prints the OS version information.
We decided it was time to refresh the environment to simulate infection of a new user and to install interesting new files to the user’s home directory.
Shortly after the new environment was up and running, we got an incoming connection. Almost instantly, the operator issued a command to download and execute a file (technical details of the new file below)!
Immediately after, the operator ran a few netstat commands, most probably looking to see if the new payload was listening on the network properly. The Unix command netstat displays the network status of the system, such as network connections and routing table.
Not seeing what he wanted to see, our operator tried to re-execute the dropped executable! Let’s see how that turned out:
Yes, you do have to specify the path to the executable when /tmp is not in $PATH. In despair, he attempted to take some screenshots of the entire desktop window, using the OS X ‘screencapture’ command. Oddly enough, the file was not saved in his current work directory as it should have. We can’t explain why that happened.
Then, a few connection attempts later, the operator logged back on and totally lost it. He issued two Unix ‘rm’ commands, used to remove directory entries: one to remove the user’s home directory and one to remove the system’s root directory.
That concludes this dramatic episode of Monsieur Frustrated Operator. Now to some technical stuff.
One of the first things we did was to recover and analyze the Mach-O executable dropped onto our test machine. We were curious to see what that was: a new variant of OSX/Lamadai, or even a specialized new piece of software? Instead, we found it was the same variant of OSX/Lamadai with a hardcoded C&C server set to 127.0.0.1. This explains why the operator grepped his netstat output for “127.0.0.1”. However, the rationale behind this action is up for debate inside ESET’s Security Intelligence Laboratory. Some argue that the operator realized he was connected to a monitoring system instead of a real, infected one and wanted to redirect the traffic away from the real C&C. Others contend that it would have been easier for him to simply deactivate or remove the malware from the system.
Also, when we first analyzed OSX/Lamadai.A, we said that the malware did not have persistence capabilities on an OS X 10.7.2 system, as the path /Library/Audio/Plug-Ins/AudioServer was not user-writable. We looked a little deeper into this, as other researchers reported that the threat was indeed persistent on their machines. We realized that this very same path is user-writable in previous OS X versions (10.5/Leopard and 10.6/Snow Leopard). This is the cause of some potential confusion and a timely reminder of the benefits of upgrading to the latest version of OS X.
Credits go to Marc-Étienne M. Léveillé for the technical analysis and test environment setup, thanks to the usual suspects for reviewing and commenting this article.
MD5 of the dropped executable: 46c8ca78af43012388936345336d203b
Alexis Dorais-Joncas
Security Intelligence Team Lead
