In June 2024, security researchers published their analysis of a novel implant dubbed “MuddyRot”(aka “BugSleep“). This remote access tool (RAT) gives operators reverse shell and file input/output (I/O) capabilities on a victim’s endpoint using a bespoke command and control (C2) protocol. This blog will demonstrate the practice and methodology of reversing BugSleep’s protocol, writing a functional C2 server, and detecting this traffic with Snort. 

Key findings 

• BugSleep implant implements a bespoke C2 protocol over plain TCP sockets. 
• BugSleep operators have demonstrated multiple file-obfuscation techniques to avoid detection. 
• BugSleep implements reverse shell, file I/O, and persistence capabilities on the target system. 

Sending and receiving data 

This blog will use sample b8703744744555ad841f922995cef5dbca11da22565195d05529f5f9095fbfca for analysis. Two of the lowest functions in the C2 stack, referred to as SendSocket (FUN_1400034c0) and ReadSocket (FUN_140003390), are very light wrappers for the send and receive API functions and handle payload encryption. They include some error handling by attempting to send or receive data 10 times before failing.  

This protocol uses a pseudo-TLV (Type Length Value) structure with only two types: integer or string. Integers are sent as little-endian 4- or 8-byte values, and strings are prepended with the 4-byte value of its length. Payloads are then encrypted by subtracting a static value from each byte in the buffer (in this sample it is three).  

Figure 1: Example of data encryption used by BugSleep

There are two main functions for handling C2 communications: C2Loop (FUN_1400012c0) and CommandHandler (FUN_1400028a0). C2Loop is responsible for setting up socket connections with the server and sending a beacon, while CommandHandler is responsible for processing and executing commands from the server. 

After setting up the socket connection, the implant beacons (FUN_140003d80) to the C2 server for a command. The beacon is a StringMsg in the form ComputerName/Username. If the server responds with an IntegerMsg equal to 0x03, BugSleep will terminate itself. We suspect this is remnants of an old kill command or an emergency kill without the overhead of reading the real kill command later. 

Each BugSleep command is sent as an IntegerMsg after the beacon response. The following enumeration defines all the command IDs discovered. 

Phoning home 

The implant communicates using plain TCP sockets, which can be seen using a Netcat listener and Wireshark. 

Recalling the message encryption demonstrated in Figure 1, the beacon can be decrypted with a little bit of Python (Figure 4). This will be used again when building the rest of the C2 server.  

Python C2 server 

With an understanding of the protocol basics, it is time to start building the C2 server. Full source code can be found here. 

Beacon 

As mentioned earlier, the BugSleep beacon function sends a StringMsg and reads an IntegerMsg response from the server. Since the IntegerMsg returned can be anything but 0x03, we returned the length of the Computer Name/Username string received by the server.

Ping command 

The simplest command to implement is the Ping command. It has the command ID of 0x63 (BugSleep subtracts one from whatever ID it receives). The code is simple: send back 4 bytes.  

Once the beacon comes in, the server is responsible for: 

1. Sending 4 bytes for beacon response 
2. Sending 4 bytes for Ping command ID 
3. Reading 4 bytes of Ping data 

The ping command was observed sending back 4 bytes recently allocated on the heap, so it’s not guaranteed to know what that data looks like. To validate things are really working, a breakpoint can be set in WinDbg and memory set manually before being sent. 

File commands 

The next set of commands are responsible for downloading files onto the compromised system or uploading files to the C2 server (PutFile and GetFile, respectively). These commands are inverses of each other, so only the GetFile command will be discussed in detail. The methodology was to trace each call to SendSocket or ReadSocket and implement the response for that call in Python. In CommandHandler, the implant reads the length and value off the wire. This is the file to be retrieved.  

The CmdGetFile function opens the target file and chunks it over the socket one page at a time. The list of SendSocket calls is as follows: 

The PutFile command differs slightly from the GetFile command with how it uses pointer math to process incoming pages. 

This translates to each page starting with a 4-byte page number followed by 1020 bytes (or 0x3fc) of file data, which the GetFile command does not do; it sends full 1024-byte pages of file data without page numbers. 

Reverse shell 

