Threat Intelligence | Blog | Okta

Using advanced posture checks as a tooling watchdog

Rafa Bono, Katie Nickels — Tue, 11 Aug 2026 16:00:00 +0000

Adversaries love to make life difficult for defenders. One of the best ways for attackers to operate undetected is to disable security tools on a compromised device.

Sometimes users do the hard work for them. When a frustrated user disables a security service that appears to be getting in the way of getting their work done, it creates the same opportunity for attackers. So do unintentional actions, like a failed update.

Unfortunately, many defenders also fail to check that critical security tools are running, and in doing so create a glaring blind spot. Most organizations rely on periodic compliance sweeps that leave these gaps wide open between audits. Too often an organization only discovers whether security tools were running after a compromise, when it's too late.

That's why we're excited to introduce advanced posture checks to the Okta Verify client for macOS and Windows. This feature transforms every authentication flow into a persistent tooling watchdog. By running an osquery SQL query at the moment an account tries to authenticate, administrators can verify that mandatory security tools are not just deployed, but are also actively running. If the defenses aren't there, the device doesn't get in.

Below, we'll look at how to leverage this feature - but first let's start with why it's important.

The gap that's hiding in plain sight

Most organizations have a well-defined list of tools every managed endpoint is supposed to carry, from EDR agents to MDM devices and beyond. Though the exact set of tools varies from one organization to another, each category of security tool serves a consistent purpose that is crucial to a well-defended environment.

The problem is that just because you deployed something, doesn't mean it's still running. Agents crash and services get disabled - sometimes by users who want to speed up their laptop, and sometimes by malware that knows exactly which process to kill first. A VPN client ships an update that breaks the service, and the team doesn't find out until you notice a pattern in helpdesk tickets weeks later. None of these show up in regular monitoring unless you're specifically looking for process absence, and most teams aren't.

This problem is amplified by the fact that most compliance checks only verify the presence of the security tool once, even if it falls out of compliance later. Advanced posture checks flips this: the check runs at every authentication event, so a tool that stops running at 9am will result in a user being denied at 9:05am.

Defense impairment in the wild

Adversaries know that if they can blind your security operations, they've already achieved a significant goal. These actions are so prevalent that MITRE ATT&CK has an entire tactic for it called Defense Impairment, consisting of 18 different techniques. One of the most prevalent techniques is T1685: Disable or Modify Tools, which is where our tooling watchdog query below focuses.

While adversaries disable many categories of security tools, the use of EDR killers has become commonplace during ransomware intrusions, with operators frequently disabling EDRs prior to encryption. For example, Gentlemen ransomware operators rely on their "GentleKiller" malware to disable telemetry processes like osqueryd.exe. Similarly, Reynolds ransomware uses a Bring Your Own Vulnerable Driver (BYOVD) technique, weaponizing a vulnerable driver to kill local EDR agent processes across a wide range of platforms. By preventing devices with disabled tools from authenticating to your protected resources (apps and data), you can stop these attackers before they successfully encrypt data.

The watchdog pattern

The detection query we are introducing with this post - which you can find in the okta/customer-detections repository - approaches this as a "digital health check" for a user device. Instead of just looking for a single process, the query acts like a scorecard. The query gives the device a point for every mandatory security tool category that is actively running, and the device "passes" only if its total score hits the target. Every security tool category is assigned its own Common Table Expression (CTE) that yields a 1 if a relevant process is currently active, and a 0 if not. The final result aggregates every category, ensuring the check only allows authentication when every mandatory tool is accounted for.

Here is an example of how a device could be evaluated...

Is telemetry being passed? Yes, so the score is 1
Is the device running EDR? Yes, so the score is 1
Is the device running MDM? Yes, so the score is 1
Is the device running DLP? Yes, so the score is 1
Is the device running VPN/ZTNA? No, so the score is 0
Is the device running DNS security? Yes, so the score is 1
Is the device running vulnerability management? Yes, so the score is 1

Scorecard: 6 out of 7 failed! Therefore, the device would not be granted access.

There are seven categories, each covering the major vendors in that space across macOS and Windows:

The remaining five CTEs follow the same pattern for MDM, DLP, VPN/ZTNA, DNS security, and vulnerability management. They all feed into a single scoring step:

Free tokens for sale: How fake signups drive AI fraud

Jeremy Kirk, Mathew Woodyard — Tue, 04 Aug 2026 07:00:00 +0000

Introduction

As AI models have become vastly more capable, these multifunctional tools are being used for a wide range of tasks-from coding and analysis to software testing, research, and vulnerability hunting.

This has given rise to expansive gray and often illegal market offerings for accounts with AI providers. The demand is driven by both cost and restrictions on access. It is being satisfied in a variety of ways, one of which is through fraudulent account registrations, often capitalizing on free trials or credits.

This post will explore how free and discounted AI services are being abused with a view to how fraudulent signups can be controlled in Okta and Auth0 while imposing low friction for legitimate new signups.

Why use the gray market?

There are several reasons why users seek out gray market or illegal services offering AI model access: cost, access, and some degree of anonymity.

Cost: Providers offer discounts between 70-90% off subscription prices. Offerings may be for subscription-based accounts, a certain number of tokens, or a certain number of requests (prompts). With those packages, the allotted number of requests can use an unlimited number of tokens.

Access: Users in China often cannot get direct access to U.S. frontier AI models. Frontier U.S. models are either banned or blocked by China, which has a number of AI regulations, or not offered by providers due to national security and distillation concerns.

In September 2025, Anthropic took aim at the burgeoning gray market by restricting subsidiaries offering services to unsupported regions like China. Nonetheless, the market is thriving and fraudulent registration is one of the reasons. The Chinese-language offerings, which are on messaging platforms, underground forums and indexed in GitHub repos like this detailed one, appear to outnumber and scale much larger than the smaller-time, English-language cybercriminal offerings.

The ChinaTalk blog investigated these Chinese-language gray-market API services, which are referred to as "transfer" or "relay" stations and are advertised on messaging services such as Taobao and Telegram. Vendors have developed sophisticated operations using AI gateways and online uptime monitoring services.

