Google confirmed it had detected and swiftly disabled a fraudulent account in its Law Enforcement Request System (LERS) after threat actors claimed they could access both LERS and the FBI’s eCheck verification portal. According to BleepingComputer, the FBI declined to comment. Google emphasized that no legal requests were issued from the fake profile and no user data was accessed.
What LERS and FBI eCheck are and why they matter
LERS is Google’s secure portal where law enforcement agencies (LEAs) submit court orders and emergency disclosure requests (EDRs) for user data. FBI eCheck facilitates identity validation and data exchange for investigations. Any unauthorized foothold in these systems raises the risk of convincing impersonation—threat actors could mimic legitimate requests, triggering lawful but unintended disclosures.
Claims from attackers versus Google’s response
Operators using the moniker “Scattered LAPSUS$ Hunters”—linked by researchers to Scattered Spider, LAPSUS$, and Shiny Hunters—posted screenshots they say prove access to LERS and eCheck and announced they would go “underground.” Google acknowledged only the presence of a bogus LERS account, stating it was deactivated before any action was taken. There is currently no corroborated evidence of data compromise.
Attribution context: overlaps with social engineering–driven crews
Researchers associate the group with actors known for social engineering and abuse of legitimate tools. Reported tactics include coercing staff to connect Salesforce Data Loader to corporate instances for data exfiltration and extortion, compromising a Salesloft repository, hunting for secrets with TruffleHog, and weaponizing discovered tokens across the Salesforce ecosystem. Google Threat Intelligence (Mandiant) has publicly detailed campaigns against Salesforce and Salesloft, prompting hardening across the sector.
Public taunts and a claimed “shutdown”
Amid increased scrutiny, the actors mocked the security community on Telegram and later posted a “closure” notice on a domain linked to BreachForums—an announcement that many analysts interpret as a pivot to quieter operations rather than a true exit.
The systemic risk of forged emergency data requests
EDRs are processed rapidly because they concern imminent harm and require strong trust in the requester’s identity. If adversaries convincingly impersonate an LEA or obtain a seemingly valid portal account, providers can be pressured into disclosing data in good faith. Real-world precedent exists: in 2022, Bloomberg reported that Apple and Meta responded to forged EDRs sent from compromised LEA email accounts, a technique linked by some researchers to LAPSUS$-adjacent actors. The pattern underscores that process abuse and identity spoofing can be as dangerous as software exploits.
Recommended defenses for LEA portals and service providers
Secure enrollment and authentication: Enforce phishing-resistant MFA (e.g., FIDO2/WebAuthn hardware keys) and conduct rigorous identity proofing before issuing access. Follow CISA guidance on phishing-resistant MFA adoption.
Policy and workflow controls: Require out-of-band callback verification for EDRs using pre-established contacts and signed keys. Limit scope via least privilege, data segmentation, and per-request justification.
Detection and response: Continuously monitor anomalies (request velocity, geolocation, timing, subject matter). Maintain rapid credential revocation, periodic revalidation of LEA accounts, and immutable audit trails.
Controls for enterprises (SaaS, DevOps, SecOps)
Access hygiene: Enforce least privilege across CRM and SaaS platforms. Gate tools like Salesforce Data Loader with approval workflows, strong MFA, and granular scoping.
Credential lifecycle: Prohibit non-expiring personal tokens; adopt short-lived, just-in-time credentials and automated key rotation. Integrate secret scanning (e.g., TruffleHog, gitleaks) into CI pipelines and protect Git with branch protection, SSO, and mandatory MFA.
Data safeguards: Deploy DLP and detailed logging to detect anomalous exports from CRM or marketing systems. Simulate social engineering and implement “challenge-callback” procedures for urgent data requests, especially those citing executive or legal pressure.
The incident highlights that even mature legal request workflows can be targeted via trust exploitation rather than technical exploits. Organizations should tighten identity proofing for LEA portals, adopt phishing-resistant authentication, institutionalize out-of-band EDR verification, and constrain what any single account can request or approve. These steps, backed by continuous monitoring and rehearsed response playbooks, materially reduce the likelihood that forged legal processes will lead to unauthorized data exposure.
