Threat Intelligence | Blog | Okta

Defending against TeamPCP software supply chain attacks | Threat Intelligence

Jeremy Kirk, George Wang — Sun, 17 May 2026 14:00:00 +0000

Executive summary

From late 2025, a threat actor group calling itself TeamPCP has turned the tools and practices built for high-velocity software deployment into delivery mechanisms for malware.

While the group has used a variety of methods to target organizations, the most impactful methods are those that abuse GitHub features within victims' CI/CD pipelines.

TeamPCP has leveraged access to tools used in these pipelines to distribute credential-stealing malware - hoovering up package registry tokens, cloud credentials, SSH keys, Git credentials, personal access tokens and any secret available in a CI/CD environment.

In this post, we'll look at:

The mechanism of these attacks, including the exploitation of the pull_request_target trigger in GitHub Actions.
How to apply identity and access management controls to protect developer and maintainer accounts,
Ways to minimize exposure to supply-chain risk

Background

Modern software development

Modern software is most often built on top of a vast ecosystem of established free and open-source software. The contributions of cryptographic libraries like OpenSSL, programming languages like Python and package ecosystems such as npm underpin today's critical infrastructure and our daily experience of the internet. Open-source projects are often run by volunteers who contribute features and maintain code. While for-profit software companies that use open-source software may choose to contribute financial or development, for the most part, open source projects are labors of love.

Software supply-chain attacks are a pervasive risk. Open-source software can be exposed to every kind of attack - from email takeovers due to expired domains, binary takeovers due to deleted S3 buckets, bad actors infiltrating the community, changes in repository ownership, or malware hidden in poisoned package updates.

Open source software is published in public code repositories like GitHub and in package registries such as npm and the Python Package Index (PyPi). A fully fledged software program may contain dozens or hundreds of open-source software packages, libraries and frameworks. Each of these components, known as dependencies, is periodically updated with new features, security patches or stability fixes, all of which need to be updated in the downstream products that use them.

The key to dealing with this complexity is automation. If a maintainer patches a vulnerability in a library, the update can be distributed and applied automatically. This allows developers to close the window of opportunity from when a vulnerability is disclosed to when it is patched. In some configurations, software packages are updated without human intervention.

But there's a tradeoff. These same automations can conversely be abused as malware delivery systems. Attackers can sneak backdoors or credential-stealing malware into a legitimate product or masquerade as a benign dependency. These attacks are particularly dangerous because they leverage the key strength of the modern software development lifecycle: scale and automation.

Don't pull the pull_request_target trigger

In the last few months, attackers have recycled a years-old attack technique.

GitHub's free Dependabot tool scans dependencies and automatically opens a pull request (a proposed code change) informing maintainers when a component needs to be updated. To move even faster, a pull request can be configured to trigger a workflow, which are automations executed by GitHub's built-in CI/CD platform, GitHub Actions.

GitHub developed the pull_request_target trigger to allow maintainers more flexibility when dealing with a pull request that came from a fork (an independent copy of a repository). Compared to the already existing pull_request trigger where actions are run against the fork, pull_request_target runs the actions at the original repository. This functionality allowed maintainers of the repository to set up tasks like maintenance automations, test integrations or other CI workflows for pull requests.

In many cases these set ups require access tokens that live within the Github Actions workflows. Workflows are .yaml files that describe an automation job and what tools to use. This is a prime target for opportunistic malicious actors, particularly if those access tokens are long lived and broadly scoped. The hacking community coined their own term for abuse of the pull_request_target feature for malicious purposes: a "Pwn Request."

GiHub warned of misuse in 2021 and again in 2025. The warning last year was explicit:

A malicious actor can submit a seemingly innocuous pull request that, when triggered by pull_request_target, unleashes havoc. This malicious code, running in the context of the target repository's environment, could exfiltrate secrets or even tamper with repository contents and releases.

TeamPCP

TeamPCP is a financially-motivated cybercrime actor that first surfaced in late 2025. The group, also tracked as DeadCatx3, PCPcat, ShellForce, and CipherForce, created the Telegram group ID "Team_PCP," which was initially named "Black Witch / PCP."

This threat group focuses on gaining initial access to their target's GitHub repositories by exploiting known weaknesses in GitHub configurations. The group seeks to abuse these weaknesses to create and distribute malicious updates to widely-used software. Updates are modified to steal secrets, credentials, personal access tokens, API keys and any other secret on a compromised device. This credential theft enables follow-on attacks against entities that have not revoked or rotated credentials.

Constant target

While hunting for repos that use GitHub Actions workflows with pull_request_target was the attack du jour for 2026, it's far from the only threat targeting open source maintainers. Several software supply chain attacks have also started after attackers targeted the online accounts of maintainers.

In September 2025, threat actors compromised the account of a prolific open-source npm maintainer via a targeted email phishing attack, under the pretext that the maintainer needed to reset their two-factor authentication (2FA). The email warned that accounts with "outdated" 2FA credentials would be locked two days later. The maintainer's credentials were abused to update at least 18 packages with code that monitored for cryptocurrency transactions and replaced destination wallets with those controlled by attackers.

In July 2025, the Python Package Index Blog disclosed ongoing phishing attacks targeting its users via email. The attackers used email addresses that were included as part of package metadata. PyPi disclosed that four user accounts were compromised in an Adversary-in-the-Middle (AitM) style phishing attack during these campaigns. The attackers abused this access to create two API tokens and released malicious versions of the num2words package. PyPi noted that the attacks would not have succeeded if strong, phishing-resistant authentication had been required.

Recommendations

Unless an organization has the resources and means to inspect every single open-source dependency before it is merged, there will always be some degree of exposure to supply-chain risk. These risks can be minimized. Supply-chain security is a large, complex subject, and this post will not attempt to cover it all. Below are some of the more broadly applicable practices based on our own experience, plus specific configuration advice for GitHub Actions and a reading list for further resources.

Cooldown period: Fortunately, malicious updates to popular open-source packages with hundreds of thousands of installs per week tend to be discovered quickly. Many organizations hold off on installing the latest version, known as an n-1 patching strategy, or staying one or two versions behind unless there is an urgent need to update.

Even a short delay may be of benefit. The pnpm project, a high-performance alternative to npm, recently introduced a minimum release age of 24 hours as a default in its pnpm 11.0 release to provide time for differential analysis. Developers can, however, override the setting. With that setting, pnpm will not install dependencies or transitive dependencies until a specific window of time has passed, allowing for detection and removal of malicious versions in the registry.

Software bill of materials (SBOMs): SBOMs are machine-readable descriptions of the libraries, dependencies and other components of a software product. SBOMs are intended to allow for the quick identification of possible vulnerable or tampered software in order to mitigate supply-chain risks.

SBOMs can answer the critical questions after a new supply-chain incident, such as whether the vulnerable component has been downloaded during the exposure period and if the component has been deployed to production. This knowledge can be useful for remediation, particularly when a large number of credentials need to be revoked and rotated.

Audit dependencies: A Software Composition Analysis (SCA) tools analyze open-source dependencies to surface vulnerabilities and associated risks such as reputational ones, licenses, number of downloads, install scripts, and maintenance status.

Npm's command-line interface has the npm audit command, which generates a report on vulnerabilities based on GitHub Advisories in a software project based on the registry used. More comprehensive tools, such as Snyk and Socket.dev, integrate with GitHub and are free for open-source and individual developers.

GitHub Actions: The quickest fix for the pull_request_target attack vector is to avoid it where possible. Security teams can scan all GitHub Actions workflows and remove pull_request_targets trigger for a workflow if that functionality is not required.

Workflows in GitHub Actions point to dependencies using tags. These are mutable. If a maintainer account is compromised, a GitHub Action workflow could also be modified to a tag for a specific commit that has been compromised.

To guard against this, GitHub introduced SHA pinning for Actions. Rather than pointing at a version tag for a dependency, maintainers can specify a hash for the dependency when the workflow runs.

Protect developer and maintainer accounts: Open-source project maintainers play a critical role in the software supply chain and are targeted routinely. GitHub has supported passkey-based authentication since 2023. Based on the FIDO2/WebAuthn standards, passkeys are cryptographically tied to a domain at enrolment making them impossible to use on a lookalike phishing site. Passkeys can be implemented in both hardware and software to cater for different use cases.

The credential-stealing malware used in the attack described earlier in this post targeted nearly every kind of developer credential. Developer workstations often access production environments and tore the sort of secrets attackers lust for. Again, implementing phishing-resistant authentication using passkeys or security keys that is enforced in policy is recommended. Additionally, requiring more than one approval before a pull request is merged can increase the chance of detecting suspicious behavior. Also, all pull requests and commits should be digitally signed to ensure only an authorized user is contributing.

Device code phishing: it's phishing with dynamite

Brett Winterford — Sun, 10 May 2026 16:00:00 +0000

When most people think of "phishing", they usually think of users being tricked into disclosing credentials or downloading malware

One of the fastest growing methods of attack does neither. Instead, a targeted user is tricked into authorizing an attacker-controlled client. These attacks abuse user trust in the OAuth-based authorization flows used to grant an app access to data in another app.

In early 2026, device code phishing is surging. This attack exploits known weaknesses in the device code authentication grant - a method in which users authorize a client on one device by signing in on a separate device. This grant was intended to make it easier to sign in to devices that are "input-constrained" - where it is awkward to enter a password. But we also see it used for many other use cases, including workforce use cases. Threat actors have now appropriated this flow with striking success to trick users into authorizing their malicious applications.

Threat researchers at Push Security have observed a 15x increase in device code phishing attacks targeting Microsoft 365 users since the start of the year. Researchers from Okta Threat Intelligence and Proofpoint have now observed indications that some threat actors have pivoted from AitM phishing attacks to perform device code phishing attacks.

Device code phishing has taken center stage because attacks have been industrialized via "phishing as a service" operations such as EvilTokens.

EvilTokens provides a low-skilled cybercrime attacker with the infrastructure, lures, defence evasion tools and alerting/messaging required to launch device code phishing attacks against Microsoft customers at scale, and with minimal effort on the part of the user.

In this article, we'll explain what the device code flow is used for, how it is exploited, and the conditions that make this form of attack "phishing with dynamite".

The device code authorization grant

Device Code Phishing abuses a specific OAuth 2.0 authorization flow designed for input-constrained devices - the OAuth 2.0 Device Code Authorization Grant (RFC8628).

An input constrained device could be a streaming app on your TV, apps that run your household appliances, or even the entertainment systems in your car. In any system where it's clumsy to type a long, strong password, the device code flow enables a user to sign in out-of-band on a mobile or laptop and authorize (consent) the client to access their account data.

If we used the idea of a streaming video app to illustrate:

A user wants to sign-in to a streaming app on their television
The user's smartphone browser is the out-of-band authorizing device
an authorization server brokers access to back-end servers of the streaming service.

In a legitimate device code authorization flow:

A user attempts to sign-in to their streaming service account from a TV.
An app on the TV requests access from an authorization server by sending a Client ID in a request to a specified endpoint. The authorization server returns a device code, user code and verification URI.
The app instructs the user to visit the verification URI - either presenting it as a web address or a QR code on the TV screen - and also supplies the user an eight character user code to enter on their smartphone to authorize the app.
Upon visiting the supplied web address, the user is prompted to enter the user code and is asked to verify their identity. The user may optionally be asked to consent to granting the app access to server-hosted resources (account data in the streaming service).
In the background, the app continually polls the authorization server in requests that include the Client ID and the device code. The client app is effectively asking the authorization server whether the user has authorized it. Once the user consents, the authorization server responds to a poll request with an access token. That access token can then be used to make API calls to the streaming service.

All of these interactions happen in a few seconds. The flow is both convenient and it encourages the use of stronger methods of authentication (especially when compared to short passwords and OTPs being entered into input-constrained devices).

Unfortunately, the device code flow is also prone to abuse in social engineering attacks.

Device code phishing

In a device code phishing attack, by contrast, the attacker controls the client app:

The attacker either registers a new app in an attacker-controlled tenant, or uses a Client ID known to be trusted by the authorization server of the targeted user. Requests to the authorization server are treated as valid because the device code authorization flow does not require that the client app is authenticated or even registered with the authorization server. There is nothing to stop an attacker abusing a known Client ID, and Client IDs are not typically protected as secrets.
The attacker supplies the user code and verification URI to a targeted user via a phishing site or over the phone via a social engineering call. If the authenticated user visits this web address and enters the user code, they will effectively grant the attacker's app access to their resources. The attacker simply needs to poll the authorization server and will receive an access token in response.

Phishing with dynamite

In attacks we have observed to date, attackers have shown interest in impersonating clients that:

Are authorized by one common authorization server,
Are assigned to all users by default in new tenants (including free/trial tenants)
Have a known/common Client ID that is the same in every tenant

Unfortunately, Microsoft apps meet this criteria on several fronts:

An EvilTokens user can start a device code flow by sending a POST request to the same common endpoint that is applicable to every Microsoft customer (/common/oauth2/devicecode).
This POST request has to include a legitimate Client Id. The Client Ids of first-party apps that are available by default in Microsoft tenants are routinely listed and tabled and the odd relationships between them are discussed openly. Threat researchers noted that by default EvilTokens abuses the known Client ID of Microsoft Office, but other researchers have observed abuse of additional Microsoft apps.

This means that a single tool is useful for attacking just about every Microsoft customer on the planet - irrespective of whether it's a teen authorizing an app on his XBox or an IT manager authorizing an app for a Fortune500 company.

The upside for an attacker of all users authenticating via a single domain (login.microsoft.com) is that it's very easy to attack at scale. In a device code phishing attack on Microsoft customers, attackers direct all targeted users to a common endpoint (login.microsoft.com/common/oauth2/v2.0/devicecode). At that endpoint, any user of Microsoft services is a valid user, especially when using Client IDs that many or all users are likely to be assigned.

By contrast, the Okta platform was designed around the principle that every organization has its own independent and decentralized authorization server(s). There is no concept of a "common" endpoint where users from different organizations verify their identity at one location.

This means that while clients created in Okta are not immune to device code phishing attacks, Okta's architecture forces attackers to do a lot more homework on any potential target.

Tycoon 2FA phishing actors disperse, branch into new attacks | Threat Intelligence

Houssem Eddine Bordjiba, Daniel L�pez, Jeremy Kirk — Sat, 02 May 2026 16:00:00 +0000

At one stage in mid-2025, Tycoon 2FA was responsible for more Identity Threat Protection (ITP) detections than any other phishing kit.

Tycoon 2FA offered threat actors an affordable, reliable service for MFA bypass against Microsoft 365 and Google Workspace tenants, without having to build and maintain the infrastructure required to perform Attacker-in-the-Middle (AitM) campaigns.

All that changed in March 2026, when a global law enforcement campaign disrupted 330 domains associated with Tycoon 2FA operations, including its distributed control panel and phishing pages built using the kit.

Okta Threat Intelligence can reveal that while the law enforcement operation put a significant dent in Tycoon operations, some of its operators continue to use the service. Several of its operators appear to have diversified into new forms of social engineering: including abusing the device code authorization flow.

The making of Tycoon

The original Tycoon phishing kit debuted in 2023 and did not include the ability to intercept session tokens.

But as controls like multifactor authentication (MFA) made traditional phishing more difficult, the kit evolved into Typhoon 2FA, an AiTM phishing kit that captured session tokens in real time. The service surged in popularity, primarily targeting Microsoft 365 and Google accounts.

Customers with little technical skill could subscribe to Tycoon 2FA via private Telegram channels for a few hundred dollars per month, allowing them to use an end-to-end service to execute account takeovers. Attackers sent tens of millions of phishing emails that directed unsuspecting users to Tycoon 2FA.

Targeted users were tricked into logging into familiar login pages that impersonated popular service providers. The targeted user's email address was typically pre-filled into the phishing page.

Using a transparent reverse proxy, Tycoon 2FA passed a person's credentials to the legitimate service and relayed most types of MFA challenges satisfied by the user. When an impersonated service returned a session token to the user's browser after a successful authentication, Tycoon 2FA's proxy grabbed it.

