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

Cisco denies recent data breach claims by the Kraken ransomware group, stating leaked credentials are from a resolved 2022 incident. Learn more about Cisco's response and the details of the original attack.

Cisco has refuted claims of a recent data breach after the Kraken ransomware group published sensitive information, allegedly stolen from the company’s internal network, on its dark web leak site. Cyber Press reported on the ransomware group’s claims, which included the exposure of credentials linked to Cisco’s Windows Active Directory environment. 

According to the report, the leaked dataset contained usernames and their associated domains, unique relative identifiers (RIDs) for each user account, and hashed representations of passwords (NTLM hashes). The compromised accounts include privileged administrator accounts, regular user accounts, service and machine accounts linked to domain controllers, and the crucial Kerberos Ticket Granting Ticket (krbtgt) account.

The report further revealed that credential-dumping tools like Mimikatz, pwdump, or hashdump were likely used to extract this information. These tools are commonly employed by cybercriminals and advanced persistent threat (APT) groups to harvest credentials stored within system memory. Alongside the leaked data, the attackers left a threatening message, hinting at their intent to inflict further damage.  

“You lied to us and play for time to kick us out. We will meet you soon, again. Next time you’ll have no chance,” attackers stated.

Files published by the Kraken ransomware group (Image via: CyberPress)

However, Cisco has issued an official statement contradicting the ransomware group’s claims, revealing that the exposed credentials stem from a previously disclosed security incident that occurred back in May 2022.  

“Cisco is aware of certain reports regarding a security incident. The incident referenced in the reports occurred back in May 2022, and we fully addressed it at that time. Based on our investigation there was no impact to our customers,” the company stated.

Hackread.com reported a breach where attackers gained control of a Cisco employee’s personal Google account containing company credentials. Through sophisticated voice phishing (vishing) attacks, the attackers bypassed multi-factor authentication (MFA) and gained access to the target user’s VPN. Cisco confirmed it successfully removed the intruder, who made several unsuccessful attempts to regain access in the following weeks.

Cisco’s CSRIT and Talos teams found no evidence suggesting the attacker accessed critical internal systems, such as the production environment or code signing architecture.  

At the time of the 2022 incident, Cisco believed the perpetrator was an initial access broker (IAB) linked to the group tracked by Mandiant as UNC2447, known for its use of the FiveHands malware, as well as the Lapsus$ threat collective and the Yanluowang ransomware operation.  

While the current claims by the Kraken ransomware group involve data from an older incident, the re-emergence of this information highlights the increasing prevalence of credential-based cyberattacks and the need to implement advanced yet reliable security measures.

Organizations should adopt proactive defences, such as forced password resets, disabling NTLM authentication, implementing multi-factor authentication, monitoring access logs for unauthorized activity, and enhancing network monitoring to detect intrusion attempts.

Cisco Rejects Kraken Ransomware’s Data Breach Claims

The popular generative AI (GenAI) model allows hallucinations, easily avoidable guardrails, susceptibility to jailbreaking and malware creation requests, and more at critically high rates, researchers find.

Source: Mundissima via Alamy Stock Photo

Organizations might want to think twice before using the Chinese generative AI (GenAI) DeepSeek in business applications, after it failed a barrage of 6,400 security tests that demonstrate a widespread lack of guardrails in the model.

That's according to researchers at AppSOC, who conducted rigorous testing on a version of the DeepSeek-R1 large language model (LLM). Their results showed the model failed in multiple critical areas, including succumbing to jailbreaking, prompt injection, malware generation, supply chain, and toxicity. Failure rates ranged between 19.2% and 98%, they revealed in a recent report.

Two of the highest areas of failure were the ability for users to generate malware and viruses using the model, posing both a significant opportunity for threat actors and a significant threat to enterprise users. The testing convinced DeepSeek to create malware 98.8% of the time (the "failure rate," as the researchers dubbed it) and to generate virus code 86.7% of the time.

Such a lackluster performance against security metrics means that despite all the hype around the open source, much more affordable DeepSeek as the next big thing in GenAI, organizations should not consider the current version of the model for use in the enterprise, says Mali Gorantla, co-founder and chief scientist at AppSOC.

Related:CISA Places Election Security Staffers on Leave

"For most enterprise applications, failure rates about 2% are considered unacceptable," he explains to Dark Reading. "Our recommendation would be to block usage of this model for any business-related AI use."

