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.

Chinese 'Infrastructure Laundering' Abuses AWS, Microsoft Cloud

Austin, TX, USA, 4th February 2025, CyberNewsWire

**Austin, TX, USA, February 4th, 2025, CyberNewsWire**

SpyCloud’s Identity Threat Protection solutions spearhead a holistic identity approach to security, illuminating correlated hidden identity exposures and facilitating fast, automated remediation.

SpyCloud, a leading identity threat protection company, announced key innovations in its portfolio, pioneering the shift to holistic identity threat protection. By operationalizing its vast collection of darknet data with automated identity analytics that correlate malware, phishing, and breach exposures across individuals’ past and present work and personal personas, SpyCloud enables security and fraud prevention teams to comprehensively uncover hidden identity assets, rapidly remediate exposures, and better protect their businesses from previously unseen threats.  

Identity security vendors have focused narrowly on securing corporate accounts, leaving organizations vulnerable to cybercriminals exploiting the broader identity exposures of employees, consumers, and suppliers. A shift to an identity-centric perspective is needed, particularly as the scope of identity exposures continues to grow. SpyCloud research reveals that the average individual has as many as 52 unique usernames/emails and 221 passwords exposed on the darknet across their online personal and professional identities. 

The impact of these exposures is evident: nearly a quarter of data breaches resulted from compromised identity data. Credential attacks led to $4.81 million in related costs per breach and took the longest to identify and contain. 

SpyCloud’s holistic identity threat protection addresses these challenges by encompassing the full spectrum of an individual’s online presence. This innovative approach empowers security teams to proactively protect against previously unseen risks, including the darknet exposures of identity and authentication data stolen about employees, consumers, and suppliers that have been beyond their visibility to date. 

> “The cybersecurity industry has spent years and billions of dollars securing accounts, but criminals have moved far beyond account-level access,” said **Ted Ross, SpyCloud’s CEO and Co-Founder**. “The dirty secret of the identity security industry is that efforts to lock down the perimeter fail because they focus on accounts, while bad actors target the full scope of users’ holistic identities. These sprawling identities, exposed through breaches, infostealer infections, and phishing attacks, create shadow data that traditional tools simply can’t address. ”

> Ross continued, “SpyCloud changes the dynamic by providing unmatched visibility into the same data criminals are exploiting, enabling organizations to remediate exposures across the entirety of users’ online personas. This shifts the advantage back to security leaders, empowering them to act on threats that were previously beyond their reach.”

**Key Innovations Underpinning SpyCloud’s Holistic Identity Threat Protection** 

*   **Refined analytics driving actionability on exposed identities:** SpyCloud applies advanced data science and proprietary technology to dynamically correlate billions of recaptured darknet data points, providing a broader and more accurate view of identities. By connecting authentication data, financial data, and personally identifiable information (PII), SpyCloud uncovers hidden relationships across seemingly unrelated accounts, continuously and at scale.
*   **Automated remediation in <15 minutes:** SpyCloud’s holistic identity portfolio now enables rapid, automated remediation within enterprise security ecosystems, including EDR, IdP, SOAR, and SIEM tools. This allows security teams to neutralize threats in less than 15 minutes of discovery, reducing risk without straining resources or operational bandwidth.
*   **Malware reverse engineering to combat ransomware:** SpyCloud specializes in the tracking and analyzing of malware – with deep insights into pervasive infostealers such as Lumma C2, Redline Stealer, Vidar, and more – as they are often a precursor to ransomware. Through its advanced malware reverse analysis, SpyCloud provides comprehensive visibility into malware-exposed data, helping organizations identify compromised devices, users, and applications and closes critical security gaps, including those stemming from unmanaged or under-managed devices used by employees, contractors, and vendors.
*   **Accelerated cybercrime investigations:** SpyCloud’s Investigations solution, used by cyber threat intelligence (CTI) teams, security operations, fraud and risk prevention analysts, and law enforcement globally, includes automated identity analytics to uncover the full scope of digital identity exposures, accelerating complex cybercrime investigations into threat actor attribution, insider risk (including potential hiring fraud), and supply chain risk analysis from days or hours to minutes.

