Thanks to Gabor Szappanos of SophosLabs for his work on this article.
You may have heard or seen mention of the latest catchily-named malware attack: “Sandworm.”
The name is rather dramatically borrowed from the famous 1960s science fiction epic Dune, where it refers to a sort of worm-like creature, hundreds or even thousands of metres long and as good as indestructible except with nuclear weapons.
In the current context, the name applies to a strain of malware, announced with fanfare by a security company that claims to have seen it used recently in the wild in targeted attacks.
These attacks are said to have been “used in [a] Russian cyber-espionage campaign targeting NATO, European Union, Telecommunications and Energy sectors.”
The attack relies on a vulnerability in Windows known as CVE-2014-4114, patched in Bulletin MS14-060 of Microsoft’s October 2014 Patch Tuesday.
That makes the attack used by Sandworm a so-called zero-day exploit, because the vulnerability was first exploited before a patch was available.
→ The terminology “zero day” refers to the fact that there were zero days that you could have been patched in advance.
Combine a zero-day exploit and claims of Russian espionage with a catchy name and an all-devouring logo and you have a magnetic-sounding story.
Fortunately, the Sandworm malware is a lot easier to deal with than its interplanetary annelid namesake.
In fact, in malware terms, it’s not a worm at all.
Here’s what you need to know.
How Sandworm arrives
The malware travels in a Powerpoint file that refers to an .INF file, where INF is the Windows extension given to a special sort of information file used during software setup.
INF files were once a fruitful vehicle for malware authors, thanks to a special file named AUTORUN.INF that could be used on removable drives such as USB memory sticks to specify a program that would run automatically when the drive was plugged in.
AUTORUN.INF files are no longer allowed to run programs automatically, however, so that risk has as good as vanished.
But INF files can still be used for installation-oriented tasks such as putting files into place (and optionally renaming them), and setting entries in the registry.
That’s enough to install malware that will run later on, even if it’s not sufficient to infect your computer right away.
How Sandworm works
In the Sandworm attack, the malicious Powerpoint file that kicks things off actually refers to an INF file with a remote filename, using a UNC path.
→ UNC paths are those special Windows filenames that include a server name, not just a drive letter and a directory name, such as \\SERVER\SHARE\FILE.TXT for servers on your own network, or \\198.51.100.5\REMOTE.DAT for a file located by IP number.
Windows is supposed to block applications like Powerpoint from sucking in and launching external files in this way, for obvious security reasons, but the Sandworm attackers found, or at least acquired, a vulnerability that made it possible anyway.
In the attack, the malicious Powerpoint file pulls in two files from a remote server that combine to deliver the malware payload.
The files have the innocent-looking names slides.inf and slide1.gif, as though they were part of the presentation itself.
But slide1.gif is actually an executable (program) file, and slides.inf is an installer file that renames slide1.gif to slide1.gif.exe before adding a registry entry that will run the offending program when you next logon.
In other words, even without the ability to run a program directly, the Powerpoint-INF-and-GIF cocktail is enough to install a program that will run later on.
Even though the malware itself is not embedded inside the malicious Powerpoint file, it is fetched in what is often called a drive-by install – one that happens without any pop-up dialog or warning that would let you stop it by choice.
What to do?
Unlike the sandworms of the desert planet Arrakis in the Dune saga, you don’t need high explosives, or disk-wiping tools, to counteract this threat.
Applying Microsoft’s MS14-060 patch will close the hole on which this vulnerability relies.
Additionally, security products can:
- Identify booby trapped files that exploit the vulnerability, thus preventing them from opening in the first place.
- Block the “call home” traffic used in known attacks in order to prevent payload code or data from being retrieved, even on unpatched computers.
Sophos products detect and block “Sandwormed” Powerpoint files as Troj/20144114-A. The slide1.gif malware file referred to above is blocked as Mal/Generic-S. The servers used in the “call home” of the attack are also blocked to prevent the download of any other malware that might be published there.
If executable files were blocked at the edge, by say a Sophos UTM, would they be blocked based on content of the file rather than the file extension? And then this would have been mitigated before it has the opportunity to install.
Yes.
We recognise EXE files by their internal structure (believe it or not, they still start with the bytes “MZ”, for Mark Zbikowski, the Microsoft coder who invented the original EXE file format for DOS back in the 1980s :-). Same thing for PPT, PPTX, PDF, PNG…the list goes on.
We can’t rely on the name – it might be deliberately tweaked by a crook, like here, or it might be a machine-generated temporary name, e.g. for an encoded attachment, that gets replaced after the file is downloaded.
“Magic bytes” can also be obfuscated by the malware; having Z9 rewritten to MZ on the way down to disk. This would be evident in the RE on the malware itself at some point. Could be a sneaky way to obfuscate file-level monitoring content decisions on proxies or DLP/IDP at edges that observe file contents.
True. But then you need fairly general purpose malware or shellcode already running to do the deobfuscation at the end. (If you can do that, you can scramble the thing unrecognisably. Or, as some malware does, encrypt it with a private key. That way, no-one else can feed malware to the downloader…Hybris from about AD2000 was the first malware I remember doing that.)
Always enjoy these articles by you Paul. You make it insanely easy to understand what’s going on. Essentially… Who, What, When and Where.
Very informative.
Thanks Paul.
May I know which IDE file contains this detection? I should ensure of it… Thanks a lot!
I don’t know off the top of my head…I can probably find out, but I am always reluctant to say “make sure you have this one IDE more than any of the others” because if *any* are missing, it means that your updating is broken, and that’s much worse than not being able to detect this one piece of not-very-often-seen malware.
Have you successfully updated since the article was published? If so, you will have the relevant IDE because (rather obviously 🙂 it predates the article.