The FBI Warned About ShinyHunters. Then Came the FBIJobs Claim.

The warning and the claim

On May 15, 2026, the FBI published a public warning about a group calling itself ShinyHunters: how it pressures victims and why its claims should not be taken at face value. On September 22, a representative using that name told reporters it had broken into FBIJobs.gov, the bureau’s own hiring portal, and taken records on agents and applicants. Reporters documented an apparent defacement and, later, an unavailable notice. The stated demand was not money. According to Nextgov, the group wanted the FBI to retract or correct the May warning.

The FBI said it was investigating the claims. Its statement did not confirm an entry path, the systems reached, or the volume taken. That distinction matters, and this article holds to it. A compelling story is not a completed investigation.

The FBIJobs claim is the unresolved end of a longer pattern. Since 2024 the ShinyHunters name has been attached to data theft from cloud data warehouses, CRM platforms, a learning management system used by thousands of schools, an HR application, and now a federal hiring site. In each case the way in was ordinary: stolen credentials, a convincing phone call, an integration trusted too far, a public portal left open, a support ticket, or software exploited before a patch existed. The human mistake was rarely the last chance to stop the theft. The defensive question that matters is where the system could have interrupted what followed.

This article follows six of those paths at reading length. The reference edition carries the full chronology, the role-by-role attribution for each case, the named controls with their sources, a control checklist, and a 30/60/90-day plan.

The pattern behind the name

This is a study of access becoming business harm, not a claim that one stable team carried out every event. Responders track separate operators and phases under identifiers including UNC5537, UNC6040, UNC6240, UNC6395, UNC6661, and UNC6671. The ShinyHunters name can connect an extortion or publication claim without establishing who obtained initial access.

The campaigns nevertheless expose a coherent defensive problem. Attackers repeatedly converted one weak point into trusted access:

• Old credentials stolen from an unmanaged or previously infected endpoint
• A convincing voice call that led a worker through a legitimate authorization screen
• A trusted third-party integration whose tokens reached many customers
• Excessive guest permissions on a public portal, with no stolen login at all
• Untrusted customer content opened in a privileged support workflow
• An internet-exposed enterprise application exploited before a patch existed

After access, the attackers often used the victim’s normal interfaces, sessions, tokens, APIs, export tools, and administrative functions. The theft looked less like destructive malware and more like an authorized user or application doing something abnormal at high speed. That makes human behavior important, but it does not make the employee the whole explanation.

Founder’s Perspective: think like the attacker, then check your own assumptions

The weakest link is still human behavior, but that observation cannot become a way to transfer responsibility to an employee. The organization has to keep one mistake from becoming unrestricted access.

Before I founded Mount Xion, I handled this firsthand. I review the logs myself whenever phishing attempts are on the rise. That habit is how I caught it, within 90 minutes. In the age of AI, that is far too long. A man-in-the-middle phish had captured a user’s sign-in. What stood out was impossible travel: the account signed in from the user’s usual city, then from another state seconds later. Nothing acted on that signal. The organization’s Entra sign-in policy blocked only locations outside the United States, so both sign-ins passed. That was the wrong posture. A country boundary is not a trust boundary.

The attacker got in and then went quiet. My read was that they were banking on no one noticing, so the credentials could be used later, on their schedule. The organization relied on a managed service provider for monitoring, but no system or policy enforced that kind of review. I ran the full trace anyway: what that identity had touched, what sessions and tokens it still held, and where else it could reach. There was no other foothold, but the session was still live. If I had not been doing that due diligence, the attacker could still be in that network today.

That review habit is what I am arguing for. The absence of activity is not the absence of an attacker. A password reset that leaves sessions and tokens alive is not a complete containment response. Assigning monitoring to a provider is not the same as knowing it happens. After the incident, monitoring became a defined, reported part of the provider’s scope. The organization added automated alerts, so a sign-in like that one would be flagged without anyone having to look. It also tightened its sign-in controls. Until a system or policy enforces the review, someone who owns the risk has to look.

I came to civilian security from a military environment that spent more of its effort on the human and process side than industry does. That balance is worth importing. The technology community risks becoming so excited about new tools that it neglects the craft of thinking like a hacker at every level. That craft means following the attacker’s choices through the person, the workflow, the identity, the application, the data, the operations, and the business consequence. Tools scale sound judgment. They do not replace it. Executives need enough adversarial understanding to govern the tradeoffs and recognize where a control can fail.

How to read the evidence

