Archive for November 2nd, 2020

Emotet -> Qakbot -> more Emotet, (Tue, Nov 3rd)


On Friday 2020-10-30, I generated an Emotet infection in my lab and saw Qakbot as the follow-up malware.  I let the activity run for a while, then another Emotet infection appeared on the same host after Qakbot started.

This appears to be an Emotet to Qakbot to another Emotet infection, with all three infections persistent on my infected lab host.

Shown above:  Flow chart for the infection chain I saw on Tuesday 2020-10-27.

Today’s diary reviews this Emotet to Qakbot to more Emotet infection from last week.

The malspam

The malicious spam (malspam) was a Halloween-themed message sent on Thursday 2020-10-29 to one of my honeypot email accounts.  It had a Word doc attached to the message.  The Word doc has a malicious macro designed to infect a vulnerable Windows host with Emotet.

Shown above:  Halloween-themed malspam with malicious Word doc attachment pushing Emotet.

The attached Word document uses a template that’s typical for recent Word docs pushing Emotet.

Shown above:  Word doc with macro for Emotet.

Infection traffic

The traffic didn’t look much different than what I’ve seen before for Emotet to Qakbot infections, there just seemed to be more Emotet traffic than normal after the Qakbot traffic kicked in.  That didn’t seem too unusual, though.

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

Shown above:  Traffic from the end of my pcap filtered in Wireshark.

In the above image, Emotet traffic is more frequent than I usually see.  Usually, Emotet will call back every 15 minutes, unless the host has been turned into a spambot.  Emotet spambot activity includes more frequent C2 callback traffic, but we would also see indicators of spambot traffic, and that’s not the case here.

Forensics on an infected Windows host

When I checked the registry, I saw two entries for Emotet.  When Emotet updates itself, it will replace an already existing binary.  I’d never personally seen two separate Emotet binaries active and set up in the registry like this.

Shown above:  Windows registry updates from my infected lab host.

Shown above:  Persistent Emotet EXE from 1st Emotet infection and Qakbot follow-up malware.

Shown above:  Qakbot persistent on my infected lab host.

Shown above:  Another Emotet infection persistent approximately 17 minutes after the initial Qakbot EXE appeared.

Of note, Emotet backdates the persistent EXE files 8 days before the current date.  So the modified date on both of these Emotet EXE files is 2020-10-22, but the timestamp is the correct time for 2020-10-30.  Based on the timestamps for these binaries, it appears that Qakbot caused the second Emotet infection.

Indicators of Compromise (IOCs)

SHA256 hash: ed51269c3602786ff6ddef3a808d8178d26e4e5960f4ac7af765e4bd642128dd

  • File size: 233,466 bytes
  • File name: Party invitation.doc
  • File description: Word doc with macro for Emotet

SHA256 hash: a4c780c8b6ecb7d73f7498a4a46286cf2a2ecc6f378e2ba89deea06591c3cc04

  • File size: 364,544 bytes
  • File location: hxps://imperfectdream[.]com/wp-content/xb2csjPW6/
  • File location: C:Users[username]Nscs8ryS8t4g_lEpl6_wa2m.exe
  • File location: C:Users[username]AppDataLocalmsexcl40msimg32.exe
  • File description: Emotet EXE retrieved by Word macro

SHA256 hash: dcda70b5cc63629dd2760dbc76ffda0bedefd0ee92af4d4e3740acc7dd2eaff2

  • File size: 261,080 bytes
  • File location: C:Users[username]AppDataLocalmsexcl40cryptnet7e4.exe
  • File location: C:Users[username]AppDataRoamingMicrosoftGzzndshwwcrrcbu.exe
  • File description: Qakbot EXE retrieved by the Emotet-infected host

SHA256 hash: 4180c4c11e631a7545d40dadb74280c00f53271a75b113c387bb87adaf2cecf7

  • File size: 318,992 bytes
  • File location: C:Users[username]AppDataRoamingMicrosoftGzzndshwwcrrcbu.exe
  • File description: Updated Qakbot EXE persistent on the infected Windows host

SHA256 hash: 4d1eeb527a61391ddcf30b0f9d6d9f96369e0179c1e1a65da5da33a196a991d4

  • File size: 192,512 bytes
  • File location: C:Users[username]AppDataLocalAccountsControlInternalmfc40.exe
  • File description: Another Emotet EXE persistent on the infected Windows host

HTTPS traffic caused by Word macro to retrieve initial Emotet EXE:

  • port 443 – enjoymylifecheryl[.]com
  • port 443 – homewatchamelia[.]com
  • port 443 – seramporemunicipality[.]org
  • port 443 – imperfectdream[.]com

HTTP traffic caused by the two Emotet infections:

  • 91.121.200[.]35 port 8080 – 91.121.200[.]35:8080
  • 45.230.228[.]26 port 443 – 45.230.228[.]26:443
  • 172.91.208[.]86 port 80 – 172.91.208[.]86
  • 50.91.114[.]38 port 80 – 50.91.114[.]38
  • 121.124.124[.]40 port 7080 – 121.124.124[.]40:7080
  • 167.99.105[.]11 port 8080 – 167.99.105[.]11:8080
  • 159.203.16[.]11 port 8080 – 159.203.16[.]11:8080
  • 188.226.165[.]170 port 8080 – 188.226.165[.]170:8080
  • 75.127.14[.]170 port 8080 – 75.127.14[.]170:8080