**DeepSeek's High-Risk Security Testing Results**

Overall, DeepSeek earned an 8.3 out of 10 on the AppSOC testing scale for security risk, 10 being the riskiest, resulting in a rating of "high risk." AppSOC recommended that organizations specifically refrain from using the model for any applications involving personal information, sensitive data, or intellectual property (IP), according to the report.

AppSOC used model scanning and red teaming to assess risk in several critical categories, including: jailbreaking, or "do anything now," prompting that disregards system prompts/guardrails; prompt injection to ask a model to ignore guardrails, leak data, or subvert behavior; malware creation; supply chain issues, in which the model hallucinates and makes unsafe software package recommendations; and toxicity, in which AI-trained prompts result in the model generating toxic output.

The researchers also tested DeepSeek against categories of high risk, including: training data leaks; virus code generation; hallucinations that offer false information or results; and glitches, in which random "glitch" tokens resulted in the model showing unusual behavior.

Related:Data Leaks Happen Most Often in These States — Here's Why

According to Gorantla's assessment, DeepSeek demonstrated a passable score only in the training data leak category, showing a failure rate of 1.4%. In all other categories, the model showed failure rates of 19.2% or more, with median results in the range of a 46% failure rate.

"These are all serious security threats, even with much lower failure rates," Gorantla says. However, the high failure results in the malware and virus categories demonstrate significant risk for an enterprise. "Having an LLM actually generate malware or viruses provides a new avenue for malicious code, directly into enterprise systems," he says.

**DeepSeek Use: Enterprises Proceed With Caution**

AppSOC's results reflect some issues that have already emerged around DeepSeek since its release to much fanfare in January with claims of exceptional performance and efficiency even though it was developed for less than $6 million by a scrappy Chinese startup.

Soon after its release, researchers jailbroke DeepSeek, revealing the instructions that define how it operates. The model also has been controversial in other ways, with claims of IP theft from OpenAI, while attackers looking to benefit from its notoriety already have targeted DeepSeek in malicious campaigns.

Related:XE Group Shifts From Card Skimming to Supply Chain Attacks

If organizations choose to ignore AppSOC's overall advice not to use DeepSeek for business applications, they should take several steps to protect themselves, Gorantla says. These include using a discovery tool to find and audit any models used within an organization.

"Models are often casually downloaded and intended for testing only, but they can easily slip into production systems if there isn't visibility and governance over models," he says.

The next step is to scan all models to test for security weaknesses and vulnerabilities before they go into production, something that should be done on a recurring basis. Organizations also should implement tools that can check the security posture of AI systems on an ongoing basis, including looking for scenarios such as misconfigurations, improper access permissions, and unsanctioned models, Gorantla says.

Finally, these security checks and scans need to be performed during development (and continuously during runtime) to look for changes. Organizations should also monitor user prompts and responses, to avoid data leaks or other security issues, he adds.

**About the Author**

Elizabeth Montalbano is a freelance writer, journalist, and therapeutic writing mentor with more than 25 years of professional experience. Her areas of expertise include technology, business, and culture. Elizabeth previously lived and worked as a full-time journalist in Phoenix, San Francisco, and New York City; she currently resides in a village on the southwest coast of Portugal. In her free time, she enjoys surfing, hiking with her dogs, traveling, playing music, yoga, and cooking.

DeepSeek AI Fails Multiple Security Tests, Raising Red Flag for Businesses

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.

Source: Diana Vyshniakova via Alamy Stock Photo

Attackers are exploiting Google Tag Manager by planting malicious code within e-commerce sites built on the Magento platform. The code can steal payment card data, demonstrating a new type of Magecart attack that leverages Google's free, legitimate website marketing tool.

Researchers from Sucuri discovered an ongoing Magecart campaign in which attackers load code that appears to be a standard Google Tag Manager (GTM) and Google Analytics tracking script from a database onto e-commerce sites. These tracking scripts are typically used for website analytics and advertising purposes; however, the code used in the campaign has been tweaked to act as a card skimmer for the infected site, the researchers revealed in a recent blog post.

"Within the GTM tag, there was an encoded JavaScript payload that acted as a credit card skimmer," Sucuri security analyst Puja Srivastava wrote in the post. "This script was designed to collect sensitive data entered by users during the checkout process and send it to a remote server controlled by the attackers."

