MuddyWater (11-23-2019) – Part 2: Macro analysis and dropped file

Continuing from part one, we can now use Microsoft Visual Basic for Applications to step through the macro and see how it works.

First things first, the macro starts here with Workbook_Open().


It calls a function called irnqdecjko. In this function, we see multiple calls to another function called irnqdxjwko which is fed a number.


Function irnqdxjwko takes the parameter fed and uses it to query a form named F. It will take that text from form F and split it on the periods and toss it into an array called h.



In this case, the fifty-second item in array is chosen and saved to variable g. Here is the fifty-second item in that array:


That value is then tossed into another function called irnqdkjdkoIrnqddjdko will then decode that string. It takes four characters of the array at a time, does an xor a few times amongst some other manipulations and outputs it to variable g. This loops again and again until it is done.


Those two functions are called over and over again throughout the entire macro. Below is the main function that does most of the heavy lifting for this macro.


The first part sets up the WScript.Shell object and some other variables. I’ve added the decoded values.


We can see that the CallByName is used throughout this macro. It gets fed parameters such as RegWrite and to what those registries should be set.


The next section edits the \CurrentVersion\Run\ registry to have wucj.exe execute a file called zdrqgswu that gets dropped in the TEMP folder. According to this article, wucj.exe is just a copy of wscript.exe.


Ultimately, this macro makes use of wscript.exe to run the dropped file named zdrqgswu. What does this file do? (by the way, you can download it —-> HERE <—-)


I’m not going to go into too much detail here, but a quick overview…

  • Variable blhcqkvwge gets decoded in line 14 and stored in variable hdupqjaiot.
  • The strings in lines 23 and 24 get decoded using function jhohvgaemi. They decode to “ScriptControl” and “JScript” respectively.
  • This means that line 29 is really “JScript.Eval(hdupqjaiot)”.

And what exactly is in hdupqjaoit? Here’s a partial output:


And we can finally see the URL to which it reaches out.

Thanks for reading!


MuddyWater (11-23-2019) – Part 1: VBAProject password and .xls documents

tl;dr – Use compatibility mode  to turn an .xls document into an .xlsm. Then you can unlock the VBAProject at your leisure.

What follows isn’t that difficult, but I thought I’d step through it anyway. It might save someone else some pain (or at least a self-induced forehead slapping moment).

This document came across my feed the other day and thought I would take a look.


You can find that document on Click on the link below to get a copy for yourself.


Anyway (lol), the macros could be extracted from it quite easily. I’ll look at them more carefully in a bit. The next thing I did was open the document and enable the macros to see if any new processes like cmd.exe or powershell pop up anywhere. It was unusual that nothing did.

This means we need to take a more careful look at the macros and see what they’re all about. However, opening the document, hitting ALT+F11 to open Visual Basic for Applications gives us its demand for a password.


Of course, that’s no big deal. We’ve dealt with this before. All we need to do is turn the .xls file into a .zip, open it up, extract the vbaProject.bin file, edit it with a hex editor and we’re good.

But no. If we treat this file as a .zip, we end up seeing these next to useless files:

That is because this is an .xls document. Pre-2007, .doc and .xls documents used Microsoft’s proprietary binary format. After 2007, Microsoft used their Open Office XML format to represent documents, charts, and more.

How does this help us? If we can open this .xls document and convert it to an .xlsx (or .xlsm) document, it should allow us to unzip the file and edit that vbaProject.bin file to get around that pesky password. We cannot, however, just change the format of the file by adding an x at the end of .xls. We need to open the document and convert it this way.



Open the document as an archive, navigate down into the \xl\ subfolder and you’ll see vbaProject.bin. Extract that file, open it up with a hex editor, search for the string DPB, replace it with DPx, save changes, and toss the .bin file back into the .xlsm document.


Open the document, ignore errors, hit ALT+F11, right-click on the project, choose VBAProject Properties, click on the Protection tab, and uncheck the “Lock project for viewing” box. Save the document one more time, open it back up, hit ALT+F11 and you’ll see…


Now couldn’t we have just looked at the macros that we dumped earlier? Yes, but the benefit of being able to do this is that we can use the debugging capabilities here to interact and watch how the macros work.

That will be the next post. Thanks for reading!