SANS

Subscribe to SANS hírcsatorna SANS
SANS Internet Storm Center - Cooperative Cyber Security Monitor
Frissítve: 2 óra 41 perc
2021. január 18.

Doc & RTF Malicious Document, (Mon, Jan 18th)

A reader pointed us to a malicious Word document.

First, I run my strings.py command on it, with option -a to get statistics (see my diary entry "Strings 2021").

There aren't any long strings in this file (the longest is 33 characters). So there isn't a payload here that we can extract directly, like we did in diary entry "Maldoc Strings Analysis".

Let's check if there are URLs in this file, by grepping for http:

Unfortunately, none.

Let's take a look at the longest strings (-n 20: strings at least 20 characters long):

If you are a bit familiar with the internals of Word documents, you might recognize this as the name of XML files found inside OOXML files (.docx, .docm, .xlsx, ...).

Let's try oledump.py:

This means that there are no OLE files inside this OOXML file, hence no VBA macros.

Since an OOXML is an OPC file, e.g. a ZIP container, let's take a look with my tool zipdump.py:

It looks like this OOXML file only contains XML files (extensions .xml and .rels). Let's verify by getting statistics of the content of the contained files, by using option -e:

Here is a close look on the statisctics:

All contained files starts with <?xm and have only printable ASCII characters (except one file with 90 bytes >= 127).

So we have no binary files in here, just text files. One possible scenario, is that this .docx file contains a reference (URL) to a malicious payload.

Next step, is to extract all files and search for URLs in them. Now, in Office OOXML files, you will find a lot of legitimate URLs. To get an idea of what type of URLs we have in this document, we use my re-search.py tool to extract URLs, and display a unique list of hostnames found in these URLS, like this:

The following hostnames are legitimate, and found in Office OOXML files:

schemas.openxmlformats.org
schemas.microsoft.com
purl.org
www.w3.org

But the IP address is not. So let's extract the full URLs now, and grep for 104:

I downloaded this document. Let's start again with strings:

4555 characters long: this might be a payload. Let's take a look:

This looks like a lot of hexadecimal data. That's interesting. And notice the 3 curly braces at the end. Hexadecimal data and curly braces: this might be a malicious RTF document. Let's check with the file command (I use my tool file-magic.py on Windows):

This is indeed an RTF file. RTF files can not contain VBA code. If they are malicious, they often contain an exploit, stored as (obfuscated) hexadecimal characters inside the RTF file. Hence the strings command will not be of much use.

I recently updated my tool rtfdump.py to make analysis of embedded objects (like malicious payloads) easier. We use the new option -O to get an overview of all objects found inside this RTF file:

There's one object with name equation... . It's very likely that this is an exploit for the equation editor, and that we have to extract and analyze shellcode.

Let's extract this payload and write it to a file:

Let's see if there are some intesting strings:

Nothing interesting.

The equation editor that is targeted here, only exists as a 32-bit executable. Hence the shellcode must also be 32-bit, and we can use the shellcode emulator scdbg to help us.

We use option -f findsc to let scdbg search for entrypoints, option -r to produce a report, and -f shellcode to pass the shellcode file for analysis:

The shellcode emulator found 4 entry points (numbered 0 to 3). I select entry point 0. This results in the emulation of shellcode, that calls the Win32 API (GetProcAddress, ...). This is clearly 32-bit Windows shellcode. And it decodes itself into memory. We can use option -d to dump the decoded shellcode:

This creates a file: shellcode.unpack. Let's use strings again on this file:

This looks more promising. What are the longest strings:

And finally, we have our URL.

 

 

 

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.
2021. január 18.

ISC Stormcast For Monday, January 18th, 2021 https://isc.sans.edu/podcastdetail.html&#x3f;id=7332, (Mon, Jan 18th)

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

New Release of Sysmon Adding Detection for Process Tampering, (Sun, Jan 17th)

Version 13.01 of Sysmon was released, a Windows Sysinternals tool to monitor and log system activity.

This version adds detection for process tampering, like process hollowing and process herpaderping. You use ProcessTampering in your configuration to activate it.

Here is an example of process hollowing detection:

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.
2021. január 16.

Obfuscated DNS Queries, (Fri, Jan 15th)

This week I started seeing some URL with /dns-query?dns in my honeypot[1][2]. The queries obviously did not look like a standard DNS queries, this got me curious and then proceeded to investigate to determine what these DNS query were trying to resolve.

But before proceeding, I have logs going back to May 2018 and reviewed the logs to see when this activity was first captured. The first time the honeypot logged something similar was in February 2020 with one long query that was different to all other queries. All the logs are targeting TCP/443 and are unencrypted.

Using base64 URL safe option in CyberChef, I was able to decode the DNS information for the 3 different queries. The first query captured in February 2020 appears to be a test (see decoded information below). The other two resolve to a URL: one as a test (www.example[.]com) and the other to Baidu search engine (www.baidu[.]com).

Sample Logs

  • tcp-honeypot-20200212-195552.log:20200226-230039: 192.168.25.9:443-54.153.67.242:59822 data 'GET /dns-query?dns=AAABAAABAAAAAAAAAWE-NjJjaGFyYWN0ZXJsYWJlbC1tYWtlcy1iYXNlNjR1cmwtZGlzdGluY3QtZnJvbS1zdGFuZGFyZC1iYXNlNjQHZXhhbXBsZQNjb20AAAEAAQ HTTP/1.1\r\nHost: XX.30.102.198:443\r\nConnection: close\r\nAccept-Encoding: gzip\r\nUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36\r\n\r\n'
  • tcp-honeypot-20200413-081332.log:20200413-171212: 192.168.25.9:443-195.37.190.77:40634 data 'GET /dns-query?dns=AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB HTTP/1.1\r\nHost: XX.30.102.198\r\nUser-Agent: Go-http-client/1.1\r\nAccept-Encoding: gzip\r\nConnection: close\r\n\r\n'

[...]

  • 20210112-110540: 192.168.25.9:443-39.96.138.251:60736 data 'GET /dns-query?dns=AAABAAABAAAAAAAAA3d3dwViYWlkdQNjb20AAAEAAQ HTTP/1.1\r\nHost: XX.49.33.78\r\nUser-Agent: Go-http-client/1.1\r\nAccept: application/dns-message\r\nAccept-Encoding: gzip\r\nConnection: close\r\n\r\n'
  • 20210113-040125: 192.168.25.9:443-161.117.239.46:49778 data 'GET /dns-query?dns=AAABAAABAAAAAAAAA3d3dwViYWlkdQNjb20AAAEAAQ HTTP/1.1\r\nHost: XX.49.33.78\r\nUser-Agent: Go-http-client/1.1\r\nAccept: application/dns-message\r\nAccept-Encoding: gzip\r\nConnection: close\r\n\r\n'

Base64 Decoded Queries

  • AAABAAABAAAAAAAAAWE-NjJjaGFyYWN0ZXJsYWJlbC1tYWtlcy1iYXNlNjR1cmwtZGlzdGluY3QtZnJvbS1zdGFuZGFyZC1iYXNlNjQHZXhhbXBsZQNjb20AAAEAAQ .............a>62characterlabel-makes-base64url-distinct-from-standard-base64.example.com.....
  • AAABAAABAAAAAAAAA3d3dwViYWlkdQNjb20AAAEAAQ   .............www.baidu.com.....
  • AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB .............www.example.com.....

