J@IL-GPT: an infostealer in a fake ChatGPT tool

§ 01. Summary

J@IL-GPT is a Windows infostealer distributed as a ChatGPT 4.5 jailbreak. Its code collects saved credentials and application data, captures screenshots, and prepares encrypted HTTP uploads.

The GitHub repository directs users to a 7,202,239-byte EXE. Its loader reconstructs a 2,662,400-byte executable from hexadecimal data hidden in fabricated log entries. That program embeds a browser-collection DLL and a conditional downloader with persistence functions. An earlier MSI, disguised as AMD chipset software, delivers the same collection code through a different wrapper.

Distribution and extraction chain. Download PNG.

§ 02. Distribution

DarkForums post 423476, displayed under yahyawrt on 27 March 2026 at 08:29 PM, promotes the “latest uncensored version” of a ChatGPT 4.5 jailbreak. The thread has a SOURCE CODE prefix and links to github.com/kikus662zqdz/j-ilgpt/tree/main. Original thread.

The author bumped the thread on 29 March. Replies include a thank-you and, on 31 March, a warning about the EXE. Neither establishes execution or an infection.

The link follows the mutable main branch. It remained unchanged as the repository moved from Python instructions to an MSI and then an EXE.

The forum timestamp has no timezone label; GitHub timestamps below are UTC. The forum and repository accounts have not been linked to a verified real-world identity or common controller.

§ 03. Repository contents

At revision d23920785624dfa20077b4a20bb144d0d251032f, the repository contains four files: the EXE, README, requirements.txt, and this complete 23-byte main.py:

import main
main.Xyz()

The checkout has no Xyz implementation. Its dependencies—colorama, openai==0.28.0, and requests—do not supply the missing application. The visible source cannot account for the distributed EXE. Pinned Python file, dependency list.

The same Python file and 33-byte dependency list appear in CarbonComputers/Worm-GPT at revision dbaab3dbb3d4e15dcc88ae509a92b12492dbf6f0, dated March 2024. That tree includes main.cpython-311.so, a compiled extension absent from J@IL-GPT. Of J@IL-GPT's initial 51 nonblank README lines, 43 match the older README exactly. The copy changes branding and removes upstream contact and credit lines. Older project.

The reuse does not attribute the Windows malware to the older project's authors.

§ 04. Packaging history

The nine-commit history records the switch from Python instructions to Windows installers:

The Python-to-MSI change, Windows rewrite, and MSI-to-EXE change preserve the installation changes.

The release tag points to the 27 March MSI-era tree, while its attached EXE comes from 29 March. Its automatic source archive therefore represents an earlier package state. The release-attached README is also stale: its 1,210 bytes match the initial copied README, while the current installer-focused README is 1,019 bytes. Release metadata.

The API's published_at, rather than its earlier created_at, dates the release's publication. The preserved download counter was 11 asset downloads; it does not measure executions, unique users or victims.

§ 05. MSI execution

The deleted ZIP and MSI remain recoverable from Git history. The ZIP's MSI is byte-identical to the separately committed package.

The type-2 custom action extracts and launches Binary.p, a 7,135,320-byte PE, through a temporary file. Static MSI extraction does not invoke this action. Microsoft custom-action documentation.

ARPSYSTEMCOMPONENT=1 suppresses the normal Control Panel entry when applied; it does not remove other installation evidence. Microsoft property documentation.

No evidence links AMD to the package's creation, signing or distribution.

§ 06. Encoded payload

The EXE is a native 64-bit Windows GUI executable. Its PE sections end at offset 515,072, followed by 6,687,167 bytes of trailing data—approximately 93% of the file.

After version-like text, a 6,682,637-byte payload block begins at 519,590. The final twelve bytes contain three little-endian 32-bit integers:

Footer magic:      0x6d512115
Data offset:      519590
Data length:      6682637
Boundary check:   519590 + 6682637 + 12 = 7202239

The loader validates the magic and bounds. The block contains a five-byte header followed by 22,542 fabricated log lines, including process names such as explorer, OneDrive and spoolsv, timestamps, tokens and nonces. These records encode the payload; they are not Windows event logs or evidence of victim activity.

