To Patch or Not to Patch? The Story of a Malicious Update

While it’s unlikely that Shakespeare had patching in mind when he penned “to be or not to be”, I started thinking about this seemingly simple question the other day when I heard about a recent Microsoft out-of-cycle patch (which means that Microsoft pushed out a critical patch outside of its regular “patch Tuesday”). Patching is always a good idea, but not all patches are created equal - especially if they are received via email.  Those are most likely always malicious.  Since some readers of this blog may not have experienced this first-hand, I’d like to share an example of a malicious campaign with you and explain how a link to a malicious binary, spread via email under the guise of a Microsoft update, can have a catastrophic effect.

The malware link shown below in Figure 1 was spread via an email phishing campaign that purportedly had a cyber spin to it.  In the body, the email notified the recipient that an urgent update was necessary and included a hyperlink to a nefarious link, and the link still hosted the malware so it was easy to obtain for analytical purposes.  It’s important to note that while I’m not at liberty to disclose the actual email, the malicious link was reported by urlquery.net, an online service for testing and analyzing URLs for malicious content, making an excellent resource for researchers (portions of the link have been redacted for security reasons).

Figure 1: urlquery.net displaying a malicious link to malware

After obtaining the malicious ZIP file, closer inspection revealed the compressed archive file contained an executable binary named ‘Mse-Security.Update.exe’ (binary icon included below)—and this is where our story begins.

Upon execution of the binary, the unknowing victim wouldn’t notice anything unusual.  However, underneath the operating system’s hood, the story is quite different.  The user probably wouldn’t have been the wiser that several artifacts were dropped on their system to include a persistent executable binary (.exe) along with two dynamic link library (.dll) files on the victim host.  Nor would the user have known it would capture keystrokes, web activity and document all running applications.  Not only that, the user wouldn’t have been aware that the malware was also grabbing screen captures of their desktop, then disseminating all this collected data back to its Command and Control (CnC) server via FTP.  And this is only the beginning.  The real fun comes when we start dissecting this in greater detail.

‘Mse-Security.Update.exe’ is a dropper that drops four files contained within a newly created directory named ‘LMCAEC’.  This directory is created with System Hidden attributes and it resides in the application data directory for all users.  Here is how it appears on Windows XP:

            Figure 2: LMCAEC Directory Tree

The binary PLG.exe is the persistent implant which has a registry RUN key to insure it runs at startup.  It also has a unique icon. Some will recognize this as the Ardamax Keylogger (see below).

Upon execution, it captures, encodes, then writes four different types of stolen data.  Each of these data types gets stored in another directory named IGW.  This too resides within the same all users path.  The contents of these files are continually written to.  Figure 3, below, shows an example of the directory as well as the type of data stored within each file:

Figure 3: IGW Directory Tree

There’s also some network activity, but we’ll look at that in a moment.  First, let’s take a look at the stolen data files.  At first glance PLG.001, PLG.002 and PLG.004 look similar, but obfuscated.  After closer inspection, however, a few things jump out.

The first thing I noticed was the appearance of an every other byte pattern consisting of the same two-bytes (see red highlights in Figure 4).  These turned out to be extra bytes thrown in probably for obfuscation.   These extra bytes begin appearing regularly at offset 0x12, but they also appear in the first dword (or 4-bytes) of the file (also highlighted in red). 

Second was a 2-dword (or 8 byte) separator, or delimiter (see green highlights in Figure 4).  The first dword of the separator consist of null bytes, while the first byte of the second dword contains the length (in hex) of the data segment to follow (i.e. 0x8a = 138; 0x 6A = 106; 0x 4A = 74).  These data segments are the encoded stolen data.  Additionally, with the exception of the first segment, each concluded with a dword bitmask (see black highlights).

More importantly, however, was the encoding key.  The stolen data is encoded with a 2-byte xor key found interspersed with the extra bytes within the first dword of the file (see blue highlights in Figure 4).  Once the extra bytes are removed, this 2-byte key can be applied to decode the data.  I’ll expand upon this in more detail shortly.   

Figure 4: PLG.001 Encoding Schemes (with decoded data)

Scripting a decoder gives you a quick peek at the stolen data from a command line, as shown in Figure 5.

Figure 5: PLG.001 output from a python decoder

Interestingly, analysis of PLG.004 revealed it followed the exact obfuscation scheme of PLG.001, whereas the extra bytes and encoding key were flip-flopped within the first dword of PLG.002.  Figure 6 illustrates this by highlighting their respective ‘xor keys’ in blue and their ‘extra bytes’ in red.  Notice too that these values are different for each file – they are variables created on the fly during run time.  Another interesting piece to these files can be found at offsets 0x11 through 0x21.  Every other byte decodes to ‘Wonderful’ (see highlighted green below—did you spot that previously in Figure 5?).

Figure 6: File Comparison (key in blue, extra bytes in red)

After examining the three files above, I took a quick peek at the config file ‘PLG.00’ in the LMCAEC directory.  It too began with the same encoding scheme described above, but it followed the path of PLG.002 in that the first dword was:  extra byte : key : extra byte : key (see Figure 7).  Moreover, once the file is decoded, two interesting strings appear between offsets 0x121 and 0x14B: ‘a5XXXX64’ and ‘metXXXXXXt85’ (portions intentionally redacted with Xs).  These strings can be seen below in the pop up box in Figure 7, but we’ll come back to them momentarily.

Figure 7: PLG.00 Decoded

First, let’s get back to the files in the IGW directory for a moment.  These eventually have the ‘PLG’ in their name replaced with a date time stamp.  For example, PLG.001 becomes something like 2015-04-08_13-01-23.001.  These files are still encoded as described above; however, within milliseconds of their respective name changes, they are decoded and the contents are added to an html page for exfiltration.  The html page has the same basic naming convention, but the filename is prepended with a ‘flag’ indicating the type of data contained within the html page.  These flags are: App, Keys, Web and Screen.  This means our file ‘2015-04-08_13-01-23.001’ becomes ‘Keys_2015-04-08_13-01-23.html’.  Figure 8 demonstrates their respective naming conventions before and after.

Figure 8: Stolen Data Files (naming convention: before and after)

The html files are then exfiltrated via FTP to the CnC server ‘aymail[.]site11[.]com’ logging in with the credentials: username ‘a5XXXX64’ and password ‘metXXXXXXt85’ (remember those from our PLG.00 file?).  This login can be seen in Figure 9.

Figure 9: FTP Login Session

Once these are pushed to the CnC server, both versions of these files are deleted from the system.  Interestingly, the html files are in the clear as can be seen in Figures 10 through 13, detailing examples of the exfiltrated data.  This data loss could be quite damaging depending on the unsuspecting user’s activity.

Figure 10: Keystrokes by the Victim User

Figure 11: Websites Visited by the Victim User

Figure 12: Applications Used by the Victim User

Figure 13: Exfiltrated Screen Capture of the Victim User’s Desktop

And there you have it – a day in the life of a malicious update; one that updated nothing except the attacker’s stolen data repository.  Before signing off though, I’d like to leave you with a chronological snippet of the malware during runtime.  Table 1 details the dropper and implant along with their respective operations and results.  The chronology is followed by the file identifying hashes of the malware discussed within this post.  Until next time--patch smartly!

Table 1: Chronological Gist of Malware During Runtime

File Identifiers:

If this sort of analysis interests you, check out our Senior Malware Research Scientist position. We are always looking for great malware research talent to join the Endgame team!

https://www.endgame.com/careers/senior-malware-research-scientist-san-francisco