So far, Sucuri has uncovered at least six sites affected by the campaign, "indicating that this threat is actively affecting multiple sites," Srivastava wrote.

**Exploiting a Legitimate Google Tool for Card Skimming**

Related:Canadian Man Charged in $65M Cryptocurrency Hacking Schemes

The attack demonstrates a nontypical Magecart attack that leverages a legitimate free tool from Google that allows website owners to manage and deploy marketing tags on their website without needing to modify the site's code directly. GTM eliminates the need for developer intervention each time a marketer aims to track or modify an ad or marketing campaign.

Sucuri researchers were alerted to the Magecart activity by a customer who found that someone was stealing credit card payment data from its e-commerce site. An investigation led to the discovery of malware being loaded from a database table cms\_block.content file for the website. The malware abused a GTM tag, which was altered by embedding an encoded JavaScript payload that acted as a credit card skimmer.

Attackers obfuscated the script using the technique function \_0x5cdc, which maps index values to specific characters in the array. This makes it difficult for someone to immediately understand the purpose of the script, Srivastava wrote.

The script also uses a series of mathematical operations in a loop, further scrambling the code, and also uses Base64 encoding. "This is a trick often used by attackers to disguise the true purpose of the script," she wrote.

The researchers also discovered an undeployed backdoor in one of the website's files that "could have been exploited to further infect the site, providing attackers with persistent access," Srivastava added. Indeed, Magecart attackers last year demonstrated a new tactic of stashing backdoors on websites to deploy malware automatically.

Related:Behavioral Analytics in Cybersecurity: Who Benefits Most?

Sucuri also previously investigated malicious activity that abused GTM to hide other types of malicious activity, including malvertising as well as malicious pop-ups and redirects.

**Mitigation & Remediation of Magecart Attacks**

"Magecart" refers to a loose collective of cybercriminal groups involved in online payment card-skimming attacks. These attacks typically inject card skimmers into websites to steal payment card data that can later be monetized. Big-name organizations that have been targeted by these attacks include Ticketmaster, British Airways, and the Green Bay Packers NFL team.

Once they identified the source of infection on their customer's site, Sucuri researchers removed the malicious code from any other compromised areas of the site, as well as cleaned up the obfuscated script and the backdoor to prevent the malware from being reintroduced.

To ensure an organization's e-commerce site has not been affected by the campaign, administrators should log in to GTM, and then identify and delete any suspicious tags that are being used on the site, Sucuri recommended. They also should perform a full website scan to detect any other malware or backdoors, and remove any malicious scripts or backdoor files.

Related:Cybercrime Forces Local Law Enforcement to Shift Focus

E-commerce sites built on Magento and their extensions also should be updated with the latest security patches, while all site administrators should regularly monitor e-commerce site traffic as well as GTM activity for anything unusual.

**About the Author**

Elizabeth Montalbano is a freelance writer, journalist, and therapeutic writing mentor with more than 25 years of professional experience. Her areas of expertise include technology, business, and culture. Elizabeth previously lived and worked as a full-time journalist in Phoenix, San Francisco, and New York City; she currently resides in a village on the southwest coast of Portugal. In her free time, she enjoys surfing, hiking with her dogs, traveling, playing music, yoga, and cooking.

Magecart Attackers Abuse Google Ad Tool to Steal Data

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

Cisco has released updates to address two critical security flaws Identity Services Engine (ISE) that could allow remote attackers to execute arbitrary commands and elevate privileges on susceptible devices.
The vulnerabilities are listed below -

CVE-2025-20124 (CVSS score: 9.9) - An insecure Java deserialization vulnerability in an API of Cisco ISE that could permit an authenticated, remote

Cisco Patches Critical ISE Vulnerabilities Enabling Root CmdExec and PrivEsc

Malvertisers got inspired by the website for a German university to bypass ad security and distribute malware.

There is a constant “cat and mouse” game between defenders and attackers, the latter trying to outsmart and get a head start on the former. In the context of online advertising, this involves creating fake identities or using stolen ones to push out malicious ads.

An attacker not only needs to evade detection but also create a lure that will be convincing to most people. In this blog post, we focus on what malvertisers use in almost all of their campaigns, namely decoys also known as “white pages” in order to fool the advertising entity.

The particular case is a malicious Google ad for Cisco AnyConnect, a tool often used by employees to remotely connect to company networks, but also by universities. In fact, we found that threat actors were using the name of a German university to create a fake website designed not to fool actual victims, but rather to bypass detection from security systems.

