By Philippe Laulheret
ClipSP (clipsp.sys) is a Windows driver used to implement client licensing and system policies on Windows 10 and 11 systems.
Cisco Talos researchers have discovered eight vulnerabilities related to clipsp.sys ranging from signature bypass to elevation of privileges and sandbox escape:

TALOS-2024-1964 (CVE-2024-38184)
TALOS-2024-1965 (CVE-2024-38185)

Monday, November 25, 2024 08:00

By Philippe Laulheret

ClipSP (clipsp.sys) is a Windows driver used to implement client licensing and system policies on Windows 10 and 11 systems.

Cisco Talos researchers have discovered eight vulnerabilities related to clipsp.sys ranging from signature bypass to elevation of privileges and sandbox escape:

*   TALOS-2024-1964 (CVE-2024-38184)
*   TALOS-2024-1965 (CVE-2024-38185)
*   TALOS-2024-1966 (CVE-2024-38186)
*   TALOS-2024-1968 (CVE-2024-38062) 
*   TALOS-2024-1969 (CVE-2024-38187)
*   TALOS-2024-1970 (CVE-2024-38062)
*   TALOS-2024-1971 (CVE-2024-38062)
*   TALOS-2024-1988 (CVE-2024-38062)

This research project was also presented at both HITCON and Hexacon. A recording of the latter’s presentation is embedded at the end of this article.

****What is ClipSp?****

ClipSp is a first-party driver on Microsoft Windows 10 and 11 that is responsible for implementing licensing features and system policies, and as such it is one of the main components of the Client Licensing Platform (CLiP). Little is known about this driver; while most Microsoft drivers and DLLs have publicly available debug symbols, in the case of ClipSp, those were removed from Microsoft's symbol server. Debug symbols provide function names and other related debug information that can be leveraged by security researchers to infer the intent behind the many functions of a binary; their absence hinders that. Surprisingly, the driver is also obfuscated, a very rare occurrence in Microsoft binaries, likely to deter reverse engineering even further. Limited public research exists, much of which either predates our findings or was released in response to our reports. The latter research also shares symbols from an older version of ClipSp, which could be a useful springboard for anyone wanting to research this driver. The most interesting aspect of this software involves implementing features related to licensing Windows applications from the Windows App store and activation services for Windows itself.

****Deobfuscation****

The driver is obfuscated with Warbird, which is Microsoft’s proprietary obfuscator. Luckily, past research comes in handy, and we can adapt to suit our needs. The plan to deobfuscate the driver is to leverage the binary emulation framework Qiling, to emulate the part of the driver responsible for deobfuscating the obfuscated sections, and dump the executable memory range to import it into our favorite reversing tool.

During normal operation, the obfuscation appears as follows:

We can see that a decrypt function is called twice with different parameters, followed by a call to the actual function being deobfuscated and, finally, two calls to re-obfuscate the relevant section.

Using Ida Python, we can track all the references to the decrypt functions (there are actually two distinct functions), and recover their arguments by looking at the instructions that precede the function call where the RCX and RDX registers are being assigned. Per calling conventions, these two registers are the first and second arguments of the function. Then, we can feed this information to our modified Qiling script to emulate the decryption functions and dump the whole deobfuscated binary. Once the driver is deobfuscated, we can start reversing it to understand how Windows communicates with the driver, understand various business logic elements, and look for vulnerabilities.

****Driver communication****

Usually, drivers either register a device that can be reached from userland or export the functions that are meant to be used by other drivers. In the ClipSp case, things behave slightly differently. The driver exports a “ClipSpInitialize” function that takes a pointer to an array of callback functions that get populated by ClipSp, to then be used by the calling driver to invoke ClipSp functionalities. Grepping for “ClipSpInitialize” throughout the System32 folder shows that the best candidate for using ClipSp is “ntoskrnl.exe”, followed by a handful of filesystem drivers that use a limited amount of ClipSp functions. For the rest of this report, we will focus on how “ntoskrnl” interacts with ClipSp.

Analyzing the cross-references within the Windows’ kernel to ClipSp functions, it becomes clear that, to interact with them, a call to “NtQuerySystemInformation” with the SystemPolicy class is required. Other binaries in the CLiP ecosystem will issue these system calls, while also providing a remote procedure call (RPC) interface to decouple other software from the undocumented API. However, nothing stops us from interacting with the “NtQuerySystemIformation” endpoint directly, which becomes a handy trick to bypass some of the additional checks that are enforced by the intended RPC client library.

****Obfuscated structures****

Unfortunately for us, looking at how a legitimate binary interacts with the SystemPolicy class, we can see the following (from  wlidsvc!DeviceLicenseFunctions::SignHashWithDeviceKey):

This is another layer of obfuscation that encapsulates the data passed over to the API. The idea here is that a network of binary transformations (also known as a Feistel cipher) is used to encrypt the data with the various operations inline in the code (as seen above). Part of the API call will provide the list of operations that were used, and the kernel will call them directly with the appropriate parameters to decrypt the data. As such, the easier approach to dealing with this is to simply rip out both the encryption code and the associated parameters and re-use them in our own invocation of the API. Copying and pasting the decompiler’s output into Visual Studio is a little tedious but usually works fine. Before returning from the syscall, the resulting data is obfuscated in a similar fashion, and, once again, ripping out the data from a working implementation is the most straightforward way to deal with it. Overall, the data format looks as such:

The inner payload (left) is an array of size-value entries that contain the command number that needs to be executed, followed by the Warbird material used to encrypt the reply from the kernel, and finally command-specific data that depends on which ClipSp function is being invoked.

This data is then encapsulated into a structure that mostly specifies the number of entries there are in the provided array and the whole thing then gets encrypted. The remaining Warbird data in the righ-most part of the diagram is to instruct the kernel how to decrypt the provided data.

Here’s our best guess at the various available commands:

Most of them call into ClipSp, but a few (especially in the <100 range) may be solely handled by the Windows kernel.

****Sandbox considerations****

Microsoft provides a tool to test if a piece of code can be run within a low-privilege context called a Less Privileged Application Container (LPAC) sandbox. Using this with our proof of concept, we can confirm that ClipSp’s APIs are actually reachable from an LPAC context. This is particularly interesting as these application containers are usually used to sandbox high-risk targets, such as parsers and browser rendering processes. As such, any elevation of privilege vulnerabilities we could find would likely double as sandbox escapes as well.

****Processing licenses****

Throughout the reversing process, we observed that the license files handled by ClipSp were quite interesting. They are usually obtained silently from Microsoft when interacting with UWP applications (both coming from the App Store and those installed by default, such as Notepad). They can also be used for other purposes, such as Windows activation, hardware binding, and generally providing cryptographic material for various applications.

At first, license files appear to be opaque blobs of data that are installed via the “SpUpdateLicense” command. This can be invoked following the process described above with the command “\_id = 100”. Existing licenses are stored in the Windows registry at the following location:

HKLN\\SYSTEM\\CurrentControlSet\\Control\\{7746D80F-97E0-4E26-9543-26B41FC22F79}

Only the SYSTEM user can access this registry key. From an elevated prompt, the following command can open regedit as SYSTEM:

PsExec64.exe -s -i regedit

The format for these licenses is mostly undocumented, but looking at how they are being parsed is pretty informative. These licenses are in a tag-length-value (TLV) format, where the list of authorized tags is contained in an array of tuples of the form (tag, internal\_index) hardcoded inside ClipSp. Upon parsing, a pointer to each valid TLV entry is stored in an array at the location indicated by the internal\_index:

****Signature bypass (**TALOS-2024-1964**)****

Licenses are signed by various signing authorities whose public keys are hardcoded in ClipSp. Verification code looks as such:

The “entry\_of\_type\_24” value is a pointer saved during the parsing of the license and points to its signature. The difference between “entry\_of\_type\_24” and “License\_data” is pointer arithmetic used to count the number of bytes from the beginning of the license blob up to its signature. 