DNS Queries by Base64 String

  • IP Activity resolving to www.example[.]com has been active since April 2020 with 2 packets per month.
  • User-Agent → Mozilla/5.0 (compatible; DNSResearchBot/2.1; +http://195.37.190.77)

195.37.190[.]77

====================

  • IP Activity resolving to www.baidu[.]com only started in December 2020 and has been active since then.
  • User-Agent → Go-http-client/1.1

39.96.138[.]251
39.96.139[.]173
39.96.139[.]223
39.96.140[.]32
47.74.84[.]52
47.241.66[.]187
54.153.67[.]242

====================

  • IP Activity resolving to 62characterlabel-makes-base64url-distinct-from-standard-base64.example.com only seen once in February 2020 which appears to be only a test.
  • Something interesting, 62characterlabel-makes-base64url-distinct-from-standard-base64 is equal to 62 characters
  • User-Agent → Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36

161.117.239[.]46

====================

Do you have similar obfuscated DNS queries in your logs? Please use our comment form to share them.

[1] https://github.com/DidierStevens/Beta/blob/master/tcp-honeypot.py
[2] https://www.inetsim.org/documentation.html
[3] https://gchq.github.io/CyberChef/

-----------
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.
2021. január 15.

Throwback Friday: An Example of Rig Exploit Kit, (Fri, Jan 15th)

Introduction

As this week winds down, I wanted to highlight a threat that's significantly diminished in recent years.  For today's #ThrowbackFriday, I'm reviewing an example of Rig exploit kit (EK) generated yesterday on Thursday 2021-01-14.

History of Rig EK

EKs are a malware distribution method.  They're channels to send malware to vulnerable Windows hosts.  An EK's payload is Windows-based malware.

Rig EK was discovered in 2014, back when EKs were much more common than today.  Like other EKs in 2014, Rig exploited Internet Explorer (IE) and browser-based applications that worked with IE like Java, Flash, and Silverlight.  Since then, people have increasingly moved to other browsers like FireFox and Chrome.  Because of this, EK activity began to decline.

Windows 10 was introduced in 2015 with Microsoft Edge as its default browser.  As more people switched to Windows 10, some EKs disappeared.  Rig EK continued to decline, with a substantial drop in 2017.  By 2018, Rig EK was one of only a few remaining EKs.  Today, people still discover examples of Rig EK, but it's only effective against out-of-date hosts running Windows 7 and using IE.

To prepare for throwback Friday, I fired up a vulnerable Windows 7 host, opened IE 11, and entered a URL that led to Rig EK.

Gate to Rig EK

An HTTPS gate that leads to Rig EK has been active since December 2020:

  • hxxps://anklexit[.]online/twDGMjtfsacfa3e

On 2020-12-24, @nao_sec tweeted an example of Rig EK pushing SmokeLoader that contained the above URL.  Earlier this month, Rig EK from the same gate pushed Dridex.

URLs like this act as a gate to an EK.  This gate wouldn't direct me to Rig EK when I tried it through a VPN.  However, tethering through my phone worked.  These gates are somewhat picky.  Use the gate once, and it might work.  But try it again from the same IP address, and it prevents you from reaching the EK again.  You generally have to wait 12 to 24 hours before the gate will work again, if you're coming from the same IP address.

Traffic from an infection

See the below images for traffic from the infection.


Shown above:  Traffic from the infection filtered in Wireshark.


Shown above:  Rig EK landing page shown in an HTTP stream.


Shown above:  Dridex installer EXE sent by Rig EK as an encrypted binary.


Shown above:  Certificate issuer data for HTTPS traffic generated by Dridex installer.

To get a better understanding of Dridex infection traffic, see this Wireshark tutorial I wrote about it last year.

Forensics on an infected Windows host

While the Rig EK payload (an EXE to install Dridex) generated HTTPS command and control (C2) traffic, it wasn't able to install Dridex on the victim host.  So I only saw the Dridex installer EXE.  I also captured a small file (approx 1 kB) of JavaScript text used by Rig EK before it was deleted during the infection process.


Shown above:  Artifacts from the infection caused by Rig EK.

Indicators of Compromise (IOCs)

The following are indicators from this infection.

Traffic from an infected Windows host:

  • 188.225.75[.]54 port 443 - anklexit[.]online - HTTPS URL - gate to Rig EK
  • 188.227.106[.]164 port 80 - 188.227.106[.]164 - Rig EK
  • 162.241.44[.]26 port 9443 - HTTPS traffic caused by Dridex installer
  • 185.184.25[.]234 port 4664 - attempted TCP connection caused by Dridex installer
  • 138.201.138[.]91 port 3389 - attempted TCP connection caused by Dridex installer

Certificate issuer data from Dridex HTTPS traffic to 162.241.44[.]26 over TCP port 9443:

  • id-at-countryName=DS
  • id-at-stateOrProvinceName=Tholend finck4
  • id-at-localityName=Khartoum
  • id-at-organizationName=Antymasu PEEC
  • id-at-commonName=anompatof.rip

Malware/artifacts from the infected Windows 7 host:

SHA256 hash: 209093c71d0e87df00a290c588a5147e1e14023402f317d7903c6402d52a87ee

  • File size: 98,819 bytes
  • File location: hxxp://188.227.106[.]164/?MzA1NTIz&pwDDc&AcAZl=pinny.866&shghfg[long string]
  • File description: HTML for Rig EK landing page

SHA256 hash: f14c7ba0240be3456164dd63f53dd4bc7eb34bcdb1ac26e98a623edc0390b56b

  • File size: 1,152 bytes
  • File location: C:\Users\[username]\AppData\Local\Temp\3.tMp
  • File description: JavaScript text file dropped by Rig EK

SHA256 hash: 0376f97c21d2f00bc9c0919ce108ef14a2b3b1b356b2caa502a6cae81c7798f2

  • File size: 1,198,592 bytes
  • File location: C:\Users\[username]\AppData\Local\Temp\jv9qx.exe
  • File description: Rig EK payload, Windows EXE to install Dridex malware

Final Words

Pcap and malware/artifacts for this diary can be found here.

I wonder how it long this method of malware distribution will remain profitable.  Apparently, enough people currently use out-of-date vulnerable Windows hosts.  I guess this presents a big enough target base for the people behind Rig EK.

Every time I find Rig EK, I think back to all the entries I posted on my blog from 2013 through 2016 featuring Rig and other EK infections.  That's why I consider today's diary a #ThrowbackFriday.

---
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.
2021. január 15.

ISC Stormcast For Friday, January 15th, 2021 https://isc.sans.edu/podcastdetail.html&#x3f;id=7330, (Fri, Jan 15th)

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

Dynamically analyzing a heavily obfuscated Excel 4 macro malicious file, (Thu, Jan 14th)

Recently I had to analyze an Excel malicious file that was caught in the wild, in a real attack. The file was used in a spear phishing attack where a victim was enticed into opening the file with Excel and, of course, enabling macros.

The image below shows what the file looks like when opened in Excel:

As you can see, it is a very common malicious Excel file where the victim is supposed to click on the Enable content button to see the document. Of course, once the victim does that it is game over and the machine gets infected. My goal was to analyze the malicious Excel file to identify what exactly it is doing.

Typically, the first step to analyze such a document would be verify macros with Didier’s oledump.py tool, which is the de-facto standard malicious document analysis tool (the FOR610 instructors are joking that Day 3 of FOR610 is Didier’s day, since he wrote so many useful tools).

However, as you can see below, I was a bit disappointed to see that there are no macros – this normally means that the attacker is using Excel 4 macros – an old way of creating active content:

$ python3 oledump.py ~/source.xls 
  1:      4096 '\x05DocumentSummaryInformation'
  2:      4096 '\x05SummaryInformation'
  3:    162264 'Workbook'

Both Didier and Xavier wrote a number of diaries about analyzing Excel 4 macros (available here and here), so the next step was to use the BIFF plugin Didier wrote, which allows output of BIFF records – these hold Excel 4 macros (formulas really), so let’s do that:

Ok, we’re getting somewhere, however there were thousands of lines like this in the output:

Not nice. This means that Didier’s BIFF plugin does not know how to parse these bytes, which define a currently unknown formula. Didier also wrote about another tool that can be used to deobfuscate malicious Excel files, XLMMacroDeobfuscator (read the diary here) so I thought about trying that as well:

Hmm, a bit better but we still do not know what exactly this file is doing. There are two important things we can see in XLMMacroDeobfuscator’s output though:

  1. First, we can see that there is a cell with the name of Auto_Open. The contents of this cell will be executed (if it is a formula) automatically when this Excel file is open, after the user has clicked on the Enable content button, of course.
  2. Second, we can see that the last two functions that are called are WORKBOOK.UNHIDE and WORKBOOK.HIDE. These do exactly as their names say – they will hide one workbook and unhide another – this will result in the final, decoy content to be shown to the victim (no screenshot, sorry, as it contains sensitive information about the target).

Armed with this knowledge I wanted to dig further into the file. While most researchers might prefer static analysis since it is safer, in this case such analysis might be very difficult or time consuming. The main reason is that the tools we have on our disposal failed to completely parse the document (as shown above) and, besides this, the file is heavily obfuscated with a number of formulas and calculations that are performed automatically by Excel.

So, I decided to go with dynamic analysis of the file – cool thing is that, at least for this case, we do not need any other tools but Excel. Of course, by running malicious code we will be putting ourselves to risk, so if you ever need to perform a similar analysis, make sure that you do it in a VM, without Internet access (or you will be really living on the edge).

Since this malicious document does not have a VBA macro, it relies on executing formulas. Excel will generally execute formulas top to bottom in a column, then move to the next column and so on. This does not necessarily has to be in this order, but in all cases I have checked it was. Our first step will be to find the cell (formula) that gets executed first – XLMMacroDeobfuscator already told us that it is a cell in the “Sheet_vrg” tab of this document, and that the cell is $HV$19420 (column HV, row 19420). We can also see this by opening the malicious file in Excel (notice I am not enabling content yet!) and then going to Formulas -> Name Manager. We will see this very same cell displayed, as shown in the figure below:

Let’s scroll now to this cell to see what its contents look like:

Aha – this is actually what XLMMacroDeobfuscator showed to us, but it partially evaluated the contents so we still do not know what this code actually does. So let’s see how we can dynamically analyze this document. Excel actually allows us to manually evaluate any formula shown in the document. All we have to do is right click on a cell, but the catch-22 here is that we have to click on Enable content in order to do that, and by doing this we will execute the malicious macro.

The solution is, luckily, relatively simple. A function called HALT() exists that does exactly what the name says, so we can manually insert this function in a free cell and then change the Auto_Open name to point to our cell. What’s even better – in the image above you can see that there is already a cell with the =HALT() function (it’s the last one), so let’s just change Auto_Open to that cell:

Now we can safely click on the Enable content button and nothing will happen! We will stop at the =HALT() function but we can now inspect other cells and contents around this file.

Since the document is heavily obfuscated, we will want to somehow debug it – single step through it. In this particular case, this was not all that difficult, but keep in mind that with a very complex and obfuscated document, the following activities might be more difficult to perform (but still easier than performing static analysis).

What we will want to do here is (ab)use the =HALT() function to execute a formula in a single cell and then stop the execution. This will allow us to examine what happened, evaluate the formula and continue. In the example below, you can see that I copied contents of all cells under the first one (the original Auto_Open cell) and put =HALT() in the cell immediately after the first one. This will cause Excel to stop processing formulas:

We can now use Excel’s built-in evaluation. In order to do that we will right click on the first cell, select Run and then Step Into. This is what we will get:

Pretty cool! Notice that nice “Evaluate” button? Let’s see what it does:

So this is what the first cell does! Depending on how complex this is, we might need to click on “Step Into”, which will take us further down the rabbit hole (Hi Neo!) and we will start evaluating whatever is under this particular function. Since I was impatient I clicked on “Continue” – remember that I put our “breakpoint” with the =HALT() function and this will be kind of similar to pressing F9 in your debugger.

In this document there was a bunch of functions called by the top one – most of them actually deobfuscated various content which is now populated in “new” cells in this worksheet. Keep this in mind – a nasty document could actually change contents of our =HALT() cell, which would lead to the payload fully executing.

Since it was not the case here, we continue by shifting the =HALT() breakpoint to the next row, like this:

You can probably guess what we’ll do next – right click on the =REGISTER() cell, click on Run then Step Into, and this is what we get:

Let’s Evaluate this again – it should work because the cell that got executed before populated what this (currently executing) cell needs:

Interesting! The REGISTER() function allows us to create a defined name which will point to a function in an external DLL. Sounds fantastic for the attacker – what they are doing here is create a name called “bBpmgyvS” which will point to the CreateDirectoryA function in the Kernel32.dll library. It is quite clear that the attacker will want to create a directory on the local machine.

And now it is rinse and repeat – we use the same method to evaluate all other cells until we figure out what the document is doing. The one I was analyzing uses the same mechanism to create another name that points to URLDownloadToFileA from the URLMON.dll library, which is used to download the second stage binary.
The same mechanism is again used to create a name that points to ShellExecuteA function from the Shell32.dll library which executes the downloaded binary.

At the end, the attacker hides this sheet and shows a decoy one.

And this leads us to the end of this diary/tutorial. I hope you found it interesting and useful, and that it will help someone analyze such heavily obfuscated Excel 4 macro malicious files which, this time with help of Microsoft’s own Excel can be relatively easily dynamically analyzed.

Finally, I have to stress out one more time that you should be ultra careful when performing such an analysis since we will be executing malicious code.
 

--
Bojan
@bojanz
INFIGO IS

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

ISC Stormcast For Thursday, January 14th, 2021 https://isc.sans.edu/podcastdetail.html&#x3f;id=7328, (Thu, Jan 14th)

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

ISC Stormcast For Wednesday, January 13th, 2021 https://isc.sans.edu/podcastdetail.html&#x3f;id=7326, (Wed, Jan 13th)

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

Hancitor activity resumes after a hoilday break, (Wed, Jan 13th)

Introduction

Campaigns spreading Hancitor malware were active from October through December 2020, but Hancitor went quiet after 2020-12-17.  On Tuesday 2021-01-12, criminals started sending malicious spam (malspam) pushing Hancitor again.  Some people have already tweeted about this year's first wave of Hancitor.  See the links below.

Today's diary reviews recent Hancitor activity from Tuesday 2021-01-12, where we also saw Cobalt Strike after the initial infection.


Shown above:  Flow chart for recent Hancitor infection activity.

The malspam

On Tuesday 2021-01-12, malspam spreading used the same fake DocuSign template we saw several times last year.  These emails have a link to a Google Docs page.


Shown above:  Screenshot from one of the emails distributing Hancitor on Tuesday 2021-01-12.


Shown above:  Link from the email redirects to a page that can generate a Word document for Hancitor.


Shown above:  Word document with macros for Hancitor.

Infection traffic

As you might expect, traffic to the Google Docs page and clicking on the link generates a great deal of related web activity, mostly HTTPS traffic. Shortly after the Word document is sent, we find indicators of Hancitor and Cobalt Strike malware.  I've always seen Cobalt Strike when I test Hancitor in an Active Directory (AD) environment.  if you're investigating an actual Hancitor infection, be aware that it will likely send Cobalt Strike if the victim host is signed into an work environment that uses AD.


Shown above:  Traffic caused by the Google Docs page before the infection filtered in Wireshark.


Shown above:  Hancitor and Cobalt Strike traffic within an AD environment.

Indicators of Compromise (IOCs)

The following are indicators associated with Hancitor infections from Tuesday 2021-01-12.

Date/time of the six messages:

  • Tue, 12 Jan 2021 15:06:25 +0000 (UTC)
  • Tue, 12 Jan 2021 16:06:06 +0000 (UTC)
  • Tue, 12 Jan 2021 16:41:01 +0000 (UTC)
  • Tue, 12 Jan 2021 16:48:35 +0000 (UTC)
  • Tue, 12 Jan 2021 17:09:10 +0000 (UTC)
  • Tue, 12 Jan 2021 18:06:56 +0000 (UTC)

IP addresses the malspam was received from:

  • Received: from digital-negative.com ([179.154.63.198])
  • Received: from digital-negative.com ([74.85.247.234])
  • Received: from digital-negative.com ([181.137.227.228])
  • Received: from digital-negative.com ([104.161.24.86])
  • Received: from digital-negative.com ([23.236.75.32])
  • Received: from digital-negative.com ([112.15.74.137])

Spoofed sending addresses:

  • From: "DocuSign Signature  Service" <qybacy@digital-negative.com>
  • From: "DocuSign Signature and Invoice" <iqinica@digital-negative.com>
  • From: "DocuSign Electronic Signature and Invoice Service" <eupanic@digital-negative.com>
  • From: "DocuSign Electronic Signature " <uvizao@digital-negative.com>
  • From: "DocuSign Signature  Service" <nuxzoj@digital-negative.com>
  • From: "DocuSign Electronic Signature  Service" <zwtmicy@digital-negative.com>

Subject lines:

  • Subject: You received notification from DocuSign Electronic Service
  • Subject: You received notification from DocuSign Service
  • Subject: You got notification from DocuSign Electronic Signature Service
  • Subject: You got invoice from DocuSign Electronic Signature Service
  • Subject: You got notification from DocuSign Service
  • Subject: You received notification from DocuSign Electronic Signature Service

Links from the malspam:

  • hxxps://docs.google[.]com/document/d/e/2PACX-1vSEfjWipv61XyrbNDn1neBUGeHzEPM35pYN5QRYrpUy4X-sbHybYEZ7-b6Zf8yGyA_1e4wNj452FD_O/pub
  • hxxps://docs.google[.]com/document/d/e/2PACX-1vTiMxxKYdtOy98JFAiBaNe1W-VVdRGcZOZurDYA1jhcat-mcbcA8Uw7m_v4BvJ-H3o9m7ML_TtRNPQP/pub
  • hxxps://docs.google[.]com/document/d/e/2PACX-1vShuUk4DvIVthVxqc8UIUgZ7hOQzBQ1Dop8sXP73qBfS-JrlSrdIaZslExSyrr459kvaMmWbOAUkYii/pub
  • hxxps://docs.google[.]com/document/d/e/2PACX-1vRQ8skYzE8fzy9FnmU06fNCSEBTGwdYCxE1_NyLjxTCG7uEhpFtmI_IWAtk1FFmuQyAReDSuUCdyCFs/pub
  • hxxps://docs.google[.]com/document/d/e/2PACX-1vT_UMMUFR8J8IbN7rthTdttvciBU-17slZ2anuIq4A-8zT4xtF9ngzzyiEjlE8HSDZQ5tWu_w6HBFMf/pub
  • hxxps://docs.google[.]com/document/d/e/2PACX-1vQgYON0ZqbynIRhybfOxzkN8jUzIa-DkiYp-KOTxKzhFaDt2miDJBp14XJw8lMPHtU1tkIXDcwquIr-/pub

URLs that returned script to create the Word docs:

  • hxxp://savortrading[.]com/toweringly.php
  • hxxps://libifield.co[.]za/figs.php
  • hxxps://expertcircles[.]co[.]uk/assotiation.php
  • hxxps://libifield[.]co[.]za/oilcan.php
  • hxxp://3.133.244[.]105/irs.php

8 examples of downloaded Word docs (read: SHA256 hash - file name):

  • 080bade36015dd79925bab0975ac0f30f18424bdd1e7836d63c2dee350bdbd69 - 0112_528419802.doc
  • 2ac3b573d70c40c5c0fafe4e5914c723f2322a1c9cd76d232447654604ff8b76 - 0112_929792452.doc
  • 385425e94ed8ac21d7888550743b7a2b89afbeb51341713adb6da89cd63b5aff - 0112_203089882.doc
  • 7b013a271432cc9dea449ea9fcf727ed3caf7ce4cc6a9ba014b3dd880b5668dd - 0112_1079750132.doc
  • 8bcf45c2de07f322b8efb959e3cef38fb9983fdb8b932c527321fd3db5e444c8 - 0112_1005636132.doc
  • cab2a47456a2c51504a79ff24116a4db3800b099ec50d0ebea20c2c77739276d - 0112_722674781.doc
  • d6755718c70e20345c85d18c5411b67c99da5b2f8740d63221038c1d35ccc0b8 - 0112_153569242.doc
  • ed3fa9e193f75e97c02c48f5c7377ff7a76b827082fdbfb9d6803e1f7bd633ca - 0112_114086062.doc
  • Note: Each of the above files is 753,152 bytes in size.

SHA256 for 8 examples of DLL files dropped by the Word docs:

  • 00b2312dd63960434d09962ad3e3e7203374421b687658bd3c02f194b172bfe3
  • 0941090d3eb785dbf88fbfafffad34c4ab42877b279129616a455347883e5738
  • 43690eaf47245d69f4bda877c562852e4a9715955c2160345cb6cc84b18ca907
  • 82c9bc479ea92c1900422666792877e00256996ce2f931984115598ed2c26f23
  • 878319795a84ebfe5122d6fc21d27b4b94b3c28ad66679f841dec28ccc05e801
  • c3e06473c4c3d801c962e6c90ccbcab3d532fb5a6649077ea09cd989edf45eaf
  • cdcd5ee8b80d3a3863e0c55d4af5384522144011b071d00c9c71ae009305f130
  • edabef17fce2aaca61dbd17a57baf780cd82a2b0189b0cf3c5a7a3ca07e94a44
  • Note 1: Each of the above file is 570,368 bytes in size.
  • Note 2: Each file was saved at C:\Users\[username]\AppData\Roaming\Microsoft\Templates\W0rd.dll

Traffic to retrieve the Word doc:

  • port 443 - docs.google.com - HTTPS traffic
  • 104.31.80[.]93 port 80 - savortrading[.]com - GET /sacrifice.php

Hancitor post-infection traffic:

  • port 80 - api.ipify.org - GET /
  • 185.87.194[.]148 port 80 - fruciand[.]com - POST /8/forum.php

Binaries used to infect host with Cobalt Strike:

  • 47.254.175[.]0 port 80 - steroidi[.]pro - GET /2112.bin
  • 47.254.175[.]0 port 80 - steroidi[.]pro - GET /2112s.bin

Cobalt Strike Post-infection traffic:

  • 162.223.31[.]160 port 1080 - 162.223.31[.]160:1080 - GET /GvSL
  • 162.223.31[.]160 port 1080 - 162.223.31[.]160:1080 - GET /visit.js
  • 162.223.31[.]160 port 443 - HTTPS traffic

Final words

Hancitor has been active and evolving for years now, and it remains a notable presence in our current threat landscape.  This diary reviewed a recent infection on a vulnerable Windows host from malspam sent on Tuesday 2021-01-12.

Decent spam filters and best security practices should help most people avoid Hancitor infections. Default security settings in Windows 10 and Microsoft Office 2019 should prevent these these infections from happening.  However, it's a "cat-and-mouse" game, with malware developers developing new ways to circumvent security measures, while vendors update their software/applications/endpoint protection to address these new developments.  And malware distribution through email is apparently cheap enough to remain profitable for the criminals who use it.

A pcap of the infection traffic, some emails, and malware associated with today's diary 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.
2021. január 12.

Microsoft January 2021 Patch Tuesday, (Tue, Jan 12th)

This month we got patches for 83 vulnerabilities. Of these, 10 are critical, one was previously disclosed, and one is already being exploited according to Microsoft.

Amongst critical vulnerability, let’s start with the already being exploited CVE-2021-1647. It is related to a remote code execution (RCE) vulnerability affecting Microsoft Defender until version 1.1.17600. The CVSS for this vulnerability is 7.80.

There is also a RCE on Windows RPC Runtime (CVE-2021-1658). According to the advisory, it requires no user interaction, low privileges, and low attack complexity. This vulnerability had the highest CVSS score for this month: 8.80.

And finally, the previously disclosed one is a privilege escalation vulnerability affecting splwow64 (CVE-2021-1648). This zero-day has been publicly disclosed Google Project Zero (PZ2096) and the Zero Day Initiative (ZDI-CAN-11349 through 11351). According to ZDI advisory, the specific issue that may result in privilege escalation exists within the user-mode printer driver host process splwow64.exe due to lack of proper validation of user-supplied data. CVSS: 7.80.

See Renato's dashboard for a more detailed breakout: https://patchtuesdaydashboard.com

January 2021 Security Updates

Description CVE Disclosed Exploited Exploitability (old versions) current version Severity CVSS Base (AVG) CVSS Temporal (AVG) ASP.NET Core and Visual Studio Denial of Service Vulnerability %%cve:2021-1723%% No No Less Likely Less Likely Important 7.5 6.5 Active Template Library Elevation of Privilege Vulnerability %%cve:2021-1649%% No No Less Likely Less Likely Important 7.8 6.8 Azure Active Directory Pod Identity Spoofing Vulnerability %%cve:2021-1677%% No No Less Likely Less Likely Important 5.5 4.8 Bot Framework SDK Information Disclosure Vulnerability %%cve:2021-1725%% No No Less Likely Less Likely Important 5.5 4.8 Diagnostics Hub Standard Collector Elevation of Privilege Vulnerability %%cve:2021-1651%% No No Less Likely Less Likely Important 7.8 6.8 %%cve:2021-1680%% No No Less Likely Less Likely Important 7.8 6.8 GDI+ Remote Code Execution Vulnerability %%cve:2021-1665%% No No Less Likely Less Likely Critical 7.8 6.8 HEVC Video Extensions Remote Code Execution Vulnerability %%cve:2021-1644%% No No Less Likely Less Likely Important 7.8 6.8 %%cve:2021-1643%% No No Less Likely Less Likely Critical 7.8 7.0 Hyper-V Denial of Service Vulnerability %%cve:2021-1691%% No No Less Likely Less Likely Important 7.7 6.7 %%cve:2021-1692%% No No Less Likely Less Likely Important 7.7 6.7 Microsoft DTV-DVD Video Decoder Remote Code Execution Vulnerability %%cve:2021-1668%% No No Less Likely Less Likely Critical 7.8 6.8 Microsoft Defender Remote Code Execution Vulnerability %%cve:2021-1647%% No Yes Detected Detected Critical 7.8 7.0 Microsoft Edge (HTML-based) Memory Corruption Vulnerability %%cve:2021-1705%% No No Less Likely Less Likely Critical 4.2 3.8 Microsoft Excel Remote Code Execution Vulnerability %%cve:2021-1713%% No No Less Likely Less Likely Important 7.8 6.8 %%cve:2021-1714%% No No Less Likely Less Likely Important 7.8 6.8 Microsoft Office Remote Code Execution Vulnerability %%cve:2021-1711%% No No Less Likely Less Likely Important 7.8 6.8 Microsoft SQL Elevation of Privilege Vulnerability %%cve:2021-1636%% No No Less Likely Less Likely Important 8.8 7.7 Microsoft SharePoint Elevation of Privilege Vulnerability %%cve:2021-1712%% No No Less Likely Less Likely Important 8.0 7.0 %%cve:2021-1719%% No No Less Likely Less Likely Important 8.0 7.0 Microsoft SharePoint Server Remote Code Execution Vulnerability %%cve:2021-1707%% No No More Likely More Likely Important 8.8 7.7 Microsoft SharePoint Server Tampering Vulnerability %%cve:2021-1718%% No No Less Likely Less Likely Important 8.0 7.0 Microsoft SharePoint Spoofing Vulnerability %%cve:2021-1641%% No No Less Likely Less Likely Important 4.6 4.0 %%cve:2021-1717%% No No Less Likely Less Likely Important 4.6 4.0 Microsoft Windows Media Foundation Remote Code Execution Vulnerability %%cve:2021-1710%% No No Less Likely Less Likely Important 7.8 6.8 Microsoft Word Remote Code Execution Vulnerability %%cve:2021-1715%% No No Less Likely Less Likely Important 7.8 6.8 %%cve:2021-1716%% No No Less Likely Less Likely Important 7.8 6.8 Microsoft splwow64 Elevation of Privilege Vulnerability %%cve:2021-1648%% Yes No Less Likely Less Likely Important 7.8 7.0 NTLM Security Feature Bypass Vulnerability %%cve:2021-1678%% No No Less Likely Less Likely Important 4.3 3.8 Remote Procedure Call Runtime Remote Code Execution Vulnerability %%cve:2021-1658%% No No Less Likely Less Likely Critical 8.8 7.7 %%cve:2021-1660%% No No Less Likely Less Likely Critical 8.8 7.7 %%cve:2021-1664%% No No Less Likely Less Likely Important 8.8 7.7 %%cve:2021-1666%% No No Less Likely Less Likely Critical 8.8 7.7 %%cve:2021-1667%% No No Less Likely Less Likely Critical 8.8 7.7 %%cve:2021-1671%% No No Less Likely Less Likely Important 8.8 7.7 %%cve:2021-1673%% No No Less Likely Less Likely Critical 8.8 7.7 %%cve:2021-1700%% No No Less Likely Less Likely Important 8.8 7.7 %%cve:2021-1701%% No No Less Likely Less Likely Important 8.8 7.7 TPM Device Driver Information Disclosure Vulnerability %%cve:2021-1656%% No No Less Likely Less Likely Important 5.5 4.8 Visual Studio Remote Code Execution Vulnerability %%cve:2020-26870%% No No Less Likely Less Likely Important 7.0 6.1 Windows (modem.sys) Information Disclosure Vulnerability %%cve:2021-1699%% No No Less Likely Less Likely Important 5.5 4.8 Windows AppX Deployment Extensions Elevation of Privilege Vulnerability %%cve:2021-1642%% No No Less Likely Less Likely Important 7.8 6.8 %%cve:2021-1685%% No No Less Likely Less Likely Important 7.3 6.4 Windows Bluetooth Security Feature Bypass Vulnerability %%cve:2021-1683%% No No Less Likely Less Likely Important 5.0 4.4 %%cve:2021-1684%% No No Less Likely Less Likely Important 5.0 4.4 %%cve:2021-1638%% No No Less Likely Less Likely Important 7.7 6.7 Windows CSC Service Elevation of Privilege Vulnerability %%cve:2021-1652%% No No Less Likely Less Likely Important 7.8 6.8 %%cve:2021-1653%% No No Less Likely Less Likely Important 7.8 6.8 %%cve:2021-1654%% No No Less Likely Less Likely Important 7.8 6.8 %%cve:2021-1655%% No No Less Likely Less Likely Important 7.8 6.8 %%cve:2021-1659%% No No Less Likely Less Likely Important 7.8 6.8 %%cve:2021-1688%% No No Less Likely Less Likely Important 7.8 6.8 %%cve:2021-1693%% No No Less Likely Less Likely Important 7.8 6.8 Windows CryptoAPI Denial of Service Vulnerability %%cve:2021-1679%% No No Less Likely Less Likely Important 6.5 5.7 Windows DNS Query Information Disclosure Vulnerability %%cve:2021-1637%% No No Less Likely Less Likely Important 5.5 4.8 Windows Docker Information Disclosure Vulnerability %%cve:2021-1645%% No No Less Likely Less Likely Important 5.0 4.4 Windows Event Logging Service Elevation of Privilege Vulnerability %%cve:2021-1703%% No No Less Likely Less Likely Important 7.8 6.8 Windows Event Tracing Elevation of Privilege Vulnerability %%cve:2021-1662%% No No Less Likely Less Likely Important 7.8 6.8 Windows Fax Compose Form Remote Code Execution Vulnerability %%cve:2021-1657%% No No Less Likely Less Likely Important 7.8 6.8 Windows GDI+ Information Disclosure Vulnerability %%cve:2021-1708%% No No Less Likely Less Likely Important 5.7 5.0 Windows Graphics Component Information Disclosure Vulnerability %%cve:2021-1696%% No No Less Likely Less Likely Important 5.5 4.8 Windows Hyper-V Elevation of Privilege Vulnerability %%cve:2021-1704%% No No Less Likely Less Likely Important 7.3 6.4 Windows InstallService Elevation of Privilege Vulnerability %%cve:2021-1697%% No No Less Likely Less Likely Important 7.8 6.8 Windows Installer Elevation of Privilege Vulnerability %%cve:2021-1661%% No No Less Likely Less Likely Important 7.8 6.8 Windows Kernel Elevation of Privilege Vulnerability %%cve:2021-1682%% No No Less Likely Less Likely Important 7.0 6.1 Windows LUAFV Elevation of Privilege Vulnerability %%cve:2021-1706%% No No Less Likely Less Likely Important 7.3 6.4 Windows Multipoint Management Elevation of Privilege Vulnerability %%cve:2021-1689%% No No Less Likely Less Likely Important 7.8 6.8 Windows NT Lan Manager Datagram Receiver Driver Information Disclosure Vulnerability %%cve:2021-1676%% No No Less Likely Less Likely Important 5.5 4.8 Windows Print Spooler Elevation of Privilege Vulnerability %%cve:2021-1695%% No No Less Likely Less Likely Important 7.8 6.8 Windows Projected File System FS Filter Driver Information Disclosure Vulnerability %%cve:2021-1663%% No No Less Likely Less Likely Important 5.5 4.8 %%cve:2021-1670%% No No Less Likely Less Likely Important 5.5 4.8 %%cve:2021-1672%% No No Less Likely Less Likely Important 5.5 4.8 Windows Remote Desktop Protocol Core Security Feature Bypass Vulnerability %%cve:2021-1674%% No No Less Likely Less Likely Important 8.8 7.7 Windows Remote Desktop Security Feature Bypass Vulnerability %%cve:2021-1669%% No No Less Likely Less Likely Important 8.8 7.7 Windows Remote Procedure Call Runtime Elevation of Privilege Vulnerability %%cve:2021-1702%% No No Less Likely Less Likely Important 7.8 6.8 Windows Runtime C++ Template Library Elevation of Privilege Vulnerability %%cve:2021-1650%% No No Less Likely Less Likely Important 7.8 6.8 Windows Update Stack Elevation of Privilege Vulnerability %%cve:2021-1694%% No No Less Likely Less Likely Important 7.5 6.5 Windows WLAN Service Elevation of Privilege Vulnerability %%cve:2021-1646%% No No Less Likely Less Likely Important 6.6 5.8 Windows WalletService Elevation of Privilege Vulnerability %%cve:2021-1681%% No No Less Likely Less Likely Important 7.8 6.8 %%cve:2021-1686%% No No Less Likely Less Likely Important 7.8 6.8 %%cve:2021-1687%% No No Less Likely Less Likely Important 7.8 6.8 %%cve:2021-1690%% No No Less Likely Less Likely Important 7.8 6.8 Windows Win32k Elevation of Privilege Vulnerability %%cve:2021-1709%% No No More Likely More Likely Important 7.0 6.1

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter

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

ISC Stormcast For Tuesday, January 12th, 2021 https://isc.sans.edu/podcastdetail.html&#x3f;id=7324, (Tue, Jan 12th)

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

Using the NVD Database and API to Keep Up with Vulnerabilities and Patches - Tool Drop: CVEScan (Part 3 of 3), (Mon, Jan 11th)

Now with a firm approach to or putting an inventory and using the NVD API (https://isc.sans.edu/forums/diary/Using+the+NIST+Database+and+API+to+Keep+Up+with+Vulnerabilities+and+Patches+Part+1+of+3/26958/ and https://isc.sans.edu/forums/diary/Using+the+NIST+Database+and+API+to+Keep+Up+with+Vulnerabilities+and+Patches+Playing+with+Code+Part+2+of+3/26964/), for any client I typically create 4 inventories:

  • Devices/appliances and applications that are exposed at the perimeter (public internet or other firewalled trust boundary)
  • Server applications and devices/appliances
  • Workstation  applications
  • IOT devices (in workstation or dedicated VLANs/subnets)

As we've noted, you can use nmap as a short-cut for a first draft of any products that have listening ports.  It's not perfect, but it gives you a decent starting point, or something to "diff" against from one scan to the next.  To just get your the CPE list for a subnet or range of IPs, this does the trick nicely:

nmap -p <ports> -sV --open <subnet> | grep -i cpe | awk -F" "  "{print $NF}" | sort | uniq

(-F gives the delimiter, the print command prints the $NF field.  Since $NF is the number of fields, it prints the last one, which happens to be the CPE).


Let's focus on the first one of these target list - perimeter services for an actual customer.
Starting with Cisco FTD (Firepower Threat Defense), we see that even the titles vary from version to version, and the versions are very granular for this product
>type official-cpe-dictionary_v2.3.xml | grep -i title | grep -i cisco | grep -i firepower | grep -i -v management | grep -i "threat defense"
( excerpt only)

    <title xml:lang="en-US">Cisco Firepower Threat Defense (FTD) 6.5.0.3</title>
    <title xml:lang="en-US">Cisco Firepower Threat Defense 6.5.0.5</title>
    <title xml:lang="en-US">Cisco Firepower Threat Defense 6.6.0</title>
    <title xml:lang="en-US">Cisco Firepower Threat Defense (FTD) 6.6.1</title>

Since this is such a lengthy (and version-specific) list, let's try to consolidate.  From cisco's download site, the latest and recommended version (as of today) is 6.6.1.  Knowing that this client will be "close to current" on this, a quick look for FTD 6.6:

"cpe:2.3:a:cisco:firepower_threat_defense:6.6.*:*:*:*:*:*:*:*"

gives us these hits:

cpe:2.3:a:cisco:firepower_threat_defense:6.6.0:*:*:*:*:*:*:*
cpe:2.3:a:cisco:firepower_threat_defense:6.6.1:*:*:*:*:*:*:*

So our final input data file has the following (hostname followed by the cpe "blanket" query):

"dc01-fw01","cpe:2.3:a:cisco:firepower_threat_defense:6.6.*"

Let's add in the Citrix Netscaler Gateway (now called ADC).  The ADC is a pretty versatile appliance, it can be a load balancer, a firewall, a front-end for a Citrix farm, or (just like everyone else these days) and SD-WAN solution.  In our case it's a front-end for a Citrix XenServer farm.
The current version is 13.x, so let's search for all of 13.*:

cpe:2.3:o:citrix:application_delivery_controller_firmware:13.*

Finally, this client also has an application that uses Apache Struts, which they have been very particular about monitoring since the Equifax breach:
The current stable version is 2.5.26, let's hunt for cpe:

cpe:2.3:a:apache:struts:2.5.*

So our perimeter input file will look like this (again, the fields are hostname,cpe):

"dc01-fw01","cpe:2.3:a:cisco:firepower_threat_defense:6.6.*"
"dc01-adc01","cpe:2.3:o:citrix:application_delivery_controller_firmware:13.*"
"dc01-appsrv01","cpe:2.3:a:apache:struts:2.5.*"

We'll call our code with (note the input filename):

cvescan.ps1 -i Customername.Perimeter.in -d 90

This will give us the CVEs for the indicated platforms, for the last 90 days, sorted from high severity to low.

And our code will look like the listing below (maintained at https://github.com/robvandenbrink/CVEScan ):

##########################################################################

# CVESCAN

# Version 1.iscisc0

# Assess an inventoried infrastructure from pre-inventoried CPEs and published CVEs

#

# Hosted at https://github.com/robvandenbrink/CVEScan

#

# Further documentation at:

#         https://isc.sans.edu/forums/diary/Using+the+NIST+Database+and+API+to+Keep+Up+with+Vulnerabilities+and+Patches+Part+1+of+3/26958/

#         https://isc.sans.edu/forums/diary/Using+the+NIST+Database+and+API+to+Keep+Up+with+Vulnerabilities+and+Patches+Playing+with+Code+Part+2+of+3/26964/

#         https://isc.sans.edu/forums/diary/Using+the+NVD+Database+and+API+to+Keep+Up+with+Vulnerabilities+and+Patches+Tool+Drop+CVEScan+Part+3+of+3/26974/

#

# Syntax:

#         CVEScan.ps1  -i <input file> -d <how many days back to look>

##########################################################################

 

param (

[alias("i")]

$infile,

[alias("d")]

$daterange

)

 

function helpsyntax {

write-host "CVESCAN: Assess a known inventory against current CVEs"

write-host "Parameters:"

write-host "    -i          <input file name>"

write-host "Optional Parameters:"

write-host "    -d          <CVEs for last "n" days>"

write-host "cvescan -i perimeterdevices.in -d 60"

exit

}

 

if ($daterange -eq 0) { write-host "ERROR: Must specify input filename and date range`n" ; helpsyntax }

 

# setup

$allCVEs = @()

$CVEDetails = @()

 

$apps = Import-Csv -path $infile

$now = get-date

$outfile = $infile.replace(".in",$now.tostring("yyyy-MM-dd_hh-mm")+"_"+$daterange+"-days.html")

$StartDate = $now.adddays(-$daterange).tostring("yyyy-MM-dd")+ "T00:00:00:000%20UTC-00:00"

 

# Collect host to CVEs table

foreach ($app in $apps) {

    $request = "https://services.nvd.nist.gov/rest/json/cves/1.0?modStartDate=" + $StartDate + "&cpeMatchString=" + $app.cpe

    $CVEs = (invoke-webrequest $request | ConvertFrom-Json).result.CVE_items.cve.CVE_data_meta.id

    foreach ($CVE in $CVEs) {

        $tempobj = [pscustomobject]@{

            Hostname = $app.hostname

            CVE = $CVE

           }

        $allCVEs += $tempobj

        }

    }

 

$Header = @"

<style>

TABLE {border-width: 1px; border-style: solid; border-color: black; border-collapse: collapse;}

TH {border-width: 1px; padding: 3px; border-style: solid; border-color: black; background-color: #6495ED;}

TD {border-width: 1px; padding: 3px; border-style: solid; border-color: black;VERTICAL-ALIGN: TOP; font-size: 15px}

</style>

"@

 

$filepath = gci $infile

 

$Title = @()

$Title += [pscustomobject]@{ Organization="Scope";bbb=$filepath.basename.split(".")[1] }

$Title += [pscustomobject]@{ Organization="From Date:"; bbb=($now.adddays(-$daterange).tostring("yyyy-MM-dd")) }

$Title += [pscustomobject]@{ Organization="To Date:";bbb=$now.tostring("yyyy-MM-dd") }

 

(($Title | convertto-HTML -title "CVE Summary" -Head $header) + "<br><br><br>").replace("bbb",$filepath.basename.split(".")[0]) | out-file  $outfile

 

(($allCVEs | Convertto-HTML -Head $header) + "<br><br>") | out-file -append $outfile

 

#parse out just the CVEs

$justCVEs = $allCVEs | select CVE | Sort-Object | Get-Unique -AsString

 

# collect CVE info

foreach ($CVE in $justCVEs) {

    $h = ""

    $request = "https://services.nvd.nist.gov/rest/json/cve/1.0/" + $CVE.CVE

    $cvemetadata = (invoke-webrequest $request) | convertfrom-json

    $CVEURLs = $cvemetadata.result.cve_items.cve.references.reference_data.url

    $affectedApps = ($cvemetadata.result.CVE_items.configurations.nodes.children.cpe_match) | where {$_.vulnerable -eq "true" } | select cpe23Uri,versionendincluding

 

    # add the affected hosts back into the detailed listing

    # write-host $CVE.CVE

    foreach ($ac in $allCVEs) {

        if ($ac.CVE -eq $CVE.CVE) {

            $h += ($ac.Hostname + "<br>")

            }

        }

 

    $tempobj = [pscustomobject]@{

        CVE = $CVE.CVE

        Hosts = $h

        # Just the datestamp, remove the clock time

        "Published Date" = ($cvemetadata.result.cve_items.publishedDate).split("T")[0]

        "CVE Description" = $cvemetadata.result.cve_items.cve.description.description_data.value

        Vector = $cvemetadata.result.CVE_items.impact.basemetricv3.cvssv3.attackVector

        "Attack Complexity" = $cvemetadata.result.CVE_items.impact.basemetricv3.cvssv3.attackComplexity

        "User Interaction" = $cvemetadata.result.CVE_items.impact.basemetricv3.cvssv3.userInteraction

        "Base Score" = $cvemetadata.result.CVE_items.impact.basemetricv3.cvssv3.baseScore

        "Severity" = $cvemetadata.result.CVE_items.impact.basemetricv3.cvssv3.baseSeverity

        "Reference URLs" = ($CVEURLs | ft -hidetableheaders | out-string).replace("`n","`n<br>")

        "Affected Apps" = ($affectedapps | ft -HideTableHeaders | out-string).replace("`n","`n<br>")

        }

    $CVEDetails += $tempobj

    }

 

# to just view the detailed output

# $CVEDetails | out-gridview

 

# to output to HTML

$Header = @"

<style>

TABLE {border-width: 1px; border-style: solid; border-color: black; border-collapse: collapse;}

TH {border-width: 1px; padding: 3px; border-style: solid; border-color: black; background-color: #6495ED;}

TD {border-width: 1px; padding: 3px; border-style: solid; border-color: black;VERTICAL-ALIGN: TOP; font-size: 15px}

</style>

"@

 

# Note that the <br> tags get escaped, these are un-escaped below

# this is a horrible hack, but I can't find a decent "elegant" way to do this

# ... in less than 5x the time it took me to do it the ugly way  :-)

 

 

(($CVEDetails | sort -descending -property "Base Score" )| Convertto-HTML -Head $header) -replace '&lt;br&gt;', '<br>' | out-file  -append $outfile

 

Our output is dumped into: Customername.Perimeter-dateandtime-days.html, so for this example and today's date: Customername.Perimeter2021-01-11_09-50_90-days.html (note that the output filename mirrors the input filename - change that if you need)

Note also in the output that I had to un-escape all of the line breaks that were in the output (sometimes the quick and dirty methods win over perfect code)

Looking at that file, our output (truncated) looks as below.  The lead in is the customer and date range info, followed by the CVE's found on which host.  The final table contains all the CVE details, in descending / unique order of "Base Score" of Severity:

 


 As mentioned, the code is on my github - use it or modify it to suit your needs.  For the most part it's a short list of API requests, with parsing, formatting and I/O bolted on - so if you'd prefer this to be in a different language of course feel free!

If you were able to head off a "situation" in your environment, or if that nmap trick finds something unexpected in your environment, please do post to our comment form (subject to NDA's of course)

===============
Rob VandenBrink
rob@coherentsecurity.com

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

New version of Sysinternals released, Process Hollowing detection added in Sysmon, new registry access detection added to Procmon https://docs.microsoft.com/en-us/sysinternals/, (Mon, Jan 11th)

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

ISC Stormcast For Monday, January 11th, 2021 https://isc.sans.edu/podcastdetail.html&#x3f;id=7322, (Mon, Jan 11th)

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

Maldoc Analysis With CyberChef, (Sun, Jan 10th)

In diary entry "Maldoc Strings Analysis" I show how to analyze a malicious document, by extracting and dedocing strings with command-line tools.

In this video, I analyze the same malicious Word document, using CyberChef only. This is possible, because this particular maldoc contains a very long string with the payload, and this string can be extracted without parsing the structure of this .doc file.

I pasted the recipe on pastebin here.

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.
2021. január 9.

Maldoc Strings Analysis, (Sat, Jan 9th)

As I announced in my diary entry "Strings 2021", I will write some diary entries following a simpler method of malware analysis, namely looking for strings inside malicious files using the strings command. Of course, this simple method will not work for most malware samples, but I still see enough samples for which this method will work.

Like this recent malicious Word document. When you analyze this sample with oledump.py, you will find an obfuscated PowerShell command inside the content of the Word document.

But we are not going to use oledump this time. We will look directly for strings inside the document, using my tool strings.py (similar to the strings command, but with some extra features).

When we run strings.py with option -a on the sample, a report with statistics will be produced:

We see that strings.py extracted 1549 strings, and that the longest string is characters bytes long.

That is unusual for a Word document, to contain such a long string. We run strings.py again, now with option -n 15000: this specifies that the minimum length of the strings extracted by strings.py should be 15000. Since there is only one string that is longer than 15000 in this sample, we will see the longest string (and only the longest string, no other strings):

This looks like a BASE64 string (ending with ==), except that there are a lot of repeating characters that are not BASE64 characters: ] and [.

What we have here, is obfuscation through repeated insertion of a unique string. I explain this in detail in my diary entry "Obfuscation and Repetition".

]b2[ is propably the string that is inserted over and over again to obfuscate the original string. To be sure, we can use my ad-hoc tool deobfuscate-repetitions.py:

So the repeating string actually seems to be ]b2[s (appearing 2028 times), and when you removing this repeating string, the string that remains starts with cmd cmd ...

My tool deobfuscate-repetitions.py will continue running looking for other potential repeating strings, but it's clear that we found the correct one here, so we can just stop my tool with control-C.

And now that we used my tool to detect repeating strings, we will use it to deobfuscate the original string. This is done by using option -f (find) to find a deobfuscated string that contains a string we specify, cmd in this example:

And what we see here is a PowerShell command with a BASE-64 encoded script as argument.

If we still had any doubts if this was a malicious document, then this is a clear result that the sample is malicious.

And up til now, we didn't use any special tool to look inside the malicious Word document (.doc): just the strings command.

For this sample, we don't need to understand the structure of a Word document, or be familiar with a tool like oledump.py to peek inside a Word document. You just need some familiarity with the command-line, and be able to run the strings command with some options.

If your objective was to determine if this Word document is malicious or not, then you have succeeded. Just by using a strings command.

If your objective was to figure out what this Word document does, then we need to analyze the PowerShell command.

Tomorrow, I will publish a video where I do the full analysis with CyberChef. Here I will continue with command-line tools.

Next, we use my base64dump.py tool to find and decode the BASE64 script:

Like all BASE64-encoded PowerShell scripts passed as an argument, the script is in UNICODE. We use option -t utf16 to transform it to ASCII:

T

What we see here, is an obfuscated PowerShell script. When we take a close look, we can see fragments of urls. Strings containing URL fragments are concatenated in this PowerShell script. We will remove the concatenation operator (+) and other characters to reasemble the fragments, using command tr:

So we start to see some words, like family, but we still need to remove some characters, like the single quote:

And parentheses:

So now we have something that looks like a URL, except that the protocol is not what we expect (HTTP or HTTPS). We can use my tool re-search.py to extract the URLs:

If you want to understand why we have ss and s as protocol, and why @ terminates most URLs, we still need to do some analysis.

First, we use sed to put a newline character after each ; (semicolon), to have each PowerShell statement on a separate line, and make the script more readable:

And then we grep for family to select the line with URLs:

Notice here that the protocol of each URL contains string ]b2[s, and that there is a call to method replace to replace this string with string http.

Let's do this with sed ([ and ] have special meaning in regular expressions used by sed, so we need to escape these characters: \[ and \]):

Finally, we have complete URLs. If we use re-search again, to extract the URLs, we get a single line:

This time, re-search is not extracting indivudual URLs. That's because of the @ character: this is a valid character in URLs, it is used to precede the protocol with credentials (username:password@hxxp://example[.]com). But this is not what is done in this PowerShell script. In this script, there are several URLs, and the separator is the @ character. So we replace the @ character with a newline:

And finally, re-search.py gives us a list of URLs:

For this sample, extracting the malicious PowerShell script is quite easy, just using the strings command and a string replacement. Decoding the script to extract IOCs takes more steps, all done with command line tools.

In next diary entry, I will publish a video showing the analysis of the same sample with CyberChef.

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.
2021. január 8.

Using the NIST Database and API to Keep Up with Vulnerabilities and Patches - Playing with Code (Part 2 of 3), (Fri, Jan 8th)

Building on yesterday's story - now that we have an inventory built in CPE format, let's take an example CVE from that and write some code, what's in the NVD database (and API) that you can access, then use in your organization?

First, let's play with CVE-2020-24436, which is an Acrobat Reader vulnerability.  In PowerShell, let's construct our query, then from the results pull out all the bits that we're interested in.

$request = "https://services.nvd.nist.gov/rest/json/cve/1.0/CVE-2020-24436"
$cvemetadata = ( (invoke-webrequest $request) | convertfrom-json)

Let's start with the Published Date.  Note again that there's also a "last modified" date - the idea being that if a CVE gets updated that the modified date will reflect that.  Even looking at that briefly though that "last modified" date seems to be programatic, so I think it's getting changed when folks don't intend it - my first check was a Peoplesoft vuln from 2017, it had a 2020 last modified date for no reason I could see.  Anyway, here's the published date:

$PublishedDate = $cvemetadata.result.cve_items.publishedDate
$PublishedDate

2020-11-05T20:15Z

Next, the text description.  This is where the "traditional" CVE delivery paths fall down - they generally give you get the CVE number, then this text description, maybe a severity score.  This is fine for news stories or your report to management, but it's not something you can "monitor" when hundreds of them fly by every day.  Sorry about the rant, but I guess that's why we're playing with this code, so that you can build your own delivery mechanism for your organization.  Anyway, back to the text description:

$CVEDesc = $cvemetadata.result.cve_items.cve.description.description_data.value

$CVEDesc
Acrobat Pro DC versions 2020.012.20048 (and earlier), 2020.001.30005 (and earlier) and 2017.011.30175 (and earlier) are affected by an out-of-bounds write vulnerability that could result in writing past the end of an allocated memory structure. An attacker could leverage this vulnerability to execute code in the context of the current user. This vulnerability requires user interaction to exploit in that the victim must open a malicious document

The Reference URLs that may have more detail (usually there's a vendor URL in this list):

$CVEURLs=$cvemetadata.result.cve_items.cve.references.reference_data.url
$CVEURLs
https://helpx.adobe.com/security/products/acrobat/apsb20-67.html
https://www.zerodayinitiative.com/advisories/ZDI-20-1355/

The data on severity and scope (what we used to call the CVSS score):

$CVE_CVSSv3Data = $cvemetadata.result.CVE_items.impact.basemetricv3.cvssv3
$CVE_CVSSv3Data
version               : 3.1
vectorString          : CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
attackVector          : LOCAL
attackComplexity      : LOW
privilegesRequired    : NONE
userInteraction       : REQUIRED
scope                 : UNCHANGED
confidentialityImpact : HIGH
integrityImpact       : HIGH
availabilityImpact    : HIGH
baseScore             : 7.8
baseSeverity          : HIGH

 

We know what's installed on our affected host, but what versions of the application are affected by this CVE?  Note that list gives you vulnerable versions ($_.vulnerable = "True") and versions that are not affected ($_.vulnerabile = "False")

$CVEAffectedApps=$cvemetadata.result.CVE_items.configurations.nodes.children.cpe_match

$CVEAffectedApps

vulnerable cpe23Uri                                                   versionEndIncluding
---------- --------                                                   -------------------
      True cpe:2.3:a:adobe:acrobat:*:*:*:*:classic:*:*:*              20.001.30005       
      True cpe:2.3:a:adobe:acrobat_dc:*:*:*:*:classic:*:*:*           17.011.30175       
      True cpe:2.3:a:adobe:acrobat_dc:*:*:*:*:continuous:*:*:*        20.012.20048       
      True cpe:2.3:a:adobe:acrobat_reader:*:*:*:*:classic:*:*:*       20.001.30005       
      True cpe:2.3:a:adobe:acrobat_reader_dc:*:*:*:*:classic:*:*:*    17.011.30175       
      True cpe:2.3:a:adobe:acrobat_reader_dc:*:*:*:*:continuous:*:*:* 20.012.20048       
     False cpe:2.3:o:apple:mac_os:-:*:*:*:*:*:*:*                                        
     False cpe:2.3:o:microsoft:windows:-:*:*:*:*:*:*:* 

Winnowing this down to just the vulnerable versions:

($cvemetadata.result.CVE_items.configurations.nodes.children.cpe_match) | where {$_.vulnerable -eq "true" }

vulnerable cpe23Uri                                                   versionEndIncluding
---------- --------                                                   -------------------
      True cpe:2.3:a:adobe:acrobat:*:*:*:*:classic:*:*:*              20.001.30005       
      True cpe:2.3:a:adobe:acrobat_dc:*:*:*:*:classic:*:*:*           17.011.30175       
      True cpe:2.3:a:adobe:acrobat_dc:*:*:*:*:continuous:*:*:*        20.012.20048       
      True cpe:2.3:a:adobe:acrobat_reader:*:*:*:*:classic:*:*:*       20.001.30005       
      True cpe:2.3:a:adobe:acrobat_reader_dc:*:*:*:*:classic:*:*:*    17.011.30175       
      True cpe:2.3:a:adobe:acrobat_reader_dc:*:*:*:*:continuous:*:*:* 20.012.20048       

 

Now with some code written, on Monday we'll string everything together into a useful, complete reporting tool that you can use.

===============
Rob VandenBrink
rob@coherentconsulting.com

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

ISC Stormcast For Friday, January 8th, 2021 https://isc.sans.edu/podcastdetail.html&#x3f;id=7320, (Fri, Jan 8th)

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

Directly related to today's main story on CPE/CVEs - Code Exec in Cisco Jabber, all platforms https://nvd.nist.gov/vuln/detail/CVE-2020-26085, (Thu, Jan 7th)

=============== Rob VandenBrink

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