Someone Hacked Banks With AI. Then Asked Claude for a Resume

0:00 One person likely used AI tools to attack South Korean banks in about 2 weeks. Then that person left the folders that recorded the AI sessions open on the internet. The tools gave the

0:10 attacker speed and the open folders gave CrowdStrike its evidence. If you run coding agents on a server, you may have the same folders. Those folders held the actors instructions to the AI, logs of

0:21 its sessions, and its memory notes. Session logs are plain text, so anyone who can open the folder can read them. So, how did one open folder lead investigators from one server to the

0:30 next? And one prompt in those logs asked Claude to write a resume. First, here's what happened. CrowdStrike published its report this week. It says the campaign ran from late September to early October

0:41 2026. South Korean officials say the incident surfaced on the 30th of September. So, the whole campaign fits in about 2 weeks. CrowdStrike says the actor breached a service for checking

0:52 loan progress at one bank. At another bank, the actor breached a mobile system that helps employees work. Counts differ by source. Shinhan said about 25,000 customers were affected. Reuters counts

1:04 at least nine banks, but that counts banks that disclosed attacks or appeared in local media. It's not a crowdstrike victim count. Korean officials count another way. The record, citing

1:14 officials, reports at least seven institutions and at least 68,000 people with affected data. South Korea's President Lee said, "It's now become possible to use AI to hack with ease,

1:25 even without specialized skills." Crowd Strike links the activity to an actor tied to China with moderate confidence. It bases that on a tool developed in China and on prompts written in Chinese.

1:36 China said it hadn't examined the case. Adam Meyers, a senior vice president at CrowdStrike, said, "This allows one human to target many customers in a very short period of time using the power of

1:47 AI." That's the reach claim in one sentence. Reach here means how many targets one person can work in a short time. Crowd Strike's word for the actor is likely one person. So one person is

1:58 probable, not proven. So what's real? The report names open source tooling. Several model backends and logs that record the sessions. What's unclear is how much the tools ran alone and how

2:09 much the actor drove by hand. No public source explains that split, so the evidence doesn't show how much skill the actor needed. The tool is Artex. Crowdstrike calls it an open- source

2:20 agentic pentesting tool developed in China. Pentesting means attacking a system to find its weak points, normally with the owner's permission. Agentic means the tool plans and acts in a loop.

2:30 Open source means anyone can download and read the code. This is how Rex works in general. Crowdstrike doesn't say how this actor set it up. Rex is a go program with a Postgress SQL database.

2:42 You give it an objective. A part called the planner breaks that objective into smaller steps. The readme calls each step an intent. So an intent is one smaller task on the way to the

2:52 objective. Picture a job board in a workshop. The planner pins the intents on the board and workers take them one by one. The readme calls the board a shared to-do list and the planner

3:02 refills it in multiple rounds. The picture breaks in one place. A board doesn't think, but in a tool like this, the language model does the thinking. Workers do the actual work. By default,

3:12 three workers run for each task. They execute bash commands and HTTP requests at the same time. In Go, each worker is a Go routine, a light thread, so the program can run many at once. Because

3:24 the workers run together, a slow step in one doesn't have to stop the other two. Here is a simple illustration, not something this actor ran. Say you point the tool at a test server you own and

3:35 set the objective, list the services this server exposes. The planner writes intents such as check which ports answer and fetch the homepage. Nothing in this example touches a real target. Two

3:46 workers take those intents and run the commands. The output comes back as raw text. Say they find a web service and a login page. The tool then writes what it learned into its records. It keeps two

3:56 kinds of record. The first record is the asset graph. It stores the things the tool finds, domains, IPs, services, and endpoints. In the test server example, the web service and the login page go

4:08 here. Each node in the graph is one thing the tool has seen. The each task also gets its own record, the exploration graph. It stores goals, intents, facts, and findings. So the

4:19 tool keeps a record of what it tried and what it learned round after round. A third part, the main agent handles chat with a human. A person can talk to the system while the workers run. The readme

4:30 calls this human in the loop. It means the operator can ask questions in the middle of a task. So the operator can steer a task and also watch it. So Rex is a loop that stores what it learns.

4:41 The model proposes steps, workers run them, and the graphs store the results. Then the model proposes the next steps. The operator supplies the objective and the access to the model. That's the