The last command is the reverse shell. This is the most complex because it requires many reads and writes over the socket. The disassembly is rather long and difficult to keep track of the socket calls, so we have omitted it. Effectively, the implant spawns a cmd.exe process (FUN_1400016e0) and reads the command to execute from the socket. The shell command and its output are marshaled between the processes via pipes during the session. The complexity of this operation comes from BugSleep incrementally reporting return values from pipe API calls while attempting to read shell output (FUN_140003840). The implant will enter this loop of reading commands and sending output until it receives the string “terminaten”.  

The rest of the commands are less complex but have been implemented and are viewable here. 

Snort detection 

This server gives Talos the ability to emulate any number of conversations between BugSleep and its operators. This traffic is crucial for writing and validating our detections’ performance in the wild. 

The initial candidate for detection would be the beacon. It is the first opportunity to shut down communications, isolating any BugSleep instance from receiving commands. It was observed that each beacon has the form of <len><data>, where data is sub_string(COMPUTER_NAME + “/” + USERNAME, 3). This string is not long or static, which makes it a poor candidate for a fast_pattern; however, recall that each beacon is prepended with a 4-byte length of this string. A Computer Name/Username string from any given victim is unlikely to be longer than 255 characters. This means most length fields are going to look like |XX 00 00 00| or |XX FD FD FD| when encoded. This could be a quick match, early in the stream, at a static offset, making it a decent fast_pattern candidate. 

 This will work but is likely to cause false-positives (FP) in the wild. Every sample of BugSleep was seen using port 443. The implant is also reaching outside the network to a C2 server, so traffic to be inspected by this rule can be reduced using the following header: 

The flow:to_server,established option can be used to restrict Snort to data coming from a client over established TCP streams. The FP-rate on this rule still isn’t great. Any TCP traffic leaving the network on port 443 with |FD FD FD| at offset 1 will alert. That might sound unique, but it does not indicate with confidence that the traffic is a BugSleep beacon. 

One powerful tool in Snort to add more logic or state to rules is flowbits. These allow a writer to have a sense of state within a stream across multiple rules. In this case, the beacons aren’t enough to reliably alert on. What if we use flowbits to chain beacons with the commands being sent back? The commands themselves don’t provide much content, as they are variable length non-deterministic strings (e.g., get, put, etc.) or a nondeterministic 4-byte integer (e.g., heartbeat, increment timeout, etc.). They do, however, all start with a 4-byte command ID. Setting a flowbit when a beacon leaves the network will allow another rule down the line to alert with higher confidence if it sees a command ID come back in the same stream. 

Command rules 

The pcre rule option can be used to reduce 11 rules down to one. Like the beacon rule, the three zero bytes, encoded as |03|, can be used as a fast_pattern. Once the rule has entered, the bugsleep_beacon flowbit check can be performed to help the rule exit quickly in the event of a false positive. After the three |03| bytes are confirmed to be at offset five, a PCRE can verify one of the command IDs is present.  

Sharp edges 

Sometimes, we are reminded that Snort can handle or interpret data differently than expected. Conveniently, this sample’s traffic was a perfect example and opportunity to peek under the hood and see what Snort sees. Originally, our beacon rule looked like this, trying to catch the encoded forward-slash that is always present in the Computer Name/Username string (encoded as a comma).  

Recall that the implant will: 

1. Connect to the server 
2. Send a string length (4 bytes) 
3. Send the PC/User string N bytes 
4. Read 4 bytes back to ensure a response 
5. Read 4-byte command ID and N command data bytes 
6. Start sending command responses 

As Snort is reading data over the wire, it is interpreting it and sorting it into different buffers (pkt_data, file_data, js_data, http_*, etc.). In this case, as TCP data is being chunked along the wire, Snort is looking at those individual TCP segments. Only after it has enough data will it flush into the larger “TCP stream” buffer so a rule can parse the entire stream sent from a client or server. 

Initially, the get command traffic was alerting while the put command traffic was not. Fortunately, Snort 3 comes with a tracing module to help debug these issues. The buffer option will print out Snort’s different buffers as they are filled and rule_eval will trace the rule as it is evaluated. The following screenshots are output from individual runs of Snort against each PCAP. “snort.raw” represents an individual packet, while “snort.stream_tcp” represents a reassembled TCP stream. 

At the start of the working GetFile command, the beacon size and data can be seen as two separate packets (Figure 17).  

