UpGuard discovers exposed Ollama APIs revealing DeepSeek model adoption globally. See where these AI models are running and the security risks involved.

Cybersecurity researchers at third-party risk management firm UpGuard have identified a vulnerability surrounding exposed Ollama APIs, which provide access to running AI models. These exposed APIs not only pose security risks for model owners but also offer a unique opportunity to gauge the adoption rate and geographic distribution of specific AI models, such as **DeepSeek**.

**Ollama** is an AI model framework that simplifies interaction with models by providing a user-friendly interface for selecting and downloading models. However, as per UpGuard’s research, shared exclusively with Hackread.com ahead of its release, the API can be exposed to the public internet; its functions to push, pull, and delete models can put data at risk and unauthenticated users can also bombard models with requests, potentially causing costs for cloud computing resource owners. Existing vulnerabilities within Ollama could also be exploited. 

According to UpGuard’s **research**, there is already evidence of the vulnerability being exploited, with targeted IPs being tampered with.

  
A screenshot provided by UpGuard to Hackread.com shows an Ollama instance where the models appear to have been deleted.

Researchers expressed concern that Ollama APIs are likely used by hobbyists on home or small business internet connections or university networks and these systems can be easily compromised and incorporated into botnets for future attacks.

UpGuard also analyzed the distribution of DeepSeek models across different parameter sizes running on exposed Ollama APIs. The 14b and 7b options (representing models with 14 billion and 7 billion parameters) were the most commonly observed among the exposed DeepSeek models, suggesting that many users are opting for these mid-range models.

Approximately seven thousand IP addresses currently expose Ollama APIs, indicating an over 70% rise in three months, since in its survey **Laava** found four thousand IP addresses in November 2024. Out of these exposed IPs, 700 are running some version of DeepSeek. Specifically, 334 are utilizing models from the deepseek-v2 family, while 434 are running the newer deepseek-r1 model. 

Geographically, the highest concentration of IPs running DeepSeek models is located in China (171 IP addresses, representing 24.4%), followed by the U.S. (140 IP addresses, or 20%), and Germany (90 IP addresses, or 12.9%). 

Furthermore, the distribution of DeepSeek models within the US by Internet Service Provider (ISP) analysis reveals a diverse range of providers, from large entities like Google LLC and AT&T Enterprises LLC to smaller providers and universities. Also, researchers found the highest concentration of DeepSeek instances in China, the US, and Germany, with other countries contributing smaller percentages.

> _“There are really two things that surprised us in this research: how fast exposed Ollama APIs are growing, and how quickly DeepSeek has spread. Either of those could have big consequences in the future.”_
> 
> Greg Pollock, Director of Research and Insights – Upguard

It is worth noting that DeepSeek has been restricted by entities like the **US Navy**, the state of **Texas**, **NASA**, and Italy over concerns of possible data leakage to the Chinese government. While these concerns may not apply to open-source models, most users are unlikely to scrutinize the code, UpGuard researchers noted along with identifying potential risks within the models themselves.

Therefore, to prevent **AI data leakage**, it is essential to audit one’s attack surface for exposed Ollama APIs and remain aware of which models or AI products can be crucial in third-party risk management.

7,000 Exposed Ollama APIs Leave DeepSeek AI Models Wide Open to Attack

New mobile apps from the Chinese artificial intelligence (AI) company DeepSeek have remained among the top three "free" downloads for Apple and Google devices since their debut on Jan. 25, 2025. But experts caution that many of DeepSeek's design choices -- such as using hard-coded encryption keys, and sending unencrypted user and device data to Chinese companies -- introduce a number of glaring security and privacy risks.

New mobile apps from the Chinese artificial intelligence (AI) company **DeepSeek** have remained among the top three “free” downloads for Apple and Google devices since their debut on Jan. 25, 2025. But experts caution that many of DeepSeek’s design choices — such as using hard-coded encryption keys, and sending unencrypted user and device data to Chinese companies — introduce a number of glaring security and privacy risks.

Public interest in the DeepSeek AI chat apps swelled following widespread media reports that the upstart Chinese AI firm had managed to match the abilities of cutting-edge chatbots while using a fraction of the specialized computer chips that leading AI companies rely on. As of this writing, DeepSeek is the third most-downloaded “free” app on the Apple store, and #1 on Google Play.