4:51 whole design in a few sentences. This design fits the reach claim. Several workers run at once and each task keeps its own exploration graph that fits one person running many tasks at once. It's

5:02 my reading. The readme says scanning or attacking real online systems is prohibited, but a rule in a readme doesn't stop anyone from running the code. So, the tool's own rules won't

5:12 protect you. A language model drives the loop, and Crowd Strike names the one it saw. This RTX instance used DeepSeek V4.1 Flash as its main language model. A backend is the model the tool calls. A

5:25 language model is the part that reads text and writes the next step. Two more models appear in the report. GLM 5.3 from GU AI and Grock 4.6. Crowdstrike says the actor added them for additional

5:37 clawed code sessions. That makes three model names in the report that aren't clawed. That detail matters. Clawed code is a coding agent and it can run on other model backends. So a clawed code

5:48 session doesn't always mean a clawed model did the thinking. Remember this each time you hear the word Claude in this story. Ruters adds that the suspect also used Anthropics Claude. In the

5:58 prompts that Reuters and Crowdstrike describe, the actor asked Claude directly. The reporting doesn't say which sessions ran on Claude models and which ran on other backends. Rex has the

6:08 same swappable design. Its readme says you set anthropic or open AI keys by environment variable or in the UI with an optional proxy. So the model is a part you can replace. A key is a secret

6:20 string that lets a program call a model. For defenders, that has one consequence. The model is a part you can swap. So blocking one provider won't stop the tool. Your own servers are the part you

6:31 control. The trail on disk matters to you. Claude Code creates these files for any user, including you, during normal work. Each Cloud Code session starts with a fresh context window. The agent

6:42 remembers nothing from the last session. A context window is the text the model can see right now. The docs describe two ways to carry knowledge forward. Say you tell claude code on Monday that your

6:53 tests need a local database. On Tuesday, a new session knows nothing about that. So something has to write it down. You could repeat yourself every morning, but a file saves that work. One way is a

7:03 file called claude.md. You write it. It holds instructions such as how to run the tests. Claude code loads it at the start of every session. You can read it and change it yourself.

7:14 Automemory is the second way. Claude writes these notes itself as it works. Claude code loads them into every session too. So a note from Monday can show up on Tuesday without you typing it

7:24 again. The docs add one warning. Claude treats both files as context, not as enforced configuration. So the files guide the agent, but they don't force it to obey. Don't use claude.md as your

7:36 only security control. That explains a file crowd strike found. It sat in aclaude folder in a file named claude.md. It was a pen testing prompt written in

7:47 Chinese that told the model how to run its tests. Crowdstrike found it in an open directory on one server. There's a third record, the full session log. Claude code writes each session as a

7:59 file of JSON lines. It saves each session as one file in a projects folder inside.Cloud in your home directory. So a busy server can hold many of them. Each file ends injl.

8:11 New line delimited means each line is one complete JSON record. The file is a full log of the session in plain text. Anyone who can read it can replay what the agent was asked and what it did. By

8:23 default, Claude code deletes these logs after 30 days. A setting called cleanup period days in the settings.json file inside.claude changes that. That comes from Simon Willis's October 2025 post.

8:36 So, check the current docs for the default. 30 days is longer than the span Crowd Strike describes. If the actor kept the default, a campaign from late September to early October would still

8:46 be on disk. The actor's real setting is unknown. So, three kinds of files collect on disk. Instructions say what the operator wanted. Memory says what the agent learned. Transcripts say what

8:57 happened in order. Together, they tell the whole story of a session from the goal to the result. That's useful when you debug your own agent. But it's a problem when strangers can read the

9:07 folder. The same plain text that lets you replay a session lets them replay it too. Access to the folder is the only barrier between a stranger and the file. Memory also loads into every session. So

9:19 one secret in a memory note appears in every later session. That's my inference from the docs. Now back to the question. The register reports that researchers first examined an exposed directory on a

9:29 server tied to the attacks. That's where the chain starts. an open directory that the researchers could list. That directory held the Chinese language instruction file. Crowdstrike says the

9:40 file also referenced an IP address in Hong Kong. The researchers followed that reference to a second server. So, the file gave them a lead to the next server. On the Hong Kong server, Open