To be sure, victims were part of the overall scheme, but they were instead redirected to a lookalike Cisco site linking to a malicious installer containing the NetSupport RAT remote access Trojan.

**The perfect disguise**

The malicious ad comes up from a Google search for the keywords “_cisco annyconnect_“. The ad displays a URL that looks somewhat convincing for the domain _anyconnect-secure-client\[.\]com_. We should note that this domain was registered less than a day before the ad appeared.

Upon clicking on the ad, server-side checks will determine whether this is a potential victim or not. Typically, a real victim has a residential IP address and other network settings that differentiate it from crawlers, bots, VPNs or proxies.

In recent times, we have seen criminals rely on AI to generate fake pages that look innocuous. These are also referred to as “white pages” and they do serve an important purpose. If it’s obviously so fake and bad, it will raise suspicion. We thought that in this case the perpetrator had a rather clever idea by stealing content from a university that actually does use Cisco AnyConnect.

Technische Universität Dresden (TU Dresden), is a public research university in Germany whose site can be found here. Funnily enough, the threat actors left a trail while doing their copy/paste. We can see that they added the cookie opt-in notification which is required for websites in Europe, which here leaked their browser language (Russian).

**Real victims get infected with malware**

As good as this template looks, real victims will never see it. Instead, upon connecting to the malicious server they will be immediately redirected to a phishing site for Cisco AnyConnect.

The payload is downloaded in a similar way to a campaign we had already observed before, using a PHP script that provides the direct download URL. We can see from the network traffic capture below that the file is hosted on a likely compromised WordPress site.

There is not much to be said about the fake installer other than it being digitally signed with a valid certificate. Upon execution it extracts _client32.exe_, a name notorious for being associated with NetSupport RAT.

cisco-secure-client-win-5.0.05040-core-vpn-predeploy-k9.exe  
  -> client32.exe  
  -> "icacls" "C:\\ProgramData\\CiscoMedia" /grant \*S-1-1-0:(F) /grant Users:(F) /grant Everyone:(F) /T /C

The remote access Trojan connects to the following two IP addresses: 91.222.173\[.\]67 and 199.188.200\[.\]195, further granting a remote attacker access to the victim’s machine.

**Conclusion**

Brand impersonation is a common theme with search ads. As Google enforces various policies and uses algorithms to detect malicious activity, threat actors need to constantly come up with new ideas.

Reusing a university page was a clever idea, but there were a couple of things that made this attack shy of being perfect. The domain name, while very strong for impersonation, was newly registered. Since it was part of the ad’s display URL, it could have potentially been detected by Google. We also noted that the perpetrators left a trail when they copy/pasted the code from the university website, which identified their likely country of origin.

Having said that, the malware payload was digitally signed and had few detections when first seen, so this attack may have had a decent success rate.

As always, we recommend that users take precautions whenever looking up programs to download, and to be especially wary of sponsored results.

**We don’t just report on threats—we remove them**

Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.

**Indicators of Compromise**

Malvertising infrastructure

anyconnect-secure-client\[.\]com  
cisco-secure-client\[.\]com\[.\]vissnatech\[.\]com

NetSupport RAT download

berrynaturecare\[.\]com/wp-admin/images/cisco-secure-client-win-5\[.\]0\[.\]05040-core-vpn-predeploy-k9\[.\]exe  
78e1e350aa5525669f85e6972150b679d489a3787b6522f278ab40ea978dd65d

NetSupport RAT C2s

monagpt\[.\]com  
mtsalesfunnel\[.\]com  
91.222.173\[.\]67/fakeurl.htm  
199.188.200\[.\]195/fakeurl.htm

 University site cloned to evade ad detection distributes fake Cisco installer 

A sophisticated cyberattack campaign is targeting organizations that still rely on Active Directory Federation Services (ADFS) for authentication across applications and services.

Source: Ronstik via Alamy Stock Photo

A phishing campaign is exploiting Microsoft Active Directory Federation Services (ADFS) to bypass multifactor authentication (MFA) and take over user accounts, allowing threat actors to commit further malicious activities across networks that depend on the service for single sign-on (SSO) authentication.

Researchers from Abnormal Security discovered the campaign, which is targeting about 150 organizations — primarily in the education sector — that rely on ADFS to authenticate across multiple on-premises and cloud-based systems.