DeepSeek’s rapid rise caught the attention of the mobile security firm **NowSecure**, a Chicago-based company that helps clients screen mobile apps for security and privacy threats. In a teardown of the DeepSeek app published today, NowSecure urged organizations to remove the DeepSeek iOS mobile app from their environments, citing security concerns.

NowSecure founder **Andrew Hoog** said they haven’t yet concluded an in-depth analysis of the DeepSeek app for **Android** devices, but that there is little reason to believe its basic design would be functionally much different.

Hoog told KrebsOnSecurity there were a number of qualities about the DeepSeek iOS app that suggest the presence of deep-seated security and privacy risks. For starters, he said, the app collects an awful lot of data about the user’s device.

“They are doing some very interesting things that are on the edge of advanced device fingerprinting,” Hoog said, noting that one property of the app tracks the device’s name — which for many iOS devices defaults to the customer’s name followed by the type of iOS device.

The device information shared, combined with the user’s Internet address and data gathered from mobile advertising companies, could be used to deanonymize users of the DeepSeek iOS app, NowSecure warned. The report notes that DeepSeek communicates with **Volcengine**, a cloud platform developed by **ByteDance** (the makers of **TikTok**), although NowSecure said it wasn’t clear if the data is just leveraging ByteDance’s digital transformation cloud service or if the declared information share extends further between the two companies.

Image: NowSecure.

Perhaps more concerning, NowSecure said the iOS app transmits device information “in the clear,” without any encryption to encapsulate the data. This means the data being handled by the app could be intercepted, read, and even modified by anyone who has access to any of the networks that carry the app’s traffic.

“The DeepSeek iOS app globally disables App Transport Security (ATS) which is an iOS platform level protection that prevents sensitive data from being sent over unencrypted channels,” the report observed. “Since this protection is disabled, the app can (and does) send unencrypted data over the internet.”

Hoog said the app does selectively encrypt portions of the responses coming from DeepSeek servers. But they also found it uses an insecure and now deprecated encryption algorithm called 3DES (aka Triple DES), and that the developers had hard-coded the encryption key. That means the cryptographic key needed to decipher those data fields can be extracted from the app itself.

There were other, less alarming security and privacy issues highlighted in the report, but Hoog said he’s confident there are additional, unseen security concerns lurking within the app’s code.

“When we see people exhibit really simplistic coding errors, as you dig deeper there are usually a lot more issues,” Hoog said. “There is virtually no priority around security or privacy. Whether cultural, or mandated by China, or a witting choice, taken together they point to significant lapse in security and privacy controls, and that puts companies at risk.”

Apparently, plenty of others share this view. _Axios_ reported on January 30 that U.S. congressional offices are being warned not to use the app.

“\[T\]hreat actors are already exploiting DeepSeek to deliver malicious software and infect devices,” read the notice from the chief administrative officer for the House of Representatives. “To mitigate these risks, the House has taken security measures to restrict DeepSeek’s functionality on all House-issued devices.”

_TechCrunch_ reports that Italy and Taiwan have already moved to ban DeepSeek over security concerns. _Bloomberg_ writes that **The Pentagon** has blocked access to DeepSeek. _CNBC_ says **NASA** also banned employees from using the service, as did the **U.S. Navy**.

Beyond security concerns tied to the DeepSeek iOS app, there are indications the Chinese AI company may be playing fast and loose with the data that it collects from and about users. On January 29, researchers at **Wiz** said they discovered a publicly accessible database linked to DeepSeek that exposed “a significant volume of chat history, backend data and sensitive information, including log streams, API secrets, and operational details.”

“More critically, the exposure allowed for full database control and potential privilege escalation within the DeepSeek environment, without any authentication or defense mechanism to the outside world,” Wiz wrote. \[Full disclosure: Wiz is currently an advertiser on this website.\]

KrebsOnSecurity sought comment on the report from DeepSeek and from Apple. This story will be updated with any substantive replies.

Experts Flag Security, Privacy Risks in DeepSeek AI App

Bogus websites advertising Google Chrome have been used to distribute malicious installers for a remote access trojan called ValleyRAT.
The malware, first detected in 2023, is attributed to a threat actor tracked as Silver Fox, with prior attack campaigns primarily targeting Chinese-speaking regions like Hong Kong, Taiwan, and Mainland China.
"This actor has increasingly targeted key roles

Fake Google Chrome Sites Distribute ValleyRAT Malware via DLL Hijacking