**SpyCloud’s Capabilities Set a New Standard for Identity Security**

SpyCloud champions the transition to holistic identity security, backed by nearly a decade of experience and the industry’s largest repository of recaptured breach, malware-exfiltrated, and successfully phished data. Its holistic identity lens reveals a comprehensive view of exposed identity information – from credentials and PII to financial data and sensitive digital artifacts.

> “SpyCloud’s innovative identity threat protection is about as important as it gets in cyber; identity is **everything**,” said **John N. Stewart, SpyCloud Board Member and former Chief Security and Trust Officer of Cisco.** “By making it possible to view and act on the world’s best source for identity exposures, SpyCloud raised the bar to the top for proactive defense against all types of identity-driven cyber exploitation.”

> “We are redefining identity security by making holistic protection practical and achievable for our customers,” added **Damon Fleury, SpyCloud’s Chief Product Officer.** “SpyCloud has a long history of leading the way in understanding the cybercrime ecosystem, from our early days in world-class ATO prevention to continuing to build solutions that empower organizations to proactively protect against threats stemming from infostealer malware, phished and breach data.” 

> Fleury continued, “This evolution to make holistic identity threat protection a reality for enterprises is critical to our mission of disrupting cybercrime. We aim to stop identity-based threats once and for all.”

To learn more, users can contact SpyCloud or view the following resources:

*   The Holistic Identity Frontier: Why Shift from account-centric Security to holistic identity threat protection
*   Stop identity-based cybercrimes once and for all

**About SpyCloud**

SpyCloud transforms recaptured darknet data to disrupt cybercrime. Its automated holistic identity threat protection solutions leverage advanced analytics to proactively prevent ransomware and account takeover, safeguard employee and consumer accounts, and accelerate cybercrime investigations. SpyCloud’s data from breaches, malware-infected devices, and successful phishes also powers many popular dark web monitoring and identity theft protection offerings. Customers include seven of the Fortune 10, along with hundreds of global enterprises, mid-sized companies, and government agencies worldwide. Headquartered in Austin, TX, SpyCloud is home to more than 200 cybersecurity experts whose mission is to protect businesses and consumers from the stolen identity data criminals are using to target them now.

To learn more and see insights, users can visit spycloud.com.

**Contact**

**Public Relations**  
**Emily Brown**  
**REQ on behalf of SpyCloud**  
**\[email protected\]**

SpyCloud Pioneers the Shift to Holistic Identity Threat Protection

DeepSeek R1, a cost-efficient AI model, achieves impressive reasoning but fails all safety tests in a new study…

DeepSeek R1, a cost-efficient AI model, achieves impressive reasoning but fails all safety tests in a new study by Cisco’s Robust Intelligence. Researchers used algorithmic jailbreaking to demonstrate 100% vulnerability to harmful prompts, raising concerns about its training methods and the need for superior AI security measures.

Chinese start-up DeepSeek has gained attention for introducing large language models (LLMs) with advanced reasoning capabilities and cost-efficient training. Its recent releases DeepSeek R1-Zero and DeepSeek R1 have achieved performance comparable to leading models like OpenAI’s o1 at a fraction of the cost and outperformed Claude 3.5 Sonnet and ChatGPT-4o on tasks like math, coding, and scientific reasoning.

 However, the latest research from Robust Intelligence (now part of Cisco) and the University of Pennsylvania, shared with Hackread.com, reveals critical safety flaws.

Researchers reportedly collaborated to investigate the security of DeepSeek R1, a new reasoning model from the Chinese AI startup DeepSeek. The assessment cost was less than $50 and involved using an algorithmic validation methodology.

The team tested DeepSeek R1, OpenAI’s o1-preview, and other frontier models using an automated jailbreaking algorithm applied to 50 prompts from the HarmBench dataset. These prompts spanned six categories of harmful behaviour, including cybercrime, misinformation, illegal activities, and general harm. 

Their key metric was the Attack Success Rate (ASR), measuring the percentage of prompts that elicited harmful responses. The results were alarming: DeepSeek R1 exhibited a 100% attack success rate, failing to block a single harmful prompt. This contrasts sharply with other leading models, which demonstrated at least some level of resistance to such attacks. 