For each line, the parser selects the longest lowercase hexadecimal run and accepts even-length runs of at least 32 characters. It appends decoded bytes until the declared length is reached. 21,379 lines contribute data; 1,163 do not. The resulting encoded stream is 2,662,404 bytes.

§ 07. Offline extraction

The decoded stream begins with a four-byte encoded length. Reversing it yields 2,662,400 bytes for the inner executable. The body transformation combines a 32-byte key, index-dependent mixing, byte rotations and feedback from the original input byte.

Offline reconstruction produces an MZ header, a DOS-to-PE pointer of 0x100, a valid PE signature and coherent section bounds. The recovered x64 executable has entry-point RVA 0xDCC4C and SHA-256:

e395fd44a750ccc4da5740d83645fda7b2cdc0bb9de3fd6e8cbfba7ac90c3feb

The MSI's loader uses the same container design with footer magic 0x28eec550, data offset 482,878, and length 6,652,430.

The two recovered executables differ in 101 of 2,662,400 bytes: three COFF timestamp bytes and 98 bytes in .rdata, including debug metadata and obfuscated data. Their raw .text, .data, .pdata and .reloc sections are byte-identical. The collection code is unchanged; configuration and runtime outcomes can differ.

§ 08. Loader execution

The outer EXE retains Rust source paths including src\main.rs and src\halo_gate.rs. At preferred image base 0x140000000, extraction begins at 0x140006FB0 and decoding at 0x140007C70. Dispatcher 0x140008200 reaches the manual PE mapper at 0x14000C310, which:

1. Validates DOS/PE signatures and allocates image memory.
2. Copies headers and sections, applies relocations and resolves imports.
3. Sets section protections and registers the x64 exception-function table when present.
4. Temporarily replaces the current process's PEB image-base field.
5. Flushes the instruction cache, starts a thread at the mapped entry point, waits for it and restores the original image-base field.

This mapper executes inside the existing process. VirtualAlloc documentation, CreateThread documentation.

The dispatcher also has disk-writing and process-launch fallbacks, including dynamically resolved CreateProcessW and ShellExecuteExW. The chain is therefore not exclusively memory-resident.

Microsoft certificate and version strings occur in a nested Visual C++ runtime DLL. The outer EXE's Authenticode security directory is empty; the nested strings do not constitute its signature.

§ 09. Evasion and cleanup

Function 0x140009960 checks for fourteen already-loaded analysis, instrumentation or virtualization DLLs. Their names are XOR-encoded with 0x16:

sbiedll.dll       api_log.dll      pstorec.dll
cuckoomon.dll     cmdvrt32.dll     cmdvrt64.dll
avghookx.dll      avghooka.dll     snxhk.dll
tracer.dll        vmGuestLib.dll   vboxdisp.dll
vboxhook.dll      vboxmrxnp.dll

A GetModuleHandleA match stops the dispatcher. The next check lowercases USERNAME and rejects substrings sandbox, virus, malware, sample, test, wdagutilityaccount, hal9th and defaultaccount.

A successful lookup of %USERPROFILE%\Desktop\12356.txt bypasses both checks. This is an allow condition that permits the dispatcher to proceed.

Function 0x14000AC80 resolves exports by hash and installs a vectored exception handler with hardware execution breakpoints targeting AmsiScanBuffer, EtwEventWrite and WldpQueryDynamicCodeTrust. On a matching single-step exception, the handler substitutes a return value and advances the saved instruction and stack pointers without patching the target's code:

This mechanism requires loaded modules, successful export resolution and successful context operations. It configures only the current thread, while the PE mapper starts the payload on another thread. Effective interception of that new thread has not been demonstrated.

Function 0x14000C0A0 attempts to zero 512 bytes of the current process image's in-memory header after changing protection. It leaves the disk header unchanged. Its VirtualProtect resolver rejects forwarded exports, so the wipe can fail on systems where that export forwards to another DLL.

After the dispatcher returns, main clears the decoded buffer and attempts hidden cmd.exe cleanup: a loopback ping delay followed by deletion of the quoted loader path. Cleanup can occur after the environment gate rejects execution; it does not establish that the collector ran.

§ 10. Credential collection