Traffic caused by Qakbot:

  • 47.44.217[.]98 port 443 – HTTPS traffic
  • 89.105.198[.]119 port 80 – a.strandsglobal[.]com – attempted TCP connections
  • port 443 – cdn.speedof[.]me – HTTPS traffic

Caused by Qakbot and Emotet:

  • various IP addresses – various ports – attempted TCP connections

Final words

In order to become infected, a victim must open the Word document and enable macros.  In most cases, people would see a warning against enabling macros.  Just opening the Word document by itself should not kick off the infection chain, unless the computer was set up to have macros automatically enabled.

Although Emotet pushes other families of malware like Qakbot, this is the first time I’ve seen indications that Qakbot has pushed Emotet.

A zip archive containing a pcap from today’s infection is available here.  The Word doc and EXE files from the IOCs have been submitted to MalwareBazaar Database.

Brad Duncan
brad [at]

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Social Engineering Attacks Increase Risk to your Security Posture

Hackers are getting more clever with social engineering tactics, especially through COVID-related campaigns, putting you and your organization at risk of handing over sensitive data and credentials.

Simply put, social engineering is the non-technical strategy cyber attackers use to manipulate people into giving up confidential information. Instead of exploiting vulnerabilities in an application, they find vulnerabilities within humans.

Even with the most sophisticated security technologies in place, falling victim to social engineering tactics puts your business or yourself at a higher risk of bad actors achieving their goals.

Social engineering is nothing new – however, the pandemic has created a huge surge in people’s reliance on IT, from communicating with family or friends to maintaining productivity at work.

This increased dependency on work-from-home and online footprint has made us a much easier target for social engineering attacks, so it is important now – more than ever before – to be mindful of who we are interacting with over the phone and over the Internet.

Common social engineering hacks that have risen during COVID:

  • Emails or calls posing as someone in your organization’s IT department which ask you to click a link or provide a two-factor authentication code and bypass multi-factor authentication (MFA) controls.
  • “Officials” from your local government or healthcare agency, or insurance carrier, who ask for personal information.
  • Unsolicited requests for account changes or information via email alone.

A few recommendations for you:

  • Closely inspect any unknown email address to verify it is legitimate before clicking on links or attachments.
  • Do not provide information about your organization to outside entities without proper authorization.
  • Double check a request’s legitimacy by calling or contacting the company or internal department directly.

Awareness that social engineering attacks are increasing alone is an instrumental step towards protecting yourself and your organization against a successful cyber attack. If you are suspicious about an email, report it to your IT organization’s staff immediately and don’t answer any calls you are not expecting.

Posted in: Business, Government, Individuals, Securing the Human

Leave a Comment (0) →

AV Cleaned Maldoc, (Fri, Oct 30th)

An anonymous reader reported an unusual malicious Office document.

This is oledump‘s output for this file:

Although there is a VBA storage and all the usual streams associated with VBA macros, oledump does not display macro indicators (M or m).

In such cases, I always use option -i like this:


When you use option -i (–info) without options -s, an extra column is added to the overview of streams. For all VBA module streams, a value like c+s will be displayed in that column. c stands for compiled code and s for source code.

For example, for stream 5, we have value 1355+161: this means that the first 1355 bytes of this stream contain compiled VBA code, and the following 161 bytes contain compressed VBA source code. Remark that the sum of 1355 and 161 is 1516, e.g. the size of the stream.

So now we know that stream 5, 15 and 17 are VBA modules, but that there’s something unusual with them (otherwise we would see a macro indicator: M or m).

Let’s take a look at the content of stream 5: I use option -A to output a run-length compressed hexadecimal/ASCII dump. If there are repeating rows in the hexadecimal/ASCII dump, they will be counted and removed:

The first row is all NULL bytes (00), and the following 83 rows too. And then we have some binary data with a repeating ASCII string: ‘fixed.

When I see this, I start to think that this is a malicious Office document that has been cleaned: the malicious code has been removed. Let’s check, by taking a look at the compiled code and the VBA code separately. I’ll start with the compiled code:

The 1355 bytes of compiled code are all 00: that’s not normal.

The source code:

VBA source code is compressed, but doesn’t look like this. If you try to decompress the VBA source code with option -v, like we usually do, it will not work. option -v is specific for compressed VBA source code produced by an Office application. If you want to decompress any data (including VBA source code), you have to use option –decompress like this (I’m also using option -d to dump the output):

So this is indeed compressed ASCII text: a repetition of the line ‘fixed.

But it is not VBA code compressed by an Office application, as it does not start with “Attribute VB_..” (option -v searches for VBA code staring with Attribute VB_…).

So this certainly looks to me like a malicious Office document where the VBA macros have been cleaned by an anti-virus program. But which AV?

We get a good clue by looking at the compressed data of stream 15:

The first line reads: ‘macro Fixed By 360.QEX

That’s the AV of Qihoo 360: 360 Safeguard. That’s very thoughtful of the developers to add a message that helps me identify the AV product that did this.

So the module streams have been wiped: no compiled code and no source code. This maldoc can no longer execute.

But there are some other streams that contain compiled code too, like stream _VBA_PROJECT:

This one has not been cleaned. Let’s take a look at the strings inside this stream:

So we have ShellV and different strings that look like BASE64: this is probably a maldoc that executes a PowerShell command.

I tried to find back the original maldoc using the method I described in this diary entry, but I had no success.

Didier Stevens
Senior handler
Microsoft MVP

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →