The anatomy of Flashfake. Part 1

What is Flashback/Flashfake?

It is a family of malware for Mac OS X. The first versions of this type of threat were detected in September 2011. In March 2012 around 700,000 computers worldwide were infected by Flashback. The infected computers are combined in a botnet which enables cybercriminals to install additional malicious modules on them at will. One of these modules is known to generate fake search engine results. It is quite possible that, in addition to intercepting search engine traffic, cybercriminals could upload other malicious modules to infected computers – e.g. for data theft or spam distribution.

The zero phase of the infection: hacked WordPress blogs

From September 2011 to February 2012, Flashfake was distributed using social engineering only: visitors to various websites were asked to download a fake Adobe Flash Player update. It meant the Trojan was being distributed as installation archives named “FlashPlayer-11-macos.pkg”, “AdobeFlashUpdate.pkg”, etc.

The use of exploits to distribute Flashfake was first detected in February 2012; exploits dating back to 2008 and 2011 were used in those attacks. Exploitation of the CVE2012-0507 vulnerability was first reported in March 2012. At that point, it was a vulnerability in Mac OS X that remained unpatched, despite the fact that Oracle had released a patch for it in February. This was because Apple never uses patches from Oracle and creates its own patches to close Java vulnerabilities. The patch for Mac OS X which closed the CVE2012-0507 vulnerability was released in early April.

This practice of releasing patches with delays of about two months is traditional for Apple.

Vulnerability Patch from Oracle Patch from Apple
CVE2008-5353 14 April 2009 15 June 2009
CVE2011-3544 18 October 2011 8 November 2011
CVE2012-0507 14 February 2012 03-12 April 2012


In order to spread Flashfake in March 2012, its authors made use of a cybercriminal partner program that appears to be of Russian origin.

The partner program was based on script redirects from huge numbers of legitimate websites all over the world. Around the end of February/early March 2012, tens of thousands of sites powered by WordPress were compromised. How this happened is unclear. The main theories are that bloggers were using vulnerable versions of WordPress or they had installed the ToolsPack plugin. Websense put the number of affected sites at 30,000 , while other companies say the figure could be as high as 100,000. Approximately 85% of the compromised blogs are located in the US.

Code was injected into the main pages when the blogs were hacked. Constructions of the following type were added to the code (example):

As a result, when any of the compromised sites were visited, a partner program TDS was contacted. Depending on the operating system and browser version, the browser then performed a hidden redirect to sites in the domain zone that had the appropriate set of exploits installed on them to carry out an infection.

Site code on WordPress with a link to a malicious script

The first phase of the infection: drive-by-downloads and social engineering