The campaign uses spoofed emails that direct people to fake Microsoft ADFS log-in pages, which are personalized for the particular MFA setup used by the target. Once a victim enters credentials and an MFA code, attackers take over the accounts and are able to pivot to other services through the SSO function. They appear to be carrying out a range of post-compromise activities, including reconnaissance, the creation of mail filter rules to intercept communications, and lateral phishing that targets other users in the organization.

Targeting the legacy SSO capability in ADFS, a function that's "convenient for enterprise users," can reap big dividends, observes Jim Routh, chief trust officer at security firm Saviynt. The feature was originally designed for use behind a firewall but is now more exposed because it's increasingly been applied across cloud-based services, even though it was never designed for that, he notes.

Related:Why Cybersecurity Needs Probability — Not Predictions

Attackers in the campaign are spoofing Microsoft ADFS login pages to harvest user credentials and bypass MFA in a way that one longtime security professional says he hasn't seen before.

"This is the first time I've read about fake ADFS login pages," observes Roger Grimes, data-driven defense evangelist at security firm KnowBe4.

**Help Desk Lures for Credential Theft**

Targets of the campaign receive emails designed to appear as notifications from the organization's IT help desk — a widely used phishing ruse — with a message informing the recipient of an urgent or important update that requires their immediate attention. The message asks them to use the provided link to initiate the requested action, such as accepting a revised policy or completing a system upgrade.

Still, the emails include various features that make them appear convincing, including spoofed sender addresses that appear as if they originate from trusted entities, fraudulent login pages that mimic legitimate branding, and malicious links that mimic the structure of legitimate ADFS links, the researchers noted.

Related:DNSFilter's Annual Security Report Reveals Worrisome Spike in Malicious DNS Requests

"In this campaign, attackers exploit the trusted environment and familiar design of ADFS sign-in pages to trick users into submitting their credentials and second-factor authentication details," according to the report.

**Targeting Legacy Users**

While the campaign targets various industries, organizations bearing the brunt of attacks — more than 50% — are schools, universities, and other educational institutions, the researchers said. "This highlights the attackers' preference for environments with high user volumes, legacy systems, fewer security personnel, and often less mature cybersecurity defenses," according to the report.

Other sectors targeted in the campaign that also reflect this preference include, in order of attack frequency: healthcare, government, technology, transportation, automotive, and manufacturing.

Indeed, while Microsoft and Abnormal Security both recommend that organizations transition to its modern identity platform, Entra, for authentication, many organizations with less sophisticated IT departments still depend on ADFS, and thus remain vulnerable, the researchers noted.

"This reliance is particularly prevalent in sectors with slower technology adoption cycles or legacy infrastructure dependencies — making them prime targets for credential harvesting and account takeovers," according to the report.

Related:Black Hat USA 2024 Highlights

However, even if an organization is still using ADFS, it still can take steps to protect themselves, Grimes says. He recommends that all users use "phishing-resistant MFA" whenever they can, for example.

Other mitigations recommended by the researchers include user education about modern attacker phishing techniques and psychological tactics, and the use of advanced email filtering, anomaly detection, and behavior monitoring technologies to identify and mitigate phishing attacks and detect compromised accounts early.

**About the Author**

Elizabeth Montalbano is a freelance writer, journalist, and therapeutic writing mentor with more than 25 years of professional experience. Her areas of expertise include technology, business, and culture. Elizabeth previously lived and worked as a full-time journalist in Phoenix, San Francisco, and New York City; she currently resides in a village on the southwest coast of Portugal. In her free time, she enjoys surfing, hiking with her dogs, traveling, playing music, yoga, and cooking.

Attackers Target Education Sector, Hijack Microsoft Accounts

Funnull CDN rents IPs from legitimate cloud service providers and uses them to host criminal websites, continuously cycling cloud resources in and out of use and acquiring new ones to stay ahead of cyber-defender detection.

Source: Aleksia via Alamy Stock Photo

Researchers have linked the China-based Funnull content delivery network (CDN) to a malicious practice they've dubbed "infrastructure laundering," in which threat actors exploit mainstream hosting providers such as Amazon Web Services (AWS) and Microsoft Azure. The activity involves threat actors operating "hosting companies" that rent IP addresses from these providers and then map them to their criminal websites.