From there, attackers could replay the session token and gain account access. Replaying a session token bypasses both login and MFA challenges. Session token replay has grown into one of the most common identity-based attacks.

By mid-2025, Tycoon 2FA was the most-observed phishing kit with these AitM capabilities. In July 2025, Okta Identity Threat Protection detected 11,199 phishing attempts against Microsoft customers that federated identity to Okta - a figure that was more than double the previous three months combined.

By August 2025, detections fell to 5,982 before sliding further still. In the month prior to the March 4, 2026, takedown, Tycoon 2FA phishing attempts numbered just 885.

Perversely, we observed an increased number of detections in the weeks that followed the takedown activity.

Okta detected 1,470 Tycoon 2FA phishing attempts through the end of March 2026.

Detections observed leveraging Okta's data have continued to trend downward but have not disappeared entirely, numbering 631 in April 2026.

Adaptation

In the wake of the disruption, the first obvious sign of how Tycoon 2FA operators would adapt was our detection of new and more diversified infrastructure.

Prior to the law enforcement action, most Tycoon 2FA detections originated from the networks of just three entities: Global Connectivity Solutions, M247 Europe SRL and Hivelocity.

Within one to two days of the disruption, new infrastructure started to appear. The only existing network operator that continued to host Tycoon 2FA infrastructure was M247 Europe SRL. Four new operators were observed hosting Tycoon 2FA-related activity, including a few smaller providers.

A more intriguing change is threat actor interest in a more covert form of attack: Device Code Phishing.

In this scheme, threat actors abuse the OAuth 2.0 Device Authorization Grant, which is an authentication scheme designed for input-constrained devices that is also used frequently to authorize command-line applications. Given it is inconvenient to log in to a streaming video service via a TV, users are provided a code and directed to login on a device better suited to sign-in. Once authenticated, OAuth tokens are issued to the requesting client. Threat actors see great opportunity in this abstracted flow, as users approve access to an application that is not necessarily on their device. Unsurprisingly, device code phishing has become a productized cybercrime service. EvilTokens is one such hosted device-code phishing kit targeting Microsoft environments, amongst others.

Threat researchers at Proofpoint recently spotted a tantalizing clue that suggests that even Tycoon 2FA users are re-tooling in favor of this attack type. They discovered a PDF in a phishing email used in a device code phishing campaign that re-used an artifact related to a Tycoon 2FA URL.

Okta Threat Intelligence has directly observed strong similarities between past Tycoon 2FA campaigns and recent device-code phishing campaigns. Both re-use similar anti-analysis tradecraft, for example. These include evasion strategies in the phishing lures common to Tycoon lures. The device-code phishing pages employ CAPTCHAs and use multi-hop redirect chains through legitimate infrastructure providers before the actual phishing page is shown. Recent device-code phishing pages also employ similar anti-analysis techniques as Tycoon to attempt to deflect analysis.

AitM: Still prevalent and potent

This type of retooling we have observed is part and parcel of cybercrime. It does not mean that imposing costs on the cybercrime ecosystem is fruitless. We should expect that profitable cybercrime operations will adapt to the tools available.

There remain several viable Phishing-as-a-Service alternatives to Tycoon 2FA. While organisations continue to allow users to sign-in using low-assurance factors vulnerable to phishing (especially passwords and OTPs) AitM phishing will be an effective tool for attackers.

The prevailing defense to session token theft via phishing is to enroll users in phishing-resistant authenticators such as Okta FastPass or passkeys and to enforce the use of those factors in authentication policies. AitM phishing kits cannot defeat either of these factors, and Okta FastPass offers the additional utility of being able to provide server-side detections to Okta administrators when users are targeted.

Organizations that do not or cannot enforce phishing resistance can also use services that detect the attempted re-use of a token. These services are as relevant to any form of session token theft (including malware) as they are to phishing.

BreachForums logs reveal anonymizers of choice for shady characters

Jeremy Kirk, Mathew Woodyard — Sat, 28 Mar 2026 16:00:00 +0000

When threat actors log into systems, they don't use their real IP addresses. Instead, they route their traffic through VPNs, proxies, and anonymizing networks. We analyzed a January 2026 data leak from BreachForums - a major English-language cybercrime marketplace - that contained threat actor IP addresses. The analysis can help Okta administrators make evidenced-based decisions about risky login behaviors and how to use controls to limit logins from dodgy virtual private network (VPN) services or anonymizing networks.

IP addresses are key indicators of compromise. Attackers don't want to use IP addresses that could be potentially linked to their real-world identities if law enforcement obtains warrants or subpoenas that will be honored by service providers. This pushes them to the corners: virtual private network (VPN) services that promise to not retain logs, anonymizing proxies and so-called "bulletproof" networks. The desire to protect their identity extends not only to when they are staging attacks but also when threat actors log into forums and marketplaces used for cybercriminal activity.

Underground forums occasionally experience data breaches, and these leaks are an informative source of open-source intelligence. In January 2026, a dataset from a cybercriminal forum known as BreachForums was publicly released. The data compromised registered users from the forum, including nicknames, hashed passwords, email addresses, and IP addresses, with the data current as of around October 2025.

BreachForums was a mainstay of the English-speaking cybercriminal underground, offering tools and services for fraud and cybercrime, guides, malware and served as an advertising platform for selling data leaks. It was the successor of RaidForums, which was taken offline by law enforcement in April 2022. BreachForums was disrupted by law enforcement at least twice since its first iteration in March 2022.

BreachForums ran on the MyBB open-source forum software on a MySQL database. The user database included many fields, including registered email addresses, hashed passwords, the IP a user registered to the forum and the IP of their last visit. Below is the full list of data fields.

The database contained nearly 324,000 rows. Some 235,208 rows have a "regip" - a field that is short for "registration IP," which is the date an account was registered - and a "lastip" - a field indicating when someone last logged in - of 127.0.0.9. This IP address is reserved for localhost or loopback routing. This is odd. It could mean the forum was incorrectly configured, which caused the logs to be inaccurate, or may have been intentional. However, more than 88,700 IPs have "lastip" values that are not 127.0.0.9.

We decided to look at these IPs and their corresponding ASNs to understand what services registered BreachForums participants used in order to preserve (or, in some cases, not preserve) their anonymity. The theory: If threat actors trust these networks, these networks may also be favored to launch various identity-centric account takeover attacks.

Underground cantina

All kinds of different personas logged in to BreachForums, and not just cybercriminal actors. Think of it as the online equivalent of the Mos Eisley cantina, the rough-edged alien bar in the original Star Wars film where creatures from around the galaxy mingled. Serious cybercriminals might be sitting at the bar, law enforcement and CTI professionals are lurking in the booths.

This means we can't say that all of these IPs absolutely belonged to threat actors, as law enforcement and cyber threat intelligence (CTI) researchers may use the same services in order to blend in. Nonetheless, that blend of usage can provide an even higher degree of likelihood that requests coming from these ASNs, IPs and proxies are less likely to be "normal" users, and it's also less likely that blocking them are going to trigger false positives.

Top Autonomous System Names (ASNs)

While the list below are the top ASNs seen in the BreachForums data, being included in this list is not intended to impugn the reputation of these companies or organizations. Legitimate services are consistently abused by bad actors. Also, network ranges that are owned by large network providers and data centers may lease a portion of it to smaller providers, such as those providing VPN services or proxies. Small network operators, such as bulletproof hosting providers, frequently shift their network ranges and change connectivity suppliers in an effort to make it more difficult to shut down and shield criminal customers from abuse complaints. Nonetheless, this data can provide a snapshot of activity at a certain point in time.

CDNEXT, GB: This ASN (AS212238) run by U.K. based DataCamp Limited, which is a large provider of content delivery network (CDN) and network services, had the most IPs in the BreachForum data. It runs numerous networks in locales around the world including the U.S., the U.K., the Netherlands.
TORSERVERS-NET, DE: This is a small ASN (60729) run by the Association for Digital Fundamental Rights in Germany on 185.220.101.0/24. It consists of relays for The Onion Router, or Tor, which is an anonymity platform that encrypts browsing traffic through networks of relays around the world in order to make it more difficult to figure out a user's real IP address.
M247, RO: M247 Global is a large hosting and cloud infrastructure provider.
CLOUDFLARNET: Cloudflare is a large CDN and cloud network provider focused on security and performance.
CYBEROLOGY-AS, NL: This ASN (215125) calls itself the Church of Cyberology, which describes itself as "a religious organization that encourages (online) freedom, liberty and privacy." It runs out of the Netherlands and operates Tor relays on a small IPv4 range, which is 192.42.11.0/24.

Should requests from networks abused by intrusion actors be subject to more restrictive policies, or even blocked outright?

Mature environments tend to allowlist trusted networks and deny requests from all others, so analyses of IP reputation aren't required. That being said, it's not always easy to create a known baseline, particularly in organizations with a large "extended network" of third-party partners or independent agents.

For these organizations, the first step is identifying legitimate sign-ins from these services. Administrators can identify successful sign-ins from any given ASN in Okta Identity Engine using the following query:

To provide additional context, Okta Threat Intelligence performed a quick analysis of success:failure ratios at authentication for each of the top 20 ASNs in the Breached Forum list over the week prior to publication, across all commercial Okta orgs.

The analysis reveals that requests from several of the 20 ASNs most frequently observed in the BreachForums leak fail four to five times more frequently than they succeed.

ASNumber	AS_Org	Authentication Success rate %
212238	CDNEXT, GB	24.09%
60729	TORSERVERS-NET, DE	18.34%
9009	M247, RO	36.09%
215125	CYBEROLOGY-AS, NL	11.52%
13335	CLOUDFLARENET - Cloudflare, Inc., US	82.31%
36903	MT-MPLS, MA	19.61%
36947	ALGTEL-AS, DZ	8.48%
7922	COMCAST-7922 - Comcast Cable Communications, LLC, US	58.71%
9121	TTNET, TR	21.56%
7713	TELKOMNET-AS-AP PT Telekomunikasi Indonesia, ID	33.12%
36925	ASMedi, MA	41.67%
12735	ASTURKNET, TR	35.86%
7018	ATT-INTERNET4 - AT&T Enterprises, LLC, US	72.77%
55836	RELIANCEJIO-IN Reliance Jio Infocomm Limited, IN	70.42%
8452	TE-AS TE-AS, EG	55.03%
12322	PROXAD, FR	82.44%
208323	APPLIEDPRIVACY-AS, AT	31.57%
16276	OVH, FR	59.22%
3215	France Telecom - Orange, FR	82.86%
210558	1337 Services GmbH, DE	0.36%

Our methodology compared successful authentication events (user.authentication.verify) with failed authentication events (failed sign-in events, plus those requests Okta identified as threats and blocked at the network edge). It did not differentiate between workforce and customer identity systems. The data does not include requests denied via customer use of Network Zone policies - this would double or triple the number of "failed" requests if it were included.

VPN and Proxy Usage

Threat actors who logged into BreachForums used IPs that belonged to a mix of virtual private network (VPN) and proxy services as well as private one. Although about 75% of the BreachForums IPs are not publicly routeable, more than 35,000 IPs could be enriched. Unsurprisingly, IPs linked to The Onion Router (Tor) anonymizing system comprised more than 42% of the top 10 services. The second most seen service was Mullvad VPN followed by Proton VPN and Nord VPN. Residential proxy services, which are often used to avoid triggering geolocation restrictions and for attacks such as credential stuffing, did not meaningfully appear in the results. Below is a chart showing the top 10 VPN and Proxy services used.

Top 10 VPN and Proxy Services Used

Rank	Operator	Percentage
1	TOR_PROXY	42.7
2	MULLVAD_VPN	13.3
3	PROTON_VPN	12
4	NORD_VPN	9.4
5	WARP_VPN	7.3
6	OXYLABS_PROXY	5.6
7	ICLOUD_RELAY_PROXY	3
8	EXPRESS_VPN	2.7
9	OPERA_VPN	2.5
10	SURFSHARK_VPN	2.4

Top Email Address Domains

Online service providers typically send an email to the address of newly registered users in order to confirm the address. BreachForums did not do this. This means that the email addresses in the database may not even exist with a service provider. There are advantages to not being required to provide a real email address on cybercrime forums. If the email doesn't exist, its service provider won't be able to provide law enforcement data or metadata related to it. It is also possible that BreachForums registrants used other people's email addresses as a diversion tactic.

The BreachForums data contains 323,986 rows. About 27,000 rows contain invalid email addresses, no email address or email addresses such as null@null.com. Overwhelmingly, BreachForums registrants used Gmail addresses - about 81% of the total. About 14.3% of the email addresses had domains linked to Protonmail, the privacy-centric encrypted email service. The third most common at around 1.6% was Onionmail.org, which uses the Tor network and does not retain personal data or IP addresses. The fourth most common were addresses with Cock.li, which had about 100 more accounts than the number five domain, which was Yahoo.

We ran a sample of 16,044 email addresses through Have I Been Pwned, the data breach notification service, to see where else the same addresses may have been leaked before. This doesn't mean that the email addresses have actually been registered, but if an email address appears in another breach, it may be more probable that the email address exists.

Of the 16,044 email addresses in our sample, 10,200 email addresses appear only in the "BreachForums2025" data, and 7,515 are Gmail addresses. This suggests that BreachForum registrants heeded the advice of one of its administrators, who advocated use of "disposable" email addresses, or those used for a single purpose and not for other accounts. The remaining 5,844 accounts appeared across other large data breaches related to information stealing (infostealer) malware logs.

Conclusion

The BreachForums data provides insights into the choices made by threat actors when logging into a criminal forum. Presumably, most of those users were making choices that reflected a degree of awareness of their own operational security.

Usage of VPNs and anonymizing networks does not imply that all of those users are engaged in shady activity. However, these are the types of networks are typically used by those seeking to hijack accounts with stolen credentials sourced from underground markets and via malware campaigns. By understanding broad trends around attacker use of VPNs, proxies and other service providers that don't respond to abuse reports, defenders can make informed decisions to deflect identity-centric attacks.

Recommendations

With Okta's Adaptive MFA, administrators have visibility into risk signals by comparing a login event with a previous one, such as whether the user is using the same IP address, location, or device. If the pattern varies on the user's previous history, the user can be prompted for another authentication factor.

Okta customers can also block proxies, virtual private networks (VPNs) and other anonymizing networks using Enhanced Dynamic Zones. Using these controls, it is possible to block all requests at the network edge before the user reaches the sign-in page.

Auth0 customers can set Tenant Access Control Lists to manage traffic, or can limit logins from certain IP addresses using Auth0 Actions.

LiteLLM supply chain attack: an explainer for identity pros

Brett Winterford — Tue, 24 Mar 2026 16:00:00 +0000

In June 2025, Okta Threat Intelligence predicted that the rapid adoption of AI agents would generate "identity debt" as developers experimented with these new technologies.

This scenario has played out in numerous software supply chain attacks over the last six months, in which attacker payloads search compromised developer systems for plaintext secrets in configuration files and exfiltrate them to attacker-controlled servers.

The latest of these attacks - and one of the most consequential - targeted users of LiteLLM.

What is LiteLLM, and what went wrong?

LiteLLM is most often used by developers as a gateway for client applications to call any number of large language models (2000+) sourced from over 100 providers.

This offers software developers an ability to perform A/B testing of different models, build redundancy into agentic apps (swap to a secondary model if a primary is unavailable or is rate limited), as well as use cases concerned with auditing and cost control.

On March 24, 2026, threat actors known as TeamPCP pushed malicious updates to the LiteLLM PyPI package (versions 1.82.7 and 1.82.8).

These updates install a file on the compromised device (see indicators below), which executes a malicious script every time Python starts on the device. The script essentially functions as an infostealer - it seeks out and stages environment variables (API tokens, secrets, tokens), SSH keys, Git keys and CI/CD secrets, cloud credentials (AWS, GCP, Azure keys), database credentials, kubernetes secrets and SSL/TLS keys. It also pulls configuration files, shell history and other details (hostname, IP) about the compromised environment. The stolen data is staged and compressed into a file that is then exfiltrated to an attacker-controlled server.

