Author: UnboundCompute

A BadUSB attack starts with a device that lies about what it is. It looks like an ordinary flash drive, but the tiny controller chip inside has been reprogrammed to tell your computer it is a keyboard. The moment you plug it in, it starts typing commands on its own, far faster than any person could, and the machine obeys because keyboards are trusted by design. There is no virus file to find, because the trick is not a file at all. It is the device claiming an identity it should never have.

What does HID mean, and why does your computer trust keyboards?

HID stands for Human Interface Device. It is the standard category the USB specification uses for the things a person operates directly: keyboards, mice, game controllers, and similar input hardware. When you plug one in, the device introduces itself with a small description of what it is and what it can send. Your operating system reads that description, sees the word keyboard, and loads a generic driver that is already built into the system. No installation, no prompt, no scan. You expect a keyboard to send keystrokes, so a keyboard is allowed to send keystrokes the instant it arrives.

That trust is deliberate and it is also the whole problem. A keyboard is the one peripheral that is assumed to speak for the human sitting at the desk. Whatever it types, the computer treats as your intent. There is no meaningful check on whether a keyboard is real, whether a human is actually pressing keys, or whether the typing speed makes any sense for a person. The identity a USB device announces is taken at face value, and the identity is exactly what a BadUSB attack forges.

How a BadUSB attack forges an identity at the firmware level

Every USB device runs a small piece of software of its own, called firmware, on its controller chip. That firmware decides the descriptor the device shows the host: this is a mass storage device, or this is a keyboard, or both. On many cheap controllers that firmware can be rewritten. Once it is rewritten, the same physical stick that used to say flash drive can instead say keyboard, and it will hold that story every time it is plugged into any machine.

Picture a made up example. An attacker leaves a plain looking USB stick in the parking lot of an office we will call Acme. A curious employee finds it, plugs it into a work laptop to see who it belongs to, and expects a folder of files. Instead the stick has been reprogrammed. Its firmware announces a keyboard, the laptop loads the trusted keyboard driver without asking, and the device fires off a short burst of keystrokes it had stored on board. To the laptop, a person just sat down and typed very quickly. Nothing about the traffic looks wrong, because as far as the operating system knows, a keyboard did what keyboards do.

There is no malware to scan for. The attack is the device claiming to be a keyboard, and your computer has no habit of doubting a keyboard.

Why antivirus does not see it

Antivirus works by inspecting files and processes for known bad patterns. A BadUSB attack hands it nothing to inspect. The malicious part lives in the device firmware, not on disk, and the firmware never copies a suspect file onto your machine. What reaches the computer is a stream of keystrokes, which is the most normal input a computer can receive. You cannot quarantine a key press. You cannot flag a keyboard as malware without flagging every keyboard.

This is why the defense cannot be a scanner. The failure is a trust decision made before any file exists: the decision to believe a device’s claim about its own identity. Fixing it means changing who is allowed to become a trusted keyboard, and under what conditions, rather than hunting for something to delete.

How is this different from juice jacking?

It is easy to lump every USB threat together, but these are two different problems and the fix for one does not fix the other. Juice jacking is about a charging port or cable that carries data as well as power, so a public charging station could try to pull files off your phone or push something onto it while it charges. It abuses the fact that one USB connector moves both power and data. We cover that risk on its own in juice jacking explained.

A BadUSB attack is not about power or file transfer. It is about identity. The device is not reading your data or sneaking a file across, it is pretending to be a class of hardware your computer trusts and then acting as that hardware. One is a data over power problem. The other is an identity problem. A data blocker that strips the data pins can help against juice jacking, but a device you deliberately plug in as a keyboard still gets to be a keyboard.

How do you defend against it?

• Never plug in a device you did not buy. A found stick, a giveaway drive, a cable of unknown origin. The single most reliable defense is refusing the physical introduction in the first place.
• Use USB device control and allowlisting. Tools such as USBGuard on Linux let you approve devices by their properties and block everything else by default, so a brand new keyboard appearing out of nowhere is refused rather than trusted.
• Require confirmation before a new keyboard is trusted. A policy where a freshly connected input device has to be approved by the person at the machine removes the whole point of a device that types the instant it is plugged in.
• Disable unused USB ports or fit port blockers. If a port does not need to accept input hardware, close it. Fewer open ports means fewer places a forged keyboard can introduce itself.
• Lock your screen and use short timeouts. A device that types into a locked machine reaches almost nothing. Short idle timeouts shrink the window in which a burst of typed commands can land on a desktop left open.
• Treat trust as physical, not just digital. The same mindset that governs an evil maid attack applies here: once someone can touch your hardware, software controls alone are not enough.

Peripherals earn trust by claiming an identity, and that claim is rarely checked. The same theme runs through how Bluetooth LE pairing breaks, where a trusted wireless channel can be set up more loosely than people assume. The lesson under all of it is one worth carrying into software too: an identity a system merely announces is not the same as an identity a system has verified. That gap between assumed trust and proven trust is exactly the kind of assumption we care about testing, and you can read more about how we think on our about page.

Frequently asked questions

What is a BadUSB attack?

It is an attack where the firmware inside a USB device is reprogrammed so the device lies about what it is. A stick that looks like a flash drive tells your computer it is a keyboard, and the moment you plug it in it types a burst of commands the computer trusts, because keyboards are trusted by design.

What does HID mean and why does it matter here?

HID stands for Human Interface Device, the USB category for input hardware like keyboards and mice. Your operating system loads a built in driver for a keyboard automatically and lets it send keystrokes right away. A BadUSB attack abuses that trust by announcing itself as a keyboard when it is really something else.

Why does antivirus not catch a BadUSB attack?

Because there is no malicious file to scan. The trick lives in the device firmware, and what reaches your computer is a stream of keystrokes, which is the most normal input a machine can receive. You cannot flag a keyboard as malware without flagging every keyboard, so the defense has to be about controlling which devices are trusted, not scanning for files.

How is a BadUSB attack different from juice jacking?

Juice jacking is about a charging port or cable that moves data as well as power, so it might read or plant files while your phone charges. A BadUSB attack is not about power or file transfer at all. It is an identity problem, where the device pretends to be a class of hardware the computer trusts and then acts as that hardware.

How do you defend against a BadUSB attack?

Never plug in a device you did not buy, especially a found or giveaway stick. Use USB device control and allowlisting such as USBGuard, require confirmation before a new input device is trusted, disable unused ports or fit port blockers, and keep your screen locked with short idle timeouts so typed commands reach almost nothing.

Put an autonomous researcher on your own systems

UnboundCompute is an autonomous security researcher that reasons about how an application fits together and proves the access control and injection bugs it finds. We are opening a small number of founding design partner seats: private early access pointed at a staging target you choose, and a say in what it looks for. If your team ships software worth pressure testing, apply to the design partner program.

A DMA attack abuses Direct Memory Access, the feature that lets some peripherals read and write system RAM directly, without asking the CPU for each byte, because that is faster. A malicious device plugged into a Thunderbolt or PCIe port can ride that same channel to read and write memory behind the operating system’s back. It can scrape secrets straight out of RAM, or patch the code that checks the lock screen, while the machine sits locked on a desk. The login prompt never mattered here, because the attack never went near the keyboard.

What is Direct Memory Access and why does it exist?

Moving data through the CPU is slow. If a disk controller, a network card, or a graphics card had to interrupt the processor for every chunk of data it copied, the processor would spend most of its time shuffling bytes instead of running programs. Direct Memory Access solves that. The device is handed the ability to talk to main memory on its own, so it reads and writes RAM while the CPU gets on with other work. When the transfer finishes, the device raises one interrupt to say it is done.

This is a deliberate design and a good one. A high speed capture card writing video frames, or a network card receiving packets, needs to place data in memory fast. The point to remember is what the feature grants: a device that can do DMA is trusted to reach into system memory directly. On a machine that hands out that trust freely, the port becomes a door into RAM.

How a DMA attack turns a plugged in device into a memory reader

Thunderbolt is the part that surprises people. A Thunderbolt port is not only a data port. It carries PCI Express, the internal bus that expansion cards sit on, out to a socket on the side of the laptop. A device on that bus is treated much like a card installed inside the case, which means it can be granted the same DMA rights an internal card has.

So the attacker does not need to break a password. They build or buy a small device that presents itself as a normal peripheral, plug it into the exposed port, and ask the bus for memory. If nothing restricts the request, the device reads whatever addresses it likes.

With direct reach into RAM, two moves open up:

• Read secrets out of memory. Disk encryption keys, session tokens, cached passwords, and private data all live in RAM while the machine is on. A device that can read arbitrary memory can copy them out, even though the screen is locked.
• Write memory to change behavior. The routine that decides whether your password is correct is just bytes in RAM. Overwrite the check so it always returns success, and the lock screen accepts anything you type.

The lock screen is a question the operating system asks itself in memory. A device that can rewrite that memory gets to answer the question for it.

A locked laptop on an open desk

Picture an invented machine, the Acme laptop, left locked on a desk while its owner steps away for coffee. The screen shows a password prompt. Everything looks safe. But a Thunderbolt port on the side is open and active.

An attacker walks up, plugs a prepared device into that port, and the device requests a sweep of system memory. Because the machine grants DMA to the device without restriction, the request succeeds. In one path the attacker copies the region holding the disk encryption key and walks away with it. In another the attacker locates the password check and patches it in place, then types any password and is let in. The owner returns to a laptop that looks exactly as they left it. Nothing was typed at the prompt, and no keyboard log would show a thing, because the keyboard was never used.

This is close in spirit to the evil maid attack, where brief physical access to an unattended machine is enough to tamper with it. It also overlaps with the cold boot attack, another route to reading secrets out of memory, though that one chills and reboots the RAM rather than riding a live bus.

Why the login prompt was never the barrier

It helps to compare this with a threat that looks similar and is not. In juice jacking, a hostile charging port pushes power and data over USB and tries to trick the operating system into mounting the device or accepting a payload. That attack still goes through the software stack. It knocks on the front door.