Legitimate AI model service providers are trying to counter fraudulent registration. In April 2026, Anthropic said it will use Persona's ID verification system to verify some new accounts, which involves providing a government-issued ID and a live selfie. To track the proliferation of proxy services catering the Chinese market, Anthropic developed a fingerprinting system to detect account abuse in Asian time zones, although it will be removed as it said it had developed detection methods.

Performance: Sophisticated offerings may use AI API gateways such as LiteLLM or OpenRouter to link to a variety of models from different providers, which helps minimize disruptions if accounts are shut down due to abuse.

Operational security: If the AI model proxy service is not forwarding the true origin IP, it acts as a way for illicit customers to hide their identity. If the illicit provider is proxying with sophistication, the customer may be able to evade detection.

Payment privacy: These services accept cryptocurrency, which may offer a higher degree of privacy than other payment options. Many providers do not require personal information to create accounts.

Customer service: Illicit AI vendors may provide customer support if an account is shut down or service is disrupted.

However, there are disadvantages:

Operational security: While the gray market offers some operational security over direct purchases, it cuts both ways. When services are configured as a gateway proxy, the service provider has full visibility into prompts, as those prompts must be forwarded to a model. This is a privacy concern, as the service provider could accidentally leak or sell data.

Disruption: Model providers may unexpectedly cut off accounts as controls to prevent fraudulent accounts are tightened, disrupting complex workflows.

Bait and switch: Service providers may advertise access to a frontier-model but deliver a less expensive and less capable model, which may not be evident at purchase.

Prompts for cash: Gray market service providers have an incentive to act as an adversary in the middle. Even if it were possible to forward input and output with zero knowledge, a gray market service provider would lose the ability to gather telemetry on their users and the ability to distill frontier models. This source of prompts is cited by ChinaTalk as a key source of additional revenue.

Cheaper tokens

Okta Threat Intelligence found more than a half-dozen services advertisements via underground forums and messaging platforms, which represents a fraction of these services. One such site is Poison Claude:

Advertisements for Poison Claude explain how the service can offer the cheap tokens: by taking advantage of free bonus credits, such as the US$100 bonus credit on AWS for Bedrock accounts. The service plainly states on its website that: "We add those accounts to our pool, your request is routed to a specific account under the hood (you don't see this) and you get charged 5-15% of the official per-token price depending on the model."

The flat-fee monthly plans available on Poison Claude are possible due to "the gap between what the upstream providers charge us under bonus credit and what we charge you." The models offered are Opus 4.8, Opus 4.7, Opus 4.6, and Sonnet 4.6.

As of July 3, 2026, Amazon offered US$100 in AWS credits that could be applied to Bedrock and other AI services, with another $100 available based on completing certain account activity. It's probable that access to Bedrock has been enabled through fraudulent registration.

Poison Claude accepts payment in cryptocurrencies including USD Tether, USD Coin, ethereum, litecoin, and bitcoin cryptocurrency. Once paid, a customer is provisioned an API key for an Anthropic-compatible API. Users are then instructed to set these environment variables so that their installation of Claude Code uses the Poison Claude API rather than the legitimate one.

Prompts are passed from Poison Claude's API to Anthropic, with the answers returned to the customer.

How popular is Poison Claude? A configuration mistake provides a clue. Poison Claude's operators exposed an API route. Running a GET command on /api/status showed the number of total and active users:

--> HTTP 200: {status: operational, total_users: 881, active_users: 872}

The main domain for Poison Claude, poison-claude.bitsender[.]top was hosted behind Cloudflare's CDN, obscuring its originating IP address. However, the site's operators forgot to include the endpoint, api.claudeopus[.]shop, which was hosted on Hostinger in Mumbai (the exposure has been fixed).

Startup credit

Ecomagent.in is another service offering unlimited tokens via its own endpoint for subscriptions below market price. On offer is access to Opus 4.8, Opus 4.6, Sonnet 4.6, and GPT Codex 5.5 via its custom API endpoint.

Ecomagent shows on its website an example cURL request to its own API with the phrase "Hello" and then the expected output as a .json object that contains the model's response: ""Hello! How are you doing today? Is there something I can help you with?"

The response contained metadata about the prompt and token usage. The output contains a field labeled id: "msg_vrtx_01XNdd65BAkT82dLgksZGWD3", which is indicative of a response coming from Google's Vertex platform, now called the Gemini Agent Enterprise Platform.

Like Amazon, Google Cloud offers credit for new accounts, although users must register a billing payment card. Google also offers up to $350,000 in credits to AI startups that plan to use the Gemini Enterprise Agent Platform or its Gemini model. A test of Ecomagent showed no responses that contained an id field with msg_vrtx.

Ecomagent lists a Telegram username for support on the website. Ecomagent claims to be able to offer discounted Anthropic models due to its use of startup credit. Like many AI companies, Anthropic also offers free credits to startups, ranging from between US $25,000 up to $100,000. Startups must apply for these credits, and presumably, this usage would violate the terms and conditions.

Like Poison Claude, Ecomagent also exposed an unauthenticated API route showing the "total_users" and "active_users" of the service, both numbering under 1,000.

Case study: AI video service

This year has been the gold rush for AI, with startups and established companies fiercely competing for business. Many AI services offer free trials or free access.

Okta Threat Intelligence recently observed an AI video company with a high rate of brute-force fraudulent signups that likely came from bots. This vendor offers free trial access to its service.

Between June 1, 2023, and July 1, 2026, logs show over 105,000 brute force attempts to sign up from 251 distinct IPs likely connected to bots.

Based on our data, we can say it is highly probable that China-based users are circumventing regional restrictions. Some of the top VPN providers, like QuickQ VPN, are commonly used by Chinese internet users, and the top email domain was qq.com, which is a popular email service in China.

That aside, the free trial enticed opportunists globally. As seen on the right-hand side of the graph below, the overall signup list contains disposable domains like dakaka.org, emailinbo.live, and ratixq.com, pointing to highly probable synthetic identity creation at scale.