The malicious package only impacted LiteLLM users that installed or upgraded LiteLLM via PyPi between 10:39 UTC and 16:00 UTC on March 24, 2026 and had not pinned prior versions.

Given LiteLLM was downloaded 96 million times last month, a back-of-the-envelope calculation says that we're still talking about hundreds of thousands of downloads of the malicious payload.

The attackers claim - without providing evidence - to have exfiltrated over 300GB of data during this window.

Agent sprawl at play

The LiteLLM was a software supply chain attack, not an identity-based attack.

The extent of the impact on any entity depended on whether they pinned library versions to prevent automatic updates and whether they used tools that scan new code for malicious payloads.

That being said, the blast radius for any impacted organization is as much a story about agent sprawl - an unbridled experimentation with AI agents by individuals within an organization.

It's reasonable to assume that the users most vulnerable to this attack will be individual developers that installed LiteLLM using pip (package installer for Python) to experiment with the technology.

In an ideal world, developers do not connect AI systems to production resources during experimentation phases.

We don't live in an ideal world. We don't tend to know if AI systems are useful until they're granted system resources or access to real data. And in many organizations, the adoption of AI agents remains decentralized and doesn't fall under the governance of a formal security program. Developers and other administrators repeatedly connect AI agents directly to production applications and data using static API tokens and service account credentials. That's where a supply chain attack like this becomes an identity story.

In unmanaged environments, resources are often accessed using bearer tokens stored in configuration files. Possession of the tokens alone grants the holder of the token access to a target resource. The tokens are not short-lived and not constrained to a specific IP or client.

So while we can guess at the impact of this event, the actual impact largely hinges on:

whether the tokens stolen were revoked or rotated before attackers could use them, and
if the token would be valid in the context of the attacker's client and IP.

How Auth0 helps developers secure agentic apps

From a developer perspective, one way to reduce the blast radius of supply chain attacks is to avoid hardcoding long-lived API keys in environment files, where malicious payloads are designed to find them.

Developers building agentic applications using Auth0 (see Auth0 for AI Agents) can use the Auth0 Token Vault service to replace static keys with short-lived access tokens.

Those short-lived access tokens can also be bound to the private key held by the client the tokens were issued to via Auth0 support for Demonstrating Proof of Possession (DPoP). Requests generated by attacker attempts to reuse the short-lived token outside of that specific context will fail.

How Okta helps address agent sprawl

Okta for AI Agents helps organizations to centralize all AI agents in the enterprise into a single directory, and to manage connections between agents and the applications and data they need to perform tasks.

Every AI agent brought under management with Okta is assigned a human owner. Agentic access to sensitive resources either uses scoped tokens issued by Okta, or vaulted credentials retrieved from Okta Privileged Access.

Recommendations

Centralize package retrieval and consider using tools that build packages direct from source repositories, rather than from community artifact repositories. Configure your environment to automatically scan updates for malware and vulnerabilities before they can be pulled by developers.
Connect agents to sensitive resources using ephemeral, sender-constrained tokens. Use Token Vaulting to issue short-lived access tokens, and apply DPoP (Demonstrating Proof of Possession) to ensure stolen tokens cannot be reused from an attacker's IP or client.
Develop an enterprise-wide strategy for management and governance of AI agents.
- Assign human ownership of every agent in use.
- Apply policies for authorizing agentic access to sensitive resources. At minimum, require that the resources accessible by agents support OAuth 2.0 authorization with granular scopes.
- Embrace cross app access (XAA). This reduces the number of consent requests users encounter when authorizing agents. Distributed auth protocols like XAA are also less vulnerable to attacks on a centralized gateway.
Apply mitigating controls to the use of static API tokens or service account credentials. Configure IP allowlists and vault the credentials using privileged access management tools.

Advanced posture checks

Okta Device Assurance can be used to assess whether a device running the Okta Verify client is running a vulnerable version of LiteLLM:

Indicators of Compromise

Indicator	Type	Source	Context
models.litellm[.]cloud	Domain	LiteLLM	Exfiltration server associated with the LiteLLM attack
litellm_init.pth	Filename	LiteLLM	Name of file downloaded to systems compromised in the LiteLLM attack
tpcp.tar.gz	Filename	LiteLLM	Name of file script creates after staging credentials for exfiltration from a compromised system.
45.148.10.212	IP Address	Aqua Security	Associated with previous attacks by the same threat actor targeting the Trivy project.
scan.aquasecurtiy[.]org	Domain	Aqua Security	Associated with previous attacks by the same threat actor targeting the Trivy project.

Rob Gil and Rafa Bono contributed to this article.

Disrupting ShieldGuard: a security extension primed to drain crypto wallets

Grayson Schermerhorn, Yang Wang, Simon Conant, Adam Smallhorn — Mon, 16 Mar 2026 16:00:00 +0000

Executive summary

Okta Threat Intelligence has discovered and helped industry partners to take down the infrastructure of a cryptocurrency scam called "ShieldGuard".

ShieldGuard claims to be a blockchain project that offers - through its promotion of a browser extension - a capability that blocks known threats to cryptocurrency wallets, such as phishing or malicious smart contracts.

The project was promoted using a multi-level marketing campaign in which users would be rewarded for early use of the extension (via a cryptocurrency "airdrop") and for promoting the capability to other users.

Our analysis of the browser extension, presented in detail below, revealed its true intent: ShieldGuard appears designed to harvest wallet addresses and other sensitive data for major cryptocurrency platforms including Binance, Coinbase, MetaMask, OpenSea, Phantom and Uniswap, as well as for users of Google services.

The extension also extracts the full HTML of pages after a user signs into Binance, Coinbase, OpenSea or Uniswap via their browser.

Threat analysis

ShieldGuard was promoted via a public website as a legitimate security application for users of Web3 services.

The creators of ShieldGuard also registered:

A listing in the Google Chrome Store
A social media profile at x[.]com
A Telegram channel

The web site and associated social media profiles for ShieldGuard claimed the extension would detect suspicious transactions prior to a user signing a request.

The creators of the browser extension attempted to drive downloads by launching an "airdrop".

An airdrop is a marketing campaign in which a blockchain-enabled service is "bootstrapped" by early adopters in the community. Early participants are issued coins or tokens that can be exchanged for some form of value if they sign-up prior to a specified date.

Interested users were encouraged to download the browser extension and sign-up for a user account at a claim portal in order to be eligible for the distribution of these tokens.

The ShieldGuard website reassured potential users that the software would not need direct access to their crypto wallets: the extension would poll a central server for updates on known threats and identify them in the user's browser.

Our analysis of the browser extension found that it includes a range of very different capabilities:

The browser extension harvests cryptocurrency wallet addresses from any website a user visits, using the EIP-6963 wallet discovery protocol
The browser extension exfiltrates full page content from cryptocurrency exchange and DeFi sites (which includes account balances, portfolio data, and transaction history)
The browser exfiltration is capable of executing arbitrary code on a device running the extension, as demonstrated through an ability to block access to legitimate websites on command and replace them with fake security warnings.
The browser extension tracks users via persistent UUIDs across all browsing sessions

Malware analysis

Analysis environment

To safely analyze the threat, we installed ShieldGuard browser extension and executed it within an isolated, containerized browser. Initial static analysis revealed that the extension's code was heavily obfuscated, a technique frequently employed by malicious actors to evade detection during review processes and to complicate reverse-engineering efforts.

Architecture and evasion techniques

ShieldGuard was revealed to be a sophisticated piece of malware designed to bypass the security restrictions of Chrome's Manifest V3. To achieve this, it bundles a complete custom JavaScript interpreter (vendor.js).

Bypassing Remote Code Execution Bans: Instead of using prohibited functions like eval(), the extension's background script fetches encoded script strings from a Command and Control (C2) server. It then uses its custom JS interpreter to parse and execute these scripts within the context of the victim's web pages. This allows the attackers to execute arbitrary remote code on demand without triggering Chrome's security policies.

Deceptive Permissions: Upon installation, the extension requests the permission to "Read and change all your data on all websites," granting it full access to the victim's browsing activity.

Malicious payloads and data exfiltration

Dynamic analysis confirmed the following attack flow:

A user with the browser extension installed navigates to a web site
The extension contacts the Command and Control server at shieldguards[.]net/scripts
The server returns the EIP-6963 wallet discovery script
The script discovers all installed wallets
The script extracts the wallet addresses from discovered wallets
All Ethereum addresses are extracted from discovered wallets
If the user has navigated to Binance, Coinbase, OpenSea or Uniswap, the extension waits for a set period of time before capturing the full HTML of the page
The HTML snapshot is exfiltrated

Our analysis found that the C2 server at shieldguards[.]net actively delivers two primary payloads:

Payload 1: Wallet address harvester (all websites):
A script is injected into every website the victim visits. It uses the EIP-6963 wallet discovery protocol to find all installed wallet extensions (e.g., MetaMask, Phantom, Coinbase Wallet), retrieve all associated Ethereum wallet addresses, and exfiltrate this list to the C2 endpoint at https://shieldguards[.]net/notifications.

This provides the attackers with a comprehensive inventory of a victim's wallets and their browsing habits.

Payload 2: Page content snapshot (targeted crypto sites):
For high-value targets, a second payload is delivered. After a five-second delay to allow the page to fully render, this script captures the entire page's HTML (document.documentElement.outerHTML) and sends it to https://shieldguards[.]net/snapshots. This allows the attackers to steal sensitive data directly from the DOM, including account balances, portfolio holdings, and transaction history.

Command & Control (C2) infrastructure

The browser extension communicates with a C2 server hosted at shieldguards[.]net, which is proxied through Cloudflare.

The key C2 endpoints identified were:


Endpoint	HTTP request method	Purpose
/scripts	POST	Delivers malicious JavaScript payloads.
/snapshots	POST	Receives exfiltrated page HTML.
/notifications	POST	Receives stolen data like wallet addresses.
/check/{domain}	GET	Determines if a domain should be blocked or appear "safe".
/uninstall	GET	Tracks when users uninstall the extension via a UUID.

Attribution and linked campaigns

There is potential that the threat actors are Russian-speaking, based on a Russian error string ("??????: ?? ??????? ?????????? ?????") and Cyrillic character support found within the custom JavaScript interpreter.

The investigation also uncovered strong links to another malicious campaign known as "Radex." We observed links between an administrative account used to set up an Auth0 tenant (radex4me@proton.me) and a Chrome extension ID associated with Radex (fkogigpebmhlbldifmjngmlooifljnif). It is very likely that both campaigns are operatd by the same threat actor.

Disruption

Okta Threat Intelligence has worked with industry partners to:

Disable all sign-in functionality
Remove the shieldguards[.]net domain from CDN services, revealing the website's origin server at Partner Hosting LTD, a bulletproof hosting provider
Remove the shieldguards browser extension from the Google Chrome Store
Remove the shieldguards[.]net domain from its domain registrar - which had the effect of disconnecting existing installs of ther browser extension from the C2 infrastructure.

Advice for end users

Beware the "too good to be true" trap

While legitimate sign-up promotions exist, scammers frequently use the promise of free crypto or high returns to create a false sense of urgency. If an offer looks too good to be true, it almost certainly is.

Practice safer online browsing

Browser plugins are a common source of malware. Installing them gives unknown third parties full access to your browser's window, history, and potentially your passwords and session cookies.

The best security advice is to limit if not eliminate browser plugins on the devices you use for access to sensitive accounts like crypto exchanges.

If browser plugins are absolutely required, follow these strict guidelines:

Official Sources Only: Only install plugins from official storefronts (Chrome Web Store, Mozilla Add-ons, or Apple Safari Extensions). Do not rely on the presence of an extension in these stores or positive reviews in these stores as markers of trustworthiness. Malicious browser extensions can present a strong rating until such time as the access they provide is abused.
Restrict Permissions: Configure browser plugins to only activate when clicked, or restrict them to only run on specific, necessary websites.
Regular Audits: Regularly audit your installed extensions to remove or disable unnecessary ones.
Compartmentalize: Use a completely separate, clean browser (or a strict Private/Incognito mode where all plugins are disabled) exclusively for crypto transactions and sensitive work.

Protect your crypto wallets

Safeguard your digital assets against browser compromises by using a reputable offline hardware wallet, diligently double-checking pasted addresses and enabling phishing-resistant MFA.

Advice for Okta customers

We recommend allowlisting strategies that provide security teams the ability to control the execution of third-party code on any browser used for access to corporate resources.

Two suggested approaches are provided below.

1. Deploy Managed Chrome:

Restricting local admin rights on managed company devices
Require a managed device for access to sensitive resources in Okta authentication policies
Deploy a Managed Chrome browser to user devices
Create an allowlist of approved browser extensions, removing the ability for users to add other extensions without admin approval
Create a process for users to request new extensions

2. Advanced posture checks:

Require a managed device for access to sensitive resources in Okta authentication policies
Deploy Okta Verify to user devices (using the latest version available in the Okta Admin Console)
Use advanced posture checks (part of Okta device assurance policies) to assess what browser extensions are running in the user browser at sign-in. Write authentication policies that allow access to sensitive resources from allowlisted browser extensions and deny access from all others.
Create custom remediation messages for users that are denied access to resources based on the extension running in their browser.
Create a process for users to request new extensions

Indicators of Compromise

Type	Indicator	Comment
AS Number	AS215826	Bulletproof host autonomous system serving malicious traffic
Chrome extension ID	olnppmocapoaecjhkiilemmnkjbmabfj	ShieldGuard tools extension ID
Chrome extension ID	fkogigpebmhlbldifmjngmlooifljnif	Radex extension ID

Vietnam-based cybercrime markets enable account sign-ups at scale

Mathew Woodyard, Angelos K. Marnerides, Michael Photiades, Jeremy Kirk — Sat, 28 Feb 2026 16:00:00 +0000

Executive summary

Okta Threat Intelligence, working with our partners at the University of Cyprus, have connected a cluster of fraudulent account registration activity to a sprawling cybercrime ecosystem based in Vietnam.

Fraudulent online accounts are more than just a nuisance; they are a critical tool for large-scale financial fraud. From spam to phishing to devastating interpersonal fraud scams, these accounts provide a veneer of legitimacy that allows criminals to abuse platforms and customers of those platforms.

In late 2025, Okta Threat Intelligence investigated signup fraud campaigns using infrastructure clusters internally designated as O-UNC-036 that relied on disposable email addresses in order to execute SMS pumping attacks, which is also known as International Revenue Sharing Fraud (IRSF). In this scheme, malicious actors automate the creation of puppet accounts in a targeted service provider. Fraudsters use these account registrations to trigger SMS messages to premium rate phone numbers and profit from charges incurred. This activity can prove costly for service providers who use SMS to verify registration information in customer accounts or to send multifactor authentication (MFA) security codes.

In the course of this investigation, Okta Threat Intelligence and our partners observed links from O-UNC-036 to dozens of websites that cater to individuals who want to conduct online fraud. This cybercrime-as-a-service (CaaS) ecosystem provides paid infrastructure and services that make it easier for other individuals to conduct online fraud. Many of these online storefronts sell user accounts that have been hijacked or created through automated means. This post will explain the threat that fraudulent registration poses to service providers, how it is executed and steps that can be taken to mitigate abuse.

Fuel for fraud

There is demand and a brisk trade for accounts on social media sites and services like LinkedIn, Instagram, Facebook, and TikTok. Fraudulent accounts can be leveraged in numerous ways that can impact the reputation of a service provider. Accounts can be used to send spam or to direct unsuspecting users to phishing sites. Fraudulent account registration is used to gain access to limited products such as concert tickets, to exploit free trials or manipulate product reviews. This all results in an erosion of trust in a service provider and a degraded experience for users.

Fraudulent accounts are also used to approach targets of interpersonal fraud scams: cyber-enabled crimes that range from investment and cryptocurrency scams to romance and sextortion schemes. Often referred to as "pig butchering," targets are persistently engaged online and over the phone in schemes designed to defraud them. These operations have exploded in recent years in southeast Asia, particularly in border areas near China, Myanmar, Thailand and Cambodia, and are run out of large compounds by organized criminal networks.