A DMA attack skips the door. It does not send input the operating system will read and validate. It reaches under the operating system and touches memory directly, so the checks that guard the login path are never consulted. That is why a strong password does not help here on its own. The password matters only if something forces the attacker’s device to go through the code that checks it, and raw DMA does not.

How do you defend against it?

The fix is to stop trusting a plugged in device with unrestricted memory, and to time that distrust for the moment the machine is most exposed.

• Turn on the IOMMU. The IOMMU, called Intel VT-d on Intel platforms and given an equivalent name by AMD, sits between devices and memory and translates the addresses a device may use. With it configured, a device sees only the small window it was assigned, not all of RAM. It is the single most important control here, so confirm it is enabled in firmware and used by the operating system.
• Enable Kernel DMA Protection. On modern systems this feature blocks DMA from Thunderbolt and similar ports until a user has logged in, and keeps blocking newly attached devices while the screen is locked. That closes the exact window in the Acme example, the locked and unattended desk.
• Set Thunderbolt security levels and require approval. Thunderbolt can be told to require a human to approve each new device before it is granted access, rather than trusting anything inserted. Set the security level so an unknown device gets nothing until someone says yes.
• Deny DMA before login and while locked. The dangerous moments are the ones with no user present: before boot finishes and whenever the machine is locked. Configure the system so external DMA is refused in both states, and only allowed once an authenticated user is active.
• Disable ports you do not use. If a laptop never needs Thunderbolt or an external PCIe path, turn it off in firmware. A port that grants no access is not a door at all.

The theme across all of these is the same. Speed features are safe until they are handed to an untrusted device at an unguarded moment, and the defense is to narrow both what a device can reach and when it is trusted at all.

This class of problem is about an assumption the machine makes, that a device on the bus is allowed in memory, rather than about a malformed input. That is the kind of hidden assumption an autonomous researcher built to test assumptions, rather than to match known payloads, is meant to probe. You can read more about how we think about that on our about page.

Frequently asked questions

What is a DMA attack?

It is an attack that abuses Direct Memory Access, the feature that lets some peripherals read and write system RAM directly without going through the CPU. A malicious device plugged into a Thunderbolt or PCIe port uses that channel to read secrets out of memory or to patch the lock screen check, all while the machine sits locked.

Can a DMA attack work while my laptop is locked?

Yes. That is the point of it. The attack reaches memory directly and never sends input through the login path, so the lock screen is not consulted. A device with unrestricted DMA can copy encryption keys out of RAM or overwrite the password check even though the screen shows a locked prompt.

Why is Thunderbolt a risk when USB feels safe?

A Thunderbolt port carries PCI Express out to the side of the machine, so a device on it is treated much like an expansion card inside the case and can be granted the same direct memory rights. Threats like juice jacking still go through the software stack over USB, while a DMA attack goes under the operating system entirely.

How do I defend against a DMA attack?

Enable the IOMMU so a device sees only the memory window it was assigned, turn on Kernel DMA Protection so external ports are blocked before login and while locked, set Thunderbolt to require approval for each new device, and disable ports you never use. The goal is to narrow both what a device can reach and when it is trusted at all.

Put an autonomous researcher on your own systems

UnboundCompute is an autonomous security researcher that reasons about how an application fits together and proves the access control and injection bugs it finds. We are opening a small number of founding design partner seats: private early access pointed at a staging target you choose, and a say in what it looks for. If your team ships software worth pressure testing, apply to the design partner program.

A cold boot attack recovers secrets from a computer’s memory after the power is cut, using a physical fact that surprises most people: RAM does not forget instantly. For a short window the bits stay readable, and the most valuable of them is the disk encryption key that a running system keeps in memory so it can work. An attacker with the machine in hand cuts power, boots a tiny program that reads memory back out, and walks away with the key that was supposed to protect an encrypted drive.

What a cold boot attack actually exploits

Dynamic RAM stores each bit as a charge in a tiny capacitor. Those capacitors leak, so the chip refreshes every cell many times a second to hold the value. When you remove power the refresh stops, but the charge does not vanish. It drains over a period that ranges from a fraction of a second to several seconds at room temperature, and the pattern of bits stays mostly intact for that whole time. This slow fade is called DRAM remanence, and it is the gap the attack lives in.

The trick that makes the window longer is temperature. Cold capacitors leak slower. If you chill the memory chips with a can of compressed air held upside down, or colder still, the contents can survive for minutes instead of seconds, long enough to move the chips into another machine and read them there at leisure. That chilling step is where the name comes from.

A locked laptop that is only asleep is holding its own decryption key in a place an attacker can read.

Why the disk key sits in RAM in the first place

Full disk encryption protects data at rest. When the machine is off, the drive is a block of ciphertext and the key is derived from your passphrase or unwrapped by the TPM at boot. But once the system is running it needs to read and write files constantly, and it cannot ask you for the passphrase on every block. So it keeps the master key, or a key derived from it, resident in RAM for the whole session. That is not a bug. It is how the drive stays usable in real time.