It is worth noting that researchers used a temperature setting of 0 for reproducibility and verified jailbreaks through automated methods and human oversight. DeepSeek R1’s 100% ASR starkly contrasts with o1, which successfully blocked many adversarial attacks. This suggests that DeepSeek R1 while achieving cost efficiencies in training, has significant trade-offs in safety and security.

Via Cisco’s Robust Intelligence

For your information, DeepSeek’s AI development strategy utilizes three core principles- Chain-of-thought” prompting, reinforcement learning, and distillation, which enhance its LLMs’ reasoning efficiency and self-evaluate reasoning processes.

As per Cisco’s investigation these strategies, while being cost-efficient, may have compromised the models’ safety mechanisms. Compared to other frontier models, DeepSeek R1 appears to lack effective guardrails, making it highly susceptible to algorithmic jailbreaking and potential misuse.  

The research emphasizes the need for rigorous security evaluation in AI development to balance efficiency and reasoning without compromising safety. It also highlights the significance of third-party guardrails for consistent security across AI applications.

Cisco Finds DeepSeek R1 Highly Vulnerable to Harmful Prompts

In an attack vector that's been used before, threat actors aim to commit crypto fraud by hijacking highly followed users, thus reaching a broad audience of secondary victims.

Source: Ronstik via Alamy Stock Photo

An active, one-click phishing campaign is targeting the X accounts of high-profile individuals — including journalists, political figures, and even an X employee — to hijack and exploit them to commit cryptocurrency fraud.

Researchers at SentinelLabs uncovered the campaign, which they said appears to be most prominent on X but is not limited to a single social media platform, they revealed in a recent blog post. The goal of attackers is ultimately to use the potential reach of the high-impact accounts — which also include technology and cryptocurrency organizations as well as owners of accounts with valuable, short usernames — to target people with crypto scams for financial gain, the researchers said.

"Once an account is taken over, the attacker swiftly locks out the legitimate owner and begins posting fraudulent cryptocurrency opportunities or links to external sites designed to lure additional targets, often with a crypto theft-related theme," SentinelLabs threat researchers Tom Hegel, Jim Walter, and Alex Delamotte wrote in the post.

Ultimately, this compromise of high-profile accounts — a tactic used before by cybercriminals, most notably in targeting celebrity Twitter accounts in 2020 — enables the attacker to reach a broader audience of potential secondary victims, maximizing their financial gains, the researchers noted.

Related:Can AI & the Cyber Trust Mark Rebuild Endpoint Confidence?

Indeed, the campaign is also similar to one uncovered last year that compromised the Linux Tech Tips X account along with other high-profile users. The researchers discovered related infrastructure and similar phishing messages used in both campaigns, evidence that suggests the same threat actor is behind both, they said. However, at this time it's not known from which region of the world the actor hails, or who might be behind the campaign.

**Classic Fake Crypto Lures & Adaptable Infrastructure**

SentinelLabs observed a variety of phishing lures being used in the campaign, including a "classic account login notice" that targets people with an email informing them that someone logged into their account from a new device. The email includes a link suggesting they "take steps to protect" their account which actually leads to a site that phishes X credentials, according to the post.

Other email-based lures use copyright-violation themes to get users to click on a phishing page that ask them to enter their X credentials. In recent cases, the phishing page to which victims were redirected abused Google’s “AMP Cache” domain cdn.ampproject\[.\]org to evade common email detections, according to SentinelLabs.

Related:PrintNightmare Aftermath: Windows Print Spooler Is Better. What's Next?

Infrastructure used in the account suggests that the actor behind the campaign is "highly adaptable, continuously exploring new techniques while maintaining a clear financial motive," the researchers wrote.

Recent activity used the domain securelogins-x\[.\]com to deliver emails and x-recoverysupport\[.\]com to host phishing pages. As "any of these domains can be considered email delivery or phishing-page hosting," the activity indicates "a level of informality and flexibility of infrastructure use," the researchers observed.