There are also indications of scammers getting in on the free trial action. Access to this particular service was advertised on cybercriminal forums. One seller contacted via Telegram claimed to have both API keys and credentials, with the credential offering allowing "full access" to the service.

A second vendor monetized fraudulent sign-ups with the same service. For US$40 in the cryptocurrency Tether, the vendor offered a "created" account. The vendor claimed this was better than a hacked account-one in which a legitimate user's credentials had been stolen-since a hacked account was more likely to get shut down.

The seller then provided a username and a password, claiming that once the trial period was over the account would switch to a "paid membership." In fact, this was a ruse. The vendor, likely based in Turkey, had a history of defrauding customers and was banned from the notorious BreachForums cybercriminal forum.

How Okta Threat Intelligence is disrupting them

Prior to publication, Okta Threat Intelligence notified Cloudflare and Anthropic of the infrastructure and abuse patterns documented in this post. Cloudflare was alerted to Poison Claude's use of its CDN to obscure the service's origin, and Cloudflare subsequently placed a phishing warning in front of the site.

As of July 16, 2026, Cloudflare has declined to take action on claudeopus[.]shop, which uses Cloudflare as a CDN and Cloudflare Turnstile for bot protection. We also notified Amazon Web Services and Google Cloud of the apparent abuse of their startup credit programs by Ecomagent and similar services.

The relevant domains and API endpoints have been archived and submitted to abuse reporting channels. We continue to notify AI providers of signup fraud attacks against their Auth0 tenants and Okta organizations. We are sharing these findings publicly to raise awareness for CIAM administrators and AI providers alike, and will continue to monitor for new fraudulent services as the gray market for AI access matures.

Conclusion

Bot activity is rising across the internet, particularly with the increasing deployments of AI agents. Those running bot networks also have more choice than ever with which to counter bot detection methods, such as residential proxies. Residential proxies allow malicious traffic to come from benign consumer IP connections with often little or no history of malicious activity, making it risky to block.

While a certain amount of fraudulent registration is inevitable and the downside of offering free trials, it can be countered. In the recommendations section are tools and sources for Okta and Auth0 CIAM controls that allow administrators to strike a sensible balance with signups.

Countering signup fraud

Attackers create fake accounts for a range of reasons. As illustrated before, this includes exploiting new-user promotions, but there are many others: aging accounts to appear legitimate, overwhelming systems to block real users, fraudulent social engineering schemes, enumerating valid usernames as a stepping stone to credential stuffing or phishing and spam.

Anything short of adopting more secure factors on signup is insufficient. Auth0 and Okta's native passkey support raises the cost of account creation to a level automated attackers cannot absorb: a hardware-bound, phishing-resistant credential that cannot be farmed, shared, or bulk-provisioned. Okta Threat Intelligence has not yet observed passkeys used in any signup fraud campaign we track. AI providers should treat passkey-required signup not as a UX trade-off but as a fraud control: it will not stop a determined human from creating an account, but it makes the industrialized bot abuse feeding services like Poison Claude economically untenable.

Static API keys are the currency of the gray market. Poison Claude's business model is built on aggregating and reselling them through their centralized provider. The appeal of static keys is convenience, but on modern platforms that convenience gap has largely closed.

Auth0 and Okta's application model replaces a static key with the OAuth 2.0 client credentials flow: the machine exchanges a client ID and secret for a short-lived access token, scoped to the permissions it needs. A leaked token expires on a configurable, short schedule by default. A leaked static key does not. Providers should issue no credential with an indefinite lifetime: any token that can be copied into a file and shared is eventually a gray-market product.

Playbooks for countering signup fraud are available for Auth0. Okta Customer Identity administrators should implement controls like bot protection, progressive profiling and registration policies, Enhanced Dynamic Network Zones, and Identity Threat Protection (ITP) to prevent fraudulent signups.

Behind the scenes of a vishing operation

Mon, 27 Jul 2026 16:00:00 +0000

Executive Summary

Okta Threat Intelligence recently obtained material from a sensitive source that provides an inside view of Work Panel, an operator console used by threat actors running vishing campaigns that target customers of multiple identity providers, including Okta.

Work Panel is a multi-tenant platform that packages everything an operator needs to run a vishing-driven account takeover operation. Registering a new phishing domain, cloning a target brand, and standing up a new isolated phishing site are each one-button operations. New campaigns can be launched in minutes.

The platform is designed to be sold to multiple operators. Each operator brings their own integrations (registrar account, content-delivery keys, B2B contact-data API key, Telegram bot, SIP provider) and their own callers. Multiple intrusion clusters can run their own deployments in parallel.

Our analysis of Work Panel offers unique insights into the day-to-day operations of vishing actors. Infrastructure owners, campaign managers and outsourced callers each sign in to Work Panel with distinct roles, exposing in the process a cybercrime ecosystem in which the social engineer on the call is increasingly treated as interchangeable labor. By design, the human callers conducting vishing campaigns cannot view or access the credentials they help their 'manager' to capture. That insider-risk control gives operators exclusive access to the spoils of a campaign and significant leverage over the individuals that agree to make the calls on their behalf.

The only persistent components are the platform, the infrastructure pipelines, and the recruitment networks that feed it.

Threat Analysis

This advisory walks through what a single vishing operation looks like from the operator side using Work Panel, an active operator console used by at least one of the intrusion clusters Okta has been tracking as O-UNC-045 aka CORDIAL SPIDER.

Work Panel is not a single phishing page or a script. It is a full web application designed to run a vishing-driven account takeover business. The console organizes the work into multiple sections covering target recon, voice-call routing, brand cloning, infrastructure provisioning, live session management, captured-credential review, and an audit log. Different roles see different tabs, and the access boundary is enforced on the server rather than hidden in the client.

This is a meaningful step away from the phishing kit pattern that dominated earlier credential-theft operations. A traditional phishing kit ships as a folder of HTML and PHP files that a single operator deploys, watches, and manages alone. Work Panel ships as a service. Operators deploy it once and then onboard a workforce.

IAM: Three roles, three workspaces

The operator workforce in Work Panel is structured around three server-enforced roles: caller, manager, and admin.