The consequence is the whole point of the attack. A machine that is powered on, even locked, even suspended to RAM, is a machine whose decryption key is loaded and waiting. Sleep does not clear it. The lock screen only blocks the keyboard and mouse; it does nothing to the contents of memory. So the security of an encrypted disk quietly depends on the state the laptop was left in, not just on the strength of the passphrase.

An example: the Acme laptop left suspended

Picture a work laptop from an invented company, Acme. An employee closes the lid at an airport gate and the machine suspends to RAM. The drive is encrypted, the login screen is up, and the employee assumes the data is safe because the disk is locked. Someone takes the laptop. Instead of guessing the passphrase, the attacker cuts power, then immediately powers the machine back on into a small purpose built program loaded from USB. That program does one job: copy the raw contents of memory to an external drive. Somewhere in that dump, in a predictable structure, is the disk key. The encryption did its job perfectly and still lost, because the key was sitting in RAM the entire time the lid was closed.

How the key is found in a memory dump

A raw memory image is a large, messy blob, but disk encryption keys are not hidden in it well. Cipher key schedules have a recognisable structure, so an attacker scans the dump for byte patterns that match an expanded key and confirms candidates by trying to decrypt a known block. Because remanence is not perfect, some bits in the dump will have decayed to their ground state. Key finding tools account for this by correcting a handful of flipped bits until a valid key falls out. The upshot is that even a partly faded image is often enough.

The defenses that close the window

There is no single switch that removes the risk, but several measures each shrink it, and together they close most of the gap. The right mix depends on how exposed the machine is.

• Shut down instead of sleeping in high risk situations. A full power off gives the memory time to fade and lets the system clear keys on the way out. If a laptop crosses a border or is left unattended, shut it down rather than suspending it. Hibernation writes state to the encrypted disk and powers off, which is safer than suspend to RAM as long as the hibernation image lands on the encrypted volume.
• Scrub keys on shutdown and reboot. The operating system can overwrite key material with zeroes as it powers down, so a dump taken a moment later finds nothing useful. Wiping memory early in the boot sequence closes the reboot into a tiny program path, because the attacker’s tool arrives to find the secrets already gone.
• Keep keys out of plain RAM. Some designs hold the key in CPU registers or on chip cache rather than main memory, or seal it in the TPM and release it only under strict conditions. A key that never sits in DRAM cannot be read out of DRAM.
• Use hardware memory encryption. Modern platforms can encrypt the contents of RAM with a key held inside the memory controller. A dump of the chips then yields ciphertext, and moving the chips to another machine yields noise, because the decrypting key never leaves the processor package.
• Refuse to boot untrusted code. Boot protections that check the loader before running it stop the classic reboot into a rogue memory dumper. See how secure boot works for the mechanism that verifies each stage before handing over control.

Where this sits among physical access attacks

A cold boot attack needs the attacker to hold the machine, which places it in the same family as the evil maid attack, the umbrella for threats that assume brief physical access to a device you left behind. It is a close relative of the DMA attack over Thunderbolt, which reaches the same target, the contents of RAM, but through a fast peripheral port instead of by pulling power. Encrypting the data on the disk is not the finish line; the memory of a running machine is a second copy of your secrets, and it is far softer.

The common thread across all three is that a defense which looks complete on paper can leave a live copy of the very thing it protects sitting in an easier place. That gap, between what a system claims to secure and what it actually leaves exposed, is exactly the kind of assumption an autonomous researcher built to test assumptions is meant to probe. More about how we think about that on our about page.

Frequently asked questions

What is a cold boot attack?

It is a physical attack that reads secrets out of a computer’s RAM after the power is cut. Because memory chips hold their contents for a short window rather than clearing instantly, an attacker can reboot into a small program, or move the chips to another machine, and dump memory to recover the disk encryption key the running system kept there.

Why does data stay in RAM after the power is off?

Dynamic RAM stores each bit as a charge that leaks slowly once the chip stops refreshing it. At room temperature the bits fade over a period from a fraction of a second up to several seconds, and chilling the chips stretches that window to minutes. This slow fade is called DRAM remanence.

Does full disk encryption stop a cold boot attack?

Not on its own. A running system keeps the disk key resident in RAM so it can read and write files, so a machine that is powered on, locked, or asleep is holding its own key in memory. The encryption protects the drive at rest, but the key in RAM is a second copy an attacker can read.

How do you defend against a cold boot attack?

Shut the machine down fully instead of sleeping in high risk situations, scrub keys to zero on shutdown and early in boot, keep keys in CPU registers or the TPM rather than plain RAM, use hardware memory encryption where the platform supports it, and enable boot protections that refuse to run untrusted code.

Put an autonomous researcher on your own systems

UnboundCompute is an autonomous security researcher that reasons about how an application fits together and proves the access control and injection bugs it finds. We are opening a small number of founding design partner seats: private early access pointed at a staging target you choose, and a say in what it looks for. If your team ships software worth pressure testing, apply to the design partner program.