A new malware campaign dubbed SparkCat has leveraged a suit of bogus apps on both Apple's and Google's respective app stores to steal victims' mnemonic phrases associated with cryptocurrency wallets. 
The attacks leverage an optical character recognition (OCR) model to exfiltrate select images containing wallet recovery phrases from photo libraries to a command-and-control (C2) server,

SparkCat Malware Uses OCR to Extract Crypto Wallet Recovery Phrases from Images

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

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 global phishing campaign is actively exploiting a legacy Microsoft authentication system to steal user credentials and bypass multi-factor authentication (MFA), targeting over 150 organizations.

A global phishing campaign is underway, exploiting a legacy Microsoft authentication system to steal user credentials and bypass multi-factor authentication (MFA), targeting over 150 organizations.

A sophisticated phishing campaign is exploiting vulnerabilities in Microsoft’s Active Directory Federation Services (ADFS) to compromise user accounts and bypass multi-factor authentication (MFA), as revealed in research by Abnormal Security.

The attackers employ a combination of social engineering and technical manipulation. Phishing emails, mimicking legitimate notifications, lure victims to spoofed ADFS login pages. These emails often use urgent tones, warn of supposed updates or policy changes, and incorporate legitimate branding, logos, and even contact information to appear genuine. 

One of the phishing pages was sent to a targeted company (Via Abnormal Security)

URL obfuscation and shortened links further conceal the malicious destination.  It is worth noting that the attackers personalize the phishing pages to match the target organization’s specific MFA setup, such as tailoring prompts for push notifications, and mechanisms like Microsoft Authenticator, Duo Security, and SMS verification. 

The phishing landing page replicates the organization’s ADFS portal, dynamically pulling logos and design elements, creating a convincing counterfeit. While some client-side validation might exist, the page does not verify credentials against the organization’s systems since any username and password combination is accepted.  

The next step involves capturing the user’s second-factor authentication. Phishing templates are designed to collect various MFA factors, including codes from authenticator apps, SMS messages, or even push notifications. This information, coupled with the stolen credentials, is relayed to the attackers.

To complete the deception, the victim is redirected to the genuine ADFS login page after submitting their information, reinforcing the illusion of a successful login. With the stolen credentials and MFA details, the attackers proceed with account takeover (ATO), often using VPNs to mask their location.  Post-compromise activity typically includes internal reconnaissance, setting up mail filter rules to conceal their presence, and launching lateral phishing attacks.

Lateral phishing, sent from the compromised account, leverages established trust relationships within the organization. These emails often mimic legitimate communication patterns, targeting colleagues and associates. The mail filter rules, often with deceptive names and obfuscated keywords (e.g., “Hish” for “Phish”), help the attackers remain undetected.

“This approach leverages nuanced psychological tactics to exploit human vulnerabilities and reinforce a false sense of legitimacy,” Abnormal Security’s report read.

A fake Microsoft ADFS used in the campaign (Via Abnormal Security)

Research reveals that this campaign has targeted over 150 organizations in various sectors. The education sector is most impacted with 50% of attacks followed by healthcare (14.8%), government (12.5%), technology (6.3%), and transportation (3.4%).  Geographically, the attacks are largely focused on the United States, but incidents have also been reported in Canada, Australia, and Europe.

The report suggests that attackers are exploiting the fact that many organizations have not switched to Microsoft’s modern identity platform, Entra. ADF reliance is particularly prevalent in sectors with slower technology adoption, emphasizing the need for prioritizing migration to modern solutions and employing a multi-layered security approach.

Roger Grimes, a data-driven defence evangelist at KnowBe4, commented on the issue, telling Hackread.com that this is the first time they have heard about fake ADFS login pages hinting at the sophistication of this campaign.

