1. Executive summary
On September 21, 2026, three Elsevier domains (elsevier.com, evolve.elsevier.com, submit.elsevier.com) redirected visitors for at least 78 minutes to a page branded "LAPSUS$ GROUP, Chapter II", which taunted the FBI and displayed a countdown to a future victim. Cloudskope researchers attribute the redirect to a change at the DNS or CDN edge: a DNS record, a CDN redirect rule, or compromise of the account that manages them. Elsevier has not explained the cause and has not said whether user credentials or data were stolen; the domains were cleaned and restored before 10:09pm CT. The page's branding references LAPSUS$ (MITRE G1004), a group believed inactive since late 2022, but Securonix states that no evidence reviewed establishes personnel continuity with the original 2021-2022 cluster, so attribution is unconfirmed. No CVE is in scope and no CISA-KEV exploitation state applies to this event. The direct risk to EMEA financial services is low: the incident is a defacement-style redirect at a publishing company, but the mechanism, edge DNS/CDN account or redirect-rule compromise, is directly relevant to any firm that manages public DNS or CDN configuration for customer-facing portals.
2. Regulatory framing
No specific DORA/NIS2 article is directly engaged by this item. The incident occurred at a third-party publisher, not at a client, and no fact in the item triggers an incident-reporting, testing, or contractual duty that would not apply to any security event. Clients should treat this as threat intelligence relevant to their own DNS/CDN control assurance, not as a reportable incident.
3. Technical analysis & attack chain
Confirmed steps, all single-sourced to Cloudskope via Help Net Security:
- Between roughly 7:49pm CT and before 10:09pm CT on September 21, 2026, visitors to elsevier.com, evolve.elsevier.com, and submit.elsevier.com were redirected away from the legitimate Elsevier properties.
- The redirect destination was a page branded "LAPSUS$ GROUP, Chapter II". It carried a signed statement that taunted the FBI and counted down to a future victim.
- Elsevier cleared the redirect; the affected domains and portals were "cleaned" and are accessible and functional again.
Cloudskope assesses the redirect was effected "with a change at the DNS or CDN edge: a DNS record, a CDN redirect rule, or the account that manages them." This is a mechanism assessment, not a confirmed root cause. A Chinese-language forum post claims the actor altered Elsevier's Cloudflare redirect rules; Cloudskope could not verify that claim, and we treat it as unconfirmed.
What is not known: the initial access vector, whether the actor accessed an Elsevier management account or the registrar/CDN control plane, whether any Elsevier user credentials or manuscript data were accessed, and whether the redirect destination served malware or only the statement page. The source does not describe the redirect destination beyond the statement page, and no payload, persistence mechanism, or exfiltration activity is reported. Elsevier has offered no explanation.
Attribution caveat. The page uses LAPSUS$ branding, and LAPSUS$ has a MITRE profile (G1004). Branding is not attribution. The original cluster is believed inactive since late 2022 after arrests and convictions of members; some remaining members may have joined the Scattered Lapsus$ Hunters collective in 2025; and a 2026 LAPSUS$-branded leak site has named victims including Virta Health, Vodafone Germany, and AYA Bank. Securonix, analyzing the same page, states that "none of the evidence reviewed so far establishes personnel continuity with the original 2021-2022 LAPSUS$ cluster." Adverse Trace treats the LAPSUS$ attribution as unconfirmed. The statement's implied target, "a global company generating over $50 billion in annual revenue, with operations and a strong presence worldwide," is an actor claim with no supporting evidence in the source.
4. Mitigation & containment
This incident did not occur on client infrastructure, so the actions below are preventive controls for your own DNS/CDN attack surface, prioritised accordingly.
P1 (within 24h):
- Inventory every domain and subdomain your firm publishes, and identify which registrar, DNS provider, and CDN accounts can change their records or redirect rules. Where an account can alter a customer-facing portal's routing, confirm it requires phishing-resistant MFA and that no standing shared credentials exist.
- Review current DNS records and CDN redirect/worker rules for unauthorised entries or modifications. Compare against a known-good baseline; look for redirect rules you did not create pointing at domains you do not control.
P2 (within 72h):
- Enable change logging and alerting at the DNS/CDN layer where the provider supports it, so an unexpected record or redirect-rule change pages the on-call team rather than being discovered by users. Restrict who can disable that logging.
- Remove unused subdomains and stale DNS records from your zones. Any dangling record is a route an actor can target through account compromise at the provider.
P3 (within 7 days):
- Test the DNS/CDN control plane as part of resilience testing: attempt an unauthorised redirect-rule change in a staging zone and confirm the change is blocked, logged, and alerted. Record the result.
- Verify contractual terms with your DNS, registrar, and CDN providers cover breach notification timelines and audit access to your configuration, so a provider-side compromise reaches you with the same urgency as an internal one.
5. Indicators of compromise
No indicators of compromise available in the source material. The source names the affected domains (elsevier.com, evolve.elsevier.com, submit.elsevier.com) as victim infrastructure, not as indicators, and does not publish the redirect destination URL, any hashes, or actor infrastructure.
6. Detection
Insufficient indicators to author detection rules. The source contains no artefacts of the redirect page itself (no page content strings beyond the brand name, no destination URL, no hashes), and a rule matching the string "LAPSUS$ GROUP, Chapter II" would detect reporting about the incident rather than the threat. Monitor your DNS and CDN change logs per §4 instead.
Threat actor context
LAPSUS$ · G1004 · aka DEV-0537, Strawberry Tempest
LAPSUS$ is cyber criminal threat group that has been active since at least mid-2021. LAPSUS$ specializes in large-scale social engineering and extortion operations, including destructive attacks without the use of ransomware. …
7. Sources
- Help Net Security, "Brief hijack makes Elsevier domains redirect to LAPSUS$ 'Chapter II' page", https://www.helpnetsecurity.com/2026/09/22/elsevier-domains-hijack-lapsus/, 2026-09-22
8. Adverse Trace position
We assess this incident as low direct severity for EMEA financial services clients: a 78-minute redirect at an academic publisher, with no confirmed data access, no malware reported, and no client infrastructure affected. The attribution to LAPSUS$ (G1004) is unconfirmed and rests on page branding alone; Securonix's review found no evidence of personnel continuity with the original cluster, and the entire technical account is single-sourced to Cloudskope via Help Net Security, so verify before treating the DNS/CDN-edge mechanism as established fact. The actionable point for clients is the mechanism, not the victim: an actor changed routing at the DNS or CDN edge, likely through the account that manages it, and the same control exists at every firm with customer-facing portals behind Cloudflare or equivalent. We will monitor for Elsevier's root-cause statement, for verification of the Cloudflare redirect-rule claim, and for any evidence connecting this page to the 2026 LAPSUS$-branded leak site or to the claimed $50bn-revenue target, and we will reissue if any of that lands.
Published via PulseTrace — Adverse Trace threat intelligence.