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 user form contains three buttons

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 script in Module2 decrypts the string in the Caption field

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.

Don’t shot the messenger!
Or: cure the disease, not just it’s symptoms.
Those macros are not (yet) malicious themselves, they are only used as means to fetch a malicious payload and execute this payload.
So: exercise defense-in-depth and use SAFER/Software Restriction Policies or AppLocker and deny execution in every location where (unprivileged) users are able to write/create files, and allow execution only below %SystemRoot% and %ProgramFiles%, where they can’t write/create files.

One of my co-workers has observed these URL’s in similar malicious samples that were emailed to our staff’s personal or professional email accounts. Some users have opened and against all better judgment enabled macros to run, allowing us to observe these URLs being utilized via our monitoring. While we wait for the higher ups to get back to us on the matter of changing corporate policy to allow replacing these users systems with a brick, we have blocked all URL’s found below for our systems.

The attack campaign appears to have at least 2 different types of samples (out of 3 one user received, from 2 different mail servers/relays), all 3 have different hashes but I have not figured out if they are different samples from the same family or what. They’ve all been submitted to Symantec and are detected before deploying.

I’m trying to figure out how module 2 decodes the string, but afterwards I will be analyzing those URL’s and the traffic from the downloader to them. Probably won’t find as much as you guys have though.