Confirmed facts here come from the affected organization, a government authority, or a responder with direct incident visibility. Attacker claims, corroborated observations, and recommendations are labeled as such. Mandiant and Google Threat Intelligence use different identifiers when the evidence supports different operators. Their January 2026 analysis cautions that the ShinyHunters name can cover shifting alliances and impersonation. A name on a leak post does not establish who obtained the access, who exported the data, or who published it, so each case keeps those roles separate. This article reproduces no leaked material and does not infer negligence from an incomplete record. The Founder’s Perspective sections are my professional assessment, kept distinct from any forensic finding about a named victim.

Path one: a stolen secret

Mandiant tracked the 2024 campaign against Snowflake customer accounts as UNC5537. Its June 2024 analysis found that the actor reached customer instances with credentials previously stolen by information-stealing malware. It found no evidence that Snowflake’s own environment was breached. Three conditions repeated across victims: stolen credentials that sometimes remained valid years after exposure, accounts without MFA, and instances that did not restrict access by network allow list. At least 79.7 percent of the accounts the actor used had known prior credential exposure.

Once authenticated, the actor needed neither malware nor a platform exploit. It signed in through Snowflake’s own interfaces and followed the path any analyst would: enumerate the tables, select the ones it wanted, create a temporary staging area, copy the data into it compressed, and pull the files down. The stage deleted itself when the session ended. None of it looks wrong to a database that has already accepted a valid password.

The scale is now supported by a criminal admission. In August 2026, the U.S. Department of Justice announced that Connor Riley Moucka pleaded guilty to participating in a scheme that compromised cloud-hosted data belonging to at least 165 SaaS customers, stole billions of records, and extorted victims. DOJ said the conspirators received more than $2.5 million in ransom payments and caused victim-company losses exceeding $9.5 million.

AT&T shows what one of those losses looked like. Its SEC filing confirmed that files were exfiltrated from a third-party cloud workspace between April 14 and April 25, 2024. The files held call and text interaction records for nearly all of AT&T’s wireless customers, covering May through October 2022. They did not include the content of calls or texts, Social Security numbers, or dates of birth. AT&T later confirmed to TechCrunch that the workspace was hosted on Snowflake.

What could have interrupted the chain. Set a network policy so the warehouse only answers from trusted locations. Remove every password-only path. Check corporate identities against exposure feeds so a years-old credential dies on discovery. Alert on the unload sequence, not the login. Enumeration, stage creation, a compressed copy, and a download from a new address make up this campaign’s signature. Query history records the command sequence. The exposure may have begun with human behavior, but each of those later controls was another chance to stop the theft.

Path two: a convincing call

In 2025 the target moved from a stored secret to a person at work. Google Threat Intelligence tracked the callers as UNC6040. Its June 2025 analysis described actors who impersonated IT staff by phone and walked employees to Salesforce’s connected-app setup page. There the employee entered a connection code that linked an actor-controlled copy of Data Loader, a legitimate mass export utility sometimes renamed as a ticketing tool, to the company’s environment. Once authorized, the tool held an OAuth grant with native API access and bulk export. No Salesforce vulnerability was involved.

Follow-on extortion could begin weeks or months later. Google tracks that phase separately as UNC6240, the cluster that consistently claimed the ShinyHunters name. The FBI’s September 2025 FLASH describes the same sequence. Google itself disclosed a June 2025 intrusion of this kind into one of its corporate Salesforce instances.

Qantas is the clearest public account of what the call looks like from the inside. The Australian privacy regulator’s inquiry report found that a third-party contact-center agent took a call from someone impersonating Qantas IT support. The caller walked the agent, on a legitimate CRM-related site, through actions presented as necessary to close a support ticket. Those actions connected the CRM environment to an attacker-operated extraction tool. Qantas detected unusual failed-login alerts and contained the access on June 30, 2025. Approximately 5.67 million customer records were compromised. Qantas reported that the system held no payment-card, financial, or passport data and that no passwords were accessed.

Qantas already had recurring training, supplier audits, role-based access, and incident response. The regulator’s preliminary inquiries, which make no concluded findings, did not identify a likely privacy-control violation. The report’s key observation is that standard awareness training usually emphasizes credential theft, not being guided through a legitimate authorization screen. The operative weakness was that an end user could authorize a third-party application with meaningful access, a platform default that was later changed. Qantas did not name the actor. The mechanism matches the campaign, but the individuals responsible stay campaign-linked rather than victim-confirmed.

In January 2026 the same craft moved to the login itself. Google reported that UNC6661 operators called employees while victim-branded phishing pages stayed synchronized with the caller’s script. The attackers captured SSO credentials and MFA responses, registered an attacker-controlled factor, and used that identity to enter whichever SaaS applications the account could reach, including Microsoft 365 environments. Okta’s threat research explains why number matching and one-time codes still fail against a live caller. They reduce accidental approval, but they are not phishing resistant.

