Malicious macro using a sneaky new trick
We recently came across a file (ORDER-549-6303896-2172940.docm, SHA1: 952d788f0759835553708dbe323fd08b5a33ec66) containing a VBA project that scripts a malicious macro (SHA1: 73c4c3869304a10ec598a50791b7de1e7da58f36). We added it under the detection TrojanDownloader:O97M/Donoff – a large family of Office-targeting macro-based malware that has been active for several years (see our blog category on macro-based malware for more blogs).
However, there wasn’t an immediate, obvious identification that this file was actually malicious. It’s a Word file that contains seven VBA modules and a VBA user form with a few buttons (using the CommandButton elements).
The VBA modules look like legitimate SQL programs powered with a macro; no malicious code found there … However, after further investigation we noticed a strange string in the Caption field for CommandButton3 in the user form.
It appeared to be some sort of encrypted string.
We went back and reviewed the other modules in the file, and sure enough – there’s something unusual going on in Module2. A macro there (UsariosConectados) decrypts the string in the Caption field for CommandButton3, which turns out to be a URL. It uses the deault autoopen() macro to run the entire VBA project when the document is opened.
The macro will connect to the URL (hxxp://clickcomunicacion.es/<uniqueid>) to download a payload which we detect as Ransom:Win32/Locky (SHA1: b91daa9b78720acb2f008048f5844d8f1649a5c4).
The VBA project (and, therefore, the macro) will automatically run if the user enables macros when opening the file – our strongest suggestion for the prevention of Office-targeting macro-based malware is to only enable macros if you wrote the macro yourself, or completely trust and know the person who wrote it.
See our threat intelligence report on macros and our macro-based malware page for further guidance on preventing and recovering from these types of attacks.
-Marianne Mallen and Wei Li
MMPC