During hidden redirects (example: hxxp://, the browser accessed folders /3f/ or /7f/ on the malicious website and executed JavaScript which loaded a Java applet.

Here is an example of one script:

if(rts != “on”){
document.write(‘ height=”1″>’);
document.write(‘ width=”1″ height=”1″>’);

The attack involved an attempt to execute four Jar files (Java applications). Three of these were exploits for Java vulnerabilities; the fourth was disguised as a legitimate application, with social engineering used to deceive victims.

Vulnerabilities exploited:

Each Jar file contains an exploit for one vulnerability and a malicious executable file that is extracted and installed on the system.

Code fragment in CVE2008-5353 exploit

Code fragment in CVE2011-3544 exploit

Code fragment in CVE2012-0507 exploit

If exploitation is unsuccessful, an attempt is made to infect the system using a specially crafted Java applet which tries to pass itself off as a legitimate file signed by Apple in order to get the user to grant it the rights necessary for installation.

This method of distributing Flashfake was discovered in February 2012.

The attackers rely on the user granting the application system access rights because it says it is signed by Apple. The file does not in fact have Apple’s digital signature: the certificate was forged by cybercriminals.

Fragments of code in the fake certificate

If the user agrees to grant the rights requested by the applet, a malicious file will be extracted and installed.

Fragment of code in the fake applet

Thus, the execution of any one of the four applets described above (those containing exploits or the one requesting rights from the user) in the browser will result in the installation of a container file which operates as a downloader and installer for the remaining Flashfake components.

The file is installed to /tmp/.sysenter and launched (when the exploit for CVE2012-0507 is used, a random file name is generated).

Diagram showing the first phase of the infection

Second phase of the infection: first-stage downloader

The file installed in the system is a container in Mach-O binary format, containing either a 32- or 64-bit module – both versions having practically identical functionality.

The module’s main function is to establish communication with the first-stage C&C server, download additional modules from it and install them in the system. Upon completing these functions, the module deletes itself and does not reappear on the infected system.

When it launches, the module checks if the LittleSnitch app (a popular firewall for Mac OS X), XCode (toolkit for developing OSX applications), the,, avast!.app, and antivirus applications, or the and Packet apps are present in the system. If any of these are present, the module ceases operation and deletes itself.

Otherwise, the module connects to one of the C&C servers (e.g.,, communicates the victim computer’s UUID (universally unique identifier) and additional information about the system (version of the OS). In return, it receives a data package containing two additional components encrypted with a key based on the computer’s UUID.

Fragment of the module’s code listing the applications to check for, and the C&C URL

After the data package is loaded, the module extracts component files from it and attempts to install them in the system:

Flashfake’s operation flowchart at the current phase of the infection

The backdoor downloader is the first component to be installed. It is the main bot module responsible for ensuring further interaction with the botnet and the downloading of updates.

The installer saves the body of the backdoor with an arbitrary name (beginning with a dot, e.g. ‘.null.’) to the root partition of the user’s $HOME/ folder.

The installer also creates the file .plist (see below) to ensure the backdoor’s further operation:

Example of a .plist file

This file is installed in $HOME/Library/LaunchAgents/. This ensures that the backdoor’s module is automatically loaded each time the system is started.

Flashfake’s operation flowchart at the current phase of the infection

The second component installed from the Internet intercepts web traffic and substitutes pages in the browser.

The installation procedure for this module has changed significantly in the latest version of the Flashfake installer, which propagates via the CVE2012-0507 vulnerability. See below for a description.

Fragment of the installer’s code

The installer invokes the system function to request administrator privileges and waits for the user to insert the login and root password.

Request for administrative rights

If the user enters the required info, the installer is able to open for write the browser application (Applications/ and save the module to it that intercepts traffic and substitutes pages and a second module that launches the first module in the browser process. The names of these modules are chosen randomly, but all start with a dot and end with the .png and .xsl extensions.

To ensure the modules are launched automatically, the installer modifies the contents of the file /Applications/, adding the following strings to it:



If these actions are successful, the installer connects to the C&C at, for example,, thus notifying about the successful completion of the operation. If there is an error during installation, the connection will be made to, for example,

Once these operations are completed the installer restarts the Safari browser in order to activate the modifications, ceases its operation and deletes itself from the system.

If the user does not enter the administration login and password, and presses “Cancel”, the modules will be installed using a different method.

The installer first checks the system for the following applications:, MicrosoftOffice 2008, Applications/MicrosoftOffice 2011, and If they are found, the installer ceases its operation and deletes itself from the system.

The traffic interception module is then installed to /Users/Shared/ under the name .libgmalloc.dylib.

Before this, the installer deletes files from this folder using the command rm -f /Users/Shared/.*.so. This removal operation is most probably intended to delete any earlier versions of Flashfake that are present in the system.

The installer then creates the file $HOME/.MacOS/environment.plist and saves the following strings to it:


As a result, the module will be hooked and loaded to every launched app.

Another auxiliary component will be installed to the user folder $HOME/Library/Application Support/ under a random name which starts with a dot and has a .tmp extension.

The operation flowchart at the installation stage of the web traffic sniffer module

Once the installation is completed, the installer connects to the C&C at, for example,, informing about the successful infection. After this the installer ceases its operation and deletes itself.

Continue to Part II…

The anatomy of Flashfake. Part 1

Your email address will not be published. Required fields are marked *



Lazarus targets defense industry with ThreatNeedle

In mid-2020, we realized that Lazarus was launching attacks on the defense industry using the ThreatNeedle cluster, an advanced malware cluster of Manuscrypt (a.k.a. NukeSped). While investigating this activity, we were able to observe the complete life cycle of an attack, uncovering more technical details and links to the group’s other campaigns.

Sunburst backdoor – code overlaps with Kazuar

While looking at the Sunburst backdoor, we discovered several features that overlap with a previously identified backdoor known as Kazuar. Our observations shows that Kazuar was used together with Turla tools during multiple breaches in past years.

Lazarus covets COVID-19-related intelligence

As the COVID-19 crisis grinds on, some threat actors are trying to speed up vaccine development by any means available. We have found evidence that the Lazarus group is going after intelligence that could help these efforts by attacking entities related to COVID-19 research.

Sunburst: connecting the dots in the DNS requests

We matched private and public DNS data for the SUNBURST-malware root C2 domain with the CNAME records, to identify who was targeted for further exploitation. In total, we analyzed 1722 DNS records, leading to 1026 unique target name parts and 964 unique UIDs.

Subscribe to our weekly e-mails

The hottest research right in your inbox