GitHub removed the fake LastPass repositories. Four of the six Rapuncel domains still resolve

Two days after the report, most of the chain was still answering

LastPass and Delphos Labs published their joint report on the Rapuncel infostealer on 17 September 2026. It names six attacker controlled domains in the delivery chain. On 19 September 2026 I resolved all six against four public resolvers: Cloudflare's standard resolver at 1.1.1.1, Cloudflare's malware blocking resolver at 1.1.1.2, Google Public DNS at 8.8.8.8, and Quad9 at 9.9.9.9.

Four of the six still resolved. Of those four, Quad9 returned NXDOMAIN for two. Cloudflare's malware blocking resolver returned the live address for all four. The domain the report describes as the dynamic traffic director, istatlmenus.com, and one of the two terminal domains, macperformancetools.com, resolved on every resolver I tested, including both of the two that advertise malicious domain blocking.

The GitHub side of the same campaign is gone. Both fraudulent organisations named in the report, LastPass-Authenticator and LastPass-S, return HTTP 404, as do the portal at lastpass-authenticator.github.io and both GitHub Pages redirect accounts. The storefront was removed. The warehouse behind it was not.

The six domains named in the LastPass and Delphos Labs report, resolved from a single UK vantage point on 19 September 2026 against 1.1.1.1, 1.1.1.2, 8.8.8.8 and 9.9.9.9

Domain	Role given in the report	Status on 19 September 2026
albinofennel.com	Primary payload server	NXDOMAIN on all four resolvers
icansamyope.com	Secondary payload server	NXDOMAIN on all four resolvers
hanselarinmusky.com	Secondary payload server	Resolves on three, NXDOMAIN on Quad9
zaffersnouty.com	Terminal domain	Resolves on three, NXDOMAIN on Quad9
istatlmenus.com	Dynamic traffic director	Resolves on all four
macperformancetools.com	Terminal domain	Resolves on all four, and returns a redirect to an unrelated design awards site

What that does not establish. A domain that resolves is not proof that malware is still being served from it. A traffic director is built to show something harmless to visitors who do not match the targeting profile, and the redirect macperformancetools.com returned to me is exactly the behaviour you would expect from a request that failed that profile. Nor does NXDOMAIN prove a takedown: the operator may have retired the name. A single vantage point is a single vantage point, and resolver blocklists differ by region and by the hour.

It does establish one thing that matters for planning. Eight days after the date the report gives for its own state of knowledge, and one day after the trade press picked the story up, the names in the indicator list were not uniformly dead and were not uniformly blocked. If your response to this story is to paste the domain list into a blocklist and close the ticket, you have bought less than you think.

What the primary report actually establishes

The LastPass Threat Intelligence, Mitigation and Escalation team identified the fraudulent organisation at github.com/LastPass-Authenticator on 13 August 2026. The report, written with Delphos Labs, states that its content reflects the investigation as of 10 September 2026.

The lure was a GitHub organisation and a GitHub Pages portal that LastPass says was "deliberately SEO-optimized and appeared to rank well". The portal displayed fabricated trust marks, described in the report as "Authorized Access," "VirusTotal Approved," and "Secure Archive" badges. A download click passed the visitor through two further GitHub Pages accounts as redirect waypoints, then through a traffic director, then to a terminal domain, then to a payload server.

The archives were deliberately enormous. The report names LastPass-Authenticator-download-1.66.2.zip at 148 MB and lastpass-authenticator-2.78.7.zip at 127.9 MB, padded with two filler DLLs so that scanners with file size limits would skip them.

Inside, the installer was not attacker written code at all. It was a renamed copy of Microsoft's own Visual Studio CoreCLR debugger, vsdbg.exe, placed next to a malicious vsdbg.dll so that the genuine signed executable would load the attacker's library. The chain then attempted three different routes to administrator level access, loaded a kernel driver, and used it to terminate security software from kernel mode before collecting anything.

The driver is the part worth dwelling on. Alinubx.sys is, on the report's account, a renamed and identity swapped version of CcProtect.sys, a legitimate driver from Henan Dafeng Software. It carries a valid signature through the Microsoft Windows Hardware Compatibility Publisher chain with a timestamp of March 2023, and it scored 0 out of 72 on VirusTotal as of 20 August 2026, unchanged since July 2025. It carries 145 hardcoded antivirus and endpoint detection process names.

Only then does the stealer run. Rapuncel takes credentials from more than 25 web browsers and data from more than 30 wallet applications, Discord, Steam and Telegram session data, the contents of Windows Credential Manager, documents whose names suggest passwords, seeds, wallets or recovery, and screenshots from every attached monitor. It persists as a Windows service that starts at boot. It compresses everything into a ZIP and uploads it to 2.26.126.50 over a raw connection shaped to look like ordinary web traffic.