An evil maid attack is what a stranger can do to your laptop during a few unsupervised minutes while it sits powered off in a hotel room, on a coworking desk, or in a bag handed over at a border checkpoint. The name comes from the picture of a hotel maid who slips into your room, does something to the machine on the desk, and slips out again in the time it takes to change the towels. Full disk encryption keeps the data safe while the device is off, but it does nothing for the code that runs before you type your password, and that gap is exactly where this attack lives.

How the evil maid attack works

Picture an invented machine, the Acme laptop, encrypted with full disk encryption and left in a hotel room for the afternoon. The attacker does not need to break the encryption. They need to change what happens the next time you turn the device on.

The trick is that a small piece of code has to run before the disk can be decrypted. Something must draw the password prompt, take your keystrokes, and hand the key to the disk. That code sits in the firmware and the bootloader, in the early boot chain, and on an unprotected machine it is not itself encrypted, because it is the thing that does the decrypting. It has to be readable to run. So the attacker replaces it.

They power on the Acme laptop, or boot it from a USB stick, and overwrite the bootloader with a look alike. Their version shows the same password prompt you expect. When you come back, sit down, and type your passphrase, the tampered code captures it, tucks it somewhere on the disk or sends it out over the network, and then quietly hands control to the real boot path so the machine behaves normally. You notice nothing. The attacker returns later, enters the password they stole, and now the encryption that protected the whole disk simply opens for them.

Encryption answers the question of whether someone can read a disk they stole. It says nothing about whether the machine you are about to log into is still the machine you left behind.

Why encryption alone does not stop it

Full disk encryption is built to defend against a lost or stolen device. If the laptop never comes back to you, the attacker holds a locked box and no key, and the design works as intended. The evil maid attack breaks a different assumption. Here the device does come back to you, and you type your password into it yourself.

Think about what the encryption actually covers. It protects the data at rest, the files on the drive. It cannot protect the code that runs before the drive is decrypted, because that code is what asks you for the key. On a machine with no boot integrity checking, nothing verifies that the password prompt in front of you is the real one. You trust the screen, you type the secret, and a full disk encryption setup has no way to know the screen was swapped. The key exists only in your head until the moment you enter it, and that moment is what the attacker is patient enough to wait for.

The defenses that actually address it

The fix is not stronger encryption. It is making tampering with the boot chain either impossible or obvious, and treating your physical control of the device as part of the security model.

Verify the boot chain

Secure boot and measured boot are the technical core of the answer. Secure boot checks that each stage of startup is signed by a key the firmware trusts, so a swapped bootloader that is not signed will refuse to run. Measured boot goes further: a Trusted Platform Module, or TPM, records a fingerprint of each component as it loads, and the disk key is released only if those fingerprints match the known good machine. Tamper with the early code and the measurements change, so the TPM will not hand over the key and the tampering is caught before you ever type anything. If you want the mechanics of that signing and measurement, see how secure boot works.

Add pre boot authentication

Pre boot authentication puts a secret in front of the boot process itself, so an attacker cannot even reach a normal prompt without something they do not have. Paired with a TPM that expects a specific boot state, it narrows the window in which a fake prompt could be shown to you at all.

Make tampering visible

Low tech defenses matter here because the whole attack depends on you not noticing. Tamper evident seals over screws and ports mean that opening the case leaves a mark you can check. Some people photograph the exact pattern of a glitter nail polish blob over a seam, because it is effectively impossible to reproduce. None of this stops a determined attacker, but it turns a silent swap into something you can see.

Keep the device with you

The cleanest defense is to deny the physical access the attack requires. Keep the laptop on you rather than in the hotel safe. If it must be left, power it off fully rather than leaving it asleep, so keys are not sitting in memory. And treat any device that was out of your sight, through a border check, a repair counter, or an afternoon in a room, as potentially compromised. Reflash the firmware from a trusted source, or in a high stakes setting, retire the machine rather than trusting it again.

Where this sits among physical access attacks

The evil maid attack is one of a family that all start from brief hands on time with your hardware. A cold boot attack pulls encryption keys straight out of RAM in the seconds after power is cut, when the chips still hold their charge. A DMA attack over Thunderbolt reads live memory through a port without ever passing the lock screen. And a BadUSB device pretends to be a keyboard and types commands the moment it is connected. Each one sidesteps encryption by going after the machine while it runs or before it locks, rather than the data sitting still.

What ties them together is a lesson worth carrying: a threat model that stops at data at rest is only half a model. The other half is the integrity of the device you decrypt and the memory it holds while it runs. That second half is the kind of assumption an autonomous researcher built to test assumptions, rather than match a list of known payloads, is meant to probe. More on how we think about that sits on our about page.

Frequently asked questions

What is an evil maid attack?

It is an attack in which someone gets brief unsupervised physical access to your powered off device and tampers with its boot chain. The tampered code captures your disk encryption password the next time you type it, then the attacker returns to collect the password and decrypt everything.

Does full disk encryption stop an evil maid attack?

No. Full disk encryption protects data at rest, which defends a lost or stolen device. It does not protect the bootloader and firmware that run before you type your password, so an attacker who returns the machine to you can swap that early code to steal the password you type.

How do secure boot and a TPM help?

