How a fake GPT-6 Astra setup abused signed binaries
to reach SYSTEM
A search for how to install a recently launched AI model returned an installer that does not exist. Two genuine, signed binaries carried the attacker's code to SYSTEM, and only endpoint behavior stopped it.
Ryan PatrickPartner, Director of Cybersecurity, Simvay
A user searched Google for how to install OpenAI's GPT-6 Astra, a model that had launched a few weeks earlier. The top result looked like a GitHub project page for the model and offered a desktop installer. There is no such installer. What they downloaded used two real, validly signed binaries, one from OpenAI and one from Microsoft, to run attacker code, hid itself as a Windows system task, and waited for the next reboot to call out. Our endpoint protection identified it 21 seconds after its first network beacon and killed it inside 90 seconds.
We are publishing this for two reasons. The lure is cheap and current, and it does not expire at launch week: ours was still working more than a month after GPT-6 Astra shipped. And we found no public reporting or curated indicator set for this specific campaign. The samples sit on VirusTotal almost entirely undetected, and the only public trace we could find is a single community sandbox comment, so defenders will not catch this from their threat feeds. This post walks the attack from the search result to the final payload, shows what it looked like on the endpoint, and gives defenders concrete things to detect, hunt, and block. The victim and host are left out. The indicators are real and defanged.
Key findings
- The lure is SEO poisoning tied to a product launch. A page on GitHub, named after a real AI model, ranked for a natural installation question and offered an installer the vendor does not make.
- Two legitimately signed binaries do the work. The package ships a genuine, validly signed OpenAI executable and sideloads a malicious DLL through it, then installs a second genuine Microsoft-signed executable that sideloads a second malicious DLL. Signature checks pass at every step.
- Persistence hides behind a Windows-style task. The malware registers a scheduled task with a legitimate-looking Microsoft task name and a Microsoft Corporation author field, running as SYSTEM a few minutes after every boot. On disk it lives in a folder named to look like a Windows component.
- No public reporting, and near-zero detection. We found no vendor indicators or analysis for this campaign. At the time of our incident the malicious DLLs scored 1 of 67 and 0 of 71 on VirusTotal, and the binaries that load them are legitimately signed, so signature and hash based detection has nothing to catch. The campaign had been live for over a month under more than one model name.
- The payload is a delayed, Tor-capable beacon. Nothing happens at install time. On a later reboot the SYSTEM task runs, resolves its command channel through a messaging-platform page, pulls a second stage, and stands up a Tor client. Our endpoint protection stopped it before any data left the host.
At a glance
| Element | Detail |
|---|---|
| Weapon | A ZIP installer impersonating a desktop app for a recently launched AI model, built around a signed vendor binary plus a malicious sideloaded DLL |
| Attack vector | SEO-poisoned GitHub Pages page, surfaced by a direct search for installation instructions |
| Delivery | Download from a GitHub release on the same account; no email, no attachment |
| Infrastructure | Messaging-platform pages used as a dead-drop resolver, a public file host for the second stage, a bundled Tor client for command and control |
| Persistence | Scheduled task impersonating a Microsoft component, running as SYSTEM after boot |
| Objective | Delayed command-and-control beacon with second-stage download; consistent with an information stealer or loader |
| Targets | Opportunistic: anyone searching for the named AI tool. The same kit has run under at least two model names since early September 2026 |
Why the lure worked
GPT-6 Astra is a real OpenAI model. It was announced on September 3 and rolled out to paid accounts the next day, and for a week it was in every technology feed. You reach it through ChatGPT, the Codex coding tool, and the API. There is no desktop installer, because there is nothing to install. The search that started our incident was almost exactly the question a reasonable person would ask: what is the correct ChatGPT installation for Astra.
That gap between what people expected and what the vendor shipped is the opening. When a product is new, even careful users do not yet know how it is distributed, so a plausible wrong answer does not look wrong. One widely shared post from an AI commentator, written to help, told readers to download the desktop app and warned that they would not see the new model in the browser. That advice was accurate for the vendor's real app. It also primed a reader to go looking for an installer, which is what the search returned.
The attacker did not break into a platform or buy an ad. They registered a GitHub Pages site at gpt-6-astra[.]github[.]io, published a release named after the model on the matching repository, and let search do the rest. The cost is close to nothing and the page can sit there for weeks. Ours was live for over a month before we pulled the thread. The account (gpt-6-astra) is gone now; by October 9 the release page returned a 404.
This is the pattern to take away, not the specific model name. A launch draws a wave of people asking how to install the thing, and the lure keeps working for weeks afterward, well after the launch-week guard is down.
What happened on the host
A search for how to install the newly released model returns a github.io page named for it, offering an installer the vendor never made.
GPT-6-Astra-Setup.zip pulled from a GitHub release on the same account, extracted, and launched.
A genuine, OpenAI-signed Setup.exe loads the attacker's winmm.dll from its own folder. The running image is trusted; the behavior comes from the planted DLL.
A Microsoft-signed binary and a second malicious DLL are written to C:\ProgramData\WMProcess\ and run by the task \Microsoft\Windows\WMPDeviceMetadataCollector, author Microsoft Corporation, as SYSTEM three minutes after each boot.
The task reads its live address from a public messaging-platform page, then stages a second component from an anonymous file host.
Injects into a core Windows service, writes a bundled Tor client with a bridge config to a temp folder, and starts it for command and control.
Flagged 21 seconds after the first outbound beacon; process killed and files quarantined within 90 seconds. The Tor client never formed a circuit. Endpoint reimaged.
What follows is what the endpoint telemetry recorded, in order. Times are relative to the download.
The download and first run
Within minutes of the search, the user downloaded a ZIP named GPT-6-Astra-Setup.zip, about 5 MB, from a GitHub release page and extracted it. The archive carried a genuine, validly signed OpenAI executable (Setup.exe), a set of real Electron runtime files, a malicious DLL named after a core Windows audio library (winmm.dll), and a decoy DLL that is a harmless copy of a public UI icon library, renamed to a DirectX filename as padding. The user ran Setup.exe. Because the malicious winmm.dll sat in the same folder and carried the name Windows expects, the signed process loaded the attacker's code instead of the real library. This is classic DLL sideloading: the running image is genuine and validly signed, so a signature-based control sees a trusted OpenAI process while the behavior comes from the planted DLL. Only winmm.dll is malicious. The icon-library DLL is a decoy, worth flagging because it is easy to mistake for a second payload when you triage the archive.
Elevation and the real install
The first run of Setup.exe started with normal user rights. Seconds later a Windows consent prompt appeared, the user approved it, and Setup.exe relaunched with administrator rights. That user-approved elevation is what enabled the rest: the elevated process wrote its persistence pair, a Microsoft-signed executable (WMPDMC.exe) and a malicious DLL (wmpdui.dll) beside it, into a new folder under C:\ProgramData named to look like a Windows media component, and it registered a scheduled task under the Microsoft task tree, with the author field set to Microsoft Corporation, configured to run that executable as SYSTEM a few minutes after every boot. Separately, over the next four minutes the user approved several more consent prompts and, three times, entered the local administrator account's credentials through Run as different user. Telemetry does not show why, and we cannot say what those credentials were used for. What we can say is that entering admin credentials on a host that already held a SYSTEM-level implant should be treated as exposing them. The exact folder name and task name are in the indicators below.
The decoy and the genuine app
Shortly after, the user downloaded and ran the vendor's real installer from the official store, and the real app installed normally. That is likely why nothing felt wrong: the person did end up with a working AI tool. The malicious components were already in place, and the extracted files and the ZIP were sent to the Recycle Bin.
Quiet until the reboot
The malware did no network activity at install time, which is part of why it sat undetected. It waited for the scheduled task to fire. When the laptop rebooted the next morning, the SYSTEM task ran the planted executable, and within a few seconds it reached out. It resolved its command channel the way a lot of current commodity malware does: instead of a hardcoded address, it pulled a page from a public messaging platform and read the live address from there, a dead-drop resolver, then contacted a public anonymous file host to stage its next component. It injected into a core Windows service process, wrote a Tor client with a bridge configuration into a temporary folder, and started it. The goal was a command channel that rides Tor and is hard to block by address. It did not get there. Our endpoint protection flagged the behavior 21 seconds after the first outbound connection and reported the process killed and the files quarantined inside 90 seconds. The Tor client never completed a circuit beyond local loopback.
What did not happen
We found no evidence of data leaving the host. Per-application network records show no transfer by the malware processes, the file-system change journal shows no staged archives or copies of credential stores, and the Tor client never established an external circuit before it was killed. The account's activity in the organization's cloud, mail, and identity logs showed nothing abnormal in the window. We did not see credential theft in the telemetry, but because local administrator credentials were entered on a compromised host, we treated them as exposed and rotated them. The endpoint was reimaged.
Entering admin credentials on a host that already held a SYSTEM-level implant should be treated as exposing them.
Campaign timeline
The public scanning record shows this was not a one-off. The same loader was staged before the Astra lure went up, under the name of the vendor's previous model, and ran for weeks.
- Aug 30Both malicious DLLs compiled
- Sep 3GPT-6 Astra announced; loader first seen on VirusTotal under the prior model name
- Sep 5Astra-branded release published on GitHub
- Sep 28Full chain documented in a public sandbox comment
- Oct 8Our incident: search, download, install
- Oct 9Payload runs on reboot; killed in 90 seconds
- Oct 13Still almost undetected on VirusTotal: 1 of 67 engines flag the loader. Hosting account gone
- Aug 30Both malicious DLLs compiled
- Sep 3GPT-6 Astra announced; loader first seen on VirusTotal under the prior model name
- Sep 5Astra-branded release published on GitHub
- Sep 28Full chain documented in a public sandbox comment
- Oct 8Our incident: search, download, install
- Oct 9Payload runs on reboot; killed in 90 seconds
- Oct 13Still almost undetected on VirusTotal: 1 of 67 engines flag the loader. Hosting account gone
| Date | Event | Source |
|---|---|---|
| Aug 30, 2026 | Compile timestamp on both malicious DLLs (attacker-controllable) | VirusTotal file metadata |
| Sep 3, 2026 | Loader first submitted to VirusTotal inside an installer named for the vendor's prior model | VirusTotal |
| Sep 3 to 4, 2026 | GPT-6 Astra is announced and rolled out to paid users | Vendor and press |
| Sep 5, 2026 | The Astra-branded release is published on GitHub | urlscan (retrieved Oct 5) |
| Sep 28, 2026 | A researcher documents the full chain in a public malware-sandbox comment | VirusTotal community |
| Oct 8, 2026 | Our incident: search, download, install | Endpoint telemetry |
| Oct 9, 2026 | Payload runs on reboot and is killed; the lure page already returns not found | Endpoint telemetry |
| Oct 13, 2026 | Loader 1 of 67, persistence DLL 0 of 71 on VirusTotal; the hosting account is gone | VirusTotal |
Two things stand out. The compile timestamp, which can be forged, reads August 30, before the model was announced; more telling is the reuse, since the same loader shipped under the vendor's prior model name on September 3 and was rebranded to Astra two days later. The kit is prepared ahead and renamed to whatever launches next. And five weeks after the first sample appeared, detection was still essentially nothing. A file almost no scanner flags, loaded by a validly signed process, is the whole point of this technique.
Detection and defense
Name-based rules are the wrong tool here. The binaries are genuine and signed, the task name looks like a real Microsoft one, and the folder is named like a Windows component. The signals that held up are behavioral.
Two points make that concrete. First, we found no public indicators for this campaign, so signature and hash based detection has nothing to match. The malicious DLLs scored 1 of 67 and 0 of 71 when we pulled them, and the executables that load them carry valid OpenAI and Microsoft signatures. Behavior at runtime is the only reliable signal.
Second, the persistence task runs as SYSTEM. SYSTEM is the privilege level that endpoint tampering starts from (MITRE ATT&CK T1562.001), though it is a precondition, not a guarantee: a modern EDR with tamper protection and a protected-process agent generally forces an attacker to bring a vulnerable driver (BYOVD) or a protected-process bypass on top of SYSTEM. A weak or misconfigured agent, user-mode only or with tamper protection off, can be stopped by a SYSTEM process outright. Our EDR flagged and quarantined the payload at runtime; a weaker tool on the same host might not have stopped it in time.
| Stage | What to watch for | Where to look |
|---|---|---|
| Execution | A signed vendor binary loading a DLL from a user folder (Downloads, Documents, a profile path) rather than its real install directory. High volume on its own, so use as a correlation input or scope to System32 DLL names resident outside System32 | EDR module-load and image-load events; Sysmon event 7 |
| Execution | A vendor-signed process whose on-disk path is a download or temp folder, not Program Files or the Store package path | EDR process events; Sysmon event 1 |
| Persistence | A new scheduled task under the Microsoft task tree whose action points at a binary outside System32 or Program Files, for example under ProgramData | Security event 4698 (requires the Audit Other Object Access Events subcategory, off by default), or Microsoft-Windows-TaskScheduler/Operational event 106; EDR task events |
| Persistence | A binary with a Microsoft or vendor signature running as SYSTEM from ProgramData or a similar non-standard path | EDR process events |
| Defense evasion | A SYSTEM process injecting into a core Windows service process shortly after boot | EDR remote-thread and injection events; Sysmon events 8 and 10 |
| Defense evasion | Attempts to stop, unload, or reconfigure the endpoint agent from a SYSTEM process | EDR tamper-protection alerts, service and driver events |
| Command and control | Any process reaching a public messaging platform's web pages, a public anonymous file host, or starting a local Tor client, where there is no business reason for it | DNS, proxy, firewall, EDR network events; Sysmon event 22 |
| Command and control | A Tor or pluggable-transport binary written to a temp path and launched by a non-interactive process | EDR file and process events |
Hunt for it
Since there are no public hashes worth chasing, hunt the behavior. In order of signal to noise:
- A scheduled task under
\Microsoft\Windows\whose action binary is not under System32 or Program Files. Baseline-diffing the Microsoft task tree against a known-good image surfaces the fake task immediately, because it is not a genuine built-in task. - A System32 DLL name (for example
winmm.dll) resident in a user-writable path and loaded by a non-Microsoft signed process. - A non-Microsoft or vendor-signed executable running as SYSTEM from
C:\ProgramData. - Pivots for the next renamed variant: a VirusTotal retrohunt or imphash pivot on the signed-binary-plus-sideloaded-System32-DLL-name combination, a urlscan search for the GitHub release-page pattern, and process execution from a path carrying Mark-of-the-Web in a user folder.
If you find it
- Isolate and reimage the host.
- Rotate the local administrator password and any shared local-admin credential, and hunt for reuse of that credential across the fleet (lateral movement). LAPS is the durable control.
- Fleet-sweep for the folder
C:\ProgramData\WMProcess\and the task\Microsoft\Windows\WMPDeviceMetadataCollector. - Revoke the user's cloud and identity sessions.
For your users
- Install AI tools only from the vendor's own website or the official app store for your operating system. Never from a search result, an ad, a social post, or a project page on a developer platform.
- There is no installer for a model. ChatGPT, Claude, Gemini and their peers run in the vendor's app, website, or API. A page offering a download for the model itself is fake.
- Repeated prompts for your password or for administrator approval during what looks like a simple install is a reason to stop, not to keep clicking.
For IT and security teams
- Use application control (AppLocker, WDAC, or at least a block on executables running from Downloads and Temp). This chain starts with an EXE run out of an extracted ZIP, and blocking that defeats it before any signed-binary cleverness.
- Alert on signed binaries executing from user download, temp, and profile paths.
- Alert on new scheduled tasks under the Microsoft tree whose target is outside System32 or Program Files.
- Turn on EDR tamper protection and confirm the agent runs with kernel-level self-protection. A SYSTEM-level payload like this one will test whatever you have.
- Block or alert on endpoints reaching anonymous file hosts and messaging-platform APIs where there is no business use, and on unsanctioned Tor usage.
- Remove standing local administrator rights, and manage the local admin password with LAPS. The user here was able to supply local admin credentials on demand, which is what let the install reach SYSTEM.
- Keep endpoint protection in a blocking mode. Detection depended on behavior at runtime, because static scanning saw almost nothing.
- Give staff a sanctioned way to get the AI tools they want. People search for installers because the real tool is not already in front of them.
Attribution
We are not attributing this to a named group, and our confidence in any link is low. What we can say is where it sits.
The tradecraft matches a family of financially motivated operations documented publicly through 2025 and 2026: fake AI tools as the lure, legitimately signed or legitimate binaries abused through sideloading, messaging platforms used as dead-drop resolvers or command channels, and bundled Tor for command and control. Multiple security vendors have documented clusters in this space (see references): one that a vendor report assessed as Vietnam-nexus, which advertises fake AI tools and reaches additional payloads over Tor, and another that runs its command channel through a messaging platform and sideloads through legitimate software. Our case shares individual techniques with both and matches neither cleanly. The persistence here is a scheduled task rather than a registry run key, the delivery is a search-ranked GitHub page rather than social ads or email, and the second-stage hosting differs.
Two things would raise confidence, and we have not done them yet: recovering the command-channel identifier from the messaging-platform page, and running the malicious DLLs against the published rule sets for those documented families. Until then, this is a commodity campaign using well-documented tradecraft, author unknown.
Indicators of compromise
All indicators are defanged, and we found none of them in any public threat feed or vendor report; we are publishing them so others can hunt. The live command-channel identifier (the messaging-platform handle the malware reads its address from) was not recovered; when it is, it goes only into the machine-readable bundle shared with CISA AIS, MS-ISAC and OCIC, alongside the file hashes, the scheduled-task XML hash, and the second-stage filenames. SHA1 is listed where recorded. MD5 was not separately recorded; look any file up by its SHA256 on VirusTotal for the full hash set and current detection count.
Delivery
| Type | Value | Note |
|---|---|---|
| Lure page | gpt-6-astra[.]github[.]io | fake GitHub Pages site named for the model; account gpt-6-astra; removed (404 by Oct 9) |
| Release URL | github[.]com/gpt-6-astra/gpt-6-astra[.]github[.]io/releases/tag/Astra | release tag Astra, commit cb39c25; served GPT-6-Astra-Setup.zip |
Malicious files
Only the loader DLL and the persistence DLL carry attacker code.
| File | Role | SHA256 | SHA1 | VirusTotal |
|---|---|---|---|---|
GPT-6-Astra-Setup.zip | Astra-branded lure archive, 4.99 MB | 80b2967ac0e4e4260852aebc4f5ed8efb4674be3a515a9a4c9bd49b57961bb9e | 332e3b685e375aa44a5ec98511fc53be821df46a | n/a (archive) |
sol-setup.zip | earlier lure variant, same chain, prior model name | 2a61e811669c2fa9f2d9ecbc8d4c0932897409244d352dded764a4fd936c4d1c | c2b986704406d47dd88ee4e2fcffebc854ff2ce4 | n/a (archive) |
winmm.dll | loader, sideloaded by the signed OpenAI binary | 2ebf2759195413e44f9e77cc8360976f989ff96e05531d40ec7d05756a1ea9c4 | 20238b36645fc63139a76b19a480c6a9166472fa | 1/67 |
wmpdui.dll | persistence, sideloaded by the signed Microsoft binary | 0ed24be024fa746c176de5c6cab57221942ea6291f02262dded415849d9f8dee | cf90c4599257e76984a199d98b1fd082b820a54d | 0/71 |
Legitimate components, do not block
These are genuine, validly signed files abused by the chain. They are listed so triagers recognize them in context. Do not add them to a blocklist.
| File | Role | SHA256 | SHA1 | VirusTotal |
|---|---|---|---|---|
Setup.exe | genuine, validly signed OpenAI binary; sideload host | 82d358599a1ad9de98f919b58b80e8495e3f3826477571dceb97af86d02133c6 | not recorded | signed |
WMPDMC.exe | genuine, Microsoft-signed binary; persistence host | 04c23776c6e2ae916e692ef033570aca8d2def8d17610f92cb1c9f4fdab9f328 | not recorded | signed |
D3dx9_41.dll | decoy: benign copy of a public UI icon library, renamed to a DirectX filename as padding; not malicious | begins a34174c9 (look up full hash on VirusTotal) | not recorded | 0/69, benign |
Dropped by the payload
| File | Role | SHA256 | SHA1 | VirusTotal |
|---|---|---|---|---|
tor.exe | bundled Tor client dropped by the payload | begins 60c45b01 (look up full hash on VirusTotal) | not recorded | legitimate Tor |
Network
| Type | Value | Note |
|---|---|---|
| Domain | t[.]me | Telegram page used as the dead-drop resolver; legitimate messaging-platform infrastructure, block by behavior, not by address |
| Domain | cdn5[.]telesco[.]pe | Telegram content CDN, the dead-drop resolver fetch; legitimate infrastructure, block by behavior, not by address |
| Domain | files[.]catbox[.]moe | public anonymous file host, abused for the second stage; legitimate service, block by behavior, not by address |
| IP | 149.154.167[.]99 | Telegram infrastructure |
| IP | 149.154.171[.]236 | Telegram infrastructure |
| IP | 108.181.20[.]35 | the catbox[.]moe file host. A legitimate file-sharing service abused by many unrelated families; treat as context, block by behavior |
| IP:port | 51.89.231[.]85:24526 | Tor bridge in the dropped config; no connection observed |
| IP:port | 51.89.228[.]250:21668 | Tor bridge in the dropped config; no connection observed |
The file host is worth a note. Open-source reputation data (LevelBlue OTX) shows 108.181.20[.]35 serving seven catbox[.]moe subdomains and carrying dozens of community reports across unrelated stealer and RAT families. That breadth is a sign of a shared, heavily abused service, not a link to this operator. Block the behavior, not the address.
Host
| Type | Value | Note |
|---|---|---|
| Folder | C:\ProgramData\WMProcess\ (WMPDMC.exe, wmpdui.dll) | persistence location; folder named to mimic Windows Media Player |
| Scheduled task | \Microsoft\Windows\WMPDeviceMetadataCollector, author Microsoft Corporation, SYSTEM, boot plus 3 minutes | a fabricated, legitimate-looking Windows task name, not a genuine built-in task |
MITRE ATT&CK
| Tactic | Technique | ID |
|---|---|---|
| Resource development | Stage capabilities: SEO poisoning | T1608.006 |
| Execution | User execution: malicious file | T1204.002 |
| Execution / persistence / privilege escalation | Scheduled task | T1053.005 |
| Defense evasion | Hijack execution flow: DLL (side-loading; formerly T1574.002) | T1574.001 |
| Defense evasion | Masquerading: match legitimate resource name or location | T1036.005 |
| Defense evasion | Process injection | T1055 |
| Command and control | Ingress tool transfer | T1105 |
| Command and control | Web service: dead-drop resolver | T1102.001 |
| Command and control | Multi-hop proxy (Tor) | T1090.003 |
T1562.001 (Impair Defenses: disable or modify tools) is noted in the defense section as a risk tied to the SYSTEM-level foothold. We did not observe it in this incident, so it is not in the table of observed techniques above.
References
- 01VirusTotal community analysis of the persistence DLL, Sep 28, 2026 (surfaced during our investigation; not previously reported by a vendor).
- 02urlscan.io capture of the release page, published Sep 5, retrieved Oct 5, 2026.
- 03Google Threat Intelligence Group (Mandiant), "Cybercriminals weaponize fake AI websites to deliver malware" (UNC6032, assessed Vietnam-nexus; the GRIMPULL downloader uses Tor), May 2025.https://cloud.google.com/blog/topics/threat-intelligence/cybercriminals-weaponize-fake-ai-websites/
- 04Morphisec, "Noodlophile Stealer: When Cybercriminals Get a Bit Salty" (messaging-platform C2, sideloading via legitimate software), 2025.https://www.morphisec.com/blog/noodlophile-stealer-when-cybercriminals-get-a-bit-salty/
- 05Binary Defense ARC Labs, "Chasing Phantoms: How a Multi-Stage Stealer Abuses Signed Binaries to Disappear" (cited for the signed-binary evasion and scheduled-task masquerade pattern), 2026.https://binarydefense.com/resources/blog/chasing-phantoms-how-a-multi-stage-stealer-abuses-signed-binaries-to-disappear
- 06MITRE ATT&CK, T1562.001, Impair Defenses: Disable or Modify Tools.https://attack.mitre.org/techniques/T1562/001
- 07FBI IC3 Public Service Announcement, brand impersonation via search engine advertisement services (malvertising; cited for the user-education point, our case is organic SEO), Dec 21, 2022.https://www.ic3.gov/PSA/2022/PSA221221