During the parsing, this looks as such:

If the internal index associated with the entry’s tag is 24, then the processing loop is temporarily exited. A pointer to the signature is saved, and if more data remains, the license processing is resumed.

We can see that this approach is flawed: If there is data after the license’s signature, it will still be parsed but not checked against the signature, effectively enabling an attacker to bypass the signature check of any license as long as they can get one that is already signed with the proper signing authority.

****Out-of-bound read vulnerabilities (**TALOS-2024-1965,TALOS-2024-1968, TALOS-2024-1969, TALOS-2024-1970, TALOS-2024-1971, TALOS-2024-1988**)****

We can cross reference where the license structure and its array of pointers to the TLV data is being used, and what we find is many wrapper functions that return either the length/size of a given entry or the data associated with it. In most cases, this is done in a secure fashion, but there are a few entries that make assumptions on the size of the data provided in the license blob, which leads to a handful of out-of-bound read vulnerabilities. An example of such vulnerabilities can be seen in the following screenshots:

These two functions retrieve either the size of the DeviceID field or its content. However, if the data is formatted in such a way that line 11 is reached (i.e., no entry of type 5 in the license provided) then the **data** field of entry 18 is used to provide both size and value by dereferencing its pointer, without checking if enough data was provided for that. For instance, if we append a DeviceID entry (type 18) at the end of a valid license blob, but make it so its data field is only one byte long, then the “get\_DeviceIDSize” function will read one byte out of bound, as it is expecting two bytes of data. Furthermore, any function that calls “get\_DeviceID” will receive a pointer that is pointing one byte past the end of the license file and will likely act on wrong information from the “get\_DeviceIDSize” function for further out of bound (OOB)-read problems.

****Turning an OOB-read into an OOB-write (**TALOS-2024-1966**)****

If we look specifically at the case described above where the DeviceIdSize field can be read out of bound, this creates a particularly interesting situation where the expected size of the DeviceID object can change throughout its lifetime if the data immediately adjacent in memory changes in a meaningful way. The first byte of data after the license blob will also be read as the leading byte of the (unsigned short) value defining the size of the DeviceID. Looking at how these two functions are used in ClipSp, we can see that during the installation of a hardware license, the following happens:

We can see multiple calls to the “get\_DeviceIDSize” function, with one providing the size field to a memory allocation routine, while another call is used as a parameter to a “memcpy”. If the size field changes in between the two calls, this may lead to an out-of-bounds write vulnerability.  

Exploiting a vulnerability like this is far from trivial, as one would have to win a race condition between the two fetches while being able to shape the PagedPool heap in such a way that there’s meaningful data located right after the malicious license blob.

****Conclusion****

As we have just seen, obfuscated code can hide low hanging fruit, trivial memory corruptions, and simple logic bugs. In the case of ClipSp, this issue is even more serious, as this attack vector may lead to sandbox escapes and potentially significant impact to the compromised user.

As such, this is a reminder for security researchers on the value of taking the less traveled path, even if it begins with a bramble of Feistel functions. And for the software engineers and project managers who decide to leverage obfuscation for their projects, this is also a stark reminder that this approach may hinder normal bug finding processes that would detect trivial bugs early on.