Each role uses a different part of the panel. The platform's author is explicit in their own help guide that the split is enforced server-side and not just hidden in the UI.

The caller role

The caller, who is hired by someone who wants to run a campaign with Work Panel, is the person who actually dials the targeted user.

The caller's workspace is the most restricted of the three roles. The caller has access to a target contact lookup too, a SIP credentials tab and a limited mailer for sending pretexting emails. The SIP credentials tab displays the username, password, server, and domain assigned to them by the admin for use in an external softphone.

The caller does not see the live session queue nor the credentials they help capture. They also have no visibility into the operational infrastructure or the targets assigned to any other caller.

The manager role

The manager supervises a team of callers.

The manager workspace includes additional features including a live target queue, a captured-credential review panel and a workforce administration tab. That admin tab lets them onboard or remove callers, generate one-time registration codes for new hires, assign callers to specific phishing sites, and monitor the activity log.

A manager can only manage the callers they personally onboarded or that the admin explicitly assigned to them.

The admin role

The admin owns the platform and has likely purchased it from the platform's author.

In addition to everything the manager sees, the admin manages the infrastructure pipeline (domain registration, content delivery, DNS), rotates the platform's API keys, holds a kill switch, and configures their personal Telegram notification channel.

There is typically one admin per deployment.

Caller operations

The caller workspace is a tightly scoped tool for one job: get a targeted user on the phone and keep them on the page until the manager confirms the credentials are captured.

A caller starts in the Company Lookup tab. The tab is a thin wrapper around RocketReach, a commercial B2B contact-data service. The caller types a target company's email domain and the tool returns a list of employees with their corporate email addresses, direct phone numbers, job titles, and links to their LinkedIn profiles. The caller picks a target by title, typically someone whose role makes a helpdesk-themed pretext plausible.

This recon step is the bridge between the technical infrastructure and the human social engineering that follows. It is also why these calls feel personalized. By the time the phone rings, the caller already knows the target's job title, their direct phone number, and often their manager's name. The data is not stolen. It is purchased through legitimate channels, then weaponized inside Work Panel.

The caller opens the SIP tab to retrieve their assigned SIP credentials, username, password, server and domain, and loads them into an external softphone application to place the call. Work Panel itself has no calling capability. The SIP tab is only used to pass credentials to the caller for a SIP service. Each caller's credentials are unique, assigned by the admin and visible only to that caller.

User credentials captured by the phishing kit are not displayed to the caller's screen. When the target lands on the phishing page and submits their password and MFA approval, those values flow to the manager's Sessions tab and are not provided to the caller role. The caller's job, in the kit author's own framing, is "Company Lookup and SIP." Page pushes and credential handling are explicitly described as manager-only work.

Manager operations

While the caller is on the phone with a targeted user, the manager is watching a live target queue.

Each row in the queue represents a target's browser that has landed on a phishing page. The row shows a status (live, idle, or stalled, based on how recently the browser pinged the phishing page), a country flag, an identifier (the first email or username the target typed), and the page the browser is currently displaying.

The manager's primary control is a "Push" button on each row. Push opens a small menu of phishing-flow pages the manager can send the target's browser to. The list of pages is fixed by the kit, so the manager cannot send a target to an arbitrary URL. The fixed menu includes the typical authentication challenge pages (push notification, number matching, authenticator app code, a support-ticket completion screen) for each cloned brand. The manager advances the target through the flow page by page, in real time, while the caller talks the target through each step on the phone.

When the target submits their credentials, the captured values appear in a session detail panel next to the queue. The panel shows the username, password, and any MFA codes intercepted. Each value has a copy button, and every copy is logged. If the manager's deployment has a Telegram bot configured, a notification with the captured material lands in their personal Telegram channel within seconds.

The session detail panel also shows a timeline of every page the manager pushed and a tap-code field for the number-matching MFA flow. The mechanics of the number-matching bypass are covered in the threat advisory "Vishing Operators Synchronize Phishing Sites to their Script for Hybrid Social Engineering Attacks".

Admin operations

The admin's workspace is essentially a self-service infrastructure console. Where a traditional phishing kit operator would manually register a domain, configure DNS, set up a web server, deploy the kit, and configure TLS, Work Panel does all of that from buttons in the admin tab.

The flow is automated end to end. The admin types a domain name into the 'Buy Domain' form; the platform checks availability against NiceNIC, charges the operator's registrar account, registers the domain, and spins up a Cloudflare DNS zone. On the server side, the platform provides a dedicated Caddy reverse-proxy block per phishing site. Caddy is a lightweight web server that handles HTTPS termination and routes incoming traffic to the appropriate backend.

Each site also receives a PM2 process and a configuration file; PM2 is a Node.js process manager that runs the site as a supervised background service, restarting it automatically if it crashes.

Bunny CDN handles the click-redirect hosts used in the email channel. All three sets of API credentials, NiceNIC, Cloudflare, and Bunny CDN, are stored server-side and never exposed in the client. A new phishing site for a new target is ready within minutes of domain registration. Operators can also import a Cloudflare zone for a domain registered elsewhere.