Secure boot refuses to run boot code that is not signed by a trusted key. Measured boot with a TPM records a fingerprint of each startup component and releases the disk key only if those fingerprints match the known good machine, so tampering is caught before you enter your passphrase.

What should I do if my laptop was left unattended?

Treat it as potentially compromised. Check any tamper evident seals, and if the device was out of your sight at a border check, a repair counter, or a hotel room, reflash its firmware from a trusted source or, in a high stakes setting, stop trusting that machine.

How can I reduce the risk in practice?

Keep the device with you, power it off fully rather than leaving it asleep, and turn on secure boot, measured boot, and pre boot authentication. Tamper evident seals make a silent swap visible, and treating any unattended device as suspect closes the gap the attack relies on.

Put an autonomous researcher on your own systems

UnboundCompute is an autonomous security researcher that reasons about how an application fits together and proves the access control and injection bugs it finds. We are opening a small number of founding design partner seats: private early access pointed at a staging target you choose, and a say in what it looks for. If your team ships software worth pressure testing, apply to the design partner program.

In July 2026 Hugging Face disclosed that an intruder who gained a foothold on a single dataset processing worker escalated to node level access, harvested cloud and cluster credentials, and moved across multiple internal clusters over a weekend. A Cloud Security Alliance post mortem read Hugging Face’s July 2026 disclosure as a textbook case of lateral movement: the break in touched one machine, but what followed turned that one machine into the run of the whole estate. We walk the shape of that problem here on an invented example app, Acme Cluster, and the controls that actually contain it.

The break in is rarely where the damage comes from

Most incident write ups spend their energy on the entry: the unpatched service, the leaked token, the phishing click. But a single compromised host is usually a small problem. It becomes a large one because of what the attacker does next, and what they do next is almost always the same move repeated. Land on one machine, read the credentials sitting on it, use those credentials to reach the next machine, and start again.

The damage scales with how far that loop can travel before something stops it. If the first host holds a credential that opens ten more, and each of those opens ten more, one foothold is the whole cluster within a few hops. The thing worth controlling is not only whether someone gets in. It is how far they get once they are in.

The entry is a door. The blast radius is the building. Guarding the door while leaving every internal room open is how one worker becomes every cluster.

What lateral movement actually looks like

Strip away the tooling and lateral movement is a plain sequence. Consider Acme Cluster, a typical machine learning platform with a fleet of worker nodes, a few internal services, and a cloud account behind them. An attacker gets code execution on one worker, perhaps through a poisoned dependency in a job. From there the steps are boring and reliable:

• Read what is in reach. Environment variables, files mounted into the container, an on disk cache of tokens. Secrets handed to a process at start up tend to stay readable for the life of that process.
• Ask the platform who it is. On a cloud host, the instance metadata endpoint hands back the machine’s own role credentials to anything that can make an HTTP request from that host. On a Kubernetes node, a mounted service account token names a workload identity the API server already trusts.
• Reuse to reach the next hop. Those credentials were minted for the workload, not the person, so they work the same from an attacker’s shell as from the real job. A database password, an internal API key, or a cloud role is now in hand.
• Repeat. Each new host is searched the same way, and standing trust between services means each hop rarely asks for a fresh proof of identity.

Two of those credential sources deserve a closer look, because they are where a single host quietly turns into many. The cloud metadata endpoint is covered in our piece on the instance metadata service, and the Kubernetes case in service account token abuse. Both describe the same failure: a credential that a compromised host can read and replay with no extra check.

Why over scoped and long lived credentials do the real work

The loop only pays off when the credential it finds is worth more than the host it was found on. Two properties make that true. First, scope: a token that can touch the whole cluster is far more useful than one that can touch a single queue. Second, lifetime: a credential that never expires can be harvested today and used next week, which is exactly what a weekend long intrusion needs. An over scoped, long lived credential sitting on a low value worker is a bridge from that worker to everything the credential can reach.

Technique matters too, not just theft. Some moves never read a stored secret at all. An NTLM relay forwards a victim’s authentication to a third service in real time, so the attacker moves sideways without ever seeing a password. Same shape, different mechanism: one identity, reused where it should never have reached.

Containing the blast, not just guarding the door

If the loop is read, reuse, repeat, then the defenses all aim at breaking one link in it. None of them stop the initial break in, and that is the point. They stop the second host from falling.

• Least privilege and tightly scoped credentials. The worker that runs a data job needs the one bucket and the one queue for that job, and nothing else. When its token is stolen, the blast radius is that bucket, not the account. Scope is the wall between hops.
• Short lived over long lived. Swap static keys for credentials that expire in minutes and refresh through the platform. A token harvested from a worker is close to worthless if it dies before the attacker can reach the next host with it.
• Network segmentation. A worker node has no business opening a raw connection to the billing database or another team’s cluster. Default deny between segments means a foothold can only talk to what its job genuinely needs.
• Remove standing trust between services. “Any workload inside the network is trusted” is the assumption that turns one hop into all of them. Make every service prove who it is on every call, so a stolen identity is checked, not waved through.