\[Please embed video from: https://www.youtube.com/watch?v=9t0Xt40RZEc  \]

Finding vulnerabilities in ClipSp, the driver at the core of Windows’ Client License Platform

The Threat Source Newsletter is back! William Largent discusses bidirectional communication in the SOC, and highlights new Talos research including the discovery of PXA Stealers.

Thursday, November 21, 2024 14:02

Welcome to this week’s edition of the Threat Source newsletter. 

Bidirectional communication is foundational to a well-built team regardless of environment. It’s critical in information security to be able to drive a conversation up the ladder and down and not lose the critical elements. One of the most difficult challenges that cyber security teams face is making sure that everyone that is in a decision-making space is aware of the highly technical challenges that the evolving threat landscape dictates. Navigating the challenges that come in continually evolving the team and it’s tools to defend is often a much greater challenge. I’m going to help you with those conversations. In both directions. By talking about drumming. I know, I don’t have the pro wrestling takes that Jon came to the table with, so you’re going to have to run with me Constant Reader.  

I’m going to choose drumming to outline an easy way to identify some complex issues and talk about them in both directions and drumming is a little easier to identify for non-musicians and FAR less contentious than a spicy guitar opinion. Ok, so let’s start with a simple concept.  

 Sounds difficult. Is difficult.    
Sounds difficult. Is easy.   
Sounds easy. Is difficult.     
Sounds easy. Is easy.  

 Sounds difficult. Is difficult. This one is easy – Tomas Haake from Meshuggah playing Bleed is a perfect example. Polyrhythms, stamina, speed, interdependence, and complexity. This sounds difficult. It is difficult. Only the criminally insane attempt to learn how to play this song.  

Sounds easy. Is easy. Take Phil Rudd and pick any AC/DC song from Back in Black. The perfect example of sounds easy, is easy. Perfectly in the pocket.  

Sounds easy. Is difficult. This one is harder and will cause someone to wellackshully and I assure you I do not care. I’m going to give two examples, Jeff Porcaro of Toto playing Rosanna and Vinnie Colaiuta playing Seven Days with Sting. Both of these songs are immensely easy to listen to and don’t seem like there’s anything challenging going on. Until you try to play along, then you cry and examine all the choices you’ve made in life.  

Sounds difficult. Is easy. This is going to be a sticky situation, but I’d say that you could throw on anything by Travis Barker and Dave Lombardo. Bring it haters. I’m not saying that they are bad drummers – simply that what they do sounds more difficult than it is.  

Ok William, but how does this help me at all?  

When you have information security meetings with people in your organization take a second as you look at the agenda, and your conversation in specific, and think about the groupings above and determine what kind of drumming you are hearing. Depending on your environment and team the topics will fall naturally into these categories – it can be patch and vulnerability management,  EOL devices that need to be replaced, endpoint detection and response, deciding what traffic is actionable and defining that in your SIEM, forensic analysis, threat hunting, event response, the conversations are as malleable as the threat landscape.  

It’s easy to isolate the things in your environment that are very difficult to defend AND take a skilled defender and complex tooling to defend. Those conversations flow with either junior analysts or C-Level executives. This is the “Sounds difficult. Is difficult.” type of conversation. Ditto the “Sounds easy. Is easy.” conversations are easy to have in either direction. The most difficult topics to convey fall into the “Sounds difficult. Is easy.” or “Sounds easy. Is difficult.” In my experience these conversations are usually much easier to deliver in one direction and much more difficult in the other. Jazz guys enjoy the nuance of Colaiuta and can’t wrap their minds around Lombardo while metalheads love him and don’t want to be bothered by ghost notes. By taking a moment to dissect your topic and determine where you are going to run into the “Sounds difficult. Is easy.” or the “Sounds easy. Is difficult.” situation it will allow you to prepare for those more challenging conversations so that you can craft a narrative to best capture the nuance that might be lost in a highly technical conversation with a C-Level exec, or the motivation for waiting for the next financial quarter for new tooling that the analysts really need.  

I’m not going to lie - you can prepare this way and things can still fall on deaf ears, they can still underestimate the lift required because people are fallible but if you prepare just a bit and know your audience you can drag your C-Level into a discussion on polyrhythm and pull your junior analyst up with a little Vinnie Colaiuta and make them all feel like Phil Rudd.   

**The one big thing **

Cisco Talos discovered a new information stealing campaign operated by a Vietnamese-speaking threat actor targeting government and education entities in Europe and Asia. PXA Stealer targets victims’ sensitive information, including credentials for various online accounts, VPN and FTP clients, financial information, browser cookies, and data from gaming software. PXA Stealer also has the capability to decrypt the victim’s browser master password and uses it to steal the stored credentials of various online accounts. 

**Why do I care? **

Harvested credentials can allow attackers direct access to your environment without the need to exploit vulnerabilities or face any of your defensive architecture – they can just log in. Cisco Talos Incident Response has observed an increasing number of engagements where this is the case.  

**So now what? **

Cisco Talos has released several Snort rules and ClamAV signatures to detect and defend against PXA Stealer.   

**Top security headlines of the week **

Attackers are continuing to upload hundreds of malicious packages to the open-source node package manager (NPM) repository in an attempt to infect the devices of developers that rely on these libraries. (Ars Tecnica) 

Cybersecurity and Infrastructure Security Agency (CISA) has confirmed that it's director Jen Easterly will step down from her position on President-elect Donald Trump's Inauguration Day. (Dark Reading) 

Palo Alto Networks has released a patch to fix a critical vulnerability in some instances of its firewall management interfaces. PAN observed threat activity exploiting an unauthenticated remote command execution vulnerability against firewall management interfaces. (Bleeping Computer,  Dark Reading)   

**Can’t get enough Talos? **

*   Unwrapping the emerging Interlock ransomware attack 
*   Talos Takes on Interlock 
*   November Patch Tuesday release contains three critical remote code execution vulnerabilities 
*   It's Taplunk! Talos and Splunk threat researchers meet to put the security world to rights 

**Upcoming events where you can find Talos **

 CyberCon Romania

(Nov 21-22)    
Bucharest, Romania 

 Martin Lee from Cisco Talos will speak on a panel discussion Maintaining Resilience for a Secure Cyber Infrastructure.  

misecCON (Nov. 22)    
Lansing, Michigan 

Terryn Valikodath from Cisco Talos Incident Response will explore the core of DFIR, where digital forensics becomes detective work and incident response turns into firefighting. 

AVAR

(Dec 4-6)    
Chennai, India 

 Vanja Svancer and Chetan Raghuprasad from Cisco Talos will both present, Vanja will be discussing Exploring Vulnerable Windows Drivers, while Chetan presents Sweet and Spicy Recipes for Government Agencies by SneakyChef.  

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

SHA 256: c20fbc33680d745ec5ff7022c282a6fe969c6e6c7d77b7cfac34e6c19367cf9a  

MD5: 3bc6d86fc4b3262137d8d33713ed6082  

Typical Filename: 8c556f0a.dll  

Claimed Product: N/A  

Detection Name: Gen:Variant.Lazy.605353  

 SHA 256: bea312ccbc8a912d4322b45ea64d69bb3add4d818fd1eb7723260b11d76a138a 

MD5: 200206279107f4a2bb1832e3fcd7d64c 

Typical Filename: lsgkozfm.bat 

Claimed Product: N/A 

Detection Name: Win.Dropper.Scar::tpd   

SHA 256: 47ecaab5cd6b26fe18d9759a9392bce81ba379817c53a3a468fe9060a076f8ca  

MD5: 71fea034b422e4a17ebb06022532fdde  

Typical Filename: VID001.exe  

Claimed Product: N/A  

Detection Name: RF.Talos.80  

SHA 256: 3a2ea65faefdc64d83dd4c06ef617d6ac683f781c093008c8996277732d9bd66  

MD5: 8b84d61bf3ffec822e2daf4a3665308c  

Typical Filename: RemComSvc.exe  

Claimed Product: N/A  

Detection Name: W32.3A2EA65FAE-95.SBX.TG

Bidirectional communication via polyrhythms and shuffles: Without Jon the beat must go on

QR codes are disproportionately effective at bypassing most anti-spam filters. Talos discovered two effective methods for defanging malicious QR codes, a necessary step to make them safe for consumption.

Wednesday, November 20, 2024 06:00

*   QR codes are disproportionately effective at bypassing most anti-spam filters, as most filters are not designed to recognize that a QR code is present in an image and decode the QR code. According to Cisco Talos’ data, roughly 60% of all email containing a QR code is spam.  
*   Talos discovered two effective methods for defanging malicious QR codes, a necessary step to make them safe for consumption. Users could obscure the data modules, the black and white squares within the QR code that represent the encoded data. Alternatively, users could remove one or more of the position detection patterns — large square boxes located in corners of the QR code used to initially identify the code's orientation and position. 
*   Further complicating detection, both by users and anti-spam filters, Talos found QR code images that are “QR code art.” These images blend the data points of a QR code seamlessly into an artistic image so the result does not appear to be a QR code at all. 

Prior to 1994, most code scanning technology utilized one-dimensional barcodes. These one-dimensional barcodes consist of a series of parallel black lines of varying width and spacing. We are all familiar with these codes, like the type you might find on the back of a cereal box from the grocery store. However, as the use of barcodes increased, their limitations became problematic, especially considering that a one-dimensional barcode can only hold up to 80 alphanumeric characters of information. To eliminate this limitation, a company named Denso Wave created the very first “Quick Response“ codes (QR codes). 

QR codes are a two-dimensional matrix bar code that can encode just over 7,000 numeric characters, or up to approximately 4,300 alphanumeric characters. While they can represent almost any data, most frequently we encounter QR codes that are used to encode URLs. 

**Quantifying the QR code problem **

Talos extracts QR codes from images inside email messages and attached PDF files for analysis. QR codes in email messages make up between .01% and .2% of all email worldwide. This equates to roughly one out of every 500 email messages. However, because QR codes are disproportionately effective at bypassing anti-spam filters, a significant number find their way into users’ email inboxes, skewing users’ perception of the overall problem.  

Also, of course, not all email messages with a QR code inside are spam or malicious. Many email users send QR codes as part of their email signature, or you may also find legitimate emails containing QR codes used as signups for events, and so on. However, according to Talos’ data, **roughly 60% of all email containing a QR code is spam**.   

Truly malicious QR codes can be found in a much smaller number of messages. These emails contain links to phishing pages, etc. The most common malicious QR codes tend to be multifactor authentication (MFA) requests used for phishing user credentials. 

An example MFA phishing email utilizing a QR code.

One of the problems that defenders may encounter when dealing with users’ scanning of QR codes received via email, assuming the user’s device is not connected to the corporate wi-fi, is that subsequent traffic between the victim and the attacker will traverse the cellular network, largely outside the purview of corporate security devices. This can complicate defense, because few/no alerts from security devices will notify security teams that this has occurred. 

**Why are malicious QR codes hard to detect? **

Because QR codes are displayed in images, it can be difficult for anti-spam systems to identify problematic codes. Identifying and filtering these messages requires the anti-spam system to recognize that a QR code is present in an image, decode the QR code, then analyze the link (or other data) present in the decoded data. As spammers are always looking for innovative ways to bypass spam filters, using QR codes has been a valuable technique for spammers to accomplish this. 

As anti-spam systems improve their capability to detect malicious QR codes in images, enterprising attackers have instead decided to craft their QR codes using Unicode characters.

__An email containing a QR code constructed from Unicode characters (defanged).__

The graphical parts of the image are contained within a PDF file. The PDF metadata indicates it was created from HTML using the tool wkhtmltopdf. Converting the PDF back into HTML shows the Unicode that is being used to construct the QR code. 

__HTML used to construct a malicious QR Code from Unicode characters.__

**Defanging QR codes **

When sharing malicious URLs, it is common to change the protocol from “http” to “hxxp”, and/or to add brackets (“\[\]”) around one of the dots in the URL. This makes it so browsers and other applications do not render the link as an active URL, ensuring that users do not inadvertently click on the malicious URL. This is a process known as “defanging.” Unfortunately, while defanging URLs is commonplace, many people do not defang malicious QR codes. For example, below is a news article from BBC about criminals who put QR code stickers on parking meters in an attempt to harvest payment credentials from unsuspecting victims. 

__A news article from BBC containing a working QR code (this has been defanged by Talos).__

The problem is that these QR codes can still be scanned, taking visitors to whatever malicious link that the QR code encoded. **To make malicious QR codes safe for consumption, they should be defanged.** 

There are a couple of different ways to do this. One way is to obscure the data modules, the black and white squares within the QR code that represent the encoded data. This is where the data that the QR code represents is located. However, based on Talos’ own research, a far easier way to defang a QR code is to remove one or more of the position detection patterns (a.k.a. finder patterns). These are the large square boxes located in three of the four corners of the QR code, which are used by the QR code scanner to initially identify the code's orientation and position. Removing the position detection patterns renders a QR code unscannable by virtually all scanners. Additional details on how this is achieved, will be covered later in the blog. 

A normal QR code on the left vs. a defanged QR code on the right.

**Be careful what you scan! **

For years, security professionals have encouraged users **not** to click on unfamiliar or suspicious URLs. These URLs could potentially lead to phishing pages, malware or other harmful sites. However, many users do not exercise the same care when scanning an unknown QR code as they do when clicking on a suspicious link. To be clear, scanning an unknown/suspicious QR code is equivalent to clicking on a suspicious URL. 

To complicate the situation even more, there are QR code images that are “QR code art.” These images blend the data points of a QR code seamlessly into an artistic image so the result does not appear to be a QR code at all. The potential danger with QR code art images is that a user could conceivably be tricked into scanning a QR code art image with their camera, and then inadvertently navigate to the linked content without realizing it.

**How to protect yourself from malicious QR codes **

QR codes have become ubiquitous, appearing in email, on restaurant menus, at public events, on retail packaging, in museums, and even public parks and trails. The perfect defense is to avoid scanning any QR codes; however, it can be difficult to avoid scanning these entirely, so users must exercise caution. Scanning a QR code is essentially the same as clicking on an unknown hyperlink, but without the ability to see the full URL beforehand. 

There are several QR code decoders freely available online. Typically, if you can save a screenshot of the QR code, you can upload this image to one of these decoders, and the QR code decoder will tell you what data was encoded inside the QR code. This will allow you to more closely inspect the link. You can also choose to navigate to that URL using an application like Cisco Secure Malware Analytics (Threat Grid). This will allow you to view the content behind the URL from a safe place, without jeopardizing the security of your desktop or mobile device. As always, never enter your username and password into an unknown site. It is better to navigate directly to anywhere you wish to login, rather than clicking on a URL presented to you from an unknown third party.

Malicious QR Codes: How big of a problem is it, really?

Cisco Talos discovered a new information stealing campaign operated by a Vietnamese-speaking threat actor targeting government and education entities in Europe and Asia.

New PXA Stealer targets government and education sectors for sensitive information

The Patch Tuesday for November of 2024 includes 91 vulnerabilities, including two that Microsoft marked as “critical.” The remaining 89 vulnerabilities listed are classified as “important.”

Tuesday, November 12, 2024 18:11

The Patch Tuesday for November of 2024 includes 89 vulnerabilities, including four that Microsoft marked as “critical.” The remaining vulnerabilities listed are classified as “important.”

Microsoft assessed that exploitation of the four “critical” vulnerabilities is “less likely.”

CVE-2024-43639 is a remote code execution vulnerability in Windows Kerberos that could be exploited by an attacker by creating a specially crafted application to leverage a vulnerable cryptographic protocol. While considered “critical” it was determined that exploitation is “less likely” and not been detected in the wild.

CVE-2024-43625 is a privilege escalation vulnerability in a VMSwitch driver, which is a networking component of Hyper-V. An attacker could exploit this by sending a specific series of network packets to the driver to trigger a “use after free” vulnerability in the Hyper-V host, allowing the attacker to execute arbitrary code with elevated privileges.Although classified as “critical,” exploitation was deemed “less likely” and the attack complexity considered “high.” Microsoft has not detected active exploitation of this vulnerability in the wild.

CVE-2024-43602 is a remote code execution vulnerability in Azure CycleCloud. Although marked as "critical," Microsoft has determined that exploitation is "less likely." If an attacker has gained basic user privileges they may be able to exploit this by sending specially crafted packets to the Azure CycleCloud cluster to gain root privileges. Microsoft has not detected active exploitation of this vulnerability in the wild.

CVE-2024-43498 is a "critical" remote code execution vulnerability in .NET and Visual Studio. Microsoft has assessed exploitation of this vulnerability as "less likely." A remote attacker could exploit a vulnerable .NET web app by sending specially crafted packets, or loading a specially crafted file into a vulnerable application. In the wild exploitation of this vulnerability has not been detected by Microsoft.

Of the vulnerabilities included in the release, several “important” updates were listed as “exploitation more likely”. These updates are listed below:

*   CVE-2024-49033 - Microsoft Word Security Feature Bypass Vulnerability
*   CVE-2024-43623 - Windows NT OS Kernel Elevation of Privilege Vulnerability
*   CVE-2024-43629 - Windows DWM Core Library Elevation of Privilege Vulnerability
*   CVE-2024-43630 - Windows Kernel Elevation of Privilege Vulnerability
*   CVE-2024-43636 - Win32k Elevation of Privilege Vulnerability
*   CVE-2024-49019 - Active Directory Certificate Services Elevation of Privilege VulnerabilityCisco Confidential
*   CVE-2024-43642 - Windows SMB Denial of Service Vulnerability

Additionally, Talos would like to highlight the following “important” vulnerabilities as exploitation has been detected by Microsoft:

*   CVE-2024-43451 - NTLM Hash Disclosure Spoofing Vulnerability
*   CVE-2024-49039 - Windows Task Scheduler Elevation of Privilege Vulnerability

A complete list of all the other vulnerabilities Microsoft disclosed this month is available on its update page. In response to these vulnerability disclosures, Talos is releasing a new Snort rule set that detects attempts to exploit some of them. Please note that additional rules may be released at a future date and current rules are subject to change pending additional information. Cisco Security Firewall customers should use the latest update to their ruleset by updating their SRU. Open-source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org.

The rules included in this release that protect against the exploitation of many of these vulnerabilities are 62022, 62023, 64218-64224, 64229, 64232 and 64233. There are also Snort 3 rules 301064, 300612, 301065, 301066 and 301073.

November Patch Tuesday release contains three critical remote code execution vulnerabilities

Cisco Talos Incident Response (Talos IR) recently observed an attacker conducting big-game hunting and double extortion attacks using the relatively new Interlock ransomware.

Thursday, November 7, 2024 06:00

*   Cisco Talos Incident Response (Talos IR) recently observed an attacker conducting big-game hunting and double extortion attacks using the relatively new Interlock ransomware.  
*   Our analysis uncovered that the attacker used multiple components in the delivery chain including a Remote Access Tool (RAT) masquerading as a fake browser updater, PowerShell scripts, a credential stealer, and a keylogger before deploying and enabling the ransomware encryptor binary. 
*   We also observed that the attacker primarily used remote desktop protocol (RDP) to move laterally within the victim’s network, as well as other tools such as AnyDesk and PuTTY. 
*   The attacker used Azure Storage Explorer, which leverages the utility AZCopy, to exfiltrate the victim’s data to an attacker-controlled Azure storage blob.  
*   The timeline of the attacker’s activity, from the initial compromise stage until the deployment of ransomware encryptor binary, indicates their dwelling time in the victim’s environment was about 17 days.  
*   Talos assesses with low confidence that Interlock ransomware is likely a new diversified group that emerged from Rhysida ransomware operators or developers, based on some similarities in the operators’ tactics, techniques, and procedures (TTPs) and in the ransomware encryptor binaries. 

**Who is Interlock? **

Interlock first appeared in public reporting in September 2024 and has been observed launching big-game hunting and double extortion attacks. The group has notably targeted businesses in a wide range of sectors, which at the time of reporting includes healthcare, technology, government in the U.S. and manufacturing in Europe, according to the data leak site disclosure, indicating their targeting is opportunistic. 

Like other ransomware players in the big-game hunting space, Interlock also operates a data leak site called “Worldwide Secrets Blog,” providing links to victims’ leaked data, chat support for victims' communications, and the email address, “interlock@2mail\[.\]co”.   

In their blog, Interlock claims to target organizations’ infrastructure by exploiting unaddressed vulnerabilities and claims their actions are in part motivated by a desire to hold companies’ accountable for poor cybersecurity, in addition to monetary gain. 

**Recent attack methodologies **

Throughout the investigation into the Interlock ransomware attack, Talos observed several notable TTPs used by the attacker in each stage of the delivery chain. Talos assesses that the attacker was present in the victim’s environment for approximately 17 days, from the initial compromise until deployment and execution of the Interlock ransomware. 

**Initial access **

The attacker gained access to the victim machine via a fake Google Chrome browser updater executable that the victim was prompted to download from a compromised legitimate news website.  When clicked, the fake browser updater executable “upd\_2327991.exe” was downloaded onto the victim machine from a second compromised URL of a legitimate retailer. 

**Execution **

Talos IR discovered the fake browser updater executable is a Remote Access Tool (RAT) that automatically executes an embedded PowerShell script when downloaded and run. The script initially downloads a legitimate Chrome setup executable “ChromeSetup.exe” to the victim machine’s applications temporary folder and established persistence by dropping a Windows shortcut file in the Windows StartUp folder with the file name “fahhs.lnk” configured to run the RAT every time the victim logs in, establishing persistence.  

Sample PowerShell command that downloads the RAT. 

The RAT executes the command “cmd.exe /c systeminfo" and collects information from victim machine, listed below:

Host Name

Time Zone

OS Name

Total Physical Memory

OS Version

Available Physical Memory

OS Manufacturer

Virtual Memory

OS Configuration

Max Size

OS Build Type

Virtual Memory: Available

Registered Owner

Virtual Memory: In Use

Registered Organization

Page File Location(s)

Product ID

Domain

Original Install Date

Logon Server

System Boot Time

Hotfix(s)

System Manufacturer

Network Card(s)

System Model

Connection Name

System Type

Status

Processor(s)

DHCP Enabled

BIOS Version

DHCP Server

Windows Directory

IP address(es)

System Directory

Hyper-V Requirements

Boot Device

System Locale

Then, the RAT encrypts the collected information in the memory stream. It establishes a secured socket to the command and control (C2) server hidden behind the attacker-controlled Cloudflare domain “apple-online\[.\]shop”, sends the encrypted data stream of victim machine information to the C2 server, and waits to receive the response.  

The RAT also allowed the attacker to execute two other PowerShell commands on the victim machine, which downloads the encrypted data blobs of a credential stealer “cht.exe” and a keylogger binary “klg.dll”, decrypts them with the passwords “jgSkhg934@kjv#1vkfg2S” and runs them. We observed that the keylogger is a DLL file that is run using the LOLBin “rundll32.exe”.  

A sample PowerShell command that downloads and runs the Keylogger. 

**Defense Evasion **

Talos IR observed that EDR was disabled on some of the compromised servers in the victim environment during the investigation. According to the indicators seen, Talos IR believes that the attacker could have either leveraged an EDR uninstaller tool or instrumented a vulnerable device driver Sysmon.sys (TfSysMon.sys) to disable the EDR on the victim machine. We also observed the attacker’s attempts to delete contents of the Event logs on some of the compromised systems.  

**Credential Access **

The credential stealer discovered in this campaign is compiled in Golang. It enumerates the installed browser profiles on the victim machine and copies the Login data, Login State, key4.db, browser history and bookmarks files to the victim’s application profile temporary folder. The stealer then processes the data and uses SQL queries to collect the login information of victims’ online accounts along with the associated account URLs. Finally, the data is written to a file “chrgetpdsi.txt” in the user profile temporary folder.  

The keylogger DLL running on the victim machine is a tiny executable, which hooks to the victim machine keyboard and logs keystrokes in a file called “conhost.txt”, the same folder where the Keylogger was downloaded.  

**Discovery **

The attacker ran PowerShell commands that are known indicators of pre-kerberoasting reconnaissance, a method used to obtain domain admin credentials. We assess with moderate confidence that a Kerberoasting attack was used to obtain accounts with higher privileges. 

(('AD\_Computers: {0}' -f (\[adsiSearcher\]'(ObjectClass=computer)').FindAll().count)  
(\[adsisearcher\]'(&(objectCategory=user)(servicePrincipalName=\*))').FindAll() 

**Lateral Movement **

Talos IR observed that the attacker primarily used Remote Desktop Protocol (RDP) and several compromised credentials to move between systems.  Further analysis showed that the attacker has also used AnyDesk and possibly LogMeIn to allow remote connectivity. We also spotted the installation of PuTTY on the compromised machines, which was likely used to move laterally to Linux hosts. We are not clear how these tools were dropped and executed on the infected machines. 

Sample RDP command executions observed during our analysis and with the redacted IP address details are shown below. 

mstsc /v 10.\*.\*.\* 
.\\conhost.exe -d \\10.\*.\*.\*\\e$ 

**Collection and Exfiltration  **

The attacker executed storage-explorer, a tool that allows users to manage and interact with Azure Storage, and AzCopy, which allows users to copy files to a remote Azure storage, in the victim’s machine. We believe that the attacker used storage-explorer to navigate and identify sensitive information in the victim network and executed AzCopy to upload the data to the Azure storage blob according to network artifacts analysis. We were not able to confirm how the storage-explorer and AzCopy were delivered to the victim machine. 

**Impact **

The attacker deployed the Interlock ransomware encryptor binary with the file name “conhost.exe”, masquerading as a legitimate file, onto the victim machine and stored it in a folder named with a single digit number (example: “3” or “4”) in the user profile application data temporary folder. When run, the ransomware encrypts the targeted files on the victim machine with the file extension “.Interlock” and drops the ransom note “!\_\_README\_\_!.txt” file in every folder containing files that the encryptor has attempted to encrypt. Talos IR also observed that the attacker configured the ransom note to display during interactive login, was pushed using Group Policy Objects (GPOs), a Windows utility that allows users to manage Windows operating systems and applications.  

In the ransom note, the attacker warns against attempting to recover the encrypted files and rebooting the affected machines. They also demand a response within 96 hours or else they threaten to release the victim's data on their leak site and notify the media outlets, which could lead to financial and reputational damage.  

The ransom note includes the URL for an onion site where the affected victims can contact the operator to discuss the ransom demand and purchase the decryption keys using a unique company ID of sixty alphanumeric characters generated for each victim. 

**Interlock ransomware analysis **

Talos observed that Interlock ransomware has both Windows Portable Executable (EXE) and the Linux executable (ELF) variants, indicating that the attacker is targeting both Windows and Linux machines.   

The Interlock ransomware encryption binary is a 64-bit executable, compiled on October 2, 2024. The ransomware appears on the victim’s machines in a packed executable format with the custom unpacker code located in its Thread Local Storage and several obfuscated stack strings in the binary which are decrypted during the runtime of the ransomware. 

When the ransomware runs on the victim machine it initializes the binary by loading custom structures, strings, and Application programming interface (API) functions. After the initialization, it enumerates the logical disk drives that are available on the victim machine. Initially, the ransomware checks for the drive letters “A” through “Z” and excludes the “C drive”. It picks the available logical drives and enumerates all the folders and files in them, encrypting the targeted files on the victim machine and appending the file extension “.interlock” on encrypted files. Once the logical drives are enumerated, the ransomware then enumerates and encrypts the files in the folders of the “C drive”.  

During this enumeration process, the ransomware excludes specific folders and file extensions on the victim machine from being encrypted. The operator hardcoded the folder and files extension exclusion list, shown below, in the Interlock binary.

Folder exclusion list of Windows Interlock variant:

$Recycle.Bin

Windows

Boot

$RECYCLE.BIN

Documents and Settings

AppData

PerfLogs

WindowsApps

ProgramData

Windows Defender

Recovery

WindowsPowerShell

System Volume Information

Windows Defender Advanced Threat Protection

File extension exclusion list of Windows Interlock variant:

.bat

.bin

.cab

.cmd

.com

.cur

.diagcab

.diagcfg

.diagpkg

.drv

.hlp

.hta

.ico

.msi

.ocx

.psm1

.src

.sys

.ini

.url

.dll

.exe

.ps1

Thumbs.db

The Linux variant of the Interlock ransomware performs a similar enumeration of directories and files, starting from the root directory, and encrypts the files excluding those that are in the file extension exclusion list hardcoded in the binary.

File extension exclusion list of Linux Interlock variant:

boot

.cfg

.b00

.v00

.v01

.v02

.v03

.v04

.v05

.v06

.v07

.t00

Interlock ransomware uses LibTomCrypt library, an open-source comprehensive, modular and portable cryptographic library for encryption.  The Windows Interlock ransomware variant uses the Cipher Block Chaining (CBC) encryption technique to encrypt the files on the victim machine whereas the Linux Interlock variant uses either CBC or RSA encryption technique. 

Encryption routine in Windows variant 

Encryption routine in ELF variant 

 

 

After encrypting each of the targeted files in the victim machine Interlock drops the ransom note “!\_\_README\_\_!.txt” file in each of the enumerated folders. 

Windows variant ransom note function 

ELF variant ransom note function 

 

 

We observed that the Windows Interlock variant creates a windows task name “TaskSystem” that runs at 8:00 PM daily on the victim machine as a SYSTEM user executing the configured command to run the ransomware, indicating the ransomware establishing the persistence.  

schtasks /create /sc DAILY /tn “TaskSystem” /tr “cmd /c cd "$Path of the Interlock binary" && "$command” /st 20:00 /ru system > nul

The ransomware has the capability to delete itself upon encrypting the targeted files, hiding the evidence of the encryption binary on the victim machine.  To delete the encryption binary in the Windows variant, Interlock ransomware has a tiny DLL binary embedded in the data section that is dropped into the user profile applications temporary folder with the file name “tmp41.wasd”.  

Then, “rundll32.exe” is used to execute the DLL’s export function, called “run”, which then executes the remove() function to delete the encryption binary.  

The Linux variant uses a similar technique to delete the encryptor binary from the victim machine, by executing the removeme function, which is an inline routine in the same encryptor binary.  

**Interlock TTPs overlap with Rhysida Ransomware **

Talos assesses with low confidence that Interlock ransomware is a new diversified group that emerged from Rhysida operators or developers, based on some similarities in TTPs, tools, and the ransomware encryptor binaries’ behaviors. 

We discovered code overlaps in the binaries of Interlock and Rhysida ransomware samples. Notably, the files and folders exclusion list hardcoded in the Windows variant of the Interlock ransomware has similarities with the exclusion list in Rhysida ransomware, reported by Talos in an August 2023 Threat Advisory. 

Additionally, the Interlock ransomware encryptor with the filename “conhost.exe” was earlier seen in Rhysida ransomware attacks, along with overlaps in TTPs and tools including PowerShell scripts, AnyDesk, and PuTTY, based on a CISA #StopRansomware advisory report on Rhysida Ransomware. Furthermore, both Rhysida and Interlock operators use AzCopy to exfiltrate the victim’s data to an attacker-controlled Azure storage blob, an old but uncommon technique. 

Finally, Interlock and Rhysida deliver ransom notes with a similar theme, where they portray themselves as a helpful partner notifying the victim of a breach and offering to help rectify it. This is in contrast to other prolific and sophisticated cyber groups, such a Black Basta and ALPHV, whose ransom notes demand payment, threaten, and attempt to intimidate the victim.  

Rhysida ransom note. 

Interlock ransom note. 

Interlock’s possible affiliation with Rhysida operators or developers would align with several broader trends in the cyber threat landscape, which Talos reported in our 2022 and 2023 Year in Review reports. We observed ransomware groups diversifying their capabilities to support more advanced and varied operations, and ransomware groups have been growing less siloed, as we observed operators increasingly working alongside multiple ransomware groups. 

****Coverage** **

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 Web Appliance web scanning prevents access to malicious websites and detects malware used in these attacks. 

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 Malware Analytics (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 protection 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 64114, 64113, 64189 and 301042. 

ClamAV detections are also available for this threat: 

Win.Ransomware.Interlock-10036524-0 

Unix.Ransomware.Interlock-10036662-0 

Win.Trojan.Kryptik-10036729-0 

Win.Downloader.Kryptik-10036730-0 

**Indicators of Compromise **

IOCs for this threat can be found in our GitHub repository here.

Unwrapping the emerging Interlock ransomware attack

Cisco Talos' Vulnerability Research team recently discovered five Nvidia out-of-bounds access vulnerabilities in shader processing, as well as eleven LevelOne router vulnerabilities spanning a range of possible exploits.
For Snort coverage that can detect the exploitation of these vulnerabilities, download the latest rule sets from Snort.org, and our

Thursday, October 31, 2024 11:29

Cisco Talos' Vulnerability Research team recently discovered five Nvidia out-of-bounds access vulnerabilities in shader processing, as well as eleven LevelOne router vulnerabilities spanning a range of possible exploits.

For Snort coverage that can detect the exploitation of these vulnerabilities, download the latest rule sets from Snort.org, and our latest Vulnerability Advisories are always posted on Talos Intelligence’s website. 

**NVIDIA Graphics remote out-of-bounds execution vulnerabilities**

_Discovered by Piotr Bania._

NVIDIA Graphics drivers are software for NVIDIA Graphics GPU installed on the PC. They are used to communicate between the operating system and the GPU device. This software is required in most cases for the hardware device to function properly.

Talos discovered multiple out-of-bounds read vulnerabilities in Nvidia that could be triggered remotely in virtualized environments, via web browser, potentially leading to disclosure of sensitive information and further memory corruption. Researchers used RemoteFX; while recently deprecated by Microsoft, some older machines may still use this software.

Advisories related to these vulnerabilities:  
TALOS-2024-1955 (CVE-2024-0121)  
TALOS-2024-2012 (CVE-2024-0117)  
TALOS-2024-2013 (CVE-2024-0118)  
TALOS-2024-2014 (CVE-2024-0120)  
TALOS-2024-2015 (CVE-2024-0119)

**LevelOne wireless SOHO router vulnerabilities**

_Discovered by Patrick DeSantis and Francesco Benvenuto_.

Eleven vulnerabilities of different types were discovered in the LevelOne WBR-6012 SOHO router.

The LevelOne WBR-6012 is a low-cost wireless SOHO router, marketed as an easy-to-configure and operate internet gateway for homes and small offices.

Talos discovered these vulnerabilities in the R0.30e6 version of the router:

TALOS-2024-1979 (CVE-2024-28875,CVE-2024-31151): Hard-coded credentials exist in the web service, allowing attackers to gain unauthorized access during the first 30 seconds post-boot. Used with other vulnerabilities that force a reboot, time restrictions for exploitation can be greatly reduced. An undocumented user account with hard-coded credentials also exists.

TALOS-2024-1981 (CVE-2024-24777): A cross-site request forgery vulnerability exists in the web application, and a specially crafted HTTP request can lead to unauthorized access. An attacker can stage a malicious web page to trigger this vulnerability.

TALOS-2024-1982 (CVE-2024-31152): An improper resource allocation vulnerability exists due to improper resource allocation within the web application. A series of HTTP requests can cause a reboot, which could lead to network service interruptions and access to a backdoor account.

TALOS-2024-1983 (CVE-2024-32946): A cleartext transmission vulnerability exists, and sensitive information is transmitted via FTP and HTTP services, exposing it to network sniffing attacks.

TALOS-2024-1984 (CVE-2024-33699): A weak authentication vulnerability exists in the web application firmware, which allows attackers to change the administrator password to gain higher privileges without knowing the current administrator password.

TALOS-2024-1985 (CVE-2024-33603): An information disclosure in the web application allows unauthenticated users to access an undocumented verbose system log page and obtain sensitive data, such as memory addresses and IP addresses for login attempts. This flaw could lead to session hijacking due to the device's reliance on IP addresses for authentication.

TALOS-2024-1986 (CVE-2024-33626): A web application information disclosure vulnerability can reveal sensitive information, such as the Wi-Fi WPS PIN, through a hidden page accessible by an HTTP request. Disclosure of this information could enable attackers to connect to the device's Wi-Fi network.

TALOS-2024-1996 (CVE-2024-23309): An authentication bypass vulnerability results from the web application’s reliance on client IP addresses for authentication. Attackers can spoof an IP address to gain unauthorized access without a session token.

TALOS-2024-1997 (CVE-2024-28052): A buffer overflow vulnerability can be caused by specially crafted HTTP POST requests with URIs containing 1,454 or more characters, not starting with “upn” or “upg”.

TALOS-2024-1998 (CVE-2024-33700): An improper input validation within the FTP functionality can enable attackers to cause denial of service through a series of malformed FTP commands.

TALOS-2024-2001 (CVE-2024-33623): A denial-of-service vulnerability, triggered by multiple types of specially crafted HTTP POST requests, will cause the router to crash.

NVIDIA shader out-of-bounds and eleven LevelOne router vulnerabilities

Cisco Talos has observed an unknown threat actor conducting a phishing campaign targeting Facebook business and advertising account users in Taiwan. 
The decoy email and fake PDF filenames are designed to impersonate a company's legal department, attempting to lure the victim into downloading and executing malware.

Thursday, October 31, 2024 09:37

*   Cisco Talos has observed an unknown threat actor conducting a phishing campaign targeting Facebook business and advertising account users in Taiwan. 
*   The decoy email and fake PDF filenames are designed to impersonate a company's legal department, attempting to lure the victim into downloading and executing malware. 
*   This campaign abuses Google's Appspot\[.\]com domains, a short URL and Dropbox service, to deliver an information stealer onto the target's machine to avoid network security product detections. 
*   Talos also observed the threat actor using multiple techniques to evade antivirus detection and sandbox analysis, such as code obfuscation, shellcode encryption, hiding malicious code in resource data to expand the file size to over 700 MB, and embedding LummaC2 or Rhadamanthys information stealers into legitimate binaries. 

**Phishing email campaign targets Taiwan **

Talos observed an unknown threat actor conducting a malicious phishing campaign targeting victims in Taiwan since at least July 2024. The campaign specifically targets victims whose Facebook accounts are used for business or advertising purposes. 

The initial vector of the campaign is a phishing email containing a malware download link. The phishing email uses traditional Chinese in decoy templates and the fake PDF files, suggesting the target is likely traditional Chinese speakers. Some of the fake PDF filenames that we observed during our analysis are: 

*   IMAGE COPYRIGHTED.exe 
*   \[Redacted\] 的影片內容遭到侵犯版權.exe (translates to “\[Redacted\]'s video content has been copyright infringed.exe”) 
*   版權侵權信息- \[Redacted\] Media Co Ltd.exe (translates to “Copyright Infringement Information - \[Redacted\] Media Co Ltd.exe”) 
*   版權侵權信息- \[Redacted\] Media Group Inc.exe (translates to “Copyright Infringement Information - \[Redacted\] Media Group Inc.exe”) 
*   版權侵權信息- \[Redacted\] Technology Group.exe (translates to “Copyright Infringement Information - \[Redacted\] Technology Group.exe”) 
*   版權侵權信息- \[Redacted\] Co. Ltd.exe (translates to “Copyright Infringement Information - \[Redacted\] Co. Ltd.exe”) 
*   \[Redacted\] Online -宣布侵權.exe (translates to “\[Redacted\] Online - declare infringement.exe”) 

The decoy email and fake PDF filenames are designed to impersonate a company's legal department, attempting to lure the victim into downloading and executing malware. Another observation we found is that the fake PDF malware uses the names of well-known technology and media companies in Taiwan and Hong Kong. This provides strong evidence that the threat actor conducted thorough research before launching this campaign. 

Additionally, we observed two phishing emails masquerading as notices from a well-known industrial motor manufacturer and a famous online shopping store in Taiwan. The emails claim that the company’s legal representatives have issued a notice to a Facebook page administrator alleging copyright infringement due to the unauthorized use of their images and videos for product promotion. The emails demand the removal of the infringing content within 24 hours, cessation of further use without written permission, and warn of potential legal action and compensation claims for non-compliance. Last but not least, with these two emails, we can easily identify that the threat actor uses the same template with minor modifications, such as changing the company name, legal department information, address, and website.  

Phishing email impersonating a well-known industrial motor manufacturer. 

Phishing email impersonating a famous online shopping store. 

**Attribution **

Talos observed an unknown image printing EPS file within the encrypted archive, with the filename "Support." Based on the file name and file size, it is likely that all encrypted archives we found on VirusTotal, which we have not been able to decrypt, contain the same EPS files inside. Pivoting off the EPS file metadata and its preview image on a search engine, we found an identical image with the same file name on a Vietnamese-language website. However, there is no strong evidence that it was created by an author from that region.   

Support EPS file metadata. 

The support EPS file preview image in this campaign (left) and the image we found from the internet (right). 

**Actor infrastructure **

The threat actor is abusing Google's Appspot.com domains, a short URL and Dropbox service, to deliver an information stealer onto the target's machine. Appspot.com is a cloud computing platform for developing and hosting web applications in Google-managed data centers. When the victim clicks on the download link, it initially connects to Appspot.com, then redirects to a short URL created by a third-party service, and finally redirects to Dropbox to download the malicious archive. The actor is using the third-party data storage service as a download server to deceive network defenders.  

Malware download link. 

We also discovered that the actor is using multiple command and control (C2) domains in the campaign. The DNS requests for the domains during our analysis period are shown in the graph, indicating the campaign is ongoing.  

C2 domain DNS requests. 

**Malware infection summary **

The infection chain begins with a phishing email containing a malicious download link. When the victim downloads the malicious RAR file, they will need a specific password to extract it, revealing a fake PDF executable malware and an image printing file. Once the malware is decrypted and the fake PDF executable is run, it will execute the embedded LummaC2 or Rhadamanthys information stealer, which then collects the victim’s credentials and data, sending them back to the C2 server. 

The malicious RAR file usually contains a fake PDF executable malware and an image printing file, but we observed a few malicious RAR files that contain an additional DLL file. However, without the correct password, we are not able to extract the malicious RAR file and analyze it. 

The RAR file contains a fake PDF and an image printing file.  

The RAR file contains a fake PDF, an image printing file, and additional DLL file. 

The fake PDF executable malware variant was delivered as a payload in this campaign. This malware will embed LummaC2 or Rhadamanthys information stealers into legitimate binary and the legitimate binary including iMazing Converter, foobar2000, Punto Switcher, PDF Visual Repair, LedStatusApp, and PrivacyEraser. Below shows one of the file details of the fake PDF executable. 

Fake PDF file detail information. 

**LummaC2 stealer and its loader **

LummaC2 Stealer is a type of malware designed to exfiltrate sensitive information from compromised systems. It can target system details, web browsers, cryptocurrency wallets, and browser extensions. Written in C, this malware is sold on underground forums. To avoid detection and analysis, it employs various obfuscation methods. The malware connects to a C2 server to receive instructions and transmit the stolen data. 

The loader for LummaC2 changes the execution flow of the binary malware, causing it to invoke an unknown library to execute the malicious code functions. This strategic modification complicates detection and analysis efforts. Once these malicious functions are invoked, the malware utilizes the CreateFileMappingA API to write the payload into a mapped memory block, effectively hiding it within the system's memory. After successfully mapping the payload, the malware then executes it. 

Call to an unknown library to execute the malicious code functions. 

When the malware begins executing the shellcode in memory, it first decrypts the second half of the program block, which contains part of the shellcode loader and the LummaC2 malware execution file. Once the decryption is complete, it will call the VirtualAllocate API to allocate a memory block, write the information stealer's execution file to that block, and then execute it.   

Jump code to shellcode block. 

 

 

Encrypted shellcode (left side) and decrypted shellcode (right side). 

We also collected all of the build IDs of the LummaC2 in this campaign and below are the screenshots of the LummaC2 stealer alert message box and its POST message. 

Alert message shown to the user when executing LummaC2. 

POST message with act=life and url path /api. 

Build ID: 

*   sTDsFx--Socks 
*   iAlMAC--ghost 

**Rhadamanthys stealer and its loader **

Rhadamanthys is a sophisticated information stealer that emerged in 2022 and is sold on underground forums. This comprehensive stealer malware is capable of gathering system information, credentials, cryptocurrency wallets, browser passwords, cookies, and data from various other applications. It employs numerous anti-analysis techniques, complicating analysis efforts and hindering its execution in sandbox environments. 

We observed the Rhadamanthys loader in this campaign contains 10 sections in its binary structure. Despite the presence of multiple sections, the threat actor specifically targets the .rsrc section to insert the malicious code. This section is heavily obfuscated to conceal the malicious activities and make analyses more challenging. The choice of the .rsrc section is strategic, as it is typically associated with resource data like icons and menus, making it less likely to raise immediate suspicion.  

The loader of Rhadamanthys binary structure sections. 

After analysis, we discovered that the Rhadamanthys loader employs several sophisticated techniques to ensure its persistence and evasion. Initially, the loader copies itself and writes the file to “C:\\Users\\\[user\]\\Documents\\lumuiUpdater\\ffUpdaar.exe”. In order to avoid detection by antivirus programs and sandbox environments, it expands the file size to over 700 MB. This significant increase in file size is intended to bypass heuristic and signature-based detection mechanisms commonly used by security products, which may struggle to process such large files effectively. 

The loader copies itself to the lumuiUpdater folder. 

Furthermore, the loader is configured to start automatically by modifying the Windows Registry. It writes an entry to “HKEY\_CURRENT\_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Run” and key name value “sausageLoop”, a registry key that specifies programs to be launched during the system startup. This registry modification ensures that the malicious loader is executed every time the victim's computer restarts, thereby maintaining its persistence on the infected system. 

The loader is configured to start automatically. 

Finally, the loader executes the legitimate system process "%Systemroot%\\system32\\dialer.exe" and injects Rhadamanthys' payload into it. This process injection technique allows the malware to run its malicious code within the context of a legitimate system process, further evading detection. Additionally, it uses mutex objects to ensure that only one instance of the malware runs on the infected host. Below is the list of mutex names we observed in this campaign, which has also been disclosed in previous reporting by other. 

*   Global\\MSCTF.Asm.{04fb3f26-9d18-66b5-6862-7b8a85e4b620} 
*   Session\\1\\MSCTF.Asm.{04fb3f26-9d18-66b5-6862-7b8a85e4b620} 
*   Session\\2\\MSCTF.Asm.{04fb3f26-9d18-66b5-6862-7b8a85e4b620} 
*   Session\\3\\MSCTF.Asm.{04fb3f26-9d18-66b5-6862-7b8a85e4b620} 
*   Session\\4\\MSCTF.Asm.{04fb3f26-9d18-66b5-6862-7b8a85e4b620} 
*   Session\\5\\MSCTF.Asm.{04fb3f26-9d18-66b5-6862-7b8a85e4b620} 
*   Session\\6\\MSCTF.Asm.{04fb3f26-9d18-66b5-6862-7b8a85e4b620} 
*   Session\\7\\MSCTF.Asm.{04fb3f26-9d18-66b5-6862-7b8a85e4b620} 
*   Session\\8\\MSCTF.Asm.{04fb3f26-9d18-66b5-6862-7b8a85e4b620} 

**Coverage **

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 Web Appliance web scanning prevents access to malicious websites and detects malware used in these attacks. 

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 Malware Analytics (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 protection 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 64167-64169. 

**IOC **

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

Threat actors use copyright infringement phishing lure to deploy infostealers

This blog will demonstrate the practice and methodology of reversing BugSleep’s protocol, writing a functional C2 server, and detecting this traffic with Snort.

Wednesday, October 30, 2024 06:00

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).  

Type 

Value 

Plain text 

Cipher text 

IntegerMsg 

6 

06 00 00 00 

03 FD FD FD 

StringMsg  

Talos 

05 00 00 00 48 65 6C 6C 6F 

02 FD FD FD 51 5E 69 6C 70

_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. 

Figure 2: Command IDs used by implant 

**Phoning home **

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

Figure 3: BugSleep beacon as seen through 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.  

Figure 4: Decoding beacon data 

**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.

Figure 5: Output from C2 server receiving beacon data 

**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.  

Figure 6: Switch case for handling ping command 

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. 

Figure 7: Confirming 0xdeadbeef written to memory is received by the server in a Ping command 

**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.  

Figure 8: GetFile reading path string length and path string from socket 

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: 

Figure 9: SendSocket calls made by CmdGetFile function 

Figure 10: Example C2 server output from GetFile command 

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

Figure 11: Tricky file pointer math 

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 “terminate\\n”.  

Figure 12: Example output from C2 server running the reverse shell command 

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. 

Figure 13: Detecting higher order encoded zero bytes of beacons sent from BugSleep 

 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: 

Figure 14: Restricting rule to inspect traffic leaving the network to port 443 

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.  

Figure 15: Snort rule for detecting BugSleep command sent from C2 server 

**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).  

Figure 16: Beacon rule attempting to catch forward-slash in Computer Name/Username string 

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).  

Figure 17: Individual beacon packets being processed by Snort 

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.

Figure 18: Snort trace output setting flowbit for BugSleep beacon 

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.  

Figure 19: Get file command rule alerts on traffic 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. 

Figure 20: Put file command traffic failing flowbit check 

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:  

Figure 21: Fixed beacon rule looking for 4-byte length segments 

 Now the rules work as expected!  

Figure 22: Snort output alerting on traffic from all BugSleep commands 

**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. 

SHA256 

Compile Time 

b8703744744555ad841f922995cef5dbca11da22565195d05529f5f9095fbfca 

Wed., May 8 00:55:53 2024 UTC 

94278fa01900fdbfb58d2e373895c045c69c01915edc5349cd6f3e5b7130c472 

Wed., May 22 21:56:39 2024 UTC 

73c677dd3b264e7eb80e26e78ac9df1dba30915b5ce3b1bc1c83db52b9c6b30e 

Fri., May 31 23:29:21 2024 UTC 

5df724c220aed7b4878a2a557502a5cefee736406e25ca48ca11a70608f3a1c0 

Sun., Jul 07 21:09:49 2024 UTC 

960d4c9e79e751be6cad470e4f8e1d3a2b11f76f47597df8619ae41c96ba5809 

Sat., Jul 15 09:15:20 2079 UTC

Writing a BugSleep C2 server and detecting its traffic with Snort

Can LLM tools actually help defenders in the cybersecurity industry write more effective detection content? Read the full research

Friday, October 25, 2024 10:09

Most users will associate large language models (LLMs) like ChatGPT with answering basic questions or helping to write basics lines of text.  

But could these tools actually help defenders in the cybersecurity industry write more effective detection content?  

Several security researchers from across Cisco recently looked into how LLMs, which have surged in popularity over the past year, could assist them in the detection research process. 

Part of their jobs is to try and perform test behavior that will trigger existing detection rules to check their effectiveness and try to emulate the behavior of a typical adversary — all in the name of updating that detection content to catch the latest tactics, techniques and procedures (TTPs). 

LLMs may be able to assist in this complex, time-consuming tax, as Darin Smith, Yuvi Meiyappan, Moazzam Khan and Ray McCormick write in this paper, which you can download below. 

Khan, a security researcher for Cisco, will be presenting the findings of this paper at the upcoming BSides Portland conference.