What could have interrupted the chain. Take the “API Enabled” permission off user profiles and grant it only to the few who run mass operations, so the app the caller connected cannot export. Make connected apps an administrator decision with an allowlist. Bind logins and app authorizations to known networks. Use Transaction Security Policies to block a large download while it is happening. Give the help desk a rule: an unsolicited IT call gets a callback on a known number before anyone opens a setup page.

The login attacks call for phishing-resistant authentication. In Microsoft 365 that phrase has a precise meaning: a Conditional Access authentication strength that accepts only Windows Hello for Business or a platform credential, a FIDO2 security key or passkey, or multifactor certificate-based authentication. A password plus a push or a code does not pass. Requiring a managed device or a compliant network at sign-in adds a gate that a phishing proxy or a rented server cannot pass, wherever it sits. Containment also has to reach the tokens. A password reset alone does not reliably end every session or remove app passwords. Revoke sessions, delete app passwords, and remove the authenticator the attacker registered, each as its own explicit step. The reference edition walks through the Entra controls for this path.

Path three: a trusted integration

In August 2025 the human target was replaced by a trusted machine identity. Salesloft’s public chronology, as reproduced in reporting, says an actor gained access to its GitHub account and later to the Drift AWS environment, where it obtained OAuth tokens used for customer integrations. Google Threat Intelligence tracked the customer-side activity as UNC6395. From as early as August 8 through at least August 18, the actor used those tokens to reach numerous customer Salesforce instances and export data systematically. It then searched the data for AWS access keys, passwords, and Snowflake-related access tokens. Salesforce itself was not exploited.

Cloudflare’s incident report shows how fast that moves. The actor counted the Account, Contact, User, and Case objects and pulled the schema for Case. It ran a Bulk API job against the Cases object that finished in three minutes and twenty-two seconds, then deleted the job. Support-ticket text and contact information left, while attachments did not. Cloudflare found 104 of its own API tokens in the exposed case text, rotated them, found no misuse, and disconnected every third-party integration from Salesforce. Support systems become secret repositories. A valid integration token moves data faster than a person can read an alert.

Attribution here needs care. The authoritative attribution is UNC6395. When a person claiming ShinyHunters affiliation claimed a role, Google said it had not seen compelling evidence for the connection. The pattern also continued after Drift: Microsoft’s July 2026 review describes a November 2025 campaign through Gainsight-published Salesforce apps and a separate June 2026 Klue incident, with no established common operator.

What could have interrupted the chain. Scope each integration’s token to its job and refuse the full-access scope. Pin the integration to the vendor’s addresses so a stolen token presented from elsewhere is refused. Watch the query pattern: a run of record counts followed by a bulk job on a sensitive object is the campaign in one line, visible before the job completes. Scan support cases for secrets. Know before an incident who revokes a vendor’s app and how long it takes. In Microsoft 365 the same decision lives in app consent settings and app governance, which the reference edition covers.

Founder’s Perspective: near misses and access requests are both telemetry

Annual training completion is not the same as human-risk management. If staff keep receiving phish or vishing calls, ask what stopped each attempt and what pattern is developing. Ask what the business impact will be when one succeeds, and how to interrupt that path before it becomes an incident. Near misses are not empty events. They are attack telemetry.

Access requests deserve the same treatment. In a previous role, I approved a large IT vendor’s request for full access to the organization’s tenant. It was a routine ask from a trusted partner. Then it dawned on me that the organization had no need for the vendor to hold that level of access. The risk against the reward did not add up, so I rescinded the authorization. With third-party and supply-chain compromise growing, that should be the default: unless a concrete business need exists for a specific level of access, reduce it. A vendor integration starts with a decision to grant access. That decision needs an owner, a defined purpose, and a review when the risk changes.

Path four: a public portal left open

The remaining three paths, all from 2026, required no one to be fooled at all. The first needed no exploit either. Salesforce’s March 2026 advisory describes a campaign against overly permissive Experience Cloud guest profiles. Anonymous visitors queried CRM objects that customers had not intended to expose, without logging in, using a modified open-source audit tool at scale. Salesforce attributed the weakness to customer-configured guest settings, not a platform vulnerability. FINRA’s alert on the same campaign names ShinyHunters, although Salesforce’s advisory does not. Guest permissions on a public portal are an access path in their own right.

What could have interrupted the chain. Audit the guest profile against Salesforce’s published settings list as if it were an employee. Close guest access to the public APIs. Inspect what an anonymous visitor can actually retrieve on a schedule, not only after an advisory.