Further down, the reassembled TCP stream can be seen being inspected and alerted on. Moving from the top to bottom in Figure 18, the cursor position and state of the buffer can be observed changing as the rule is evaluated. At the end, the flowbit is set and made available for the command rule.

Further down, the TCP stream for the command data is processed. The higher-order zeroes of the command are found, the flowbit checked, the PCRE performed, and the SID alerts as expected.  

When the results of the put file command traffic are inspected, a different behavior is observed. The individual packets for beacon length and beacon data are seen coming in; however, the first reassembled TCP stream that Snort is inspecting is the command being sent back to the implant. Figure 20 shows the command ID being found and then the flowbit check failing. 

Scrolling further in the log reveals the TCP stream for the beacon data is eventually populated and Snort sets the flowbit as expected. The stream for the command ID, however, has already passed and failed analysis because of the unset flowbit, resulting in no alert. The cause of this issue is the raw packets coming from the client not being reassembled into a TCP stream by the time the server packets are reassembled and inspected. This happens because Snort only reassembles when it has enough data, and 20 bytes is not enough yet. 

The fix 

Unfortunately, the beacon rule must be tweaked so it can alert as soon as possible and not rely on the TCP reassembly. Recall that the beacon function invokes SendSocket twice, once for 4-length bytes and again for the beacon data. This means the first packet Snort sees will only be 4 bytes long. Adding “bufferlen:=4” restricts Snort to only look at 4-byte packets, significantly reducing any FP rate. Our solution ended up being this:  

 Now the rules work as expected!  

Conclusion 

Since BugSleep is a new implant and weekly releases were observed being deployed, this protocol might change and bypass these rules. However, two things have been accomplished: 

1. This variant will no longer communicate over our customers’ networks. 
2. Attackers must invest development time and money to use BugSleep again. 

The published Snort SIDs covering this traffic are 63937 and 63938.  

Indicators of compromise 

Hosts: 

• 1[.]235[.]234[.]202 
• 146[.]19[.]143[.]14 
• 46[.]19[.]143[.]14 
• 5[.]239[.]61[.]97 

Hashes 

The following Windows executables were collected during our research. Assuming these have not been manipulated, the compilation time for this set of binaries indicates weekly releases of BugSleep. 

Cisco Talos Blog – ​Read More

Overview

CERT-UA, the Cyber Emergency Response Team for Ukraine, uncovered a phishing campaign orchestrated by the threat actor UAC-0215. This campaign specifically targeted public institutions, major industries, and military units across Ukraine.   

The phishing emails were cleverly disguised to promote integration with popular platforms like Amazon and Microsoft, as well as advocating for Zero Trust Architecture (ZTA). However, the emails contained malicious .rdp configuration files that, when opened, established a connection to an attacker-controlled server.   

This connection provided unauthorized access to a variety of local resources, including disk drives, network assets, printers, audio devices, and even the clipboard. The sophistication of this campaign raises security concerns for critical infrastructure in Ukraine.  

Campaign Overview  

The campaign was first detected on October 22, 2024, with intelligence suggesting that the preparatory groundwork was laid as early as August 2024. The phishing operation’s extensive reach highlights not only a localized threat but also a broader international concern, as multiple cybersecurity organizations worldwide have corroborated it. The implications of this attack extend beyond individual organizations, threatening national security.  

The primary targets of the phishing campaign include public authorities, major industries, and military organizations within Ukraine. This operation is assessed to have a high-risk score, indicating a threat to these sectors. The campaign is attributed to the advanced persistent threat (APT) group known as UAC-0215, utilizing rogue Remote Desktop Protocol (RDP) techniques.  

Technical Details

The phishing campaign attributed to UAC-0215 utilizes rogue Remote Desktop Protocol (RDP) files to infiltrate key Ukrainian institutions. The malicious emails are designed to appear legitimate, enticing recipients to open attachments that ultimately compromise their systems. When a victim unwittingly opens the .rdp configuration file, it connects their computer to the attacker’s server, granting extensive access to critical local resources, including:  

Disk Drives  

Network Resources  

Printers  

COM Ports  

Audio Devices  

Clipboard  

This access allows the attackers to execute unauthorized scripts and programs, further compromising the system.  

Conclusion  