Attackers also hosted a flurry of recent activity on an IP associated with a Belize-based VPS service called Dataclub. The domains associated with the campaign have been predominantly registered through Turkish hosting provider Turkticaret, but this alone is not enough to confirm that the attackers are from Turkey, the researchers added.

**Protect Your Corporate Social Accounts**

High-profile X accounts are often targets for threat actors because controlling them can help them reach a wider audience with fraudulent activity. Often this activity involves crypto scams aimed at financial fraud, such as a case last year in which security firm Mandiant temporarily lost control of its X account to cryptocurrency drainer malware operators.

Related:Unpatched Zyxel CPE Zero-Day Pummeled by Cyberattackers

"The cryptocurrency landscape offers financially-motivated threat actors multiple opportunities for profit and fraud," the researchers noted in the post. "While marketing for coins and tokens has long been irreverent and meme-driven, recent developments have further blurred the line between legitimate projects and scams."

To protect an X account, the researchers recommended the obvious: users should maintain good password hygiene by using a unique password, enabling two-factor authentication (2FA), and avoiding credential sharing with third-party services.

People also should be especially wary of messages containing links to account alerts or security notices, and always verify URLs before clicking on them. If their accounts do need a password reset for security purposes, these should be initiated only directly through the official website or app rather than relying on unsolicited links, the researchers advised.

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

1-Click Phishing Campaign Targets High-Profile X Accounts

By integrating security into CI/CD, applying automated policies, and supporting developers with the right processes and tools, infosec teams can increase efficiency and build secure software.

Remi Yazigi, Information Security Engineer, Cisco Systems

February 3, 2025

4 Min Read

Source: Cagkan Sayin via Alamy Stock Photo

COMMENTARY

As cyber threats grow more sophisticated, organizations must prioritize secure software development practices. Vulnerability management is a critical aspect of this, but its success depends on clear ownership and collaboration between information security and engineering teams. By shifting left and embedding vulnerability management into the development life cycle, organizations can empower engineering teams to deliver secure code efficiently. Here's how infosec teams can drive this transformation.

**Shifting Left: The Key to Proactive Security**

Traditional vulnerability management approaches often focus on addressing issues post-deployment. This reactive strategy slows development and increases the risk of exposure. Shifting left means identifying and remediating vulnerabilities earlier in the development process, during the build phase, or even before code reaches the repository. This early action reduces cost and effort while improving the quality of the codebase.

By integrating vulnerability scanning tools like Trivy into continuous integration and continuous delivery (CI/CD) pipelines, infosec teams can block builds that introduce known vulnerabilities. Tools like these, with seamless integration with GitHub Actions (GHA) and Jenkins, provide immediate feedback to developers. When vulnerabilities are identified, engineers can address them without disrupting the workflow. This approach not only enhances security but also fosters a culture of accountability and ownership among developers.

**Applying Policies for Image Promotion**

One of the most effective ways to enforce security practices is through automated policies for container image promotion. For example:

1.  Base images: Ensure that development teams use only approved base images vetted by information security. These images should be regularly updated to incorporate security patches and align with organizational standards.
    
2.  Docker registries: Restrict usage to trusted and approved registries, reducing the risk of introducing malicious or outdated images. Approved registries should provide regular scans and metadata to verify image integrity.
    
3.  Image scanning: Automate the scanning process for all container images before they are promoted to staging or production environments. By applying strict vulnerability gates, organizations can ensure only secure images progress through the pipeline. Coupled with regular rescanning of images in production, this practice maintains security over time.
    

**Handling Exceptions Transparently**

No vulnerability management strategy is complete without a robust mechanism for handling exceptions. infosec teams should provide engineering teams with a clear process to request and manage exceptions when immediate fixes are not feasible. This includes:

*   Time-bound exceptions: Set expiry dates for exceptions to ensure vulnerabilities are addressed within a reasonable time frame. Expired exceptions should trigger reminders and escalate unresolved issues.
    
*   Approval workflow: Establish an approval workflow that involves both engineering and infosec stakeholders. Collaboration ensures balanced decisions that consider security and business needs.
    
*   Documentation: Require detailed justifications for exceptions, including mitigation strategies, impact assessments, and follow-up plans. Documentation enables transparency and ensures accountability for all stakeholders.
    