Reading the LastPass and Delphos Labs report of 17 September 2026 for what it does and does not commit to

What the report states	What it does not state
The fraudulent organisation was identified on 13 August 2026 and the report reflects the investigation as of 10 September 2026	Any takedown date, or whether GitHub or the operator removed the organisations
The payload server was serving at least 40 other branded impersonation lure pages	Which brands those were, beyond one shared game related lure name
The portal was deliberately search optimised and appeared to rank well	Which ranking signals were manipulated, or where in the results it appeared
The driver terminates processes matching 145 hardcoded security product names	Whether any specific product's tamper protection held
No LastPass system, service or customer vault was involved or compromised	How many people downloaded the archives, or how many machines were infected
Rapuncel is assessed with moderate confidence as a BoryptGrab related variant	A confident attribution to a named actor or country

Two notes on interest, which are worth stating plainly and without insinuation. LastPass is a password manager vendor publishing research into a campaign that impersonates its own product, which gives it a reputational interest in the finding that no LastPass system was involved. That statement is also the most checkable thing in the report, because the failure mode being described is entirely outside LastPass systems. Delphos Labs sells a binary analysis platform, and the report closes with a line about the analytical posture this class of threat requires. Neither of those is a reason to discount the technical content. Both are reasons to read the report as research, and to test the parts you can test yourself. That is what the resolver checks above are for.

The repository looked right because every signal it needed is cheap

The interesting question is not how the malware worked. It is why a competent person installed it. The honest answer is that the signals most developers and IT staff use to sanity check a repository are, almost without exception, signals the repository owner sets.

A taxonomy of GitHub abuse published in April 2026 by researchers at Xi'an Jiaotong University, Nanyang Technological University, Singapore Management University and the University of Massachusetts Amherst makes this uncomfortably concrete. They group abuse into four classes, and the first of them, which they call Attention Hijacking, is defined as "the abuse of GitHub's repository discovery and search mechanisms", exploiting precisely the signals "users commonly rely on": popularity indicators such as stars and forks, update recency, and keyword relevance. Each of those is a named subcategory of abuse with its own detection method.

Read the list as a defender and it is a list of the things you were told to check.

Repository signals mapped against the abuse subcategories named in the April 2026 GitHub abuse taxonomy

Signal you were taught to check	What it is read as	Who sets it
Star count	Other people have used this and it was fine	Anyone who can buy stars. Named abuse subcategory: Fake Stars
Recent commits	Someone is still maintaining this	A scheduled job that edits one file. Named subcategory: Automatic Updates
README that matches your search terms	This is the thing I was looking for	The author. Named subcategory: Keyword Stuffing
A plausible repository or organisation name	This belongs to the vendor	The author. Named subcategory: Typo Squatting
Familiar names in the contributor list	Credible people are involved	Anyone, via co-author lines in commit messages, with no notification to the person named. Named subcategory: Spoofed Contributor
Badges and stats on the profile or README	Verified, audited, clean	The author, in plain HTML. Named subcategories: Fake Stats, and in this case fabricated scanner badges

The scale is not hypothetical. The StarScout measurement study presented at ICSE 2026, from Carnegie Mellon, Socket and North Carolina State, applied a detector to every GitHub event between July 2019 and December 2024 and identified six million suspected fake stars across 26,254 repositories, narrowing after post processing to 18,617 repositories with fake star campaigns and 301,000 participating accounts. Their summary of what those stars were for is blunt: "the majority of fake stars are used to promote short-lived phishing malware repositories".

Two numbers from that paper are worth holding on to. First, 90.42 per cent of the repositories their tool flagged had been deleted from GitHub by January 2025, against a baseline deletion rate of 5.03 per cent for random repositories. That is a factor of 17.98. Deletion is the normal end state of these repositories, which is why finding the LastPass impersonations already gone tells you almost nothing about how long they were up. Second, 83.90 per cent of repositories with fake star campaigns had fewer than ten days of activity. The "plausible history" is usually not plausible at all if you look at the dates rather than the count.

And the stars themselves are not expensive. Of the packages the researchers linked to fake star repositories, the median star count was 380, while 70.46 per cent had not a single dependent package. Popularity was bought. Adoption was not.

The signals that do carry weight, and how to check them in under a minute

There is a small set of signals an attacker cannot simply set, because a third party controls them. They are less satisfying than a star count because they require a lookup rather than a glance. All of them take seconds.

Publisher identity, tied to a domain. GitHub lets an organisation prove control of a domain, and GitHub's documentation states that after verification "a 'Verified' badge will display on the organization's profile", shown only when the organisation's website and email match the verified domain. This is not a trust rating. It is a claim about domain control, checked by GitHub, which is exactly the claim an impersonator cannot make. On 19 September 2026 the genuine LastPass organisation returned is_verified: true from the public API, with the verification text on its profile page naming lastpass.com.

