What happened

The Register reports that the problem surfaced publicly on September 22, when a Reddit user who described themselves as a nursing student posted a screenshot: instead of homework and textbooks, Elsevier's platforms were showing the LAPSUS$ leak site. Help Net Security, drawing on Cloudskope's analysis, lists the three affected hostnames and describes the page as carrying a signed statement that taunted the FBI and counted down to a future victim.

Elsevier's statement, as published by The Register, reads: "On September 21, Elsevier identified that visitors to select platforms were being redirected to a third-party page. Our cybersecurity team responded immediately, resolving the issue and restoring normal service." It adds that there is "no indication that core platforms, customer data, research content, or operational systems were compromised." The Register says the company declined to answer further questions, including which platforms were affected and how long the redirect lasted.

Two points are unconfirmed and should be read that way:

  • The mechanism. Cloudskope's researchers, quoted by Help Net Security, concluded that the redirect came from "a change at the DNS or CDN edge: a DNS record, a CDN redirect rule, or the account that manages them." A Chinese-language forum post claimed the actor had altered Elsevier's Cloudflare redirect rules; the researchers say they could not verify that. Elsevier has not said.
  • Who did it. The page used the LAPSUS$ name, a group that had been quiet since late 2022. Using a name is not the same as being the original group, and no authority has attributed the incident.

Why it matters if you run public infrastructure

Nothing in the public record suggests Elsevier's web servers were breached, and that is the point. A visitor's path to your site passes through a registrar, a DNS provider and usually a CDN before it reaches anything you run. Each of those is an account with its own logins, API tokens and support desk, and each can send your traffic somewhere else without touching a server. Earlier this year CoW Swap lost its domain through the registry; this month Brevo lost control of its CDN through a leaked API key. Elsevier's incident, whichever layer it turns out to be, belongs to the same family.

It also shows how detection tends to work in practice: a user noticed, posted on Reddit, and the press asked questions the next day. A redirect on a login or submission page is also a credential risk while it lasts, even if this particular page was, by researchers' reading, an extortion notice rather than a phishing form.

What to check this week

  1. Inventory who can change where your names point. Registrar, DNS provider, CDN, and any team or contractor with API tokens for them. Each should have hardware-backed MFA, named accounts and no shared logins.
  2. Scope and rotate CDN and DNS API tokens. Long-lived, full-account tokens are the common thread in edge compromises. Prefer tokens limited to one zone and one permission, and alert on the provider's audit log for redirect rules, page rules, Workers and DNS edits.
  3. Lock the registration. Turn on the registrar's transfer, update and delete locks, and ask about registry lock for the domains that carry login, payment or submission traffic.
  4. Watch from outside. An external check that your critical hostnames still resolve where you expect, and still serve the certificate you deployed, catches the DNS variant of this attack quickly. The CDN-rule variant needs a content or redirect check against the live page, because DNS and certificates stay the same.

How Attack Surface Scan covers this

Some of it, and it is worth being exact about which part. If the redirect had been done by changing DNS, Attack Surface Scan records changes to NS, A, AAAA, CNAME, MX and CAA records in the change feed (see Changes that alert). A new certificate for your names from a CA outside your authorized list goes to the unknown-certificate queue and alerts at once, and served-certificate probes report issuer changes (see Certificates). Registrar lock status is read from RDAP nightly, and removing the transfer lock is a critical change (see Domain registration hygiene).

What it would not catch: if, as the unverified forum claim says, the attacker edited redirect rules inside the CDN account, DNS and certificates would not change, and Attack Surface Scan does not monitor page content or redirect targets between scans. It also cannot see your CDN or DNS provider's audit log; that alerting has to come from the provider. For this variant, our part is the hygiene around it: locks, CAA, and knowing which provider fronts each hostname, which the inventory shows by network and CDN (see Asset inventory).

Sources