Path five: a support ticket

Instructure’s Canvas incident, described on its incident hub and customer FAQ, began with a Free-for-Teacher account and a support ticket containing malicious content. When an agent opened the ticket, a cross-site scripting flaw executed in the agent’s session, allowing the actor to obtain a token with elevated, cross-customer access. Opening the ticket was the agent’s job. Pages were altered across roughly 300 organizations. The confirmed exposed data was usernames, email addresses, course and enrollment information, and messages, with no evidence that passwords or financial data were exposed.

A second attempt on May 7 used another then-unpatched flaw. Enhanced monitoring disabled it in about ten minutes, with no data exfiltration found. Instructure says the incidents appear to have been perpetrated by ShinyHunters. Ten minutes is the number to remember: monitoring recognized the renewed behavior and turned a signal into an immediate response.

What could have interrupted the chain. Render customer submissions without script in support tools. After finding one such flaw, test the whole class. Scope a support token to one tenant and one task. Treat a support session that starts behaving outside its purpose as a signal to contain, even when opening the ticket was part of the job.

Path six: software exploited before a patch

Oracle’s June 10 alert for CVE-2026-35273, an unauthenticated remote-code-execution flaw in PeopleSoft PeopleTools 8.61 and 8.62, arrived after exploitation had begun. Google Threat Intelligence observed UNC6240 exploiting it from May 27 through June 9 through the Environment Management Hub, an administrative component that Google says can be blocked from the internet without breaking ordinary user sessions. Google notified more than 100 potentially exposed organizations, about 68 percent in higher education.

The National Association of Insurance Commissioners reported detecting unauthorized access on June 11. It confirmed that public statutory financial reports and credit-rating information were taken and later published. It said it had no current evidence that personal or payment data was exposed and disputed the volume the group claimed. The association also paused rating-data feeds, a reminder that confidentiality is not the only cost.

Patching is direct threat reduction, but the PeopleSoft wave shows its limit. The first victims were hit before a patch existed, so exposure reduction, segmentation, and egress control had to carry the load. A patch also does not remove persistence established before it. Google was explicit that web application firewall rules alone are insufficient.

What could have interrupted the chain. Take administrative endpoints such as the Environment Management Hub off the internet. Audit the access logs for external requests to them. Segment the public-facing tier from storage and the cloud control plane, with outbound connections denied by default. Once remediation exists, apply it promptly, then hunt for anything established before it.

Back to the open claim

Apply the same standard to FBIJobs. As of September 22 at 9:20 p.m. Central, the public record supported this much.

• Confirmed: the FBI told reporters it was aware of claims affecting FBIJobs.gov and was investigating.
• Corroborated: reporters documented maintenance messaging and an earlier apparent attacker-branded notice on the portal. They also checked portions of a roughly 5,000-record sample against public or previously compromised information. That partially corroborates the sample without establishing its provenance, recency, or completeness.
• Claimed by the actor: a new, undisclosed PeopleSoft zero-day, movement into FBI-managed AWS GovCloud systems, and two to three terabytes covering employees and applicants. The group also claims access to other FBI services and ongoing use of the same flaw against other organizations. It gave the FBI one week to withdraw or correct the May warning and presents that demand as its motive. The group also shared a screenshot with CyberInsider that shows a page on the applicant portal under the path of the Environment Management Hub, the administrative component the June campaign exploited. It called that system its entry point. The screenshot is unverified.
• Reported, anonymously sourced: POLITICO cited two people with knowledge of the breach who said investigators believe the group’s claims are credible. That is reporting from unnamed sources, not an official finding.
• Open theory: POLITICO also reported that investigators were considering whether the June CVE-2026-35273 exploit was reused against a system that had not received Oracle’s remediation, or whether another path was used.

The FBI’s 2022 privacy impact assessment described FBIJobs and Candidate Gateway as internet-accessible components hosted on AWS GovCloud and built on Oracle PeopleSoft. That makes a PeopleSoft-centered incident plausible, but it does not establish the 2026 architecture, the patch state, or the attack path. Reaching a workload inside GovCloud is also not the same as compromising AWS.

Three theories fit. The first is reuse of the known June flaw against an unremediated component. The second is a different, undisclosed flaw, plausible but confirmed by no advisory. The third is an identity or administrative compromise using legitimate functions, plausible but selected by no evidence. If authenticated, the screenshot could support access involving the same component as the June campaign. It would not establish the initial route or which flaw, if any, was used. The practical step for anyone running PeopleSoft does not depend on that answer: confirm that the Environment Management Hub does not answer from the internet, and review its access logs for outside requests.