_“_I’m a 36-year cybersecurity expert and author of 15 books (one on hacking MFA and over 1,500 articles. This is the first time I’ve read about fake ADFS login pages, but ADFS has been involved in bypassing MFA authentication before, so it’s not completely new to use in the hacker scene._“_

_“_All users should use phishing-resistant MFA whenever they can,_“_ Roger warned. _“_Unfortunately, most of today’s most popular MFA solutions, including Microsoft Authenticator, Google Authenticator, Duo, push-based MFA, OTP, and SMS-based MFA are very phishable and subject to the exact type of attack reported here._“_

Hackers Using Fake Microsoft ADFS Login Pages to Steal Credentials

Targets are lured into a fake interview process that convinces them to download malware needed for a virtual interview.

Source: imageBROKER.com GmbH & Co. KG via Alamy Stock Photo

NEWS BRIEF

In a new patch for its on-device malware tool, Apple is pushing signature updates to XProtect in order to block variants of a malware belonging to what is known as the macOS Ferret family.

This malware has been identified as part of "Contagious Interview," a North Korean campaign involving threat actors luring in targets and convincing them to install malware onto their devices through a fake job interview process. The other variants in the campaign include: FROSTYFERRET\_UI, FRIENDLYFERRET\_SECD, and MULTI\_FROSTYFERRET\_CMDCODES.

The DPRK malware family was first detailed by researchers in December 2024 and again in January where, as part of the campaign, targets are asked to communicate with an "interviewee" through a link that requests to install a piece of software required for virtual meetings.

Once installed, it runs a malicious shell script and installs a persistence agent, as well as an executable impersonating a Google Chrome update. 

The Contagious Interview attack chains are designed to drop JavaScript-based malware "BeaverTail," which delivers a Python backdoor known as InvisibleFerret, and harvests sensitive data from Web browsers and crypto wallets.

And now researchers at SentinelOne are highlighting samples they're calling "FlexibleFerret" that went undetected by XProtect as of Feb. 3, suggesting that the threat actors are honing their tactics to evade detection. This component dates as far back as November 2023.

"In an example in late December, one 'commenter' left instructions leading to the download of Ferret family droppers," stated the SentinelOne researchers. "This suggests that the threat actors are happy to expand the vectors by which they deliver the malware beyond the specific targeting of job seekers to developers more generally."

**About the Author**

Skilled writer and editor covering cybersecurity for Dark Reading.

Ferret Malware Added to 'Contagious Interview' Campaign

"Agentic" AI could arrive in 2025, and it may allow hackers to send individual, AI-powered agents to do their dirty work.

A paradigm shift in technology is hurtling towards us, and it could change everything we know about cybersecurity.

Uhh, again, that is.

When ChatGPT was unveiled to the public in late 2022, security experts looked on with cautious optimism, excited about the new technology but concerned about its use in cyberattacks. But two years on, much of what ChatGPT and other generative AI chat tools offer attackers is a way to improve what already works, not new ways to deliver attacks themselves.

And yet, if artificial intelligence achieves what is called an “agentic” model in 2025, novel and boundless attacks could be within reach, as AI tools take on the roles of “agents” that independently discover vulnerabilities, steal logins, and pry into accounts.

These agents could even hold people for ransom by matching stolen data online with publicly known email addresses or social media accounts, composing messages and holding entire conversations with victims who believe a human hacker out there has access to their Social Security Number, physical address, credit card info, and more. And if the model works for individuals, there’s little reason it wouldn’t work for individual business owners.

This warning comes from our 2025 State of Malware report, which compiled a year’s worth of intelligence to identify the most pressing cyberattacks on the horizon. Though the report’s guidance serves IT teams, its threats will impact individuals and small businesses everywhere. Remember that just last year a widespread IT outage grounded flights globally, cementing the relationship between companies, cybersecurity, and everyday people.

In 2025, agentic AI may further reveal just how closely tied everyone is in the battle for cybersecurity. Here’s what we might expect.

You can find the full 2025 State of Malware report here.

****The generative AI non-revolution****

The November 2022 launch of ChatGPT ushered forth a new relationship with our computers. No longer would we need to use our laptops, smartphones, and tablets to record or assist our creative work. Now, we could make those same machines complete the creative work for us.

AI image tools like Midjourney and DALL-E can create images when given simple text prompts. They can even mimic the styles of famous artists, like Van Gogh, Rembrandt, and Picasso. AI chat tools like ChatGPT, Google Gemini, and Claude—from OpenAI competitor Anthropic—can brainstorm ideas for marketing materials, write book reports, compose poems, and even review human-written text for legibility. These tools can also answer an endless array of factual questions, much like the separate AI tool Perplexity, which advertises itself not as a “search engine,” but as the world’s first “answer engine.”

This is the potential of “generative AI,” a term used to describe AI tools that can generate text, images, movies, summaries, and more, limited only by our imagination.

But where has that imagination brought us?

For unimaginative users, generative AI has made it easier to cheat in college classes and to abuse social media engagement algorithms to gain brief virality—hardly inspiring. And for malicious users, hackers, and scammers, generative AI has delivered oil-slick efficiency to proven attack methods.

Generative AI tools can more convincingly write phishing emails so that the tell-tale signs of a scam—like misspellings and clumsy grammar—are all but gone. The same is true for all text-based social engineering tricks, as AI chat tools can write alluring direct messages for romance scams and craft urgent-sounding texts that can fool people into clicking on links that carry malware.

Importantly, the attack methods here are not new. Instead, they’ve simply become easier to scale with the use of AI. But sometimes the AI pushes back.

With limitless, advertised potential, even tools like ChatGPT have boundaries, often precluding users from producing materials that could cause harm. In 2023, Malwarebytes Labs subverted these boundaries to successfully get ChatGPT to write ransomware—twice.

Because of these prohibitive rules, a set of malicious copycat AI tools can now be found online that will produce text and images that often break the law. One example is in the creation of “deepfake nudes,” which utilize AI technology to digitally stitch the face of one person onto another person’s nude body, creating fake nude “photographs.” Deepfake nudes have caused multiple crises across high schools in America, serving as a new type of ammunition for old weaponry: Blackmail.

The ability to create false text, images, and even audio has also allowed cybercriminals to create more believable threats when fraudulently posing as CEOs or executives to convince employees to, say, sign a bogus contract or hand over a set of important account credentials.

These are real threats, but they are not novel. As we wrote in the 2025 State of Malware report:

“The limited impact of AI on malware stems from its current capabilities. Although there are notable exceptions, generative AIs tend to provide efficiency rather than brand new capabilities. Cybercrime is a very mature field that relies on a set of well-established tools, such as phishing, information stealers, and ransomware that are already feature complete.”

That could change in 2025.

****“Agentic” AI and a new landscape of attacks****

Agentic AI is the next big thing in artificial intelligence, even if you’ve never heard about it before.

Google, Amazon, Meta, Microsoft, and more have all begun experimenting with the technology, which promises to take AI out of its current chatbot silo and into a new landscape where individualized AI “agents” can help with specific tasks. These agents could, for example, more effectively respond to simple customer support questions, help patients find in-network providers with their health insurance, and even suggest strategy based on a company’s most recent performance. Microsoft, for its part, has already teased its AI agent that answers employee questions around HR policies, holiday schedules, and more. Salesforce, too, is investing heavily in agentic AI, positioning the technology as a personal assistant for everyone.

As we wrote in the 2025 State of Malware report:

> “If agentic AIs arrive in 2025, they won’t just answer questions, they will be able to think and act, transforming AI from an assistant that responds to prompts, into a peer, or even an expert that can plan out tasks, interact with the world, and solve the problems it encounters.”

The implications for cyberattacks are enormous. If put into the wrong hands, malicious attackers could ask AI agents to:

*   Search vast troves of stolen data to match leaked Social Security numbers with leaked email addresses, composing and sending phishing emails that threaten more data exposure unless a ransom is paid.
*   Scrape public social media feeds for baby photos that are delivered to other AI agents that create fake profiles that weaponize those baby photos as empty threats against a child’s safety.
*   Scour LinkedIn to create a database of potentially viable email addresses from countless companies by deducing the email address format—first name, last name; first initial, last name; etc.—from publicly listed email addresses, and then mirroring that format to write and send bogus requests from executives to their direct reports.
*   Comb through public divorce records across multiple states and countries to identify targets for romance scams, who receive messages and who can carry on with whole conversations composed and controlled by another AI agent.

These attacks threaten not only individuals but small businesses, too, as a vulnerability in a person’s device can become a malware attack on a network. The same is true in reverse—if attacks on companies become more accessible, then the data that people give these companies becomes more vulnerable to exposure.

Thankfully, where agentic AI poses a risk, it also poses a boon, as individual AI agents could be tasked with finding a company’s vulnerabilities, responding to suspicious activity on its network, and even guiding everyday people into safely posting online, searching the web, and buying from unknown retailers.

The truth is that AI is here to stay. There is already too much investment from the largest developers and companies for that to reverse course any time soon. So, if the threat is that attackers might harness this AI, then the foreseeable future will involve a lot of defenders and everyday people harnessing it, too.

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

 New AI &#8220;agents&#8221; could hold people for ransom in 2025 

An investigation into more than 300 cyberattacks against US K–12 schools over the past five years shows how schools can withhold crucial details from students and parents whose data was stolen.

Tag

#google