Notice that these are access control decisions, not intrusion detection ones. Most of them live in the same family as the failures we cover under access control: a system trusting a caller because of where it sits rather than checking what it is allowed to do.

How do you catch it while it is happening?

Prevention narrows the blast radius, but you still want to see the loop in motion. The signal is reuse in the wrong place. A worker’s service account normally talks to two endpoints, then suddenly enumerates the whole cluster. A credential minted for a job in one region is used from an address in another. A node identity that has read the same three secrets for months reaches for a fourth it has never touched.

None of these are malformed requests. Each one is a valid credential used by the wrong hands, which is why the useful detections watch behavior against a baseline rather than scan for bad payloads. Log which identity touched which resource, learn the normal shape per workload, and alert when a credential steps outside the path it has always taken.

This is the kind of assumption an autonomous researcher is built to probe: not “is there a known payload here” but “does this system trust a caller it has no reason to trust, and can that trust be walked from one host to the next.” In our own early testing, a frontier model drove the full methodology on its own and identified and verified real access control and injection issues in test applications it had not seen before. More of our writing sits under access control and on our about page.

Frequently asked questions

What is lateral movement?

Lateral movement is what an attacker does after the first break in: read the credentials sitting on a compromised host, reuse them to reach the next host, and repeat until they hold the whole environment. The initial entry touches one machine, but this loop is what turns one machine into many.

Why does blast radius matter more than the initial entry?

Because a single compromised host is a small problem until the attacker can move off it. If the credentials on that host are tightly scoped and expire quickly, the damage stays contained to one machine. Over scoped, long lived credentials are what let one foothold become the whole cluster.

How do short lived credentials help?

A credential that expires in minutes is close to worthless once stolen, because the attacker has to reach the next host before it dies. Long lived static keys can be harvested today and replayed next week, which is exactly what a slow, multi day intrusion needs.

What credentials do attackers look for on a compromised host?

Environment variables, secrets mounted into the container, an instance metadata endpoint that returns the host’s cloud role, and a Kubernetes service account token. Each one names an identity the rest of the system already trusts, so it can be replayed to reach further.

How do you detect lateral movement in progress?

Watch for a valid credential used in the wrong place: a service account that suddenly enumerates the whole cluster, a token used from an unexpected region, or a node identity reaching for a secret it has never read. The requests are well formed, so detection works off behavior against a baseline, not bad payloads.

Put an autonomous researcher on your own systems

UnboundCompute is an autonomous security researcher that reasons about how an application fits together and proves the access control and injection bugs it finds. We are opening a small number of founding design partner seats: private early access pointed at a staging target you choose, and a say in what it looks for. If your team ships software worth pressure testing, apply to the design partner program.

An exposed .env file is one of the fastest ways a working app turns into a breached one. That single file holds the secrets your code needs to run: the database URL, your cloud keys, the API key for your model provider, the signing secret behind your sessions. When a stranger can read it, they do not have to break anything clever. They log in with your own keys. This post walks through how a .env ends up reachable, what an attacker gets from it, how to check your own app, and how to recover once one has leaked.

The examples use an invented app called Acme Notes, so nothing here points at a real target.

What is a .env file and why does it matter?

A .env file is a plain text list of name and value pairs that your app reads at startup. It exists so that secrets live outside your code instead of being pasted into it. A typical one looks like this.

DATABASE_URL=postgres://acme:s3cr3t@db.internal:5432/acme
STRIPE_SECRET_KEY=sk_live_51Hxxxxxxxxxxxxxxxxxx
OPENAI_API_KEY=sk-proj-xxxxxxxxxxxxxxxxxxxxxxxx
SESSION_SECRET=9f2b7c1a4e8d
SMTP_PASSWORD=hunter2hunter2

Every line is a key to something real. The database URL opens your data. The payment key moves money. The model provider key spends your budget. The session secret lets an attacker forge a signed cookie and become any user. This is why the file is meant to stay on the server and never reach a browser, a public repository, or a public bucket. The moment it does, all of those doors open at once.

How does a .env file get exposed?

There are two paths that account for most cases, plus a few quieter ones.

The first is serving it over the web. If the file gets deployed into a public web root, or the web server is willing to hand back dotfiles, then a plain request returns it. An attacker does not guess a password. They ask for the file by name.

GET /.env HTTP/1.1
Host: acme-notes.example.com

If the response is your key list, the app is already compromised and you will not see it in any login log, because nobody logged in. They read a file.

The second path is git. Someone commits the .env before adding it to .gitignore, then pushes to a repository that is public, or private now and public later. Deleting the file in a later commit does not help, because git keeps history. The secret still sits in an old commit that anyone can check out. A repository that went public for one hour is a repository whose entire history is public forever.

The quieter paths matter too. A .env can leak through a storage bucket that was set to public, through a JavaScript source map that bundles server config by mistake, through a Docker image layer where the file was copied in and never removed, or through a backup archive left in a reachable folder. Same file, different door.

Deleting a leaked secret does not un leak it. Once a value has left your control, the only safe assumption is that a stranger has a copy.

Why does an exposed .env file happen so often in AI built apps?

