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).

Screenshot of VBA script editor showing the user form and list of modules

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.

Screenshot of the VBA macro script in Module2 that decrypts the Caption string

The macro script in Module2 decrypts the string in the Caption field


The macro will connect to the URL (hxxp://<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

Comments (8)

  1. Nick says:

    Nice but oh man, the quality of the screenshots is so poor, Not professional at all. Bummer!

    1. msft-mmpc says:

      We’ve updated the images now…if you click on them they will open in a new window at full size

      1. Nick says:

        Thanks a lot!!

  2. Eddy Current says:

    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.

  3. 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.


  4. Sandra says:

    For several months we have blocked all .???m files on our mail server (along with the usual .exe, .js, .scr etc. files). We don’t have many users that need to send/receive macro files.

    Our mail system catches a lot of them.

  5. Thanks for the post; I hadn’t run across this one before….

    Keep on with the good work!


  6. Dror A. says:

    Thanks for the heads up, good job.

Skip to main content