Another Day, Another Malicious Behaviour

Published: 2016-09-30
Last Updated: 2016-09-30 07:15:07 UTC
by Xavier Mertens (Version: 1)
8 comment(s)

Every day, we are spammed with thousands of malicious emails and attackers always try to find new ways to bypass the security controls. Yesterday, I detected a suspicious HTTP GET request:

GET /ork/ HTTP/1.1

Just by reading the User-Agent string, you already know that this is something weird and it must be investigated. I downloaded the file which was indeed a ZIP archive and not a disguised PE file. But this time, the archive is protected with a password! The file MD5 is 55d620a29afc46de0a5cb2bebfd7968b and is reported as non-malicious by VT (normal: the files can't be extracted):

$ unzip -l
  Length     Date   Time    Name
 --------    ----   ----    ----
   439608  09-14-15 12:44   msvcp140.dll
   348160  04-28-16 09:15   msvcr71.dll
   676036  04-28-16 09:15   sqlite3.7.11.dll
   196608  04-28-16 09:15   ssleay32.dll
   488467  09-25-16 10:17   upd.exe
    88248  06-23-15 15:00   vcruntime140.dll
       57  09-22-16 22:19   x.Cmd
   466432  09-16-16 08:10   em.exe
   418304  09-16-16 08:31   fb.exe
   439808  09-26-16 12:27   ie.exe
  1011712  04-28-16 09:15   libeay32.dll
  2533907  09-26-16 13:55   msupd.exe
 --------                   -------
  7107347                   12 files

More checks in my log files revealed that the HTTP GET originated from a malicious Word document (MD5: 9f2264c60115cc6d1dd69a4348a26fb2 - unknown on VirusTotal). Let's have a deeper look at the file and the macros. It starts with a classic scenario, the user is enticed to enable macros to view the document. Note the look of the message which mimics a missing plug-in!

The document contains hidden data (a white font on a white background) which looks like Base64/XOR’d data:

The macro was pretty well obfuscated to evade the classic antivirus solution but a quick manual analysis of the macro revealed that the hidden data are extracted and the decrypted data are dumped in a file in a random directory with a random filename (3 letters for the directory and 2 letters for the filename): %LOCALAPPDATA%\Temp\xxx\xx.cmd.

Here are some other indicators extracted by

| Type       | Keyword       | Description                             |
| AutoExec   | AutoOpen      | Runs when the Word document is opened   |
| AutoExec   | Workbook_Open | Runs when the Excel Workbook is opened  |
| Suspicious | Open          | May open a file                         |
| Suspicious | Shell         | May run an executable file or a system  |
|            |               | command                                 |
| Suspicious | MkDir         | May create a directory                  |
| Suspicious | Binary        | May read or write a binary file (if     |
|            |               | combined with Open)                     |
| Suspicious | CreateObject  | May create an OLE object                |
| Suspicious | Chr           | May attempt to obfuscate specific       |
|            |               | strings                                 |
| Suspicious | Xor           | May attempt to obfuscate specific       |
|            |               | strings                                 |
| Suspicious | Environ       | May read system environment variables   |
| Suspicious | Put           | May write to a file (if combined with   |
|            |               | Open)                                   |

The created file 'xx.cmd' is a PE file (MD5: 9b8af9042b8f357e17e6609aa5d0dc7d) also unknown on VT. The file is executed by the macro using a Shell() command. It performs the following actions:

  • It downloads the ZIP file mentioned above
  • It extracts the content on the file system in %PROGRAMDATA%
  • It executes 'msupd.exe' (extracted from the archive - see the content above)

The next step was to get the files from the ZIP archive. The .cmd PE file was not obfuscated and contained a lot of strings. I created a dictionary based on those strings and started a dictionary attack against the archive, no success. Let's try a brute-force attack with a password estimated between 3-8 characters and I was lucky: The password was found in a few seconds (a weak 3-characters password). Here are the MD5 hashes of the extracted files:

$ md5sum *
MD5 (em.exe) = bae5851b1ea539b16800f5bdaded3a68
MD5 (fb.exe) = 38ff837f504f63e04491682e96447cdb
MD5 (ie.exe) = a8107e664bfbee36653bcdcff37afa00
MD5 (libeay32.dll) = 177bda0c92482dfa2c162a3750932b9c
MD5 (msupd.exe) = 8e402be9c03d288a5aee9565143632bc
MD5 (msvcp140.dll) = 1d8c79f293ca86e8857149fb4efe4452
MD5 (msvcr71.dll) = 86f1895ae8c5e8b17d99ece768a70732
MD5 (sqlite3.7.11.dll) = f45ed79fee632e407831fbebc51fc063
MD5 (ssleay32.dll) = 5023f4c4aaaa1b6e9d992d6bbdcd340b
MD5 (upd.exe) = 6c66d7c6a3718d515370709a9f06f4a6
MD5 (vcruntime140.dll) = c2bbcb5aae069c22711d8e49d6107401
MD5 (x.Cmd) = f97253ff3c80b94fa2efb9e5ab1808db

Only the file 'em.exe' is reported as malicious by VT[1]. The 'msupd.exe' file as an original name 'setup.exe' and is reported as a Microsoft Setup Bootstrap[2] file:

It enumerates the processes, starts a keylogger, deploys and executes the other PE files (like any Windows installer):

C:\ProgramData\ie.exe" -f "C:\ProgramData\bigchunk\ie.txt
C:\ProgramData\em.exe, -f "C:\ProgramData\bigchunk\em.txt"
C:\ProgramData\fb.exe" -f "C:\ProgramData\bigchunk\fb.txt

Those files are common tools to collect email passwords (em.exe), browsers passwords (ie.exe) and social networks passwords (fb.exe).

But the funny stuff was for sure the notification sent via email to the attacker. Here is a dump of the SMTP session recorded:

220 ESMTP Server
EHLO SystemIT Hello xxxxxxxx [x.x.x.x]
250-SIZE 104857600
250 HELP
AUTH PLAIN xxxxxxxxxxx
235 Authentication succeeded
503 already authenticated
250 OK
250 Accepted
354 Enter message, ending with "." on a line by itself
Date: Thu, 29 Sep 2016 08:20:36 +0100
Subject: Installed[SystemIT]
X-mailer: Synapse - Delphi & Kylix TCP/IP library by Lukas Gebauer

Sucessfully installed. Remote remove code: xxxxxxxxxxxxxxxxxxxxxxx Check FAQ to know how remotely uninstall software
250 OK id=1bpV6a-0003zu-98
221 closing connection

Now I have the attacker's email address and credentials to use his mail server!

Sadly, the attack was not completely successful in my sandbox environment and no data was ex-filtrated (collected credentials). I did not detect any traffic to the Wild Internet... As you can see, attackers are always trying to find ways to bypass security controls like password protected archives, generic Microsoft tools).

Stay safe!


Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant

8 comment(s)
ISC Stormcast For Friday, September 30th 2016


Diary Archives