Researchers from Silent Push discovered the practice when they noticed that AWS and Microsoft Azure cloud hosting services are "often seen in large-scale use by threat actors," according to the recently published report. Further investigation led them to the discovery that Funnull CDN, a Chinese company that already has raised suspicions for other malicious activity, has been using this tactic to host a network of scam websites.

Funnull has rented more than 1,200 IPs from AWS and nearly 200 IPs from Microsoft, according to Silent Push. While these have nearly all been taken down as of this writing, the company continuously acquires new IPs every few weeks, using them and then dumping them before defenders can identify the malicious activity.

"While providers are consistently banning specific IP addresses used by the Funnull CDN, the pace is unfortunately not fast enough to keep up with processes being used to acquire the IPs," according to the report.

Related:EMEA CISOs Plan 2025 Cloud Security Investment

The tactic is complicated to defend against because it blends malicious activities with legitimate Web traffic, making it difficult for hosting providers to block access without creating a disruption for legitimate users, one security expert notes.

"By utilizing major providers, the bad actors make it much tougher for organizations to block IP ranges because those major providers may also be providing legitimate IP addresses for important Web services," observes Erich Kron, a security awareness advocate at cybersecurity company KnowBe4. "This precludes the ability to block large chunks of addresses easily."

**Running Multiple Scams**

Funnull CDN hosts more than 200,000 unique hostnames — approximately 95% of which are generated through domain generation algorithms (DGAs) — linked to "illicit activities such as investment scams and fake trading applications," according to the report.

"Moreover, these activities are directly associated with money laundering as a service on shell gambling websites that abuse the trademarks of a dozen popular casino brands and which are available online today," according to the report.

Related:Name That Edge Toon: In the Cloud

The activity uncovered by Silent Push is not the first time Funnull CDN has been tied to suspicious activity. Last year, the company purchased a domain, polyfill\[.\]io, that more than 100,000 websites use to deliver JavaScript code. Soon after, it was found being used as a conduit for a supply chain attack that used dynamically generated payloads, redirected users to pornographic and sports-betting sites, and could potentially lead to data theft, clickjacking, or other attacks.

At its peak in 2022, Funnull CDN's investment scam infrastructure had thousands of active domains, according to Silent Push. In 2024 that portfolio was more "modest" but still had some active sites, including cmegrouphkpd\[.\]info, which recently went offline but for the past two years had hosted a fake trading platform abusing CME Group's brand and logo.

**Is "Laundering" a Misnomer?**

AWS has made a public response to the findings in the report, verifying some of them and taking issue with others. The company said before it received Silent Push's report, it was "already aware of the activity" and was actively suspending the fraudulently acquired accounts linked to Funnull CDN's malicious activity.

"All accounts known to be linked to the activity are suspended," according to an AWS statement included in the Silent Push report. "We can confirm that there is no current risk from this activity, and no customer action is required."

Related:Tenable to Acquire Vulcan Cyber to Boost Exposure Management Focus

AWS also noted that the term "infrastructure laundering" to describe the activity is a misnomer, since it doesn't involve making illicit activity "clean."

"By using that phrase, the report insinuates that AWS is the intermediary to make the abusive activity appear legitimate and thereby harder to detect or block," the company said. "That’s incorrect."

AWS did not immediately respond to a request for comment from Dark Reading.

A Microsoft spokesperson told Dark Reading the tech giant is looking into the activity described in the report. Meanwhile, Silent Push will continue to investigate related activity from Funnull CDN and other threat actors, and will provide updates when appropriate, it said.

Businesses need to review their cloud accounts to avoid getting caught up in the activity, too. KnowBe4's Kron suggests that threat actors aren't likely to set up an account with a mainstream cloud provider with their own information; instead, they are probably using stolen accounts. These account takeovers, in turn, likely involve the use of stolen or cracked credentials, making the use of multifactor authentication (MFA) another potential way to mitigate this type of activity, he says.

Kron adds: "Organizations should review the accounts with access, audit transactions, and educate people on how to spot potential malicious activity within their cloud accounts."

**About the Author**

Elizabeth Montalbano is a freelance writer, journalist, and therapeutic writing mentor with more than 25 years of professional experience. Her areas of expertise include technology, business, and culture. Elizabeth previously lived and worked as a full-time journalist in Phoenix, San Francisco, and New York City; she currently resides in a village on the southwest coast of Portugal. In her free time, she enjoys surfing, hiking with her dogs, traveling, playing music, yoga, and cooking.

Tag

#cisco