9:50 Directories held CLA code session histories, Rex configuration files, and claude memory files. The sessions covered late September to early October. They targeted South Korean

10:00 organizations. The instruction file named a second server. That server's folders held sessions that targeted South Korean organizations with dates. So, one exposed folder revealed a larger

10:11 operation. In general, each type of file answers a different question for an investigator. Session histories show what the operator asked and when. Configuration files show how the tool is

10:22 set up. Memory files show what the agent had learned. Together, they let an investigator rebuild the sequence of events. Here the contents of the configuration files are unreported. Why

10:32 those folders were open and for how long is unknown. Who else read them is also unknown. A web server or file share that serves a home directory can expose a cloud folder. That's a general

10:44 possibility and nothing shows it's what happened here. Say a team shares build files from a file server and the share route is a home directory. Every dot folder in that directory is now shared

10:54 too, including claude. Nobody on the team chose to publish it. Rooters and CrowdStrike described what the actor asked Claude. The actor asked where threat actors typically sell Korean

11:04 databach information. The actor also asked for help finding Korean Telegram sales groups. The reporting doesn't say when in the campaign the actor asked these questions. Whether Claude

11:14 answered, refused, or flagged them is unknown. Nothing primary shows what Anthropic did afterward. Crowd Strike also describes a prompt that asked Claude to write a security researcher

11:24 RZU with bullet points about the Ardex activity. Writer says that prompt came from a Claude session. The prompt held personal details. Crowd Strike says they likely belong to the actor, but the

11:35 available information cannot definitively associate them. So, I won't show or say those details. CrowdStrike's own conclusion supports the reach half of the story.

11:46 It says this activity demonstrates how AI tooling can enable a financially motivated threat actor to conduct multiple intrusions within a short time span. It also assesses that adversaries

11:56 will keep experimenting with AI tooling to raise their operational tempo. Operational tempo means how many actions an attacker finishes in a given time. A loop of planner and workers can run many

12:07 steps at the same time. So it can do more in the same time than one person at a keyboard. That is the practical meaning of reach for a defender. AI gave this actor reach. The exposed folders

12:18 and the resum prompt suggest it did not give the actor discipline. The folders held instructions, memory, and full transcripts. This is my inference, not a crowdstrike finding. For defenders, the

12:29 reach half matters more. Plan for an attacker who works fast because the tooling speeds up the work. Don't plan around attackers who make mistakes. Speed gives you less time to react, so

12:39 clean configuration matters more. Here's a recap you can repeat to a colleague. First, a planner turns an objective into intents. Second, workers run them and graphs store the results. Third, a model

12:51 does the thinking and you can swap it. Fourth, Cloud Code leaves instructions, memory, and transcripts on disk. Fifth, one open folder pointed to the next server. CrowdStrike didn't write this

13:01 checklist. I built it from the docs. First, if you run Claude code on a server, search forcloud folders. Check every home directory and every project directory. Include build servers and

13:13 shared machines. Write down each path you find. You can't fix a folder you don't know about. Second, if a web server or file share can reach a home directory, close that path. Do not serve

13:24 home directories. Then request the folder's path from outside your network. Confirm that the server refuses the request. Run that test after each change to the server. Third, if you do not need

13:34 old transcripts, lower the retention before you change it. Confirm the setting name and default in the current claude code docs. Then set cleanup period days in your settings file. A

13:44 shorter period leaves less for a stranger to read. Fourth, treat agent logs as sensitive data. A full session log can hold anything that appeared in the session. Limit who can read the

13:54 folder. Also, limit where backups copy it. Give it the same care as your other sensitive data. Fifth, read your claude, MD, and memory files as if a stranger will read them. If they contain internal

14:06 server names or secrets, remove them. Do not rely on the file to enforce a rule. Also, tell your team that these files are not private notes. Sixth, check where the folder travels. Backups,

14:18 container images, and shared volumes can carry a cloud folder to places you did not plan. Review each one because a copy in one forgotten place is still a copy. My verdict for DevOps and platform

14:30 engineers, audit these folders this week. You can't control how fast an attacker works, but you can control what your own servers publish. That is the one decision this video asks of you. How

14:40 many days should an agent transcript stay on a production server? A shorter period is safer for secrets, but a longer one helps with debugging. Pick the shortest number your debugging

14:50 allows and tell me yours.