This activity has, according to an April 2025 report by the United Nations Office on Drugs and Crime, resulted in a "surge of specialized service providers" that feature a "range of merchants specializing in the sale of fraud kits, stolen data, malware, AI-driven tools, and various underground banking, money laundering and cybercrime services utilized by other criminals targeting victims globally."

This trade often happens in relatively open forums, on social networking sites, clear-web websites and on messaging platforms including Telegram. The tools enable fraud perpetrators to find targets, learn about them, gain their confidence and eventually cause them financial losses.

"When [scammers] use fake accounts to win the trust of people, they end up with a lot of personal data about them. They can do lots of damage to those victims," says Hieu Minh Ngo, a Vietnamese cybercrime investigator who contributed to the U.N. report and runs ChongLuaDao, nonprofit scam-fighting cybersecurity awareness organization.

The "web shops" we observed used website templates produced by a Vietnam-based web design and marketing company. We observed these cookie-cutter templates used for dozens of sites offering account-related products as well as other services used for fraud, such as falsely inflating the popularity of social media posts, phone farms for managing large numbers of accounts, residential proxies and "anti-detect" browsers, which are used to evade the tools used by security teams to detect account takeovers.

While the activity we observed predominantly targets Vietnamese speakers, many of the fake account vendors using these e-commerce templates also seek English-speaking buyers, extending the reach of this threat beyond Vietnam.

In December 2023, Microsoft undertook legal action against a Vietnamese CaaS group that sold fraudulent created Outlook and Hotmail accounts. The group, Storm 1152, created and sold 750 million fraudulent Microsoft Outlook and Hotmail accounts that were used for fraud, ransomware and extortion. The action temporarily disrupted Storm 1152. However, the group has since reformed, and Microsoft filed a second civil lawsuit in July 2024 in an effort to disrupt new infrastructure. We have not observed direct links between the activity we observed and Storm 1152.

Wanted: fake accounts

There is a chicken-and-egg problem fraudsters face when they need to create large numbers of synthetic user accounts with a service provider. Each new account requires a unique email address. Our insight into the fraudulent activity started with a set of disposable email domains used by O-UNC-036.

There are a variety of email services that offer "disposable" email addresses to cater to users with privacy concerns. These addresses can be generated en-masse and the services are often designed to cater to users that will likely only use an account for a short time. Correspondence to an address is typically available via an online service, and the email address provided may only be functional for as little as 10 minutes before being disabled. For fraudulent registrations, this arrangement is fine, since users of the service have no intention of actually using the address and may need only to view its inbox once to receive a verification code.

Okta Threat Intelligence observed a flood of suspicious-looking account registrations using multiple disposable email domains, which given the nature of the services is a red flag that the registrations are not being used for legitimate purposes. Our analysis of email provider domains turned up visual similarities that led us to a sprawl of web-based storefronts hosted in Vietnam and involved in the sales of web-based accounts.

All about MMO ("Make Money Online")

The website CMSNT.co appears similar to other marketing and website design services aimed at the e-commerce market.

"We design websites for your online money-making ventures," the site reads. "Automate your online money-making process."

What follows is a series of tiles that advertise website templates.

The website templates reveal a common theme: the sale of digital accounts for various types of services, including email providers, gaming sites, and social media services. However, there is no indication that CMSNT[.]co is involved itself in the sale of digital accounts or activity that could potentially violate computer crime laws.

Some templates are customized for the sale of accounts linked to video streaming, graphic design or AI chatbot service subscriptions, or for the sales of application software keys. Another template is a Social Media Marketing Panel, which appears to be designed as a storefront for a service that artificially boosts social media engagement on major social network sites. This inflation can include bogus "likes", comments or views. CMSNT[.]co says that "AI technology simulates real user behavior. No password required, just a public link. Trusted by over 15,000 customers."

Another template is customized for offering chron job services (scheduled tasks) using python, which can be used for tasks like web scraping.

Our research revealed that CMSNT[.]co's templates are used by dozens of websites. But not everyone is paying CMSNT[.]co to use them. At some point the source code for some templates was leaked, resulting in some entities using the templates without paying for licenses.

One of those freeloaders is Via17[.]com. "Via" is a slang term for hacked accounts, and it appears frequently on sites that are selling accounts. The compromised accounts may have been acquired using brute-force techniques, where attackers try different combinations of usernames and passwords, or from "logs" collected by information stealer (infostealer) malware. These types of malware logs, which can contain login credentials, payment card details, cryptocurrency wallet information and personally identifiable information extracted from infected devices, are routinely sold on underground forums and messaging platforms.

In an instructional video on YouTube, a person affiliated with the site bills Via17[.]com as the "#1 reputable website providing Facebook accounts." The video focuses on how people can access a Facebook account using a session token, which is a small data file that allows a user to remain signed into a website. Via17[.]com sells session tokens (also referred to as "cookies") as part of some fake account offerings.

One of the primary products at Via17[.]com is the resale of accounts from social networking sites. One package offers Vietnamese Facebook accounts with 10-50 friends with two-factor authentication enabled. More than 1,000 accounts are available at a price of 55,240 Vietnamese dong, or US$2.13 each. Other tiles advertise "vintage" Facebook accounts as old as 2006. Some accounts are listed as "real" accounts. It is unclear how Via17[.]com or its users have acquired them prior to sale. "Clone" accounts are created by software, according to the site. Depending on the type of account purchased, the data provided includes a userid, password, the ability to collect 2FA codes or notifications, a recovery email address and session tokens.

A similar account marketplace is nladsgiare[.]shop, which also runs the CMSNT[.]co website code. The advertisements for accounts on this site show the role that disposable email accounts play in the account trade. A section of the front page of the site advertises Facebook accounts that have Thai or "foreign" names that are linked to disposable email addresses from a service called mailclone[.]site.

Anyone can generate an email address on mailclone[.]site. Content sent to the address - such as an email verification link - is visible directly on the site. The same style of verification is recommended for accounts on Via17[.]com, with the site recommending buyers get codes sent to accounts from another free, temporary e-mail service, temp-mail[.]io.

Via17[.]com recommends 11 other disposable email services that can be used for account registration.

Conclusion