With the domain live, the admin clicks 'Add Panel', selects a sign-in flow template (Okta, Microsoft 365, or Salesforce) and supplies a clone source. The template selection is permanent: it determines which paths the phishing site renders (/sign-in/* for Okta, /common/oauth2/v2.0/* for Microsoft, /community/* for Salesforce), and cannot be changed after creation.

When targeting Okta, pasting any sign-in URL automatically retrieves the target organization's logo, favicon, primary color, company name, and tenant domain. When targeting Microsoft, pasting any corporate email address pulls the tenant's logo, header background, welcome text, and brand colors via Microsoft's own tenant-discovery endpoints. Salesforce panels use the /community/* paths but have no equivalent automated extraction step.

Each panel runs on its own subdomain with its own process, configuration, and web server block, entirely independent of any other active panel.

The admin can also restrict which device operating systems are permitted at the gate; traffic from disallowed platforms receives an error page rather than the sign-in flow.

The admin tab also exposes the operational controls that matter most for an operator who expects to be tracked. There is a button to rotate the platform's content-delivery API key without redeploying. There is a self-destruct endpoint that tears down every phishing site, every supporting process, and every DNS record in a single action. There is an activity log that captures every action every other operator on the platform has taken, so the admin can audit the work of their hired labor.

There is also a Telegram-notification configuration that the admin populates with their own bot token and chat ID. No operator credentials of any kind are baked into the platform.

The platform also supports a second attack channel alongside the vishing calls. Operators can compose branded phishing emails directly in the panel using a built-in template editor. Templates are written with {{variable}} placeholders, such as company name, Okta domain, or primary color, that are automatically filled in from the brand profile the operator cloned when setting up the phishing site.

An operator who has already cloned a target's sign-in page can send a phishing email to the target's employees with no further setup. Outbound mail is sent through operator-configured SMTP servers, each tied to a sender domain provisioned through the same infrastructure pipeline. All links in outbound email are wrapped through Bunny CDN redirect hosts, providing click-tracking and a layer of separation between the email channel and the phishing panel.

Commentary

Work Panel is a complete, cybercrime-as-a-service software package. It accommodates the key requirements to execute successful phishing attacks: research, infrastructure, and operational security.

Insider risk is engineered out. The separation of duties is not incidental. It addresses a problem intrinsic to running a criminal operation with hired labor. Callers are sourced from underground channels, paid per successful capture, and carry no institutional loyalty. Without access to the credential archive, a caller who wants to act for personal gain by selling captured material to a competing operator, for example, has nothing to sell. The most valuable output of the operation is locked in exclusively with those at the top of the hierarchy.
Voice phishing callers are easily replaced. Callers do not have access to the operation's most valuable asset (stolen credentials), so they do not need to be trusted. They can be recruited through public underground channels with a brief test, paid per successful capture, and replaced easily. Recruitment ads for fluent English-speaking callers offering large financial returns have been observed on Telegram and tied to operators using this kit (see "Vishing Operators Synchronize Phishing Sites to their Script for Hybrid Social Engineering Attacks").
Operational resilience is built in. Every phishing site runs in its own process under its own configuration. The compromise of one site does not cascade to the others. API keys for every external service are rotatable from the panel. The self-destruct endpoint provides a one-click exit if the operator suspects their hosting environment has been seized.
The platform is multi-tenant by construction. Every operator brings their own integrations (their own registrar account, their own content-delivery keys, their own B2B contact-data API key, their own Telegram bot, their own SIP provider, their own callers). This enables the kit author to sell access to many independent operators at once without holding the credentials for any of those operators.
Operator oversight is built in. From the Live View tab, an admin can select any online caller and watch a real-time stream of their console, exactly as it appears on the caller's own screen, embedded directly in the panel. The caller is never told they are being watched: the kit author's states plainly that the window can simply be closed to stop. The only data withheld from the admin's view is anything the caller types into a password field. Every other input, message, and screen the caller sees while working is visible. Every action by every operator, credential copies, bans, role changes, code issuances, settings edits, is recorded in an activity log, auditable and exportable at any time.
The kit treats its own workforce as an interchangeable and monitored labor pool. The platform supports that labor model by stripping callers of access to anything sensitive. The result is an operation that is harder to disrupt by removing any single person, harder to follow by tracking any single domain, and easier to rebuild after a takedown than the phishing operations that came before.

What Work Panel teaches us about modern vishing operations

We assess it is likely that Work Panel was "vibe-coded" - built with substantial AI assistance. The console's design system, which includes pre-built cards, toasts, motion effects on nearly every transition, is consistent with the default output of AI coding tools when they are asked to scaffold a dashboard. This would lower the bar for one person to ship and maintain a SaaS-grade platform for criminal customers.

Treating Work Panel as just another phishing platform understates the development. The features it ships with are the features a SaaS product team would build if they were building a CRM for vishing crews. Workflow specialization, role-based access control, infrastructure automation, third-party integrations, audit logging, rotation of secrets, and a tested exit procedure are all standard SaaS engineering practices. They are now standard on the offensive side too.

The intrusion clusters using these platforms are not single individuals. They are small teams, organised around clear roles, with at least one role (the caller) treated as commodity labor. Recruitment for that role is happening in public underground channels.

This split between operators who own the infrastructure and callers who supply only their voice is not unique to Work Panel. It has become a repeating pattern in organized vishing: multiple independent actors have adopted the same model, advertising openly for hired callers while retaining the platform, the target data, and the credential capture for themselves. Work Panel formalizes what was previously an informal arrangement, but the underlying labor model was already consolidating across the market.

The most important practical implication of this organizational maturity is that the social engineering the targeted user experiences has been engineered to be as convincing and as resilient as possible. The credential-capture pipeline that supports that experience is increasingly automated.

The defensive controls that work against this kind of operation (see table below) are the same ones that worked against earlier credential-phishing campaigns. What changes with Work Panel is the timeline. New campaigns can be stood up faster, new brands cloned in minutes, and disrupted infrastructure rebuilt in hours.

Recommendations

ATT&CK

Tactic

Control Recommendation

T1566

Phishing

Enroll users in strong authenticators such as Okta FastPass, passkeys or smart cards and enforce phishing resistance in policy.

Establish, communicate and evangelise methods of verifying the identity of helpdesk personnel when they contact users.

T1078

Phishing

Deny requests from locations where your organization does not offer services. Okta network zones allow administrators to set policies that deny access to Okta-protected applications by geolocation (country), ASN, IP, or other criteria.

T1078

Valid Accounts
(Initial Access)

Okta authentication policies can 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.

T1078

Valid Accounts
(Initial Access)

Notify users of every authenticator (factor) lifecycle event using end user notifications.

T1098

Account Manipulation (Device Registration)

Apply Okta Account Management Policies that constrain the ability to add or modify authenticators based on network context, device management status and enrolled authenticators.

Specific guidance is provided in the following blog post:
https://www.okta.com/en-au/blog/threat-intelligence/intrusion-actors-self-serve-their-way-into-accounts/

How to stop attackers from self-serving their way into accounts

Brett Winterford — Thu, 09 Jul 2026 16:00:00 +0000

Executive Summary

Over the last 12 months, Okta Threat Intelligence has observed a growing number of attacks in which users are tricked into approving attacker-initiated MFA enrollments and password resets.

We have observed numerous related clusters of activity in which threat actors have tested, iterated on, and scaled these social engineering attacks.

One in five of the proactive notifications Okta sent to customers over the last month related to phishing domains that included the string "passkey". The most recent campaign observed (O-UNC-066) used a passkey enrollment pretext to gain persistent access to Entra accounts.

Strengthening MFA enrollment and account recovery now needs to be a priority for every identity team, irrespective of platform or use case.

Threat Analysis

Until 2025, the largest share of social engineering activity we observed was impersonating IT support and other helpdesk staff to trick users into entering their password and OTP on attacker-controlled phishing sites.

This category of credential phishing is rendered ineffective when organizations require the use of phishing resistant authenticators in policy. Under phishing resistant policy conditions, even when a user is tricked into visiting an attacker-controlled site, the user is unable to share their access credentials.

Several clusters of threat activity have since adapted to their target's adoption of phishing resistance by using methods of attack that bypass the need to steal and replay a user's credentials.

The list of threat activity clusters below, presented chronologically from oldest to most recent, highlights some of these tactics.

Threat Actor	Targeted Process	TTPs
O-UNC-025	Enrollment (passkey enrollment)	Attacker impersonates the security team of the targeted organization to drive users to a phishing page that encourages them to set up a passkey.
O-UNC-028	Recovery (password reset)	Attacker impersonates the employer's IT helpdesk, lures targets to a phishing page and/or to authorize an attacker-controlled application.
O-UNC-045	Enrollment (passkey or authenticator app enrollment)	Attacker impersonates the employer's IT helpdesk in voice calls to drive targets to credential phishing sites.
O-UNC-053	Recovery (password reset)	Attacker impersonates the employer's IT helpdesk, and uses urgency around the need for a password reset as a pretext.
O-UNC-066	Enrollment (passkey enrollment)	Attacker impersonates the employer's IT team in voice calls to drive targets to credential phishing sites, uses stolen credentials to enroll an attacker-controlled passkey in the user's account.
O-UNC-067	Recovery (password reset)	Attacker simultaneously triggers the "forgot password" flow while on the call, socially engineers the user into approving the reset

Notably, we have yet to observe the threat actor Okta tracks as O-UNC-067 using credential phishing kits in order to take over accounts.

This intrusion actor, active since at least June 2026, selectively targets organizations configured to allow self-service password reset (SSPR).

The threat actor first performs reconnaissance on targets to assess whether a link to trigger a password reset is accessible, and to determine what MFA challenges apply to verify the user's identity when this password reset is triggered. If a SSPR option is enabled and the user is able to verify their identity during that flow using MFA factors that are not phishing resistant, the attacker calls their target while simultaneously triggering the password reset flow.

Breaking down the account recovery process

Minimum viable defense

Irrespective of whether a social engineering campaign targets authenticator enrollment (e.g., O-UNC-066) or targets authenticator recovery (e.g., O-UNC-067), the success or failure of the attack hinges on the target's org-level account management policies.

In the weakest account management configuration:

A password reset link is available on a public sign-in page
MFA enrollment policies allow verification of the user's identity via any MFA factor
MFA enrollment policies allow verification from any IP address

This configuration may be appropriate for some customer identity use cases, but less so for workforce customers. An attacker that has engaged a targeted user on the phone can trigger the password reset from their device while convincing the user to share an OTP or accept a push request to approve the reset event.

Okta administrators can very easily add friction directly in the MFA enrollment policy by:

Requiring additional verification (beyond a single factor challenge) to initiate the reset, and
Restricting the ability to use self-service features to trusted IP ranges.

This adds friction that prevents opportunistic attacks, but would not withstand a determined adversary. A social engineering actor that triggers the self-service event is in a position to select from a list of available verification challenges during recovery, and will always choose the weakest, most "phishable" method of authentication.

That's why every Okta customer should be taking a close look at Okta account management policies.

Applying phishing resistance to authenticator enrollment

Okta account management policies (AMPs) were originally introduced to support the authenticator lifecycle requirements of organizations that use passwordless authentication. Increasingly, these policies should also be viewed as a configuration tool that protects all authenticator enrollment and recovery flows from social engineering attacks.

AMPs offer administrators the same rich set of policy constraints to account recovery that were previously only available to authentication. AMPs can be used to require verification using phishing resistant factors, managed devices, trusted networks or a range of other criteria, effectively applying "zero trust" to the account recovery process.

Okta Threat Intelligence recommends the use of Okta account management policies to apply phishing resistance to authenticator enrollment and recovery. AMPs can require a user to verify their identity using a phishing resistant authenticator before they add or modify an authenticator.

In the strongest account management configuration available, user accounts are bootstrapped using pre-registered physical security keys, and the account management policy always requires that the user verifies their identity using a phishing resistant factor before they can add or modify an authenticator. This neutralizes attacks on both authenticator enrollment and recovery. Where (rare) edge cases emerge, Okta integrates with identity verification services that require a user to provide a government-issued ID and satisfy a liveness check to initiate recovery.

The next strongest approach is to use Okta AMPs, groups and event hooks to gradually raise the enrollment assurance bar for workforce users that are not already enrolled in a sufficient number of phishing resistant authenticators.

Under such a scenario, the top (first evaluated) AMP rule might allow a user to add or modify a factor if the request comes from a managed device and the user satisfies a phishing-resistant MFA challenge. The aim should be for all users to progressively be added to the group in scope for this rule and subsequently be constrained to only using phishing resistant factors during factor lifecycle events. Users that trigger policy rules beneath it should be prioritized for migration.

The next rule might constrain a user in whatever way possible until the user has enrolled in a sufficient number of phishing resistant authenticators. Users may be required to satisfy an Identity Verification (IdV) challenge, for example, or be temporarily allowed to verify their identity using weaker authenticators for their first few days of onboarding if they enroll from a trusted network. Event hooks or Okta Workflows can also be used to automatically advance users into groups with stronger assurance requirements as they meet the necessary criteria.

Always remember to add a catch-all deny as the final (bottom) rule in any policy, to prevent any unintended access scenarios.

Applying phishing resistance to authenticator recovery

The key to phishing resistant recovery is to enroll users in a sufficient number of phishing resistant authenticators to account for any loss or disruption of a single device.

One of the greatest strengths of the Okta Verify client is that there is zero marginal cost for a user to enroll multiple devices in their Okta Verify account. A user can enroll from their managed laptop and smartphone, for example.

When every workforce user is enrolled in multiple phishing resistant factors (Okta Verify installs) across more than one device, the number of account recovery events that require the helpdesk falls considerably. If a user loses a device or if the device is unresponsive, they will still have strong, phishing-resistant authenticators enrolled on a second device (e.g., smartphone vs laptop) or via an external security key which they can use to enroll a new or replacement device.

Subsequently there is no need to include a "forgot password" link on the sign-in page, and there is no need to offer weaker account management policies.

Indicators

Indicators associated with the clusters of activity discussed above are all available to the security contacts of Okta customers at:
https://security.okta.com/?product=oktathreatintelligence

Recommendations

ATT&CK technique	Tactic	Control
T1590 / T1591	Reconnaissance	Restrict recovery operations for workforce users to behind authenticated user settings. If a workforce organization is configured to support self-service recovery (the "forgot password" flow), consider restricting the IP range from which the sign-in page can be accessed to a known or trusted network using Okta network zones.
T1583 / T1584	Resource Development	Deny requests from known anonymizing services and proxies using enhanced dynamic zones.
T1566 / T1598	Phishing / Vishing	Enroll users in strong authenticators such as Okta FastPass, passkeys or smart cards and enforce phishing resistance in policy. Establish, communicate and evangelise methods of verifying the identity of helpdesk personnel when they contact users. Apply Okta account management policies that constrain the ability to modify authenticators. Apply temporary access codes as a preferred method for recovering access after identity verification.
T1078	Valid Accounts (Initial Access)	Okta authentication policies can 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.
T1621	MFA Request Generation	Enroll users in strong authenticators such as Okta FastPass, FIDO2 WebAuthn, and smart cards and enforce phishing resistance in policy.
T1098.005	Account Manipulation - Device Registration	Apply Okta account management policies that constrain the ability to modify authenticators.

Nick Connolly contributed to this article.

Vishing actors target Entra passkey enrollment

Sat, 04 Jul 2026 16:00:00 +0000

Executive Summary

Since April 2026, a threat actor tracked as O-UNC-066 that operates a DLS site with the name Pink (reported as "CL-CRI-1147" by Palo Alto Networks Unit 42) has deployed a panel-controlled phishing kit targeting the passkey enrollment process for Microsoft 365 customers.

Okta has observed the targeting of enterprise organizations across the food and beverage, technology, healthcare, automotive, construction, and aviation industries by this cluster of activity. The primary motivation of the threat actors is data extortion.

The threat actor registers domains that incorporate the word passkey as part of a voice-enabled phishing ("vishing") scheme. The threat actor then calls targeted users on the phone in an attempt to persuade them that they need to register a new passkey.

Users are directed to a phishing kit that closely mimics the Microsoft passkey enrollment process. It appears engineered to convince a targeted user they are in the process of enrolling a passkey with Microsoft, while the threat actor simultaneously registers their own passkey in the targeted user's Microsoft account.

This pretext is well-timed - as of May 2026, Microsoft administrators have been able to create passkey registration campaigns that remind or "nudge" users to enrol in passkeys at sign-in, and in some circumstances these nudges are on by default.

Threat actors have used this well-intentioned security upgrade as a pretext for abusing the enrolment process to further their objectives.

Our analysis of the phishing kit revealed that it does not attempt to handle federation to third-party Identity Providers such as Okta. Subsequently, we have not observed the compromise of Microsoft accounts directly.

We have nonethless published advice in a separate blog post on how to apply phishing resistance to authenticator enrollment and recovery.

Threat Analysis

In the threat activity we observed, the threat actor creates per-target subdomains that mimic Microsoft Entra ID login pages. The pages are customized using each victim organization's legitimate branding. Generic Microsoft styling is loaded from Microsoft's Content Delivery Network, while the branding elements relevant to each victim organization (logo and background) is pre-staged per subdomain as part of the configuration for any given target and served from the backend of the phishing kit.

The kit is not a transparent Adversary-in-the-Middle (AitM) proxy, one of the most frequently seen types of phishing kits designed to collect credentials, MFA tokens and session tokens. It is an operator-controlled PHP panel in which a threat actor steers victims through various stages of authentication in close to real-time using a 1-second heartbeat polling mechanism. The operator can use the kit to adapt the user experience to each victim's MFA requirements (TOTP, push notification with number matching, SMS OTP) during the session. This operational design is consistent with the vishing tradecraft documented in Okta's November 2025 public blog post "Phishing kits adapt to the script of callers." The caller can control and adjust in real time what phishing pages and notifications a targeted user sees.

It is likely that the threat actor uses the kit to takeover the user account and trick the user into approving an attacker-initiated registration of a passkey.

Okta Threat Intelligence used code derived from the phishing kit to recreate the following flow, which closely resembles the passkey registration process for Microsoft Entra.

The first page of the phishing kit (/gate) reveals a page loading icon while the phishing kit performs anti-analysis checks. The second page (/identify) requests a username. The phishing kit did not redirect to a federated Identity Provider at the time of our analysis.

The next page (/password) challenges the user for a password. The captured credentials are sent in a POST request with a timestamp and Id to an operator panel at /backend.php.

Our assumption is that a phishing kit operator (which may be a different individual to the caller on the phone) captures the credentials of the targeted user within a few seconds and enters them at the legitimate Microsoft sign-in page for the targeted tenant.

The targeted user then sees a (/processing) page that presents another loading screen while the phishing kit awaits the operator's next instruction. Our assumption is that this small delay is required for a threat actor to authenticate to the user's legitimate Microsoft account using the stolen credentials, to observe what MFA challenges are presented, and select the next page of the phishing kit to present to the user.

next page of the phishing kit to present to the user.

If the operator chooses or is forced to complete an SMS OTP challenge, the user is directed to a page called /submit-otp. The captured OTP is sent in a POST request to the operator panel at /backend.php.
If the operator chooses or is forced to complete a TOTP challenge, the user is directed to a page called /submit-authenticator. The captured OTP is sent in a POST request to the operator panel at /backend.php.
If the operator chooses or is forced to complete a Push MFA challenge, the user is directed to a page called /approve-authenticator (see image below) and asked to enter the number supplied by the operator into their authenticator app.

At this stage of an attack, the user has been tricked over the phone into approving the attacker's access to their Microsoft 365 account.

In keeping with the passkey pretext, threat actors can then direct users to the /passkey/register page, which asks the user to create a passkey.

The phishing kit appears to prey on lack of user familiarity with passkey authentication. In a real passkey registration ceremony, the user might expect a system dialog to register a passkey on their device. The passkey pages in this phishing kit appear to mimic this process without registering a passkey.

At the /passkey page, the targeted user is presented with a Microsoft-branded page that encourages the user to "save your recovery key" from an attacker-controlled list of BIP-39 phrases. This closely resembles the methods used in some cryptocurrency applications to generate memorable seed phrases.

A subsequent /passkey/check page asks the user to verify the final word used in the seed phrase.

We are not aware of any direct applicability of BIP-39 seed phrases to Microsoft Entra or its passkey registration process. An attacker that has already gained unauthorized access to a user account can create their own recovery codes using a process that does not require any input from the real account holder.

It is likely that these passkey-themed pages are available to the phishing kit operator as a sleight of hand. It is a distraction to keep a user occupied on a task while the threat actor enrolls their own passkey in the legitimate Microsoft user account.

The /done page confirms that a passkey registration was successful. An unsuspecting user that does not fully understand how a passkey is enrolled may genuinely believe that they registered one with Microsoft simply by completing these otherwise meaningless tasks.

The operator can choose when to push the /done page to the user. At minimum it helps the phishing operation maintain the original pretext. Any time a user enrolls a passkey with Microsoft, the owner of the compromised account receives a legitimate Microsoft email to notify them that a new passkey had been registered in their account. During an attack, the passkey was actually enrolled by the threat actor directly with Microsoft, and the threat actor is in a position to name the passkey with something the targeted user would view as benign (perhaps even borrowing from the seed phrase selected by the targeted user). The passkey enrollment setup the targeted user experienced on the phishing site, by contrast, is likely to only exist to trick the user into thinking the attacker's enrollment was their own.

Infrastructure

Threat actors were observed creating subdomains for any given targeted entity under the following domains:

assignpasskey[.]com (2026-06-14, Internet Domain Service BS Corp., DDoS-Guard)
deploypasskey[.]com (2026-04-21, Tucows, DDoS-Guard)
passkeydeploy[.]com (2026-04-23, Internet Domain Service BS Corp, DDoS-Guard)
passkeyadd[.]com (2026-05-08, Tucows, DDoS-Guard)
setpasskey[.]com (2026-05-23, IQWeb FZ-LLC)

So a campaign targeting "exampleentity" might be something like:

exampleentity[.]setpasskey[.]com

The phishing infrastructure observed by Okta Threat Intelligence was hosted on DDoS-Guard (AS57724, Russia) and IQWeb FZ-LLC (AS59692, US).

Impact

Since April 2026, a threat actor linked to O-UNC-066 has operated a data leak site with the name Pink (reported as "CL-CRI-1147" by Palo Alto Networks Unit 42).

Recommendations

While this cluster of threat activity has not been observed impersonating Okta, similar campaigns have combined voice-based social engineering and operator-controlled phishing kits:

Public Blog Post (publicly available)

Phishing kits adapt to the script of callers

Flash Advisory (Okta customers only)

IT Support Impersonated in Requests for Password Resets

Threat Advisory (Okta customers only)

Vishing Operators Synchronize Phishing Sites to their Script for Hybrid Social Engineering Attacks

The recommendations below are specific to the defence of Okta customers.

ATT&CK

Tactic

Control Recomendation

T1566

Phishing

Enroll users in strong authenticators such as Okta FastPass, passkeys or smart cards and enforce phishing resistance in policy.

Establish, communicate and evangelise methods of verifying the identity of helpdesk personnel when they contact users.

T1078

Phishing

T1078

Valid Accounts
(Initial Access)

T1078

Valid Accounts
(Initial Access)

Notify users of every authenticator (factor) lifecycle event using end user notifications.

T1098

Account Manipulation (Device Registration)

Apply Okta Account Management Policies that constrain the ability to add or modify authenticators based on network context, device management status and enrolled authenticators.

Specific guidance is provided in the following blog post:
https://www.okta.com/en-au/blog/threat-intelligence/intrusion-actors-self-serve-their-way-into-accounts/

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

, 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

Mon, 16 Feb 2026 08: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!

Threat Intelligence | Blog | Okta

Using advanced posture checks as a tooling watchdog

The gap that's hiding in plain sight

Defense impairment in the wild

The watchdog pattern

Free tokens for sale: How fake signups drive AI fraud

Introduction

Why use the gray market?

Cheaper tokens

Startup credit

Case study: AI video service

How Okta Threat Intelligence is disrupting them

Conclusion

Countering signup fraud

Behind the scenes of a vishing operation

Executive Summary

Threat Analysis

IAM: Three roles, three workspaces

The caller role

The manager role

The admin role

Caller operations

Manager operations

Admin operations

Commentary

What Work Panel teaches us about modern vishing operations

Recommendations

How to stop attackers from self-serving their way into accounts

Executive Summary

Threat Analysis

Breaking down the account recovery process

Minimum viable defense

Applying phishing resistance to authenticator enrollment

Applying phishing resistance to authenticator recovery

Indicators

Recommendations

Vishing actors target Entra passkey enrollment

Executive Summary

Threat Analysis

Infrastructure

Impact

Recommendations

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