What the vendor says its channels are. The report is unusually direct on this point: "Official LastPass Authenticator is available through lastpass.com and the official app stores. GitHub is not a LastPass distribution channel." Nothing in the campaign survives that sentence. It is also independently checkable, because the genuine lastpass organisation holds 13 public repositories and none of them is an authenticator download.

Build provenance on the artefact, not the page. GitHub's artifact attestations exist to establish "where and how your software was built", and a consumer verifies one with a single command. An attacker can publish a release. An attacker cannot produce an attestation that verifies against the repository you expected.

Adoption rather than popularity. Dependent counts, registry download history over time and references from the vendor's own documentation are all held by someone other than the repository owner. Stars and forks are not.

# Is this organisation verified as controlling the vendor's domain?
gh api orgs/ORGNAME --jq '.login, .is_verified, .blog, .created_at, .public_repos'

# Does this release binary have provenance from the repository I expected?
gh attestation verify ./downloaded-artifact -R ORGNAME/REPONAME

# Is the history real, or a burst? Look at dates, not counts.
gh api orgs/ORGNAME/repos --paginate --jq '.[] | [.name, .created_at, .pushed_at, .stargazers_count] | @tsv'

Two more checks are specific to this case and cost nothing.

Does the product exist on this platform at all? The genuine LastPass Authenticator is a mobile application. Apple lists it for iPhone, iPad and Apple Watch, sold by LastPass US LP. Google Play lists the Android build. There is no Windows desktop LastPass Authenticator to download. The archives in this campaign were Windows executables for a product that does not ship for Windows, which is a contradiction available to anyone before they double click anything.

Does the version number exist? The fake archives carried the strings 1.66.2 and 2.78.7. On 19 September 2026 the current iOS release of the genuine app was 2.26.0, published on 8 June 2026. One of the fake version strings is far behind the real product and the other is far ahead of it. Neither corresponds to anything the vendor has shipped.

A badge is not a control, and neither is a signature

The portal in this campaign showed a "VirusTotal Approved" badge. There is no such thing. VirusTotal does not approve software, and a badge on a page the attacker wrote is a picture, not a check.

The more awkward point is what would have happened had someone done the real check. The kernel driver in this campaign scored 0 out of 72 on VirusTotal as of 20 August 2026, and the report states that score had been unchanged since July 2025. A diligent user who ignored the fake badge, uploaded the file and looked at a genuine result would have been reassured by it. The fabricated badge and the authentic scan agreed. Only one of them was lying, and it did not matter.

The same trap sits one layer down, in code signing.

Every signature in this chain was valid. The installer was Microsoft's genuine vsdbg.exe, correctly signed by Microsoft, doing exactly what it is built to do when it loads a library sitting next to it. The kernel driver carried a valid Microsoft Windows Hardware Compatibility Publisher signature. On the report's account the only change made to a legitimate third party driver was its name and identity strings, and that was enough.

This is worth holding against the UK control most likely to be cited in a post incident review. Cyber Essentials: Requirements for IT Infrastructure v3.3, published in April 2026, offers application allow listing as one of the two ways to meet the malware protection control. Its wording is: "Only approved applications, restricted by code signing, are allowed to execute on devices", with the obligation that "users must not be able to install any application that is unsigned or has an invalid signature".

Read as written, signature validity alone does not stop this. Every binary that mattered was signed and every signature was valid. What does stop it is the other half of the same requirement, the half that is harder to implement and easier to skip: actively approving applications before deployment and maintaining a current list of them. An allowlist of approved applications stops a renamed debugger. An allowlist of valid signatures waves it through.

The kernel blocklist deserves the same reading. Microsoft's vulnerable driver blocklist has been enabled by default since the Windows 11 2022 update and is enforced whenever memory integrity, Smart App Control or S mode is active. Microsoft's own documentation is candid about what that buys: the blocklist "isn't guaranteed to block every driver found to have vulnerabilities", it is updated quarterly with monthly servicing, and Microsoft says it is "often necessary for us to hold back some blocks to avoid breaking existing functionality". A control that is reactive by design, against a driver whose distinguishing feature was that it had been renamed, is not a control you should describe to your board as covering this.

Why this is worse on an IT administrator's machine than on anyone else's

Rapuncel's collection list reads like an inventory of an IT department. Credentials from more than 25 browsers is the browser password store, which on most administrator workstations holds saved logins for the things nobody put in the identity provider. Session data from Discord, Steam and Telegram is the part that gets mentioned in headlines and matters least in an enterprise. Windows Credential Manager is the part that matters most, because that is where mapped drives, remote desktop credentials, saved service accounts and a good deal of tooling keep their secrets. Screenshots from every attached monitor are, on an administrator's desk, screenshots of consoles.

