About this post: Thanks to Luke Acha for his parallel research into this sample and the wider cluster around it. This analysis and write-up were produced by Claude (Opus 5.5), working as an agent in Claude Code on a REMnux analysis VM. Tools used: Malcat, capa, KesaKode, unicorn, capstone, ILSpy, Wine (sandboxed), ANY.RUN and tshark.
TL;DR
Document_727721.exe presents itself as the setup program for "CookUp", a little app that suggests recipes from the ingredients you have. It is signed with an EV code-signing certificate issued to Pausatech LLC, and it really does install a working recipe app. Behind the installer, though, sits a loader that asks a server whether you are worth infecting, and only then downloads a hidden DLL and runs it straight from memory. In every session we observed, the server said "no", so the final payload stayed out of reach. The loader itself is fully mapped.
- Lure: a convincing three-step installer that drops a real, harmless "CookUp" recipe app.
- Signing: Sectigo EV certificate for Pausatech LLC (serial
008a52c5ffe70c4449c624c47cdc4214df). - Three gates: the file name, a hashed list of analysis tools, and a server-side "yes/no" hidden in the digits of a token.
- Payload delivery: a scrambled blob from
applicensingstudio[.]com, unpacked and loaded as a DLL directly in memory. - Status: the server refused every session we observed, so stage 2 is unknown.
A recipe app, of all things
A brand-new certificate used to sign a "productivity" app nobody has heard of is a pattern we see again and again with signed malware. Here the product is CookUp, and the installer does a nice job of it: Welcome page, folder picker, desktop and Start Menu shortcut checkboxes, even a note that it "Requires .NET Framework 4.8".

Press Install and you really do get CookUp.exe in %LOCALAPPDATA%\Programs\CookUp. We decompiled it: a small .NET program with a built-in recipe list, no networking and nothing hidden. It is the decoy, there so that nothing looks wrong afterwards.
But it’s signed!
Code signing is a digital signature on a program that tells Windows who published it. An EV (Extended Validation) certificate requires the most checks on the company before it is issued, so Windows and browsers trust it more. This file is EV-signed by Pausatech LLC, a New Mexico company, through Sectigo. The certificate has been reported to the CA and added to the CertGraveyard.
There’s also a trick in how the signature is stored. The file header claims the signature area is about 2 KB bigger than the signature really is, and that extra space is filled with junk bytes. Windows reads the first, valid signature and is satisfied, so a user sees a trusted publisher. Many security tools, though, choke on the junk, report the signature table as corrupted, and then don’t list the file as signed at all. VirusTotal, for example, shows no verified signer for this file. Once we corrected the size in a copy of the file, the signature checked out as genuine. Every related installer we looked at (see below) uses the same trick, across all five signing companies.
A signature says who signed a file, not whether it is safe. The signer has nothing to do with any "CookUp" product, and as you’ll see below, the installer is built to do far more than install recipes.
Three gates before anything bad happens
The interesting part is written in Go and heavily obfuscated: almost every text string is encrypted, and most function names are scrambled. Once those were peeled back, the logic turned out to be three gates in a row.