The inner Rust main routine, 0x1400543E0, calls collectors and a final transfer routine. CoreFTP collector 0x1400689E0 opens the current user's SOFTWARE\FTPWare\COREFTP\Sites, reads Host, User and PW, decodes and decrypts stored passwords, and submits formatted records to queue 0x1400214B0 under \Apps\CoreFTP\Credentials.txt.

That path is a queued output label; an on-disk file with that name is not established. The queue transfers at 10 MiB with type apps, then main flushes remaining data as apps_complete. Its JSON serializer emits type and files; entries contain app, path and Base64-encoded data.

Additional module paths name FileZilla, Pidgin, OneNote, Obsidian, Monero, Discord, Steam, Roblox, Chromium extensions and Gecko extensions. Availability of data depends on installed applications and accessible profiles.

The screenshot path runs from 0x1400543E0 through 0x140053C60 to capture helpers using StretchBlt and GetDIBits, before system-information packaging. Captures can include open administrative interfaces and documents.

§ 11. Browser DLL

At inner RVA 0xEAF74, a 1,520,300-byte XOR-obfuscated Base64 object decodes into a 1,140,224-byte x64 DLL exporting KdMXFBaWQ.

The DLLs recovered from both packages have identical machine code and differ in 42 bytes: a numeric configuration value, timestamps and an internal name that changes from L342SWFQ498Y.dll to 82X2QY4TGTUH.dll. Those names are embedded metadata, not confirmed endpoint filenames.

The Rust launcher creates a suspended browser process, allocates and writes memory there, makes the code executable, and starts a remote thread at the DLL's reflective-loading entry. This is separate from the outer loader's same-process mapping path.

The DLL worker reaches these collectors:

Key-recovery code handles encrypted_key and app_bound_encrypted_key from Local State. Firefox code resolves NSS PK11SDR_Decrypt. Successful decryption across browser versions was not tested.

The inner EXE also reaches 0x140040440, which resolves ntdll!EtwEventWrite, changes page protection, writes a success-return stub and restores protection. This patch differs from the outer loader's hardware-breakpoint interception.

§ 12. Network protocol

Sensitive strings use repeating XOR with the twelve-byte fallback key xnasff3wcedj. The decoder also checks CRYPTIFY_KEY in the environment.

Upload function 0x140013970 selects the discovered destination or fallback. The Telegram locator permits destination changes without replacing the binary; its current content was not retrieved.

Queued records pass through serializer 0x140024170, upload function 0x140013970, and HTTP helper 0x140012D10. The helper calls WinHttpOpen, WinHttpConnect, WinHttpOpenRequest and WinHttpSendRequest with the prepared body, and sets certificate-validation exception flags.

A 32-character secret supplies the key material. The routine derives the AES-256 key with SHA-256 and constructs this CBC/PKCS#7 frame:

Rust upload body:
  length:       4 bytes, little-endian; size of the remaining frame
  marker:      12 bytes, SHA-256(secret || secret)[0:12]
  IV:          16 random bytes
  ciphertext:  AES-256-CBC with PKCS#7 padding

Marker, EXE lineage:  f5446133b530c210154507e1
Marker, MSI lineage:  5e8f010ae8f9694e42d5cb63

The secret changes between packages and is shared by each Rust payload and its DLL. This changes traffic markers without changing collection code. The upload cipher is AES-CBC despite AES-GCM library code elsewhere.

A user-supplied screenshot shows a malware warning during HTTP navigation to the fallback domain. It does not establish an HTTPS upload response; the successful challenge widget is not a malware-safety result.

Supplied on 6 September 2026. The research team did not bypass the warning or contact the upload endpoint.

§ 13. Conditional persistence

The DLL's follow-on branch requires all three conditions:

1. Its network-send routine returns success.
2. Its process command line contains --incognito.
3. %LOCALAPPDATA%\Microsoft\OfficeBroker\svchost.exe is absent.

The Rust launcher supplies --incognito until its first successful browser injection, then clears the flag. The first successfully injected browser therefore receives the required argument. Browser discovery uses a hash map, so no fixed first browser is established.