Until an official update, this is a serious, developing claim with limited corroboration. That is what the May warning said to expect. The FBI’s notice itself cautioned that this group’s activity can combine real, exaggerated, or fabricated claims with harassment and pressure.

What the attackers’ tools say about ours

Two September 2026 reports add a detail leaders should not skip. Google’s September 8 report describes UNC6240 using Claude Code for intrusion-related coding and custom Model Context Protocol tools to analyze stolen directories for extortion. Model Context Protocol is the plug-in interface that lets an AI agent call outside tools and data. The report’s table rows name Claude Code while its caption names Gemini. The report does not resolve that inconsistency.

Anthropic’s September report describes separate operators it assessed as suspected ShinyHunters affiliates. One of them dumped over 2,100 Azure AD token sets across more than 40 corporate tenants in about 34 hours, with AI agents performing nearly all of that work. These are source-attributed operations, not proof that every ShinyHunters-linked intrusion worked this way. Neither report establishes AI use in the FBIJobs claim.

Founder’s Perspective: bounded speed

The business already owns the risk of responding too slowly. AI adds the risk of responding incorrectly at machine speed. Leadership has to evaluate both. When the evidence is strong and the action is reversible, pausing an export or revoking a token may be safer than waiting for a human while the attacker keeps moving. Humans should govern the boundaries and stay on the loop, not become a mandatory delay before every defensive action.

The reports from Google and Anthropic make one more point plainly. The reported operations used mainstream AI tools that employees and defenders can also use. That is not an argument against the tools. It is an argument for governing them on both sides: knowing what an attacker can do with them, and preauthorizing what a defender may do with them.

The workable model is bounded autonomy with a human on the loop. It already exists in production form. Microsoft Defender’s automatic attack disruption contains a device or disables an account when it identifies an active attack. Every action is logged, an analyst can release it, and exclusions protect break-glass accounts. That is the shape to copy. The products supply the preauthorized, reversible action. The governance to wrap around it is a maximum duration, immediate notification, and a named person accountable for escalation. Permanent deletion, prolonged shutdown, public communications, employee discipline, and ownership or federation changes stay with humans. The NIST AI Risk Management Framework fits this model directly.

What would not have been enough

Several familiar controls would not have stopped these paths on their own.

• Awareness training alone does not remove a vulnerable server, narrow an OAuth scope, isolate untrusted support content, or stop an export.
• MFA alone does not stop pre-authentication exploitation or a user guided into approving an attacker’s app. One-time codes and push approvals are not phishing resistant.
• A password reset alone may leave sessions, refresh tokens, OAuth grants, app passwords, or a newly enrolled factor usable.
• An alert alone cannot prevent the transfer if it arrives after a three-minute export. It can still support the investigation.
• A backup alone restores availability. It does not reverse theft, doxxing, or coercion.

Five decisions for leadership

1. Design for the human who will eventually be deceived. Hold people accountable for procedure, but hold the organization accountable for limiting the consequence of one mistake.
2. Treat access as an attack surface, including public access. Human users, service accounts, OAuth apps, support sessions, and workload identities all require least privilege, behavior baselines, and rapid revocation. Public guest permissions need an accountable owner and recurring tests.
3. Make high-confidence abnormal actions stop, not just alert. Authentication, authenticator replacement, credential creation, logging changes, and bulk export deserve preplanned blocking or pause decisions.
4. Protect the controls that protect the business. Use two-person integrity for evidence destruction, trust-boundary changes, and permanent weakening of safeguards, with a tested emergency path. Check what the tooling actually enforces before assuming it is dual control.
5. Authorize defense to operate at attacker speed. Preapprove bounded, reversible containment and keep humans on the loop for review, escalation, and irreversible decisions.

The May warning and the September claim bracket the same lesson. Every path in this study ran through a point where the organization, not the person, could have said no. The work is finding those points before the next call comes in.

About this article

This article draws on public statements by affected organizations, government authorities, and responders with direct incident visibility, cited inline. The evidence cutoff is September 22, 2026, 9:20 p.m. Central. Official FBI, DOJ, CISA, Oracle, and AWS sources were checked again on September 23 and showed no update on the FBIJobs claim. The article reproduces no leaked records, personal data, exploit detail, or attacker infrastructure. It does not infer negligence from an incomplete public record. Recommendations are defensive design judgments, not findings that a named organization lacked a listed control. The reference edition is available as a PDF. It carries the full chronology, role-based attribution for each case, the named controls and their sources, a control checklist, and a 30/60/90-day plan.