By managing exceptions transparently, organizations can balance security requirements with operational realities while maintaining accountability. This process also offers an opportunity for continuous improvement by identifying recurring vulnerabilities or patterns requiring systemic fixes.

**Building a Collaborative Framework**

For vulnerability management to succeed, infosec and engineering teams must work in harmony. Information security teams can support engineering teams by:

1.  Providing tools and training: Offer developers access to easy-to-use security tools and training on secure coding practices. This training should emphasize real-world examples.
    
2.  Defining clear policies: Develop and document policies that align with engineering workflows, ensuring that security requirements are achievable without disrupting productivity. Regularly review these policies to adapt to evolving threats and technologies.
    
3.  Creating feedback loops: Establish feedback mechanisms to address false positives, improve tool configurations, and enhance the developer experience. Prompt feedback helps developers focus on genuine risks and encourages compliance with security measures.
    
4.  Encouraging shared metrics: Track shared security metrics that matter to both teams, such as vulnerability closure rates and build success rates. Shared goals foster collaboration and build a sense of collective responsibility.
    

**Leveraging Automation and Metrics**

Automation plays a pivotal role in ensuring the scalability and reliability of vulnerability management processes. Integrating tools for automated scanning, ticket generation, and remediation tracking saves time and reduces human error. Meanwhile, metrics such as mean time to resolution (MTTR) and the number of vulnerabilities detected per build provide valuable insights into program effectiveness and areas for improvement.

**The Path Forward**

Empowering engineering teams with ownership of vulnerability management is a cultural shift that requires effort and collaboration. By integrating security into the CI/CD pipeline, applying automated policies, and supporting developers with clear processes and tools, infosec teams can drive efficiency and foster a shared commitment to building secure software.

Organizations that embrace this approach will not only reduce risk but also enhance their ability to deliver secure and reliable applications at scale. The time to shift left is now. Success requires a proactive mindset, the right tools, and above all, a strong partnership between infosec and engineering teams.

**About the Author**

Information Security Engineer, Cisco Systems

Remi Yazigi is information security engineer for Cisco Systems. He has extensive experience in cloud and container vulnerability management, specializing in automation to enhance security workflows. He holds two master’s degrees in computer engineering and cybersecurity and forensics. He joined ThousandEyes in London in 2018 and moved to the US in 2022 after Cisco Systems acquired ThousandEyes in 2020. There, he lead efforts to improve vulnerability detection and remediation. Prior to that, he worked in France as a cybersecurity consultant, focusing on securing industrial systems, including projects such as Ariane 5 space rocket and SECOIA. He is passionate about empowering engineering teams to take ownership of security processes, ensuring resilient and secure infrastructures. His expertise lies in creating scalable, efficient solutions that address modern security challenges.

Proactive Vulnerability Management for Engineering Success

Security researchers tested 50 well-known jailbreaks against DeepSeek’s popular new AI chatbot. It didn’t stop a single one.

Ever since OpenAI released ChatGPT at the end of 2022, hackers and security researchers have tried to find holes in large language models (LLMs) to get around their guardrails and trick them into spewing out hate speech, bomb-making instructions, propaganda, and other harmful content. In response, OpenAI and other generative AI developers have refined their system defenses to make it more difficult to carry out these attacks. But as the Chinese AI platform DeepSeek rockets to prominence with its new, cheaper R1 reasoning model, its safety protections appear to be far behind those of its established competitors.

Today, security researchers from Cisco and the University of Pennsylvania are publishing findings showing that, when tested with 50 malicious prompts designed to elicit toxic content, DeepSeek’s model did not detect or block a single one. In other words, the researchers say they were shocked to achieve a “100 percent attack success rate.”

The findings are part of a growing body of evidence that DeepSeek’s safety and security measures may not match those of other tech companies developing LLMs. DeepSeek’s censorship of subjects deemed sensitive by China’s government has also been easily bypassed.

“A hundred percent of the attacks succeeded, which tells you that there’s a trade-off,” DJ Sampath, the VP of product, AI software and platform at Cisco, tells WIRED. “Yes, it might have been cheaper to build something here, but the investment has perhaps not gone into thinking through what types of safety and security things you need to put inside of the model.”