Preventing fraudulent account registration is a careful balance between preventing fraud and introducing undue friction on customers. (Users may be legitimately using masking or email forwarding services - consider Apple's Hide My Email feature). Organizations are typically prepared to tolerate a certain level of fraud to avoid events in which potential customers cannot complete a registration - this must be balanced against the risks an abundance of bogus accounts poses via a degraded customer experience.

Mitigations

Auth0

Auth0 customers have several tools at their disposal to mitigate fraudulent signups before, during and after the account creation process. Okta Threat Intelligence has written a playbook to guide efforts to mitigate abuse.

To protect their tenants from signup attacks, Auth0 customers can:

Use Bot Detection to challenge bots with a CAPTCHA of your choice within the configured risk tolerance.
Tighten Suspicious IP Throttling limits on signup to reduce the number of accounts attackers can make from individual IPs.
Create a Tenant Access Control List (ACL) rules, which denies observed malicious activity from sources based on indicators such as IPs, ASNs, geolocation values and JA3/JA4 signatures and has been shown to help mitigate signup attacks.
Enforce email verification using post-login Actions or a one-time password.
Block registrations that use known disposable email domains with pre-user registration actions.
Detect signup attacks with Auth0's open source Security Detection Catalog, especially the rules detecting risks of signup fraud by disposable domains and by volume and mass unverified account creation events.
Implement identity proofing tools, like those in the Auth0 Marketplace.

Okta Customer Identity

Okta Customer Identity also has controls that can be used to mitigate fraudulent sign up. Customers can block attackers before, during and after the signup process:

Identity Threat Protection, which is now in early access for Okta Customer Identity, evaluates IP reputation and looks at behavioral signals to block scripted account signups and signins and detect when threat actors use compromised credentials to sign up for accounts.
Use Okta APIs or Workflows to identify large batches of fraudulent registrations. Okta has published a sample workflow specifically to manage the abuse of self-service registration. The workflow compares the email address from a registration attempt and runs it against a customer-defined list of malicious or disposable domains. The workflow can be configured to deactivate these accounts.
Consider forcing verification of newly registered accounts via email link or OTP validation.

Consider performing identity-proofing with specialist third-party providers for users of high value services.
Consider blocking the most risky anonymizers and proxies by leveraging enhanced dynamic network zones. This stops attackers from reaching registration pages from high-risk services. Network blocking is the most extreme response and may not be an option for some.

Universities exposed to account takeover risk from contract cheating services

Sun, 15 Feb 2026 16:00:00 +0000

Executive Summary

Okta Threat Intelligence has identified extortion campaigns that target university students.

These operations often masquerade as "tutoring" or "proctoring" services, but function as contract cheating operations that feed sophisticated identity-theft and financial-crime rackets.

These extortion campaigns appear to first involve local and online recruiting efforts that seek students as clients.

In order for third parties to complete academic work on behalf of a student, students are asked to facilitate access for the proctoring services to academic systems, in some cases by sharing authentication credentials.

These third parties then press the students for further payment by threatening to expose the student for cheating.

The extortionists have been observed logging in from VPNs, residential, and mobile IP addresses in Kenya.

Okta Threat Intelligence has collaborated with several universities and people to study this activity, including Glen Woolley, Andrew Tolhurst, and Damien Mathieson of the Cyber Security Operations team at the University of Sydney.

This is not merely a matter of academic integrity; it is a threat to student safety and standards, the university's security perimeter and as one research institute posits, national security.

These extortion schemes target students across numerous universities in the English-speaking world, including the United States, Canada and Australia. Merely providing academic cheating services is illegal in some jurisdictions. For example, Australia criminalized contract cheating and ordered ISPs to block 555 websites offering these services. Regardless of jurisdiction, extorting students under threat of exposure is illegal.

There are broader risks to universities because of how the academic work is completed. Attackers demand full access to student accounts, which could mean the transfer of login credentials and approval of multifactor authentication challenges or other kinds of remote access. This grants threat actors an ongoing foothold within the university's environment.

While Okta Threat Intelligence has not directly observed a pivot from extortion to other abuses of student access in the clusters we are tracking, threat actors could conceivably leverage and monetize their access to achieve objectives such as payroll piracy.

Okta is committed to helping customers, partners, and users understand the critical role identity security plays in these attacks.

From contract cheating to student extortion

In order to finish their academic work quickly with minimal effort, some students choose to engage third parties to complete academic tasks in their behalf.

It is only after one of these third parties submits an assignment on behalf of a student through university apps like Canvas and Blackboard that the extortion component of these campaigns commences.

For instance, a student may pay $75 for one assignment, but after the assignment is submitted, the threat actor demands a further payment of $1,000 under threat of reporting the student. In almost all cases where the victim doesn't pay, the malicious actor will report the student. The malicious actor records voice and video communications with the student and may send emails to administrators.

Critically, the extortionists have leverage against their victims. Identity and access management logs may indicate that someone else has been using the student's account. The IP logs could show "impossible travel," meaning a student account was accessed locally and then some time later from a locale it would have been impossible for the student to now be located.

Lure mechanisms: the "academic support" facade

Threat actors use a multi-channel approach to find victims, often tailoring their language and platform to specific student demographics. The extortionists thrive in high-pressure moments, such as during finals week or mid-terms.

These services are advertised using both digital and physical channels.

Digital channels

The most common lures are digital, designed to look like academic notifications or helpful peer-to-peer recommendations.

Marketing emails: Attackers send emails to students with subjects like "Struggling with your Final?" or "Expert Tutors Available - Guaranteed A+." These often use professional-looking signatures to mimic official academic support messages.
Direct messaging (WeChat, WhatsApp, Telegram): To overcome email controls enforced by many universities that are likely to block, flag or filter out spam, attackers also use popular messenger apps used by international student communities. These messages are often written in the student's native language.
Websites: Contract cheating services develop professional-looking websites to give themselves an air of legitimacy.

Physical channels

Campus Postings: Accomplices of the attackers place physical flyers around campus.

Coerced referrals: Once a student is already being extorted, the threat actor may demand that the student recruits more classmates. This turns the victim into an accessory, spreading the lure through trusted peer networks.

Campaign Objectives

The primary objective of these campaigns is financial crime, achieved by extorting students based on evidence of authorized access.

The observed activity demonstrates clear intent to put students in a compromising situation in which they are either forced to pay or risk consequences from their academic institution.

Data collected by threat actors

The malicious actors try to collect as much personal information as possible to ensure the success of their extortion plot. These actors collect data such as:

Personally identifiable information (PII): Full name, home address, and phone number.
Institutional identifiers: Student ID number and official university email address.
Academic evidence: The assignment prompts, the student's personal notes, the completed assignment and even the course syllabus.
Proof of presence: Screen recordings or screenshots of the attacker logged into the student's portal (Canvas, Blackboard, etc.)

Risks beyond student extortion

Universities and Colleges are attractive targets for financially-motivated cybercriminal groups. We assess that contract cheating and extortion services have the potential to expose institutions to additional fraudulent activity if the extortionists we observed were to capitalize on the persistent access to systems granted by students.

Payroll piracy: The same credentials used to access student portals may provide access to payroll systems in those circumstances where a student also performs work for the institution. With access to payroll accounts, attackers can change bank routing information before a pay cycle, redirecting a student's wages to attacker-controlled accounts.
Financial aid fraud: The same credentials used to access student portals may provide access to financial aid portals, providing opportunities to divert loan disbursements or apply for additional fraudulent grants in the student's name.
Phishing and spam: Threat actors may also choose to abuse the high reputation of a trusted .edu email address to bypass spam filters and target faculty, staff, or administration in an attempt to gain access to higher-privileged accounts.
Research and IP Theft: The same credentials used for access to student portals may provide access to proprietary university databases, journals, or sensitive research data in specialized fields like defense and biotechnology.
Student discount harvesting: Threat actors may abuse student identities to resell products and services purchased with a student discount.

Threat Response

What we're doing

Okta is taking the following actions to mitigate this threat:

Proactively notifying institutions when we detect suspicious activity.
Providing guidance and assistance to organizations to enhance the security of their Okta environments and assisting them to investigate any suspicious activity related to potentially compromised accounts.
Maintaining ongoing working groups with higher education institutions.

Detections

In order to reach their objectives, attackers must have persistent access to the student's account long enough to run their extortion operation.

If the university is using Okta as an Identity Provider, there are several technical indicators that can point to evidence of unauthorized account takeovers.

What follows is a summary of detections available in the Okta platform.

Authenticator reuse: Attackers frequently register the same physical hardware such as a mobile phone to register as an MFA factor for multiple accounts that have been compromised. Analysts may see several student identities associated with the same device identifier in Okta logs, which is a strong sign of multiple account takeovers. Okta has a detection in the Customer Detection Catalog on GitHub for authenticator reuse here.

Session initiated by user, completed by attacker: This behavior involves the attacker logging in using the student's credentials from a remote location. However, the MFA prompt, such as a push notification, is accepted by the student from their normal IP geolocation. This creates a session where the root session ID originates from a suspicious IP while the successful authentication success comes from a trusted IP. Okta has created a detection for this scenario here.

Impossible travel: Student accounts that have been shared with contract cheating services will often show evidence of impossible travel. We routinely observe impossible travel scenarios where a student account logs in from their expected campus location but the event is followed almost immediately by a login from an IP address geolocated to Kenya, India or Pakistan. Often these aberrant IPs will solely login to Canvas, Blackboard or other assignment submission sites. Okta has a detection in the Customer Detection Catalog for impossible travel that is paired with a detection for a new device. Together, those are two key signals of a possible account takeover.

Intentional use of proxy services: Rather than merely being sloppy, we have observed threat actors intentionally use suspicious proxy services and IPs. This is part of their extortion operation: attackers leverage the impossible travel as evidence they can show university administrators. Use of IPs from unexpected locations, especially India and East Africa, can be indicative of an account takeover. Okta has a hunt in the Customer Detection Catalog for sign in attempts from proxies that customers can leverage.

Recommendations for Okta Customers

Utilize authenticator enrollment policy to block device enrollment to specific geo-locations and to block enrollment from proxy services
Block proxy services listed under the Network Indicators section below using dynamic network zones.
Block login or require step-up authentication from high risk or unexpected locations.

Network Indicators

Okta Threat intelligence has observed suspicious patterns of account access originating from Kenyan IPs. These IPs are not contained within one ASN, but frequently are associated with known suspicious proxying services:

RAYOBYTE_PROXY
NEXUS_PROXY
PROXYRACK_PROXY
IPCOLA_PROXY
KOOKEEY_PROXY
PLAINPROXIES_PROXY
LUMINATI_PROXY
9PROXY_PROXY
PROXYAM_PROXY
IPIDEA_PROXY
ABCPROXY_PROXY
NETNUT_PROXY

A note on estimate language

Okta Threat Intelligence teams the following terms to express likelihood or probability as outlined in the US Office of the Director of National Intelligence Community Directive 203 - Analytic Standards.

Likelihood	Almost no chance	Very unlikely	Unlikely	Roughly even chance	Likely	Very likely	Almost certain(ly)
Probability	Remote	Highly improbable	Improbable	Roughly even odds	Probable	Highly Probable	Nearly Certain
Percentage	1-5%	5-20%	20-45%	45-55%	55-80%	80-95%	95-99%

The North Korean on your payroll

Simon Conant, Alex Tilley — Wed, 11 Feb 2026 08:00:00 +0000

In September 2025, Okta Threat Intelligence published research from a large-scale analysis into fraudulent employment schemes conducted by Democratic People's Republic of Korea (DPRK) IT Workers (ITW).

That research collated data from over 130 actors, conducting over 6500 interviews with 500 companies.

In this post, we look specifically at the activities of two individual personas. We selected these two examples from a large list of actors that we continue to track because they exemplify the typical tools, techniques and procedures (TTPs) employed by DPRK ITW actors. Additionally, each had novel observables that can further inform defenders against these efforts.

These two actors reveal two interesting TTPs DPRK actors use to land employment: the abuse of legitimate LinkedIn profiles to pass reference checks, and the abuse of stolen identities.

#1 - Meet "JJ"

The first of the two actors we will detail we'll refer to as "JJ". This actor has prolifically interviewed for roles in multiple verticals over two years, with an overrepresentation of roles in AI and healthcare.

The email account used by this actor is similar in structure to other DPRK-linked actors, in that it utilizes a free webmail service and the account name incorporates references to software development and other randomized alphanumeric characters. Open-source intelligence (OSINT) research conducted into the email address used by this actor uncovered a number of online services accounts that are very typical of DPRK ITW actors. All of these accounts are used exclusively for job applications and associated tasks:

Job board and hiring platforms
Scheduling platforms popular with recruiters
Document organization workspaces with AI assistance
Dynamic DNS services
Online coding platforms

While not observed with this specific actor, Okta Threat Intelligence has also used OSINT techniques to observe email addresses used by DPRK actors being registered to the following services:

Freelancer employment platforms
Article authoring and publishing platforms
Document creation and managements
Language learning platforms
Online communications
Software development social platforms
Online PDF platforms
Coding assessment platforms

DPRK actors use these online accounts and fabricated resumes to effectively create an artificial "persona". These personas appear "out of thin air", inheriting the online presence required for a professional applying for roles, but without any evidence of personal use of any internet services. The exclusive use of these specific services, combined with the absence of any personal online footprint, creates a pattern highly indicative of an artificial persona.

Additional "tells" very common to these actors can sometimes be observed in the document properties of PDF resumes they provide. Okta Threat Intelligence can provide customers with further details on these methods of detection - please talk to your account manager to find out more.

Becoming JJ

During the two years of observed activity, our threat actor JJ created and subsequently abandoned several personas.

Until recently, JJ told recruiters that he did not have a LinkedIn profile. Okta Threat Intelligence occasionally observes LinkedIn profiles associated with the persona email addresses set up by DPRK ITW actors. The scarcity of connections, posts, recommendations, other content, and activity on these profiles can be used to identify a lack of authenticity. Often we discover that a LinkedIn profile listed by a DPRK ITW actor has been disabled thanks to the detection and enforcement efforts of the LinkedIn security team.

In September 2025, JJ was observed providing recruiters an active LinkedIn profile for the first time. The LinkedIn profile matched the inauthentic name they were using to apply for roles at the time, and doesn't feature a profile picture. At first glance, the LinkedIn profile appeared robust and realistic, unlike most LinkedIn profiles established for DPRK IT Worker fraud. For example, the profile had:

Almost 200 connections
Links to a GitHub account with realistic content (see later in report for example of an unrealistic GitHub account)
Multiple "skills" listed, many of which were endorsed by multiple third-parties. The endorsing LinkedIn accounts appeared to be authentic.

A happy false-positive

Our investigation determined that the person represented in the LinkedIn profile was, until recently, a genuine employee of the listed organization.

Our assessment is that the actor has simply misrepresented a genuine Linkedin profile as their own, altering the name of their fraudulent persona to fit that of a real human to align with the employment criteria. Our confidence in this assessment was also based on the fact that the DRPK actor's email address was not the email address used for the legitimate LinkedIn profile. It was a form of "stolen valour" designed to increase their chances of employment.

A challenge for verification

This technique - creating a persona based on a real identity - reinforces the need for strong identity verification prior to any form of employment. Employers should not rely on a LinkedIn profile as a basis for determining employment history. Verification requests to current or recent employers, asking only if a person with that name was employed in the role in the timeframes listed on LinkedIn, will not reveal the fraud. It is trivial for a threat actor to employ this technique, or to generate resumes directly from a co-opted Linkedin profile using an online resume generator or an AI-augmented system that consumes a public profile as an input. The actor simply creates an altered email address and phone number and makes the task of an HR screener far more demanding.

Prospective employers should incorporate identity verification techniques such as mobile drivers license verification. If relying on knowledge factors, verifiers should only base assessments on definitively non-public information such as partially-redacted national ID number or the name of the last manager at the role. Employers cannot rely on date of birth for robust verification as this information is readily available in public data and people-search services.

#2 "EM" gets hired

We will refer to our second actor as "EM". EM's employment fraud activity stretches back over a year, with hundreds of interviews again across all verticals, but very much favoring AI-related roles and organizations. Okta Threat Intelligence also observed EM interviewing with sensitive critical national infrastructure (CNI) organizations such as commercial aviation, communications providers, internet service providers, a voting technology company and intelligence and defense contractors.

EM has a statistically high occurrence of succeeding in first interviews and being offered multiple rounds of interviews with individual organizations, and is likely to have been hired by several organisations into software development roles.

We set out to discover some of the secrets to EM's success.

The co-opted persona used by EM appears to have been crafted based on an online photograph of a legitimate person who unfortunately also displayed enough information online to enable the DPRK (and potentially others) to co-opt his identity.

The real EM and an identity problem

EM claims to be a US citizen when asked about employment eligibility, and presents very realistic identity documents. Research into the name used by this actor finds that there is only one real person with this distinct name. We found photos of a person, holding up an identity document almost identical to the document our actor presents as his own, with a different photograph and signature.

The DPRK EM

EM's professed residential and employment history differs significantly from that of the real person whose identity was assumed. Okta Threat Intelligence observed EM offering two different contact phone numbers. Both are VoIP phones - ubiquitous with DPRK actors - and one has a Caller ID location that contradicts their professed biography. The LinkedIn profile listed in their resume has since been taken down by the team at LinkedIn.

lookup cname = SEATTLE WA
lookup cname = WESTPORT WA

DPRK ITW actors often create impressive-looking GitHub accounts to backstop their technical proficiency for job interviews. EM is no exception to this.

A GitHub account used by EM has thousands of contributions, ostensibly dating back to 2011.

However it appears that EM forged most of the commit dates .

The actual earliest contribution date from EM in this account can be determined using the GitHub API (see request response below), which returns a date of December 2024, not 2011.

?  ~ curl -s https://api.github.com/repos/em???????/D??????-W?????? | jq -r '.created_at'

2024-12-14T??:??:00Z

This actor simply changed the year of their unsigned commit date from 2024 to 2011.

The many (AI) faces of EM

The face of EM, as presented in various online profiles, is inconsistent. None of them are at all similar to the image used in EM's forged identity documents.

They appear to the human eye as likely AI creations, and multiple online AI-detection tools offer mixed-high confidence assessments when asked if the profile pictures were AI generated.

A third profile picture, likely sourced from a now-deleted LinkedIn account, lacks the necessary resolution to accurately determine if it was AI-generated. It is again clearly not the same as the forged identity or other AI-generated images used by the actor.

The other DPRK EM?

During the course of our research, Okta Threat Intelligence assessed two additional professional profiles with a distinctly different biography and profile picture that tools identified as likely not being AI-generated.

As the table below shows, the two profiles show a very different story. This may be a different DPRK ITW actor using the same identity, or an earlier iteration of EM's fictional biography.

Your new (DPRK) hire

During our research, we often make assessments as to whether a DPRK ITW actor has successfully been hired into a role. In this case we can say with high confidence that EM has been hired: thanks to a LinkedIn post by their new employer, welcoming their newest hire.

The photo used in this post is even more obviously AI-generated than any of the other photographs we analyzed.

Steps have been taken to contact this organization to inform them of our observations.

Conclusion

Just as with genuine candidates hunting for work, the vast majority of interviews with DPRK facilitators and agents do not progress to a second interview or job offer.

Some actors however seem to be more competent at crafting personas and passing screening interviews. Their skill isn't limited to an ability to impress a prospective employer, but also to the tools and techniques that DPRK ITW actors use to try to obfuscate their actual origins.

Given the vast quantities of job applications and interviews being conducted, the various operators in the IT Worker scheme are clearly "learning from their mistakes" - in many cases duplicating approaches (CV structure and elements, Linkedin profile construction and interview support technologies) that have succeeded in progressing one application over another. A kind of IT Worker natural selection is at play. The most successful actors are very prolific, and scheduled hundreds of interviews each. We consider it likely that they often act as "interview brokers" in order to land employment positions that are then handed over to other DPRK ITW actors.

The third-party contractor risk

Our research revealed a large number of DPRK IT Workers seek temporary contract work as software developers hired out to third-party organizations. We assess that these companies are potentially less likely to enforce rigorous background checks on these short-term fixed task employees than the companies that they are contracting to would for direct-hire employees.

This highlights the importance of performing such checks not only on direct-hire employees, but also on all individuals given access to company resources via third-party service providers.

Background checks can never be optional

In this report we've highlighted an example of the deliberate co-option of the identity of a genuine person, together with their professional history. Rigorous background checking and employment verification will be needed to pierce this identity misrepresentation. Yet we also observed the hiring of an actor whose artificial identity would not stand up to even the most cursory use of a search engine.

Organizations that unwittingly hire a DPRK actor risk a potential de facto breach of sanctions obligations and associated legal exposure. Each compromised hire can also provide the DPRK with:

Direct financial gain (salary payments diverted to the regime)
Privileged internal access to sensitive systems, data, and networks
Operational leverage for ransomware, extortion, or follow-on cyber activity
Loss of commercially-sensitive corporate secrets
Strategic intelligence collection and access to support future offensive operations

Organizations should therefore adopt a layered defense, including rigorous identity verification during recruitment, ongoing monitoring of the access and behaviour patterns of remote workers, and a clear incident response plan for managing insider or supply chain threats. When hiring for positions of elevated trust and access, in-person verification of identity and documents and collection/provision of equipment and access tokens is a relatively small cost given the risk the organization is taking on. Access for remote employees and especially third-party contractors should be strictly limited to the minimum required to perform their role.

Steps to take to counter this threat

Okta Threat Intelligence assesses that organizations across all verticals - particularly those advertising remote or contract roles - should adopt a layered and proactive approach to recruitment, onboarding, and insider-threat monitoring. Okta recommends that organizations:

1. Strengthen applicant identity verification

Require verifiable government-issued ID checks at multiple stages of recruitment and employment
Cross-check stated locations with IP addresses (include VPN usage detection), time-zone behaviour, payroll banking information and delivery addresses provided for shipping hardware.
Use accredited third-party services to authenticate identity documents, prior employment, and academic credentials

2. Tighten recruitment & screening processes

Train HR and recruiters to identify red flags. Encourage processes that would identify whether a candidate is swapped out between rounds of interviews. Teach them to identify behavioural cues such as poor knowledge of the area they claim to reside in, a refusal to meet in person, a refusal to turn on camera or remove background filters during interviews, or interviewing using a very poor internet connection. Identify duplicated resumes, inconsistent timelines, mismatched time zones and unverifiable references. Assess the candidate's online footprint and social media presence against the information provided. Where evidence of previous work is provided, investigate whether these projects were simply cloned from the repositories of legitimate user profiles.
Verify the history of edits to CVs and PDFs in document metadata and other technical "tells" associated with duplication and reuse.
Add structured technical and behavioural verification (live coding or writing performed under recruiter observation).
Require corporate email references (not free webmail) and confirm via outbound call to the main switchboard numbers of the reference organization. Ensure these references incorporate elements other than revealed in for example public LinkedIn profiles, such as last-manager's name.

3. Enforce role-based and segregated access controls

Default new or contingent workers to least-privilege profiles and unlock additional access once probationary checks are complete.
Segment development, testing and production; require peer review and approval workflows for code merges and deployments.
Monitor for anomalous access patterns (large data pulls, off-hours logins from unexpected geos/VPNs, credential sharing).
Employ access certification campaigns to govern ongoing access.

4. Monitor contractors and third-party service providers

Where possible, contractually mandate ongoing identity verification standards, background checks, strong authentication policies, device-security baselines and rights to audit.
Require named-user accounts (no shared logins or internal service accounts where possible) and separate tenant/project access for each client environment.

5. Implement insider-threat and security awareness programs

Establish a dedicated insider-risk function or at least a working group spanning HR, Legal, Security, and IT.
Provide targeted training for recruiters, hiring managers, and technical leads on ITW tradecraft and screening controls.
Educate and empower hiring managers and staff members to observe and submit reports of potentially strange behaviour by their peers that raise questions as to their identity, goals, and locations.
Create safer reporting channels for suspicious behaviour or candidate concerns.

6. Coordinate with law enforcement and industry peers

Share indicators of compromise and suspicious candidate patterns with national cybercrime units and ISAC/ISAO groups.
Develop methods for the "insider-risk" group to receive and action indicators (email addresses, IP addresses, VPN providers, document creation, and behavioural indicators) and be prepared to "share back" relevant findings.
Actively participate in information-sharing forums to track evolving ITW tactics and tooling.

7. Conduct regular risk assessments and red-team exercises

Model insider and malicious contractor attack paths; quantify potential business impact.
Perform red team exercises that test the hiring pipeline (simulated DPRK application and interviews) to assess identity verification processes.
Update incident response plans to include scenarios involving malicious insiders, compromised contractors, and expedited access revocation.

Okta Threat Intelligence appreciates the assistance of Epieos in the research for this post.

Detecting OpenClaw using advanced posture checks

Rafa Bono — Mon, 09 Feb 2026 16:00:00 +0000

OpenClaw is a free and open-source "personal AI assistant" that a user can connect to the local resources on their computer, messaging applications, calendars, and anything else they want the agent to access.

Right now, at least one of your users is experimenting with a personal assistant like OpenClaw. How you feel about that depends largely on the risk appetite of your organization, and how quickly you can spin up resources to assess the risk of this week's AI buzztoy. This stuff is coming at us fast.

A "personal AI assistant" doesn't need to be malicious or vulnerable for you to want to wrap some policy around its use on corporate-issued devices.

The facts are:

Personal AI assistants, by their nature, will seek broad system access - interacting with files, processes, and network resources - which makes it a powerful tool if it were ever abused.
Personal AI assistants may install persistence mechanisms like launchd services and binaries across multiple paths, making them difficult to fully remove.
The default listening port for these personal assistants could be exploited for remote access to your device or command-and-control.

The most conservative option would be to block the use of these technologies until your team has had some time to figure out how to use them safely. (See these tips from the Auth0 team if you're experimenting with OpenClaw).

You may also want to make access decisions for specific resources based on whether an AI assistant is downloaded, installed, or actively listening on a device used to access enterprise resources.

That's where Okta advanced posture checks can play a role. Advanced posture checks incorporates osquery-based posture evaluations on any device running admin-issued versions of the Okta Verify client.

By integrating detection queries like the samples provided below into advanced posture checks, organizations can automatically evaluate device health at authentication time and enforce access policies that, for example:

Block or restrict sign-ins from devices where OpenClaw is detected
Deny access to specific sensitive resources (apps) from devices where OpenClaw is detected
Trigger workflows that notifies administrators of a detection.

In all cases, administrators can create customized remediation advice for the user. Users can be instructed to take the actions necessary to restore access to specific resources, without having to call the IT helpdesk.

Sample queries

Let's assume OpenClaw is the personal AI assistant you want to check for. There are a number of approaches to detecting its use on a MacOS device.

Launchd

Let's start with persistent services/daemons by searching launchd for the term "OpenClaw". OpenClaw can be configured to launch at startup before you've even opened your terminal. This is part of the reason why personal AI assistants make people very, very nervous.

SELECT 1 AS result FROM (

    SELECT path

    FROM launchd

    WHERE name LIKE '%openclaw%'

    LIMIT 1);

Files

Advanced posture checks can also search for the presence of configuration files and binaries in common installation paths.

SELECT 1 AS result FROM (

    SELECT path

    FROM file

    WHERE path LIKE '/Users/%%/.openclaw/openclaw.json'

        OR path LIKE '/%%/.openclaw/%'

        OR path LIKE '/Users/%%/.volta/bin/openclaw'

        OR path LIKE '/Users/%%/.nvm/current/bin/openclaw'

        OR path LIKE '/usr/bin/openclaw'

        OR path LIKE '/usr/local/bin/openclaw'

        OR path LIKE '/opt/homebrew/bin/openclaw'

        OR path LIKE '/Applications/OpenClaw.app'

    LIMIT 1);

Running processes

Perhaps you're less concerned by whether OpenClaw has ever run on the machine, and more concerned about whether it's running while a user is signing in to protected resources?

SELECT 1 AS result FROM (

SELECT path

    FROM processes

    WHERE name LIKE '%openclaw%'

        OR cmdline LIKE '%openclaw%'

    LIMIT 1

);

Homebrew packages

OpenClaw leans on Homebrew for access to system-level dependencies. The presence of a homebrew installation with the name "OpenClaw" is another breadcrumb to follow.

SELECT 1 AS result FROM (

    SELECT path

    FROM homebrew_packages

    WHERE name LIKE '%openclaw%'

    LIMIT 1

);

npm package checks

The presence of an npm package of the same name also offers a detection opportunity.

SELECT 1 AS result FROM (

    SELECT path

    FROM npm_packages

    WHERE name LIKE '%openclaw%'

    LIMIT 1

);

Listening ports

By default, OpenClaw listens on several network ports:

18789 (TCP): The main port for the WebSocket Gateway, which coordinates connections between clients (CLI, web UI, mobile apps) and the AI agent.
18791 (TCP): Used for browser-based control/dashboard access.
9090: The application often defaults to using port 9090 for its service mode. Users frequently deploy OpenClaw using Docker containers, where mapping this port is necessary to access the service, commonly using 0.0.0.0:9090.

SELECT 1 AS result FROM (

    SELECT path

    FROM listening_ports

    WHERE port IN

('9090', -- Default OpenClaw self-hosted port.

'18789', -- The main port for the WebSocket Gateway.

'18791' -- Used for browser-based control/dashboard access.

        OR  path LIKE '%openclaw%'

    LIMIT 1

);

Installed applications

Advanced posture checks can also simply check if an app of this name is installed on the (MacOS) system.

SELECT 1 AS result FROM (

    SELECT path

    FROM apps

    WHERE name LIKE '%openclaw%'

        OR bundle_identifier LIKE '%openclaw%'

    LIMIT 1

);

Docker images

Advanced posture checks can also check for whether OpenClaw is running in a container. Here is a check for Docker images that use the name "OpenClaw"...

SELECT 1 AS result FROM (

    SELECT id

    FROM docker_images

    WHERE tags LIKE '%openclaw%'

    LIMIT 1

);

Docker containers

SELECT 1 AS result FROM (

    SELECT id

    FROM docker_containers

    WHERE image LIKE '%openclaw%'

    LIMIT 1

);

All together now

Given many of these detections rely on mutable names, a single query (or even two) might be prone to false positives. You may find that a few in combination deliver more consistent results.

The final query I'll leave you with attempts to detect the presence of OpenClaw on a macOS device by examining multiple system sources and combining the results into a single detection score.

Each source contributes a count of matches. These counts are summed into a final score:

Score ? 2 ? openclaw_detected = 0 (insufficient confidence of detection)
Score > 2 ? openclaw_detected = 1 (confident detection)

The threshold of 2 helps avoid false positives by requiring multiple indicators before flagging a device.

WITH launch_claw AS (

    SELECT COALESCE(COUNT(*), 0) as total

    FROM launchd

    WHERE name LIKE '%openclaw%'

),

 file_claw AS (

    SELECT COALESCE(COUNT(*), 0) as total

    FROM file

    WHERE path LIKE '/Users/%%/.openclaw/openclaw.json'

        -- OR path LIKE '/%%/.openclaw/%'

        OR path LIKE '/Users/%%/.volta/bin/openclaw'

        OR path LIKE '/Users/%%/.nvm/current/bin/openclaw'

        OR path LIKE '/usr/bin/openclaw'

        OR path LIKE '/usr/local/bin/openclaw'

        OR path LIKE '/opt/homebrew/bin/openclaw'

        OR path LIKE '/Applications/OpenClaw.app'

),

 claw_process AS (

    SELECT COALESCE(COUNT(*), 0) as total

    FROM processes

    WHERE name LIKE '%openclaw%'

        OR cmdline LIKE '%openclaw%'

),

 homebrew_claw AS (

    SELECT COALESCE(COUNT(*), 0) as total

    FROM homebrew_packages

    WHERE name LIKE '%openclaw%'

),

 npm_claw AS (

    SELECT COALESCE(COUNT(*), 0) as total

    FROM npm_packages

    WHERE name LIKE '%openclaw%'

),

 netports_claw AS (

    SELECT COALESCE(COUNT(*), 0) as total

    FROM listening_ports

    WHERE port IN

('9090', -- Default OpenClaw self-hosted port.

'18789', -- The main port for the WebSocket Gateway.

'18791' -- Used for browser-based control/dashboard access.

        OR  path LIKE '%openclaw%'

),

 apps_claw AS (

    SELECT COALESCE(COUNT(*), 0) as total

    FROM apps

    WHERE name LIKE '%openclaw%'

        OR bundle_identifier LIKE '%openclaw%'

),

 docker_image_claw AS (

    SELECT COALESCE(COUNT(*), 0) as total

    FROM docker_images

    WHERE tags LIKE '%openclaw%'

),

 docker_container_claw AS (

    SELECT COALESCE(COUNT(*), 0) as total

    FROM docker_containers

    WHERE image LIKE '%openclaw%'

),

 final_score AS (

     SELECT

        + file_claw.total

        + claw_process.total

        + homebrew_claw.total

        + npm_claw.total

        + netports_claw.total

        + apps_claw.total

        + docker_image_claw.total

        + docker_container_claw.total

        AS score

     FROM launch_claw, file_claw, claw_process, homebrew_claw, npm_claw, netports_claw, apps_claw, docker_image_claw, docker_container_claw

 SELECT

    CASE

        WHEN score <= 2 THEN 0

        WHEN score > 2 THEN 1

    END AS openclaw_detected

 FROM final_score

More clawsome detections

Detecting the presence of a new and unverified application like OpenClaw is one of numerous ways in which advanced posture checks can be used to ensure resources are only accessed from devices exhibiting strong hygiene.

Stay tuned for more!

Phishing kits adapt to the script of callers

Wed, 21 Jan 2026 16:00:00 +0000

Okta Threat Intelligence has detected and dissected multiple custom phishing kits that have evolved to meet the specific needs of voice-based social engineers ("callers") in vishing campaigns.

These custom kits are made available on an as-a-service basis and are increasingly used by a growing number of intrusion actors targeting Google, Microsoft, Okta and a range of cryptocurrency providers.

The kits are capable of intercepting the credentials of targeted users, while also presenting the supporting context required to convince users to approve MFA challenges, or to take other actions in the interests of the attacker on the phone. They can be adapted on the fly by callers to control what pages are presented in the user's browser, in order to sync with the caller's script and whatever legitimate MFA challenges the caller is presented with as they attempt to sign-in.

"Once you get into the driver's seat of one of these tools, you can immediately see why we are observing higher volumes of voice-based social engineering," said Moussa Diallo, threat researcher at Okta Threat Intelligence. "Using these kits, an attacker on the phone to a targeted user can control the authentication flow as that user interacts with credential phishing pages. They can control what pages the target sees in their browser in perfect synchronization with the instructions they are providing on the call. The threat actor can use this synchronization to defeat any form of MFA that is not phishing-resistant."

Okta Threat Intelligence has published a detailed threat advisory for customers that provides an inside look at the capabilities of two such kits used by intrusion actors. This blog post summarizes the key features that make these kits so effective.

When all else fails, hit the phones

The phishing kits appear, based on common features, to have evolved from the same lineage to specifically meet the needs of callers that are interacting with targeted users in real-time.

The most critical of these features are client-side scripts that allow threat actors to control the authentication flow in the browser of a targeted user in real-time while they deliver verbal instructions or respond to verbal feedback from the targeted user. It's this real-time session orchestration that delivers the plausibility required to convince the threat actor's target to approve push notifications, submit one time passcodes (OTP) or take other actions the threat actor needs to bypass MFA controls.

Attacks tend to follow a similar sequence:

The threat actor performs reconnaissance on a target, learning the names of users, the apps they commonly use, and phone numbers used in IT support calls;
The threat actor sets a customized phishing page live and calls targeted users, spoofing the phone number of the company or its support hotline;
The threat actor convinces the targeted user to navigate in their browser to the phishing site under the pretext of an IT support or security requirement;
The targeted user enters their username and password, which is automatically forwarded to the threat actor's Telegram channel;
The threat actor enters the username and password into the legitimate sign-in page of the targeted user and assesses what MFA challenges they are presented with;
The threat actor updates the phishing site in real-time with pages that support their verbal ask for the user to enter an OTP, accept a push notification, or other MFA challenges.

This real-time session orchestration provides a new level of control and visibility to the social engineer. If presented a push notification (type of MFA challenge), for example, an attacker can verbally tell the user to expect a push notification, and select an option from their C2 panel that directs their target's browser to a new page that displays a message implying that that a push message has been sent, lending plausibility to what would ordinarily be a suspicious request for the user to accept a challenge the user didn't initiate.

It's worth noting that these hybrid phishing operations are also capable of bypassing push notifications that use number challenge/number matching as an additional method of verification. Push with number matching/challenge is not phishing-resistant by definition, as a social engineer interacting on the phone with a targeted user can simply request a user to choose or enter a specific number.

By contrast, users that are required to sign in with phishing resistant methods such as Okta FastPass or FIDO passkeys are protected from these attacks.

This is how it's done now

Diallo predicts that we're only at the beginning of a wave of voice-enabled phishing attacks, augmented by tools that provide real-time session orchestration.

"Vishing is becoming such an in-demand area of expertise that, much like access to these kits, that expertise is also sold on an as-a-service basis," Diallo said.

Further, he has observed the real-time session orchestration features of earlier kits being copied into new phishing kits designed exclusively to augment the needs of callers.

Where threat actors could once pay for access to a kit with basic features that targeted all popular Identity Providers (Google, Microsoft Entra, Okta etc) and cryptocurrency platforms, a new generation of fraudsters are attempting to sell access to bespoke panels for each targeted service.

Recommendations

Thankfully there is absolutely no doubt about what defenders need to do.

"In a workplace context, there is no substitute for enforcing phishing resistance for access to resources," said Diallo.

When using Okta for workforce authentication, that would equate to enrolling users in Okta FastPass, passkeys or "both for the sake of redundancy," he said.

Social engineering actors can also be frustrated by setting network zones or tenant access control lists that deny access via the anonymizing services favoured by threat actors.

"The key is to know where your legitimate requests come from, and allowlist those networks," Diallo said.

Some banks and cryptocurrency exchanges are also experimenting with live caller checks - in which a user can sign into a mobile app to find out whether they are on a phone call with an authorized representative at the time.

Okta Threat Intelligence has published threat advisories on voice-enabled phishing campaigns in April 2025 and January 2026 that are available exclusively to the security contacts of Okta customers.

These threat advisories include:

Indicators of Compromise (IoCs)
Analysis of multiple phishing kits
TTPs of intrusion actors conducting these attacks
Detailed control recommendations

To learn more about Okta's approach to phishing resistance, start here.

Jobseekers exploited in fake recruiter phishing campaigns

Thu, 18 Dec 2025 16:00:00 +0000

Executive Summary

Okta Threat Intelligence has identified multiple clusters of high-volume phishing activity impersonating recruitment teams from various companies, using over 400 domains to facilitate credential theft.

We track this activity as O-UNC-038.

In this report we detail:

A campaign using a "Browser in the Browser" (BitB) technique to mimic a Facebook social login, using Telegram bots for credential exfiltration.
A campaign specifically targeting Google Workspace corporate account credentials, using Socket.IO for credential exfiltration
Similar recruitment-themed phishing campaigns

The primary objective across all of these campaigns is credential harvesting.

While more sophisticated campaigns may leverage Adversary-in-the-Middle (AitM) techniques which capture session cookies to bypass Multi-Factor Authentication (MFA), the campaigns in this advisory conduct simple credential harvesting via static phishing kits.

Threat Analysis

Multiple campaigns, similar targeting

We uncovered and tracked multiple campaigns that all use similar recruitment-themed phishing lures and abuse the same services for lure delivery or tracking.

In phishing pages associated with the clusters of activity described below, we observed tracking links associated with Salesforce ExactTarget:

cl.s12[.]exct[.]net/?qs=<UniqueIdentifierString>

Phishing actors commonly abuse email marketing platforms to send phishing emails, either by setting up trial accounts for fake organizations, or by taking over the accounts of email marketing platform customers. The phishing actors can then send to large email lists from trusted mailing infrastructure.

Okta provided these domains and tracking links to Salesforce Threat Intelligence, who were able to immediately suspend the associated Salesforce accounts and investigate the campaigns.

Below we detail the different lures and functionality of two of the campaigns.

Threat Analysis - Campaign 1

Browser in the Browser (BitB) Facebook credentials campaign ("Campaign 1")

This first cluster we will analyze uses a Browser in the Browser (BitB) technique to acquire Facebook credentials from the victim by displaying a fake login dialog box window.

A BitB attack is an advanced phishing technique where a malicious webpage uses HTML, CSS, and JavaScript to create a fake browser window inside the real browser window. This fake window is designed to mimic a legitimate pop-up, such as the "Login with Facebook" prompt, complete with a fake address bar and security padlock. Any credentials entered into this fake window are captured by the attacker.

We tracked 143 domains associated with this specific Facebook/BitB-technique campaign. We also observed some diversity in hosting, possibly suggesting separate actors or sub-campaigns using the same technique.

This campaign most typically use the Vercel frontend cloud service, or register domain names at registrar.eu and host the sites with Amazon Web Services. This campaign also uses a Telegram bot for credential exfiltration and to distribute updates to the sites.

Example: Fake Meta Recruitment

The credential phishing example impersonates Meta recruitment across three distinct pages: an initial landing page, a job application page portal, and a fake Facebook login page.

Example: Fake Puma Recruitment

The sequence of three images below are another example, this time impersonating Puma recruitment:

Observed Phishing Lures - Campaign 1

The BitB campaign utilizes convincing corporate software and services to trick users into entering credentials. Once user credentials are entered into the attacker-controlled site, the submission page simulates a hanging process.

Threat Analysis - Campaign 2

This cluster does not use the BitB technique as seen in Campaign 1, but rather a static landing page that imitates a full-screen Google account login.

The phishing pages used in this campaign reject personal email address formats in an attempt to capture corporate credentials.

We observed at least 84 related domains for this campaign, which abuses Cloudflare to obfuscate the actual origin IP address and Socket.IO for exfiltration of stolen credentials.

Example: Fake Sony Playstation recruitment

Any data submitted in the "form" below is ignored, as this campaign only attempts to capture Google credentials.

Once credentials are entered, the workflow may terminate using either a hanging process similar to Cluster 1, or some sort of error dialog.

Other Recruitment-themed Phishing Clusters

Our investigation into the previous two distinct phishing clusters uncovered several more similar recruitment-themed campaigns, including almost 200 additional phishing domains.

These can be clustered into groups of infrastructure combinations and/or naming techniques, which may suggest that several independent actors may be behind these similarly-themed campaigns.

These campaigns & infrastructure impersonate multiple well-known companies and recruitment services, including:

Adecco
Adidas
Aquent
Calendly
Calvin Klein
Cisco
CocaCola
Genpact
Givenchy
Google
Hays
Ikea
Inditex
Meta
Playstation (Sony)
Puma
Randstand
Robert Half
Robert Walters
Salesforce
Starbucks
Youtube
Zara

Many of these campaign domains do not use a default / "www" host, but rather specific hostnames such as:

apply.
hire.
careers.
calendly.
case.
hr.
jobs.
join.
kvn.
recruit.
recruite.
schedule.
staff.
start.
threads.
xds.

This may both reinforce a valid-looking URL to the victim, and also obfuscate the phishing pages at the domain for crawlers or researchers looking only at the domain root.

Threat Response

What we're doing

We're actively engaged in the following activities to mitigate this threat:

Continuously monitoring for newly registered phishing domains and infrastructure associated with this campaign.
Providing guidance and assistance to organizations to enhance the security of their Okta environments and investigate any suspicious activity related to potentially compromised accounts.

Protective Controls

Recommendations

Enable phishing-resistant MFA (FastPass/WebAuthn/passkeys); disable SMS/voice for these users.
Block and monitor newly registered domains that imitate your service. If content hosted on the domain violates copyright or legal marks, consider providing evidence and issuing a takedown request with the domain registrar and/or web hosting provider.
Enforce DMARC/DKIM/SPF and alert on spoofed hiring/recruiter mail.
Teach users to only sign-in to known domains (type or bookmark).
Teach users to spot BitB impersonation:
- If a user attempts to move a login window outside of a parent host site window, it should be able to move anywhere on the user's screen. A fake login dialog is a fixed element within the parent host page - it will only be able to move within the boundaries of the host page window.
- If a user minimizes the window of the host page, a real login dialog would remain displayed independently of the host page window. A fake login element will minimize in sync with the host page window.
Advise job applicants to use official careers portals and to reject solicitations or links to communicate via other platforms.
Hunt for IoCs (e.g. Telegram bot API calls, t.me/, bot*getUpdates, sendMessage; BitB CSS/JS patterns).

Response playbook

Report and and request a takedown of malicious site
Reset the credentials (passwords, session tokens) of impacted users and notify, where required.
Review SSO logs of impacted users.
Evaluate whether to include advice on "Browser-in-the-browser" attacks in your security awareness program.

Indicators of Compromise

The security contacts of Okta customers can sign-in and download Indicators of Compromise from security.okta.com at the following link:

https://security.okta.com/product/oktathreatintelligence/jobseekers-exploited-in-fake-recruiter-phishing-campaigns

A note on estimate language

Likelihood	Almost no chance	Very unlikely	Unlikely	Roughly even chance	Likely	Very likely	Almost certain(ly)
Probability	Remote	Highly improbable	Improbable	Roughly even odds	Probable	Highly Probable	Nearly Certain
Percentage	1-5%	5-20%	20-45%	45-55%	55-80%	80-95%	95-99%

Phishing campaigns use 'Employee Benefits' lure to intercept Microsoft and Okta logins

Mon, 20 Oct 2025 16:00:00 +0000

Executive Summary

Okta Threat Intelligence has identified multi-stage phishing campaigns targeting organizations that use Microsoft applications and - where access to these apps are federated - Okta as Identity Provider (IdP).

Our findings, first researching a distinct campaign which we label O-UNC-037, subsequently led us to several other campaigns using the same phishing kit and a very similar lure theme. However, diversity in the infrastructure and style suggests that while these use the same kit and theme, they are likely separate campaigns run by other threat actors. This report focuses on O-UNC-037, although we share details of the other campaigns in the appendix at the end of this report.

The O-UNC-037 campaign has been active since at least October 2025, and largely targets technology and industrial supply organizations. It delivers phishing emails using an employee benefits or human resources (HR) themed lure to deceive users into entering their credentials on a fake Microsoft sign-in page.

The phishing infrastructure uses Adversary-in-the-Middle (AitM) techniques to intercept authentication flows in real-time, capturing credentials, MFA codes and any session tokens established during the sign-in event. This capability can bypass the protection of several common MFA methods, such as SMS codes and one-time passwords (OTP) from authenticator apps.

For organizations that use Okta for Single Sign-On (SSO), the attack then escalates to a second stage, redirecting victims to a malicious replay of an Okta sign-in page on the second-stage phishing domain, which acts as a relay server to additionally capture their Okta credentials and steal the session cookie.

Threat Analysis

This phishing campaign uses a multi-stage attack technique. It specifically targets Microsoft accounts, and handles Okta SSO redirection when encountered. The attack chain involves several steps designed to direct targeted users to an AitM credential harvesting page.

Observed Tactics, Techniques and Procedures (TTPs):

Infrastructure and Initial Access:
- Phishing emails are delivered with subject lines customized to include the user's name and lures such as "Employee Benefits Alert" or "secure message from HR Department" to create a sense of urgency.
- Campaigns use redirector domains to funnel targeted users towards the primary phishing sites, while bypassing email gateway controls.
- Campaigns require users to solve a Cloudflare CAPTCHA before presenting the phishing page.
Execution and Credential Theft:
- Uses Adversary-in-the-Middle (AiTM) techniques capturing credentials, MFA codes and session tokens by intercepting authentication flows.
- Deploys a multi-stage phishing attack, first targeting Microsoft credentials and then pivoting to Okta SSO if federation is detected.
Phishing Kit and Lure:
- Very likely leverages a Phishing-as-a-Service (PhaaS) platform, or a highly configurable phishing kit, evidenced by URL parameters for campaign tracking and template loading.
- Uses a generic but effective "Employee Benefits" social engineering lure.

Email lures

The attack begins with a phishing email sent to the target. Based on their visual characteristics, these highly convincing email lures are likely generated using a Large Language Model (LLM). The emails use sender names and subjects designed to create a sense of urgency and legitimacy related to employee benefits or secure communications.

Examples of observed email headers:

From: ADP BENEFITS <notifications[@]duobenefits[.]com>
Subject: [User Name]! Employee Benefits Alert - New Changes Effective Now

From: Secure Mail <noreply[@]mailsafe365[.]com>
Subject: [User Name]! You've received a secure message from HR Department

We also observed examples of what appears to be abuse of the third-party email marketing platform of a genuine organization, possibly through a compromised account:

From: ADP Benefits <notifications_adp_com[@]emails[.]t??????s[.]org>
Subject: Confidential: [User Name]! Your Benefits Package Has Been Updated

Initial redirector links in emails

Users are first directed to the phishing infrastructure via initial redirector links within the emails. Most of these are first-party newly registered domains, avoiding historical reputation issues to bypass email security measures:

benefits-alerts[.]com
benefitsapp001[.]com
qrcodelnk[.]com
302lnk[.]com
goto365[.]link
fastlink247[.]link
link24x7[.]link
fast2url[.]link
url247[.]link

We also noticed a redirector-link example abusing the legitimate account of an organization on a third-party email marketing service for redirection:

t??????s[.]msg???[.]com

One redirection-link example uses the compromised website of a genuine organization:

Marketing.s??????y[.].com

Using compromised email marketing service accounts, or compromised genuine websites, is an effective measure to achieve higher deliberability during phishing campaigns..

The redirector layer also affords the threat actor an ability to substitute replacement phishing pages, should any second-stage pages be taken down.

Security challenge

Upon redirection to the primary phishing site, the user is first presented with a page titled "Security Verification", employing a genuine Cloudflare CAPTCHA. This step is designed to both appear legitimate and acts as a "gatekeeper" to evade automated analysis of the phishing site.

Splash page

Once the CAPTCHA challenge is completed, the site next briefly serves up a splash screen themed to suit the aforementioned lure.

Credential harvesting

After the splash screen, a targeted user is presented with the first-stage phishing page, which impersonates a Microsoft login and uses AitM to steal user credentials, and if the user authenticates successfully, any resulting tokens.

Second-stage redirection to Okta sign in

If the victim's email domain indicates that their organization uses Okta for identity federation, the phishing site's script intercepts the legitimate authentication flow. It dynamically replaces the legitimate Okta redirect URL with a malicious one (for example sso[.]oktacloud[.]io), sending the user to a look-alike Okta phishing page to again use AitM to harvest their SSO credentials and steal the resulting session cookie. We detail this technique in our code analysis, later in this report.

Original campaign infrastructure

Our analysis of the O-UNC-037 campaign identified the following infrastructure used to host the malicious fake Microsoft Sign-In pages:

benefitsemployeeaccess[.]com
benefitsquickaccess[.]com
benefitsworkspace[.]com
benefitscentralportal[.]com
benefitsselfservice[.]com
benefitsmemberportal[.]com
benefitsgatewayportal[.]com
benefitshubportal[.]com
benefitsadminportal[.]com
benefitsaccessportal[.]com
benefitsviewportal[.]com

The phishing sites use a number of URL paths to further the "employee benefits" lure:

/benefits/login/
/compensation/auth/
/rewards/verify/
/employee/access/

Federated users are redirected to the following second-stage landing pages after providing primary credentials for their Microsoft account.

sso[.]oktacloud[.]io
sso[.]okta-access[.]com
Internal-networks[.]com

Analysis of the Okta-targeting redirect phishing domains led us to multiple instances using Cloudflare Workers, which is a serverless platform often abused by threat actors to host and serve phishing sites.

sso[.]okta-proxy[.]workers[.]dev
okta[.]undermine[.]workers[.]dev
oktapage[.]oktamain[.]workers[.]dev
okta[.]eventspecial[.]workers[.]dev

Additional campaigns infrastructure

Pivoting from the O-UNC-037 phishing campaign, we discovered other campaigns using the same phishing kit and very similar lures. Observations of infrastructure detail in these other examples suggests it's likely these are operated independently by other threat actors, possibly following the instructions of a shared or sold "method". We include a list of these domains together with the O-UNC-037 domains in the Indicators of Compromise linked from the end of this document.

Phishing page analysis

This campaign follows a structured attack chain that combines social engineering and AitM techniques capable of stealing session tokens from both Microsoft 365 or Okta. Analysis of the phishing URLs and pages suggest that the actor is using a Phishing-as-a-Service (PhaaS) or a highly configurable phishing kit.

A detailed analysis of the phishing URLs reveal a gatekeeper mechanism embedded within its query parameters, particularly in the "ht" parameter, which contains a Base64-encoded JSON object.

https://benefitsemployeeaccess[.]com/rewards/verify/d582500e?s=3&ht=eyJpZCI6IjY2ZmI2OWMwNjA2N2RjOTM5Yzc5OTM1NWE0ODNjNzM3IiwidHlwZSI6ImhvcCIsImNhbXBhaWduX2lkIjoiY2FtcF82OGYyNjQ3YTlmYjE0IiwiaG9wX3RlbXBsYXRlIjoiYmVuZWZpdHMiLCJzdWNjZXNzX3RlbXBsYXRlIjoiYmVuZWZpdHNfZXJyb3IiLCJjcmVhdGVkIjoxNzYwOTM3NDcyLCJleHBpcmVzIjoxNzYwOTQ0NjcyLCJpcCI6IjExMy4yOS4yNDMuMSIsIm1heF91c2VzIjoxMDAwMDAwMCwidXNlcyI6MCwiaG9wX2NvdW50IjozLCJzZXNzaW9uIjoiZG9oNnBhbnE0Y3RhZTVsMjhvNWoyaTdoa3YifQ%3D%3D.bb0c9db57db67ff678edafb64f3cdc4fccfa93d4a8952e05ca2a3176e8134db5

When decoded, this object reveals a comprehensive set of data points for both tracking and access control. It contains detailed tracking information, including a "campaign_id", a "hop_template" for dynamic content loading, the victim "ip" address, and a unique "session" ID. Simultaneously, it includes the terms of access through link creation and expiration timestamps ("created", "expires") and usage counters ("uses", "max_uses"). This dual-purpose structure indicates a backend system that not only functions as a gatekeeper to enforce strict, time-limited access but also allows the actor to track individual campaigns, dynamically load different phishing templates, and monitor victim interactions. This capability enables the actor to easily adapt their lures and targets without redeploying the entire infrastructure.

  "id": "66fb69c06067dc939c799355a483c737",

  "type": "hop",

  "campaign_id": "camp_68f2647a9fb14",

  "hop_template": "benefits",

  "success_template": "benefits_error",

  "created": 1760973582,

  "expires": 1760980782,

  "ip": "?????",

  "max_uses": 10000000,

  "uses": 0,

  "hop_count": 3,

  "session": "qa061c1uiht26gmtqcj49fsgci"

Analysis of the initial Microsoft phishing page shows the handling of users from Okta-federated organizations. When such a user enters their email, a legitimate O365 login portal would typically return a JSON response containing a FederationRedirectUrl that points to the company's Okta tenant.

The campaign uses JavaScript on the phishing page to intercept this process. The script is configured to:

Monitor fetch responses from the server.
Inspect JSON responses for keys such as FederationRedirectUrl, AuthURL, or RedirectUrl.
Check if the URL points to a legitimate Okta tenant (.okta.com, .oktapreview.com, etc.).
If a legitimate Okta URL is found, the script dynamically replaces it with a URL pointing to the actor's malicious second-stage phishing domain, for example: sso[.]oktacloud[.].io.
The modified response is then passed back to the browser, seamlessly redirecting the user to the actor's fake Okta login page.
Captured credentials and session cookies are exfiltrated to a "/api" endpoint on the phishing server.
The script includes functions to auto-fill the username from the URL hash and auto-click "Next" and "Stay signed in" buttons, creating a more seamless and less suspicious experience for the victim.

This AitM interception allows the actor to hijack the authentication flow in real-time, presenting the user with a replica of Okta login page to capture SSO credentials and the established session cookie.

     var _wd = "https://sso.oktacloud.io";

        var _iO = function (u) {

            if (typeof u !== "string") return false;

            if (u.includes("sso.oktacloud.io")) return false;

            if (u.includes("/app/office365")) return true;

            if (u.match(/\.(okta|oktapreview|okta-emea)\.com/i)) return true;

            if (u.match(/\/sso\/saml|\/sso\/wsfed|\/app\/[^\/]+\/sso/i)) return true;

            return false;

};

Subsequent account takeover attempts

Following the successful compromise of credentials and session token theft, the threat actors have been observed attempting, and successfully authenticating from CloudFlare IPs (AS13335).

Threat Response

What we're doing

We're actively engaged in the following activities to mitigate this threat:

Continuously monitoring for newly registered phishing domains and infrastructure associated with this campaign.
Proactively filing abuse reports with relevant registrars and hosting providers to initiate takedown requests for identified malicious sites.
Providing guidance and assistance to organizations to enhance the security of their Okta environments and investigate any suspicious activity related to potentially compromised accounts.

Protective Controls

Recommendations for customers

Enroll users in strong authenticators such as Okta FastPass, FIDO2 WebAuthn and smart cards and enforce phishing resistance in policy.
Okta app sign-on policies (formerly "authentication policies") can also be used to restrict access to user accounts based on a range of customer-configurable prerequisites. We recommend administrators restrict access to sensitive applications to devices that are managed by Endpoint Management tools and protected by endpoint security tools. For access to less sensitive applications, require registered devices (using Okta FastPass) that exhibit indicators of essential hygiene.
Deny or require higher assurance for requests from rarely-used networks. With Okta Network Zones, access can be controlled by location, ASN (Autonomous System Number), IP, and IP-Type (which can identify known anonymizing proxies).
Okta Behavior and Risk evaluations can be used to identify requests for access to applications that deviate from previously established patterns of user activity. Policies can be configured to step-up or deny requests using this context.
Train users to identify indicators of suspicious emails, phishing sites and common social engineering techniques used by attackers. Make it easy for users to report potential issues by configuring End User Notifications and Suspicious Activity Reporting.
Document, evangelize and adhere to a standardized process for validating the identity of remote users that contact IT support personnel, and vice versa.
Take a "Zero Standing Privileges" approach to administrative access. Assign administrators Custom Admin Roles with the least permissions required for daily tasks, and require dual authorization for JIT (just-in-time) access to more privileged roles.
Apply IP Session Binding to all administrative apps to prevent the replay of stolen administrative sessions.
Enable Protected Actions to force re-authentication whenever an administrative user attempts to perform sensitive actions.

Observing and responding to phishing infrastructure:

Review application logs (Okta logs, web proxies, email systems, DNS servers, firewalls) for any evidence of communication with any such suspicious domains.
Monitor the domains regularly to see if the contents change.

If content hosted on the domain violates copyright or legal marks, consider providing evidence and issuing a takedown request with the domain registrar and/or web hosting provider.

Indicators of Compromise

The security contacts of Okta customers can sign-in and download Indicators of Compromise as a CSV file from security.okta.com at the following link:

https://security.okta.com/product/oktathreatintelligence/phishing-campaigns-use-employee-benefits-lure-to-intercept-microsoft-and-okta-logins

A note on estimate language

Likelihood	Almost no chance	Very unlikely	Unlikely	Roughly even chance	Likely	Very likely	Almost certain(ly)
Probability	Remote	Highly improbable	Improbable	Roughly even odds	Probable	Highly Probable	Nearly Certain
Percentage	1-5%	5-20%	20-45%	45-55%	55-80%	80-95%	95-99%

Wide-scale, opportunistic SMS pumping attacks target customer sign-up pages

Mon, 13 Oct 2025 16:00:00 +0000

Executive Summary

Okta Threat Intelligence has identified a cluster of shared disposable email infrastructure and commodity proxy services, internally designated as O-UNC-036, that is being used to launch high-volume, automated attempts against public API endpoints.

This infrastructure has been observed in multiple persistent, large scale and financially motivated SMS pumping campaigns starting at least as early as July 2025.

To execute this attack, threat actors undertake the following sequence of actions:

Create a new account using a disposable email address, often tied to a set of domains
Add an actor-controlled phone number as an authentication factor
Send as many messages to the number as possible in order to achieve their monetary objectives

These attacks generate significant financial costs for the target organizations by running up bills with their telephony providers. We have been able to track historical activity from this cluster of disposable email domains back to at least March 2024, indicating a sustained, adaptive effort. Due to the high financial risk and potential for service degradation, we strongly recommend the immediate implementation of the protective controls, monitoring and aggressive response outlined in this report.

Threat Analysis

The primary objective of this campaign is opportunistic, large-scale account creation in order to carry out SMS pumping campaigns. In these attacks, threat actors profit by collaborating with high-cost international or premium-rate SMS providers. By exploiting the SMS delivery system of the target identity platform, the attacker triggers messages to phone numbers they control in high-cost regions. The victim organization is then billed for the exorbitant volume and cost of these international or premium SMS messages, with the cost of attacks potentially costing hundreds of thousands of dollars in telephony bills.

The attack follows a high-volume pattern:

Reconnaissance and Enumeration: Attackers identify multi-factor authentication (MFA) or user registration endpoints that trigger an SMS code.
Infrastructure Setup: Actors use commodity proxy services (VPNs, anonymizing proxies, residential botnets etc.) to distribute the source IP addresses of the traffic, reducing the efficacy of rate-limiting based solely on IP.
High-Volume Requests: Automated scripts submit requests using known, high-cost phone country codes and rapidly generated, disposable email addresses.
Cluster Activity: The O-UNC-036 infrastructure is a key enabler. This cluster utilizes a revolving pool of shared disposable email domains to bypass email-based rate limits and tenant-level velocity checks, allowing them to rapidly cycle through accounts for message requests. Okta Threat Intelligence has tracked activity in this cluster back to at least March 2024.
Target Scope: We observed this activity in multiple tenants and organizations of both Auth0 and OCI, indicating a widespread, indiscriminate search for vulnerable endpoints that trigger SMS delivery. The same shared infrastructure is likely also used to attack organizations building their own customer sign-in pages or using alternative services.

For technical details of how to identify these attacks in your logs, see the Detection and Indicators sections of this report.

Detection

Our research has not uncovered any legitimate use of emails under domains listed in the indicators section of this report. Thus the existence of users with such emails is sufficient to detect attacks. Given the potential duration of this attack, it is critical that administrators look back as far as possible in their logs to determine the scope of past and future impact.

Okta Customer Identity

High numbers of messages being sent to countries outside of your company's normal operating regions.
A spike in the following event types:

        system.sms.send_okta_push_verify_message

        system.sms.send_factor_verify_message where result=DENY

and

        reason=Toll Fraud Suspected

A spike in the following event type:

        system.email.new_device_notification.sent_message

as malicious account's alternative proxy providers or ASNs every login.

See the "Monitoring of your Okta org" section of our support article "How to Mitigate Toll Fraud when Using Okta for Voice Authentication" for a comprehensive overview of detection strategies.

Auth0

ss events from the domains listed in the Indicators of Compromise section. Administrators should refer to detection rules provided in the FOSS Auth0 Security Detection Catalog and modify them as needed.
Spikes in Guardian events, especially gd_enrollment_complete and gd_send_sms events. We advise administrators to use the risk_of_signup_fraud_by_volume.yml and sms_bombarding.yml detection rules in the Auth0 Security Detection Catalog.
A spike in "MFA bypass" events in Security Center.
High numbers of messages being sent to countries outside of your company's normal operating regions.

Protective controls and response

Okta Threat Intelligence has observed these attackers abandon a target when frustrated by the introduction of controls. This makes aggressive response and implementation of proper controls effective in stopping these attacks.

While ever sending SMS messages costs money, attackers will find a way to skim off the top. This risk can only be fully mitigated by migrating to another authentication factor. We strongly recommend the adoption of FIDO Authentication (passkeys).
Our research has not uncovered legitimate use of the domains provided in the Identicators section of this document. Deactivate users that provided these emails after making your own assessment.
Accounts created from the ASNs in the Indicators section of this document are seldom legitimate. Administrators are advised to deactivate these accounts unless friction is a major concern.
Disable sending messages to untrusted countries in your telephony provider.

Okta Customer Identity

Implement FIDO Authentication with WebAuthn and migrate users' factors away from SMS.
Use passkeys instead of SMS or voice factors.
Block anonymizers and proxies at edge by leveraging enhanced dynamic network zones.
Utilizing workflows to manage self-service registration users from malicious domains. An Okta Identity Defense generated workflow exists that can be utilized or expanded upon and can be found here.
Utilize the Okta API to quickly deactivate large batches of identified users.
Leverage identity proofing integrations.
See our support article "How to Mitigate Toll Fraud when Using Okta for Voice Authentication" for a comprehensive overview of responses and preventative controls.
Block suspicious activity using the tooling provided by your telephony provider.

Contact Okta Support to provide a list of allowed telephony countries if you're confident in the specific list of countries servicing your customers. You can also request to modify the rate limits on your organization.

Auth0

Implement FIDO Authentication with Webauthn and migrate users' factors away from SMS or voice factors.
Use passkeys instead of SMS or voice factors.
Block requests from the ASes and TLS client fingerprints in the Indicators of Compromise section at edge with Auth0's Tenant Access Control List feature.
Since these attackers are especially sensitive to friction, enabling bot detection and enforcing CAPTCHA can be an effective control.
Block users from registering using the email domains listed in the
Indicators of Compromise section with Signup and Login triggers.
Disable sending messages to untrusted countries in your telephony provider.
Lower your rate limits to lower the number of accounts attackers can create using the same IP address.
Consider identity proofing integrations like those available in the Auth0 marketplace.
If you identify a large number of fraudulent users, engage Auth0 support for assistance.

Grayson Schermerhorn and Mathew Woodyard contributed to this research.

Appendix A: Indicators

This is an ongoing investigation, and additional Indicators may be identified as the campaign evolves. Organizations are advised to remain vigilant and implement the recommended mitigation strategies.

Domain
2mails1box.com 300bucks.net blueink.top desumail.com e-boss.xyz e-mail.lol echat.rest electroletter.space emailclub.net energymail.org gogomail.ink gopostal.top guesswho.click homingpigeon.org kakdela.net letters.monster lostspaceship.net	message.rest myhyperspace.org mypost.lol postalbro.com protonbox.pro rocketpost.org sendme.digital shroudedhills.com specialmail.online ultramail.pro whyusoserious.org wirelicker.com writeme.live writemeplz.net

Domain

2mails1box.com
300bucks.net
blueink.top
desumail.com
e-boss.xyz
e-mail.lol
echat.rest
electroletter.space
emailclub.net
energymail.org
gogomail.ink
gopostal.top
guesswho.click
homingpigeon.org
kakdela.net
letters.monster
lostspaceship.net

message.rest
myhyperspace.org
mypost.lol
postalbro.com
protonbox.pro
rocketpost.org
sendme.digital
shroudedhills.com
specialmail.online
ultramail.pro
whyusoserious.org
wirelicker.com
writeme.live
writemeplz.net

Autonomous Systems Number (ASN)
212238 16276 44477 26548 200373 137409 214483 13213 397368

TLS Client JA4 Fingerprints are also available from an unredacted advisory that Okta customers can download at security.okta.com.

The s1ngularity attack: When attackers prompt your AI agents to do their bidding

Brett Winterford — Mon, 06 Oct 2025 16:00:00 +0000

In mid-September, a software supply chain incident - commonly dubbed the "s1ngularity attack" - marked a turning point in adversary use of Artificial Intelligence.

While the initial access vector was familiar - a phishing attack targeting npm package maintainers - the resulting malware was novel. This is one of the first attacks in which local AI agents were weaponized to aid in credential theft.

This technique represents a foreboding escalation in attacker ingenuity, moving beyond simple custom scripts to leverage the problem-solving capabilities of AI tools already available on a target's machine.

I sat down with Paul McCarty, Head of Research at Safety Cybersecurity - who recently published a detailed analysis of the attack - to discuss his findings, including the AI prompts used to search for secrets and bypass guardrails, and how this threat could evolve in the future. Watch the video above, or continue reading for an overview of what we talked about.

The anatomy of a post-install attack

During the attack, malicious updates were pushed to popular npm packages including nx, ultimately resulting in the theft of thousands of developer credentials. A key component of the malware was a post-install script the attacker named telemetry.js.

The main function of this script was to execute immediately upon installation and search the compromised host for sensitive files and secrets. Crucially, the attacker introduced a new discovery method, by checking for the presence of local CLI agents for popular Large Language Models (LLMs) - specifically Claude, Gemini, and AWS Q.

McCarty describes this as a clear evolution of the "living off the land" approach, where attackers abuse pre-installed, trusted tools. Developers often have these CLI agents installed to streamline coding workflows, making them a high-value, readily available target for an attacker.

Living off the local prompts

The malicious telemetry.js script didn't just passively look for files; it used AI agents to do the heavy lifting via a prompt.

Initial check: The script would detect if a supported AI agent (CLI app) was installed and on which platform (the malware primarily targeted Linux and macOS hosts).
The prompt: The malware then executed a specially-crafted prompt through the installed agent. The prompt's core objective was file enumeration: asking the AI to recursively search the host's filesystem and generate a comprehensive array of files that might contain secrets.
Targeted secrets: This wasn't a blind search. The prompt focused on "juicy files", such as .env and .config files, that would commonly hold secrets, such as:
- GitHub and npm tokens
- Cloud platform credentials (e.g., AWS tokens)
- SSH keys

The AI agent's role was to use the vast training data of the LLM and contextual awareness of the target's environment to determine the best locations to search. The AI agent effectively provided the attacker a discovery tool that could dynamically adapt to the target environment.

AI agents are unpredictable, but reliable enough at scale

McCarty's analysis of the attack payload revealed a fascinating glimpse into the attacker's thought process. Multiple successive updates to the poisoned packages reveal at least four different versions of the AI prompt.

This rapid iteration was an active battle against the non-determinism and guardrails inherent to AI applications. The attacker had to continuously experiment to find the perfect prompt that would:

Bypass guardrails: Avoid the agent's built-in safeguards that reject obvious malicious requests or requests to access file systems resources
Maximize results: Generate the most comprehensive list of sensitive file paths
Optimize speed: Narrow the focus to exclude common source code files, speeding up the overall data collection process

This iterative process demonstrates one of the shortcomings of AI tools: users often have to ask the same question multiple times, in different ways, to get closer to a successful outcome. It also highlights a growing risk for defenders: there are no guarantees that AI agents will adhere to guardrails. As McCarty's own testing showed, AI agents sometimes "ignored the guardrails and just went into YOLO mode."

This incident confirms that agentic AI represents a significant new attack surface. When wired up to developer workstations, they can be weaponized as a powerful discovery engine for the harvesting of credentials and other sensitive information.

Threat Intelligence | Blog | Okta

Defending against TeamPCP software supply chain attacks | Threat Intelligence

Executive summary

Background

Modern software development

Don't pull the pull_request_target trigger

TeamPCP

Constant target

Recommendations

Further reading

Device code phishing: it's phishing with dynamite

The device code authorization grant

Device code phishing

Phishing with dynamite

Tycoon 2FA phishing actors disperse, branch into new attacks | Threat Intelligence

The making of Tycoon

Adaptation

AitM: Still prevalent and potent

BreachForums logs reveal anonymizers of choice for shady characters

Underground cantina

Top Autonomous System Names (ASNs)

VPN and Proxy Usage

Top 10 VPN and Proxy Services Used

Top Email Address Domains

Conclusion

Recommendations

LiteLLM supply chain attack: an explainer for identity pros

What is LiteLLM, and what went wrong?

Agent sprawl at play

How Auth0 helps developers secure agentic apps

How Okta helps address agent sprawl

Recommendations

Advanced posture checks

Indicators of Compromise

Disrupting ShieldGuard: a security extension primed to drain crypto wallets

Executive summary

Threat analysis

Malware analysis

Analysis environment

Architecture and evasion techniques

Malicious payloads and data exfiltration

Command & Control (C2) infrastructure

Attribution and linked campaigns

Disruption

Advice for end users

Beware the "too good to be true" trap

Practice safer online browsing

Protect your crypto wallets

Advice for Okta customers

Indicators of Compromise

Vietnam-based cybercrime markets enable account sign-ups at scale

Executive summary

Fuel for fraud

Wanted: fake accounts

All about MMO ("Make Money Online")

Conclusion

Mitigations

Universities exposed to account takeover risk from contract cheating services

Executive Summary

From contract cheating to student extortion

Lure mechanisms: the "academic support" facade

Digital channels

Physical channels

Campaign Objectives

Data collected by threat actors

Risks beyond student extortion

Threat Response

What we're doing

Detections

Recommendations for Okta Customers

Network Indicators

A note on estimate language

The North Korean on your payroll

#1 - Meet "JJ"

Becoming JJ

A happy false-positive

A challenge for verification

#2 "EM" gets hired

The real EM and an identity problem

The DPRK EM