The intelligence gathered suggests that the UAC-0215 campaign extends beyond Ukrainian targets, indicating a potential for broader cyberattacks across multiple regions, especially amid heightened tensions in the area, including recent cyberattacks on Ukraine that have garnered international concern.   

This campaign highlights the growing sophistication of phishing tactics employed against Ukraine, as the attackers exploited RDP configurations to gain significant control over critical systems within public and industrial sectors, jeopardizing sensitive information and operational integrity.   

Recommendations and Mitigations  

To mitigate the risks posed by UAC-0215 and similar threats, organizations are advised to implement the following strategies:  

Establish better filtering rules at the mail gateway to block emails containing .rdp file attachments. This measure is critical in reducing exposure to malicious configurations.  

Limit users’ ability to execute .rdp files unless specifically authorized. This precaution will minimize the risk of accidental executions that could lead to breaches.  

Configure firewall settings to prevent the Microsoft Remote Desktop client (mstsc.exe) from establishing RDP connections to external, internet-facing resources. This step will thwart unintended remote access and reduce the potential for exploitation.  

Utilize Group Policy to disable resource redirection in RDP sessions. By setting restrictions under “Device and Resource Redirection” in Remote Desktop Services, organizations can prevent attackers from accessing local resources during RDP sessions. 

The post Phishing Campaign Targeting Ukraine: UAC-0215 Threatens National Security appeared first on Cyble.

Blog – Cyble – ​Read More

The FBI and the Cybersecurity and Infrastructure Security Agency (CISA) have launched an investigation into a series of cyber intrusions linked to hackers believed to be affiliated with the Chinese state-linked threat actors. 

This investigation follows reports that the phone communications of prominent U.S. political figures, including former President Donald Trump, Vice President Kamala Harris’ campaign team, and vice-presidential candidate JD Vance, have been targeted in a sweeping cyber-espionage effort.

Allegations of Unauthorized Access by Chinese State Linked Threat Actors

The FBI and CISA issued a statement confirming their investigation into “unauthorized access to commercial telecommunications infrastructure” perpetrated by actors associated with the People’s Republic of China, reported CBS News. This response was prompted by specific malicious activities detected within the telecommunications sector, which the agencies say are part of a larger Chinese hacking campaign aimed at gathering sensitive information from high-level U.S. officials.

The agencies emphasized their quick action, stating that upon identifying the threat, they immediately notified affected telecommunications companies, provided technical assistance, and shared crucial information to help potential victims mitigate their exposure.

High-Profile Targets

Reports indicate that the hacking campaign targeted the phone communications of several key political figures, including Donald Trump and JD Vance, as part of a broader strategy to compromise the communications of U.S. officials.

According to sources cited by CNN, the Chinese hackers also sought to infiltrate the communications of senior officials within the Biden administration. The gravity of these allegations raises concerns over the potential for foreign espionage and the safety of sensitive government communications.

Reacting to these findings, Steven Cheung, a spokesperson for Trump’s campaign, criticized the Harris campaign for allegedly “emboldening” China, reflecting the heightened political tensions surrounding the issue. However, it remains unclear whether the hackers succeeded in accessing any specific information from the targeted communications, reported Asian News International.

The Broader Context

The New York Times was among the first to report on this breach, revealing that the hacking effort is part of a wider Chinese campaign that has successfully infiltrated several U.S. telecommunications companies over the past few months. 

Investigators believe that these hackers aim to access sensitive national security information, including information on wiretap warrant requests made by the U.S. Justice Department. Notably, there is currently no evidence suggesting that the hackers targeted communications linked to law enforcement activities involving Trump and Vance.

Major U.S. broadband and internet providers, such as AT&T, Verizon, and Lumen, have also been identified as targets in this ongoing campaign.

The Response from U.S. Authorities

In light of these events, U.S. agencies are taking a coordinated approach to combat the threat posed by foreign hackers. CISA reiterated its commitment to working closely with industry partners to strengthen cybersecurity in U.S. elections. They encouraged any organization that suspects it may be a victim of similar attacks to reach out to local FBI field offices or CISA for assistance.

The information about this breach coincides with other cybersecurity threats facing the U.S. political domain. Iranian hackers have also targeted Trump’s campaign, leading to the theft and subsequent publication of sensitive campaign emails. 

These hackers, linked to Iran’s Basij paramilitary force, shared the stolen material with a Democratic operative who subsequently published it through various channels. The ongoing conflict between foreign actors and U.S. political campaigns highlights the precarious nature of cybersecurity in U.S. elections.