Other researchers have had similar findings. Separate analysis published today by the AI security company Adversa AI and shared with WIRED also suggests that DeepSeek is vulnerable to a wide range of jailbreaking tactics, from simple language tricks to complex AI-generated prompts.

DeepSeek, which has been dealing with an avalanche of attention this week and has not spoken publicly about a range of questions, did not respond to WIRED’s request for comment about its model’s safety setup.

Generative AI models, like any technological system, can contain a host of weaknesses or vulnerabilities that, if exploited or set up poorly, can allow malicious actors to conduct attacks against them. For the current wave of AI systems, indirect prompt injection attacks are considered one of the biggest security flaws. These attacks involve an AI system taking in data from an outside source—perhaps hidden instructions of a website the LLM summarizes—and taking actions based on the information.

Jailbreaks, which are one kind of prompt-injection attack, allow people to get around the safety systems put in place to restrict what an LLM can generate. Tech companies don’t want people creating guides to making explosives or using their AI to create reams of disinformation, for example.

Jailbreaks started out simple, with people essentially crafting clever sentences to tell an LLM to ignore content filters—the most popular of which was called “Do Anything Now” or DAN for short. However, as AI companies have put in place more robust protections, some jailbreaks have become more sophisticated, often being generated using AI or using special and obfuscated characters. While all LLMs are susceptible to jailbreaks, and much of the information could be found through simple online searches, chatbots can still be used maliciously.

“Jailbreaks persist simply because eliminating them entirely is nearly impossible—just like buffer overflow vulnerabilities in software (which have existed for over 40 years) or SQL injection flaws in web applications (which have plagued security teams for more than two decades),” Alex Polyakov, the CEO of security firm Adversa AI, told WIRED in an email.

Cisco’s Sampath argues that as companies use more types of AI in their applications, the risks are amplified. “It starts to become a big deal when you start putting these models into important complex systems and those jailbreaks suddenly result in downstream things that increases liability, increases business risk, increases all kinds of issues for enterprises,” Sampath says.

The Cisco researchers drew their 50 randomly selected prompts to test DeepSeek’s R1 from a well-known library of standardized evaluation prompts known as HarmBench. They tested prompts from six HarmBench categories, including general harm, cybercrime, misinformation, and illegal activities. They probed the model running locally on machines rather than through DeepSeek’s website or app, which send data to China.

Beyond this, the researchers say they have also seen some potentially concerning results from testing R1 with more involved, non-linguistic attacks using things like Cyrillic characters and tailored scripts to attempt to achieve code execution. But for their initial tests, Sampath says, his team wanted to focus on findings that stemmed from a generally recognized benchmark.

Cisco also included comparisons of R1’s performance against HarmBench prompts with the performance of other models. And some, like Meta’s Llama 3.1, faltered almost as severely as DeepSeek’s R1. But Sampath emphasizes that DeepSeek’s R1 is a specific reasoning model, which takes longer to generate answers but pulls upon more complex processes to try to produce better results. Therefore, Sampath argues, the best comparison is with OpenAI’s o1 reasoning model, which fared the best of all models tested. (Meta did not immediately respond to a request for comment).

Polyakov, from Adversa AI, explains that DeepSeek appears to detect and reject some well-known jailbreak attacks, saying that “it seems that these responses are often just copied from OpenAI’s dataset.” However, Polyakov says that in his company’s tests of four different types of jailbreaks—from linguistic ones to code-based tricks—DeepSeek’s restrictions could easily be bypassed.

“Every single method worked flawlessly,” Polyakov says. “What’s even more alarming is that these aren’t novel ‘zero-day’ jailbreaks—many have been publicly known for years,” he says, claiming he saw the model go into more depth with some instructions around psychedelics than he had seen any other model create.

“DeepSeek is just another example of how every model can be broken—it’s just a matter of how much effort you put in. Some attacks might get patched, but the attack surface is infinite,” Polyakov adds. “If you’re not continuously red-teaming your AI, you’re already compromised.”

Tag

#cisco