Gate 1, the file name. The installer looks at its own file name. It only continues if the name ends in an underscore or dash followed by 3–8 letters or digits, like Document_727721.exe, or starts with CPPWrapper_. If a researcher renames the file to its hash, as many do, it quietly behaves like a normal installer.
Gate 2, analysis tools. It lists running processes and services and compares them, as hashes rather than readable names, against a blocklist. A match means decoy only.
Gate 3, the server decides. This one is clever. The installer asks applicensingstudio[.]com for a "prep" token, a 32-character string such as 6B53B47A7A0D98E0A4F338F62747B158. It then adds up the digits in that token. If the sum is even, it goes ahead and downloads the payload; if it is odd, it stops. To anyone watching the traffic, a "yes" and a "no" look identical: just a random-looking string.
Think of it as a bouncer who hands everyone a ticket, where only the bouncer and the door know which tickets get you in.
What the hidden part does once it’s allowed in
When the token is "even" (we tested this in our lab by supplying one), the installer immediately sends a second check-in and then fetches a blob with a request ending in init=fin. That blob:
- must be at least 256 KB, with its length stored in the last 4 bytes;
- is unscrambled with a simple, fixed keystream from an LFSR (a linear-feedback shift register: a tiny circuit-style generator that spits out a repeating stream of pseudo-random bits);
- contains a length field and a Windows DLL, which the installer maps into its own memory with a home-made loader, so the DLL never touches the disk;
- kicks off a relay of three hidden DLLs: the first one’s
cx1function unpacks a second DLL, whoseacfunction produces a third, which is started throughdc. Each one is handed the installer’s path and details about the session.
We built a test blob in that format, and the installer unpacked it and mapped the DLL exactly as described. That confirms we read the format right, even without the real payload.
Part of a bigger family of "useful app" installers
CookUp is not alone. Luke Acha has been tracking a wider cluster of look-alike installers: more recipe apps (Pantry, RecipeRover, NomadicCookNow, Foodzi) signed by Launch Window, LLC; PDF tools (GooPDF, MyPdfSoftware, Paperly, Velum) signed by Net Sourcing Experts LLC; and Catchlight and Zippex signed by Virtual Holding Resources, LLC. We also found a fifth signer: another recipe installer, Document_294773.exe, named in the same Document_ style as ours, is signed by ROAD MEDIA PASS LIMITED. Several of them make the same style of init=prep / init=fin requests.
His detailed write-up of the Catchlight installer describes its payload unpacker closely enough that we could compare it with CookUp’s. They match: the same shift-register scrambler starting from 0x95000000 produces a byte-for-byte identical keystream, with the same "quarter of the file, length at offset 0x40, DLL right after it" layout. Catchlight is a modified NSIS plugin written in C, and CookUp is written in Go, so the same unpacking scheme has been rebuilt in two different languages. That points to a shared design or a common supplier behind installers carrying three different company signatures. Who actually runs them is still open. Like us, Luke never received a real payload; the init=fin replies were empty for him too.
The same Pausatech certificate also signed an earlier installer, for a disk-cleaning app called "DiskWise", which first turned up about two months before CookUp. In a first look it appeared to be a plain, working app with nothing hidden. That fits a familiar pattern: release something harmless first to build up a reputation for the certificate, then ship the real thing.
We then took a closer look at GooPDF ourselves. It’s written in C# instead of Go, and once its protection was stripped it turned out to be a talkative twin of CookUp: it logs every step in plain words. It uses the same file-name rule, the same even-digit token check, the same scrambler, and even the same 32-byte constant (the same 32 bytes appear in all three installers, CookUp, GooPDF and Catchlight). Its log messages confirmed the three-DLL relay described above. It also revealed a sneaky detail: the installer checks which antivirus is running and quietly encodes the answer into the ID it sends to the server, so the operators can decide per victim, on their side, whether to deliver the payload.
Luke frames this as possibly TamperedChef-style activity: apps that work as advertised while keeping a quiet back door for later.
What we couldn’t reach
In every session we observed, the C2 server handed out an odd token, meaning "not you". With no "even" token, the installer never asks for the payload, and the download endpoint returns nothing. So we can’t say what the hidden DLL is. It could be an info-stealer, a remote-access tool or something else entirely. The design, with export names and the decoy’s path passed in, hints at a modular second stage, but that is an inference.
This kind of server-side gating is also why the public ANY.RUN run scores it as "No threats detected": the sandbox saw a signed installer install a recipe app and nothing more.
KesaKode, Malcat’s code-similarity service, showed some overlap with GhostSocks. When we checked, the matching functions are all in the Go runtime, not in the malicious logic, so that is shared tooling and not evidence of the same family.
Advice
For regular users
- Be wary of "Document_xxxxxx.exe" files: a document doesn’t need to be a program. If something that should be a PDF or Word file ends in
.exe, don’t run it. - A signature (even EV) is not a safety guarantee. Check that the signer matches the product you expected.
- If you ran this file, the visible recipe app is harmless, but you should assume the hidden part may have run. Disconnect, run a full scan, and consider a reinstall.
For defenders
- Block
applicensingstudio[.]comand alert on the HTTP User-AgentMozilla/5.0WP. - Hunt for Go binaries signed by Pausatech LLC, and for the string
cookup/installer/internal/memload. - Watch for
%LOCALAPPDATA%\Programs\CookUp\CookUp.exeappearing from an unexpected "setup" executable. - If you capture an
init=finresponse, the format above is enough to unpack the DLL offline.
IOCs
| Type | Value |
|---|---|
| SHA256 (installer) | e7bc65daf98767646cb1a0e8c3d19cf0db0dce4618a9bcd2d287426cfd2c9034 |
| SHA256 (decoy CookUp.exe, benign) | cd94acc4a439c555e54e0703d05ff27a1810b63812a2d1baf69173de7e1d8bd3 |
| Signer | Pausatech LLC (also signed DiskWise setup.exe, 44b091e233130c18545f729b4702ec5ba1c7fa8ffb96bcf121ae6182a1749c1d), Sectigo Public Code Signing CA EV R36, serial 008a52c5ffe70c4449c624c47cdc4214df |
| Domain | applicensingstudio[.]com (behind Cloudflare) |
| URL (check-in) | hxxps[://]applicensingstudio[.]com/?ver=9de1&chan=2d6&lang=f24&arch=23a&build=301&init=prep |
| URL (check-in 2) | hxxps[://]applicensingstudio[.]com/?ver=3b0d&chan=618&lang=3b1&arch=1b1&build=f9b&init=prep |
| URL (payload) | hxxps[://]applicensingstudio[.]com/?ver=e5ce&chan=97a&lang=f69&arch=be5&build=6c4&uid=<8 hex>&init=fin |
| URL (failure report) | hxxps[://]applicensingstudio[.]com/?ver=9237&chan=4d9&lang=25e&arch=f83&build=530&init=prep |
| User-Agent | Mozilla/5.0WP |
| Path | %LOCALAPPDATA%\Programs\CookUp\CookUp.exe |
Wrapping up
CookUp is a good reminder that "it installed exactly what it said it would" is not the same as "it’s clean". The operators let their server decide who gets the real payload, which keeps sandboxes and researchers looking at a harmless recipe app. If you have seen applicensingstudio[.]com answer with an even token, or have the init=fin payload, we would love to hear from you.
You can follow the public sandbox run on ANY.RUN, and look up the signer on the CertGraveyard.