In a related investigation, the hacking group known as Mint Sandstorm, or APT42, reportedly compromised multiple Trump campaign staff accounts earlier this year. The U.S. Department of Justice has indicted three Iranian hackers involved in this breach, underscoring the persistent threat posed by foreign actors in U.S. elections cybersecurity.

International Response

As the investigation into the Chinese-linked hacks unfolds, the Chinese government has denied involvement in these alleged cyber activities. The geopolitical implications of such hacking campaigns are profound as China, Iran, and Russia continue to explore avenues to influence or monitor aspects of U.S. elections.

While U.S. intelligence agencies indicate that China has not made a significant effort to influence the presidential election directly, it has targeted various congressional and local election races through covert social media campaigns.

The investigation into the telecom hacks targeting high-profile U.S. politicians represents a critical moment in the ongoing struggle against cyber espionage. As authorities work to unravel the details of this sophisticated breach, the implications for national security remain an open question.

The post U.S. Agencies Investigate China-Linked Telecom Hacks Targeting High-Profile Politicians appeared first on Cyble.

Blog – Cyble – ​Read More

A group of security researchers discovered a serious vulnerability in the web portal of the South Korean car manufacturer Kia, which allowed cars to be hacked remotely and their owners tracked. To carry out the hack, only the victim’s car license plate number was needed. Let’s dive into the details.

Overly connected cars

If you think about it, in the last couple of decades, cars have essentially become big computers on wheels. Even the less “smart” models are packed with electronics and equipped with a range of sensors — from sonars and cameras to motion detectors and GPS.

And not only that; in recent years, these computers have been constantly connected to the internet — with all the ensuing risks. Not long ago, we wrote about how today’s cars collect huge amounts of data about their owners and send it to the manufacturer. Moreover, the manufacturers also sell this collected data to other companies — particularly insurers.

However, there’s another side to this issue: being constantly connected to the internet means that, if there are vulnerabilities — either in the car itself or in the cloud system it communicates with — someone could exploit them to hack the system and track the car’s owner without the manufacturer even knowing.

One bug to rule them all, one bug to find them

This is exactly what happened in this case. Researchers found a vulnerability in Kia’s web portal, which is used by Kia owners and dealers. It turned out that by using the API, the portal allowed anyone to register as a car dealer with just a few fairly simple moves.

This gave the attacker access to features that even car dealers shouldn’t have — at least, not once the vehicle has been handed over to the customer. Specifically, the portal permits first finding any Kia car, and then accessing the owner’s data (name, phone number, email address, and even physical address) — all with just the vehicle’s VIN number.

It should be noted that VIN numbers aren’t exactly secret information — in some countries, they’re publicly available. For instance, in the USA there are many online services you can use to look up a VIN number using a car’s license plate number.

After successfully finding the car, the attacker can use the owner’s data to register any attacker-controlled account in Kia’s system as a new user for the vehicle. From there, the attacker would gain access to various functions normally available to the car’s actual owner through the mobile app.

What’s particularly interesting is that all these features weren’t just available to the dealer who sold that car, but to any dealer registered in Kia’s system.

Hacking a car in seconds

The researchers then developed an experimental app that could take control of any Kia vehicle within seconds simply by entering its license plate number into the input fields. The app would automatically find the car’s VIN through the relevant service and use it to register the vehicle to the researchers’ account.

After that, a single button press in the app would allow the attacker to obtain the vehicle’s current coordinates, lock or unlock the doors, start or stop the engine, or honk the horn.

It’s important to note that in most cases these functions wouldn’t be enough to steal the car. Modern models are usually equipped with immobilizers, which require the physical presence of the key to be disabled. There are some exceptions, but generally these are the cheapest cars that are unlikely to be of much interest to thieves.

Nevertheless, this vulnerability could easily be used to track the car owner, steal valuables left inside the car (or plant something there), or simply disrupt the driver’s life with unexpected actions from the vehicle.

The researchers followed responsible disclosure protocol, informing the manufacturer of the issue and only publishing their findings after Kia fixed the bug. However, they note that they’ve found similar vulnerabilities before and are confident they’ll continue to discover more in the future.

Kaspersky official blog – ​Read More