Because the fast path skips the safe step. When you build with an AI coding tool or an app generator, the generator writes your secrets straight into a .env for you, which is correct. What it usually does not do is wire up the deployment so that file stays private. Tutorials say “just deploy” and move on. The step where you add .env to .gitignore before the first commit gets skipped, because the first commit felt like a formality. The result is an exposed .env file sitting one request or one git clone away from anyone who looks.

This is the same shape as other secret leaks in quickly built apps. It is a cousin of hardcoded API keys in the frontend, where the secret ships inside the browser bundle instead. Both come from the same habit: treating a secret like configuration instead of like a live credential. For the wider picture, the vibe coded app security hub maps the five failure shapes that keep showing up, and this is one of them. It also sits squarely in the access control category, because a leaked key is an access control failure that skipped the front door entirely.

The stakes are not abstract. A leaked model provider key lets an attacker run their own traffic on your account until the bill arrives, which is the same money drain covered in denial of wallet. A leaked database URL hands over every row. A leaked cloud key can spin up servers in your name.

How do you check your own app?

Three checks, all read only, all on an app you own.

• Request the file over the web. From a browser or with curl, ask for /.env on your own domain, then try the common variants: /.env.local, /.env.production, /.env.bak, and /env. Anything other than a clean not found is a problem.
• Grep your git history. The file can be gone from your working tree and still live in an old commit. Search the whole history, not just the current files.
• Scan the repository with a secret scanner. A tool that walks every commit will flag keys you forgot were ever there, including ones in files that are not named .env.

The git history check is the one people miss. A single command reads the past.

git log --all --full-history -- .env
git log -p --all -S 'sk_live_'

If either returns a commit, that secret has been in your history and must be treated as leaked, even if the file is deleted today.

How do you fix it and recover?

Fixing the leak and recovering from it are two different jobs. Do both.

Stop serving the file. The .env should never sit in the web root in the first place. Keep it outside the folder your web server publishes, and configure the server to deny dotfiles so a request for /.env returns nothing. Better still, move secrets into your platform’s secret manager and stop shipping a file at all.

Keep it out of git from the first commit. Add these lines to .gitignore before you commit anything, and commit an example file with blank values so teammates know which keys exist.

.env
.env.*
!.env.example

Rotate every secret that was ever exposed. This is the part that gets skipped, and it is the part that matters most. Deleting the file, making the repository private, or force pushing a cleaner history does not help you, because a copy may already be gone. Every key that appeared in an exposed .env file has to be regenerated at its source: new database password, new payment key, new model provider key, new session secret, new SMTP password. Until you rotate, the old keys still work for whoever grabbed them.

Rotation is uncomfortable because it means touching live services, but a deleted secret that still works is not fixed. It is just hidden from you.

What should you take away?

A .env leak is a quiet failure. No alarm fires, the app keeps working, and the only sign is a request for a file that should never have answered. That is exactly the kind of assumption an autonomous researcher is built to test: does the server hand back what it should keep, and does an old key still open a door. In our own early work, a frontier model drove the full methodology on its own and identified and verified real access control and injection issues in test applications it had not seen before. If checking your own assumptions before an attacker does sounds useful, you can read more about UnboundCompute.

Frequently asked questions

What is an exposed .env file?

It is a .env file holding your app’s secrets that has become reachable by someone who should not see it. The two common paths are the file being served over the web, so a request for /.env returns it, and the file being committed to a git repository that is or becomes public. Either way an attacker reads your keys without breaking in.

What can an attacker do with a leaked .env?

Whatever the keys allow. A database URL opens your data, a payment key can move money, a model provider key spends your budget, and a session secret lets an attacker forge signed cookies and act as any user. Because these are live credentials, the attacker skips the login screen entirely and there is no failed login to alert you.

I deleted my .env from git. Am I safe?

No. Git keeps history, so the secret still lives in the old commit even after you delete the file. Anyone who cloned the repository, or who reads a public history, still has the values. Deletion does not un leak a secret. You have to rotate every key that was ever committed.

How do I check if my .env is reachable over the web?

From a browser or with curl, request /.env on your own domain and try the common variants like /.env.local, /.env.production, and /.env.bak. Only test an app you own. Anything other than a clean not found means the file is being served and the app is already exposed.

How do I keep a .env out of git?

Add the file to .gitignore before your first commit, using lines like .env and .env.* while keeping an .env.example with blank values so teammates know which keys exist. If a secret has already been committed, scan the full history with a secret scanner and treat every value it finds as leaked.

What is the single most important recovery step?

Rotate every secret that was ever exposed. Regenerate the database password, payment key, model provider key, session secret, and any other value at its source. Until you rotate, the old keys still work for whoever grabbed a copy, so a deleted or hidden secret is not a fixed one.

Put an autonomous researcher on your own systems

UnboundCompute is an autonomous security researcher that reasons about how an application fits together and proves the access control and injection bugs it finds. We are opening a small number of founding design partner seats: private early access pointed at a staging target you choose, and a say in what it looks for. If your team ships software worth pressure testing, apply to the design partner program.