The reach is not limited to what is typed. Session cookies survive multi factor authentication because they are what is issued after it. An attacker holding a valid cloud console cookie does not need to pass your second factor, because your user already did. That is why the order of the response below starts with sessions rather than with passwords.

And a password manager on the same machine is not exempt. LastPass itself, in this report, tells affected users to "Treat every credential stored in the browser on that machine as exposed", and to change them "from a separate, known-clean device rather than the affected one". That last clause is the one people skip and the one that decides whether the reset works.

Two controls change the arithmetic, and both are now available by default rather than as projects.

Chrome's Device Bound Session Credentials became generally available on Windows on 25 May 2026, on by default for Google Workspace customers with no administrator control to disable it. Google's own framing is careful and worth quoting for its limits rather than its promise: "even if malware was present on the user's device, DBSC reduces the risk of session theft". It binds the session to the device. It does not stop the malware, and it does not cover every browser or every application.

On the Microsoft side, the action that matters is the one most incident checklists put last. In Entra ID an authentication administrator can reset a password, require re-registration for multi factor authentication, and revoke sessions, which Microsoft documents as invalidating "a user's refresh tokens, forcing reauthentication across active sessions and applications". Resetting the password without revoking sessions leaves the stolen cookie working.

If a staff member ran the installer, this is the order

Two things are deliberately not on that list. There is no instruction to run a scan and act on the result, because the whole point of the driver was to make that result unreliable. And there is no instruction to block the six domains first, because as the checks at the top of this piece show, two of them are already dead, two are already blocked by at least one major filtering resolver, and blocking a name costs the operator the price of registering another.

The NCSC's Protective DNS is worth naming here precisely because of that limitation. It is "a recursive DNS resolver which prevents access to domains known to be malicious", centrally funded, mandated for central government departments and available to other eligible organisations. It is a good control and it is a blocklist, which means it is subject to the same lag you can measure yourself with four resolvers and a terminal.

Indicators, and what each one is actually worth

Indicators from the LastPass and Delphos Labs report of 17 September 2026, with a note on the useful life of each

Indicator	Type	How long it is worth hunting on
NvFsFilter	Service name created by the installer	Good. A service name is a host artefact and survives infrastructure changes
nvfsflt64.sys in the Windows system drivers directory	Driver file path	Good, together with a check of the file's real identity rather than its name
Authenticode identity naming Henan Dafeng Software on a Microsoft attested driver	Signer identity	Best of the set. The attacker changed the file name, not the signing identity
2.26.126.50	Exfiltration endpoint, announced by AS401152, Ace Data Centers II	Short. A hosting address, cheap to change, and blocking the range has collateral
The six campaign domains	Delivery chain	Shortest. Two were already dead on 19 September 2026
Portable executables with abnormally large relocation sections	Behavioural hunt suggested by the report	Durable, and the one worth building a rule for

The report also gives file hashes for the loader, the stealer and the driver. Hashes are worth adding and worth nothing on their own: a recompile changes them and a crypter changes them per build, and this loader was built with a commercial crypter. The signer identity and the behavioural signatures are the parts that age well, which is why the report's own hunting advice leads with the Authenticode identity and the relocation section anomaly rather than with the hash list.

One correction for the record. Several trade reports describe the campaign as impersonating LastPass "and at least 39 other companies". The primary report's wording is that the payload server was serving "at least 40 other branded impersonation lure pages", and its headline says forty companies. Forty other pages and forty companies including LastPass are not the same number, and the report does not name the other brands, so the honest summary is at least 40 impersonated brands in total and possibly 41. This matters only because it is a good illustration of how a number drifts between a primary source and its coverage in a single step.

The question that exposes the gap

There is a detail in this story that no takedown fixes. On 19 September 2026 the genuine LastPass GitHub organisation had 68 followers, 13 public repositories, a median of 6 stars across them, and a most recent push dated 22 April 2025, which is 515 days ago. By every heuristic a developer is taught, it looks abandoned and unimportant. The fake organisation, by the report's account, was search optimised and ranked well.

The real one is verified as controlling lastpass.com. That is the only signal in the entire comparison that pointed the right way, and it is the one nobody looks at.

So the question to put to your own organisation is not whether someone here would have fallen for this. It is narrower and more answerable than that. When one of your engineers or one of your IT staff installed a tool from a search result last month, which of the two checks in this piece did they perform, and can you tell?

If the answer is that you have no idea, then the control you are relying on is not a control at all. It is the hope that the person was in a careful mood.