The DLL builds a PowerShell script. Its primary launcher uses ShellExecuteExW with runas, requesting normal Windows elevation. This does not establish a silent UAC bypass or granted consent. The fallback launcher is incompletely reviewed, and a usable download URL has not been verified for every resolution branch.

The script attempts Defender path exclusions, an encrypted getPayload request, response decryption, hidden execution, and two on-logon tasks requesting the highest run level:

The downloaded program is saved at the first path and copied to the second. The follow-on response was not retrieved; its program contents and successful persistence remain unknown.

§ 14. Related research

On 2 May 2026, CyberArmor reported a YouTube Bitcoin-wallet lure as SalatStealer, identifying the same seall-vernous[.]com domain, t[.]me/gerj_threuh locator and Rust string-obfuscation pattern. The infrastructure overlap does not establish a common distributor or operator. CyberArmor investigation.

MalwareBazaar records a different 2,662,400-byte sample, first seen on 28 March and tagged RustyStealer, whose submitter reports the same Telegram path. Its import-hash group includes multiple family labels, including SantaStealer. These labels do not establish a definitive family assignment for the reviewed artifacts. MalwareBazaar record.

§ 15. Indicators

All eight hashes identify preserved or reconstructed artifacts. The advertised EXE's hash also matches GitHub's release-asset digest.

Downloads: evidence manifest, artifact inventory, repository timeline, YARA rules, bundle notes, and offline extractor.

The extractor accepts either exact reviewed outer PE, validates known hashes and reconstructs the inner EXE and DLL without executing them. Extract Binary.p from the historical MSI first. The public bundle excludes malware samples, captured credentials and complete forum-page copies.

§ 16. Detection

Search the eight hashes across downloads, archives, quarantines and endpoint file history. Correlate MSI execution with msiexec.exe and its extracted Binary-table executable. Treat the AMD metadata as a case-specific indicator.

The supplied YARA rules cover the two extraction stages:

These narrow rules can miss changed sizes, footer constants or source paths. They do not inspect the inner program through its encoded container.

YARA 4.5.4 compiled both rules and passed 15 focused checks. Each of two outer and two inner PEs matched only its intended rule. Negative checks covered the Python stub, README, local Python executable, four one-byte-truncated samples, and both outer samples with changed footer magic or length. This is fixture validation, not a broad false-positive benchmark.

Correlate process ancestry with executable private memory, temporary executables, sensitive application-data reads and requests to the recovered destinations. Same-process mapping can leave no separate stealer process. Memory checks should include section-like protections, a thread at a mapped entry point and damage to the original image header.

Disk fallbacks provide separate traces. One writes an EXE and vcruntime140.dll to a temporary location, launches the EXE, waits up to 90 seconds, and attempts EXE deletion. Another uses a per-run directory and attempts removal of the EXE, runtime DLL and directory. Original-loader deletion is a separate delayed command. Available traces depend on the branch taken.

§ 17. Incident response

Download only: preserve the filename, hash, source URL and time; quarantine the file and check execution records. Visiting the repository alone is not evidence of infection through this chain.

Execution confirmed: isolate the Windows endpoint and preserve process, installer, network and endpoint records. Acquire volatile evidence where feasible before cleanup or rebuilding. Reimage under the organization's response procedure and restore from trusted material.

From a separate trusted device, revoke exposed sessions and rotate accessible credentials, prioritizing remote access and administration. Check hosting and site-administration logs if the workstation held website credentials: stolen access can enable a website compromise without a server-side exploit. No downstream website compromise was observed in this investigation.

A missing installer or clean follow-up scan cannot exclude earlier collection. Retain samples privately for responders. Moderators should preserve the exact thread, revision, package hash and links before restricting the malicious download.

§ 18. Method and limits

Samples came from the public GitHub repository linked in the forum post. Analysis covered repository and release metadata, commit history, current and deleted packages, MSI tables, PE structures, disassembly, decompilation and offline payload reconstruction.

No repository code was imported or executed, and no extracted command-and-control destination was contacted.

There is no local PCAP, observed exfiltration, verified browser-decryption success, demonstrated security-product bypass, observed persistence or measured victim count. Runtime outcomes depend on environment, privileges, accessible data and network responses. The operator's real-world identity and a definitive malware-family attribution remain unresolved.