The hacker who asked an AI to write a résumé

Somewhere on a server in Hong Kong, an attacker's AI coding sessions were sitting in an open folder: the targets, the tools, the step-by-step notes and, in one session, a request to write a "security researcher" résumé listing the results of the attack, complete with a name, a university and a phone number.

That detail comes from a report CrowdStrike published on October 7 about a campaign against South Korean banks and other financial firms in late September and early October 2026 (The Register has a good summary). CrowdStrike is careful here: it says the résumé details likely belong to the attacker, but it can't definitively connect them. So the useful part isn't who did it. It's how much the attacker's own AI tools wrote down. AI agents keep a record of everything. If your team uses or builds them, that record is sitting on your machines too, and someone should decide where it lives, who can read it and how long it stays.

The attacker worked with an open-source AI penetration-testing tool called ARTEX, alongside Claude Code and several AI models. CrowdStrike's researchers found Claude Code session histories, configuration files and memory files, which gave them, in CrowdStrike's words, "direct insight into the threat actor's operational methodology and tooling."

That isn't a special hacker setup. It's how agent tools normally work. To let you pick a session back up, they save it. Anthropic's own documentation says Claude Code stores session transcripts on the user's computer in plaintext and keeps them for 30 days by default, a period you can change. Other agent tools keep similar histories, and many read a "memory" or instructions file every time they start.

Put together, those files are a detailed diary of your team's work:

None of that is a flaw. History is what makes these tools useful. But it's a record most teams never actually decided to keep.

These files weren't taken in a clever break-in. They sat in open directories on servers the attacker controlled, readable by anyone who looked. On one server, CrowdStrike found the agent's instruction file served up with the rest of the folder, and it mentioned a second address in Hong Kong. That's where the session histories and memory files were.

That's the ordinary way records like this escape: a folder shared more widely than intended, a backup or sync tool copying hidden folders somewhere new, a test server left open, a project copied to a shared drive with everything inside it.

1. Where do the histories live? List the AI tools your team uses or has built, and where each one keeps its sessions, memory and settings: on laptops, on a shared server, in the vendor's cloud, or all three.

2. Who can read them? Treat them like email. They belong to the person who made them, not in shared drives, code repositories or any folder a web server publishes. Check that backup and sync tools aren't quietly copying them somewhere wider.

3. How long do you keep them? Pick a period on purpose and set it in the tool where you can. Shorter keeps less lying around; longer can help when you need to trace what happened. Either can be right, as long as someone chose it.

4. What never goes in? Agree on a short list of things nobody pastes into an AI session or memory file: passwords and API keys, customers' personal information, anything covered by a confidentiality agreement. Keys belong in a password manager or your systems' secret storage, where the agent can use them without writing them down.

The person behind this campaign probably never thought of their AI sessions as evidence. Most teams don't think of theirs as a record either. Your tools remember everything your team asks them, so make it a record you chose to keep, stored somewhere only the right people can open.