Malware analysis: searching for dots

Published: 2017-08-26. Last Updated: 2017-08-26 09:00:36 UTC
by Didier Stevens (Version: 1)
3 comment(s)

Reader Chris submitted a suspicious attachment. It is a 7-Zip file.

As you probably know, I like to do static analysis without extracting malware to disk, but by piping it into a chain of tools.

This can be done with 7-Zip too. Here is the content of the file:

It contains a single VBScript file: IMG_0107.vbs.

I can look at the script by extracting it (command e) and writing the output to stdout (option -so). This way, I can read the script without writing it to disk:

Take a look at the last line in the screenshot: it's a simple obfuscation of the string .responseBody. This is a strong indication that this VBS script is a downloader.

When analyzing obfuscated source code like VBA and VBS, I like to grep for lines with a dot character (.), as this gives an overview of method calls:

Not only does this output clearly shows that this is a downloader that will write to disk and execute the payload, it also reveals URLs, a User Agent String and keywords separated with the string "Swing".

Let's deobfuscate the URLs first:

With "re-search.py -n str" I extract the strings:

Then I remove the double qoutes with sed:

And finally, I split the string with sed by replacing ^ with newline:

Unfortunately, the URLs were dead when I did the analysis.

I can extract the "keywords" with the same method:

From this we can deduce that the downloaded file is written to a temporary folder in file UUmDBYNd.exe.

Another method I like for quick analysis of obfuscated source code, is just to extract strings with my re-search.py tool:

 

Didier Stevens
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

Keywords: 7zip malware vbs
3 comment(s)

Comments

Nice technique, Didier... but /historically/, that method could have led to trouble including further infection.

Back in the day, when the config.sys included lines to ansi.sys, you could actually remap an entire keyboard by printing escape sequences to the screen. If we were getting theoretical, I'd have embedded code to remap a common key to "echo y|format c:" for example, and to change the color of the screen font to black on black while I was going about it.

Also, I'm sure we've all had experiences when cat'ing a file on *nix, that you miss and hit a binary instead.. and suddenly amongst all the garbage, the title of your PuTTY session has changed to something unintelligble, so escape sequences are still very much "a thing"...

edit: dunno why that came up as "anonymous", my profile is showing my nickname. Could be a bug in the website logic as I had to reactivate my dormant account before able to log in.
Please correct me if I'm wrong, but I think those concerns apply more to *nix or DOS shells. The example above appears to be done in CMD, which is significantly different from those. It's not 0 risk, but as far as I know it's significantly less than your average BASH shell.
No, definitely correct there - that's why I'd said historically. But it did remind me that cat'ing in a shell doesn't always seem to end up in a "normal" result.

CMD doesn't use ansi.sys of course - we waved goodbye to that one some time ago ;-)

Diary Archives