TechEarl

The Colonial Pipeline Attack: One Password, No MFA, a Fuel Crisis

In May 2021, ransomware shut down the largest fuel pipeline in the US and sparked panic buying across the East Coast. The way in was a single leaked password for an unused VPN account with no multi-factor authentication. A post-mortem of the attack chain, the ransom, and the lessons.

Ishan Karunaratne⏱️ 9 min readUpdated
Share thisCopied
How the 2021 Colonial Pipeline ransomware attack started with a single leaked VPN password and no MFA, caused a fuel crisis, and what it teaches about access.

In early May 2021, a DarkSide ransomware affiliate breached the IT network of Colonial Pipeline, the largest fuel pipeline in the United States, which carries close to half of the East Coast's fuel. Colonial shut the pipeline down in response, and it stayed down for about five days. The result was panic buying, fuel shortages across the southeastern US, and an emergency declaration. The way in was not exotic. The attackers used a single compromised password for a Colonial VPN account that was no longer in active use but was still enabled, and crucially, that VPN did not require multi-factor authentication. One leaked password, no second factor, and one of the most disruptive cyber incidents in US history followed.

This belongs in the human-layer map not because someone was tricked on a phone, but because the failure was identity and access hygiene, the same substrate that social engineering exploits. A reused or leaked credential and a missing second factor are what turn a stolen password into a breach, whether the password was phished, bought, or simply found in an old leak.

What happened, in one paragraph

In late April or early May 2021, the attackers gained access to Colonial's network using the password for a legacy VPN account (data theft was under way by 6 May). The account was inactive but had not been disabled, and the VPN lacked multi-factor authentication, so the password alone was enough. The password was later found in a batch of leaked credentials on the dark web, which is consistent with the employee having reused it somewhere that was breached, though investigators could not confirm its precise origin. The DarkSide affiliate stole roughly 100 GB of data and deployed ransomware on Colonial's IT and business systems. On 7 May, Colonial discovered the ransomware and proactively shut the pipeline down. It paid a ransom of about $4.4 million in Bitcoin, brought the pipeline back online around 12 May, and the US Department of Justice later recovered a majority of the Bitcoin.

The attack chain

Editorial illustration of the Colonial Pipeline attack: a single old key lifted from a pile of leaked keys, an open gate with an empty second-lock slot, a building wrapped in a padlock chain, and a pipeline valve turning shut.
One leaked password and no second lock: a foothold on the IT network, ransomware, and a precautionary pipeline shutdown.
  1. A leaked password. The credential for an old Colonial VPN account turned up in a dark-web leak, the kind of dump that aggregates passwords stolen from unrelated breaches. Password reuse is the likely mechanism: a password exposed somewhere else becomes a key here, though the precise origin was never confirmed.
  2. No MFA, no second barrier. The VPN account required only the password. Colonial's CEO, Joseph Blount, testified to Congress that the account "only had single-factor authentication" and that it was a complicated password, not a guessable one. A strong password did not matter, because a strong password that has leaked is just a known string. MFA is the control that makes a leaked password insufficient on its own, and it was absent.
  3. The dormant account. The account was no longer in active use, but it had never been deactivated. Unused accounts that remain enabled are pure liability: no one is watching them, no one would notice them being used, and they widen the attack surface for nothing.
  4. Ransomware and exfiltration. The DarkSide affiliate moved through the IT environment, exfiltrated around 100 GB of data for double-extortion leverage, and deployed ransomware.

The detail that contained it: IT versus OT

One nuance is essential to understanding this incident, and it is often lost in the headlines: the ransomware hit Colonial's IT and business network, not the operational technology (OT) that actually controls the pipeline. Colonial shut the pipeline down itself, as a precaution, partly because the billing and business systems it needed to operate and invoice were down, and partly to be certain the attack could not reach the control systems.

That is both a success and a warning. The success is that the segmentation between IT and OT held; the attackers did not get hands on the physical pipeline controls. The warning is how much disruption was caused anyway, by an IT-side ransomware event and a precautionary shutdown. For critical infrastructure, the lesson is that you do not need to compromise the control systems to cause a crisis. Taking down the business systems around them, and forcing a defensive shutdown, is enough.

The cost and the ransom

FigureWhat it was
~5 daysPipeline shutdown (around 7 to 12 May 2021).
~45%Share of the US East Coast's fuel supply the pipeline carries.
~$4.4 millionRansom Colonial paid to DarkSide, in Bitcoin.
~$2.3 millionValue the US DOJ later recovered by seizing the attackers' Bitcoin wallet.

Two careful notes on the numbers. The DOJ recovered most of the coins (about 63.7 of the roughly 75 bitcoin paid), but because the Bitcoin price had fallen between the payment and the seizure, the recovered dollar value (~$2.3 million) was about half the ~$4.4 million paid, not most of it. And Colonial's decision to pay, made under the pressure of a national fuel disruption, remains one of the most debated ransom decisions in the field; the company has said it paid to restore service as fast as possible.

The lessons I take from it

MFA on every remote-access path, no exceptions. This is the entire ballgame. A single factor means a single leaked or phished password is a breach. The VPN, the most exposed remote door into the network, had none. Multi-factor authentication on every externally reachable account, especially VPN and remote access, is the control that would most directly have stopped this. CISA built much of its post-Colonial messaging around exactly this point.

Decommission accounts you are not using. The account was dormant but enabled, which is the worst combination: live enough to be used, dead enough that no one was watching. Disable accounts when they fall out of use, and audit for the ones that have already slipped through.

Assume credentials will leak; design so that is survivable. You cannot prevent every password from ending up in a dump, especially with reuse. So the architecture has to assume it and not fall over: MFA, so a leaked password is not enough; monitoring, so unusual use is noticed; and least privilege, so a single account reaches little.

IT/OT segmentation is what kept this from being far worse. The wall between the business network and the pipeline controls is the reason this was a fuel-logistics crisis and not a physical-safety one. For any organisation with operational technology, that segmentation, and the discipline to keep it, is among the most important controls there is.

Where to go next

This is the credential-and-MFA case in the social engineering taxonomy, the substrate that the active social-engineering techniques exploit. Its closest siblings are the Uber breach, where a stolen password met weak MFA, and the Twitter and MGM breaches, where attackers phished or pretexted their way past authentication that a hardware key would have held.

Sources

Authoritative references this article was fact-checked against.

TagsSecurityRansomwareColonial PipelineMFACritical InfrastructureCase Study

Found this useful? Pass it on.

Copied

Ishan Karunaratne

Software Systems Architect · Senior Software Engineer · Engineering Leadership

Software systems architect and senior software engineer with more than two decades designing, building, and running production software, Linux systems, and DevOps infrastructure, and lately working AI into the stack. Now a CTO, though what I write here is drawn from the full arc of that work, across architecture, engineering, and operations, not any single job.

Keep reading

Related posts

How the 2019 Capital One breach used SSRF to reach the AWS EC2 metadata service, steal IAM credentials, and exfiltrate 100M+ records. Why IMDSv2 exists.

The Capital One Breach: SSRF and the Cloud Metadata Service

In 2019, a misconfigured firewall let an attacker use SSRF to reach the AWS metadata service, steal the server's IAM credentials, and exfiltrate the data of over 100 million Capital One applicants. It is the canonical cloud-SSRF breach and a prominent example of the attack class IMDSv2 was designed to mitigate. A post-mortem of the attack chain.

What column type a password should be in MySQL: VARCHAR(255) holding the encoded bcrypt or argon2id hash, why CHAR(60) and VARCHAR(60) and TEXT are wrong, and the lookup-then-verify flow.

What Column Type Should a Password Be in MySQL?

The column type for a password in MySQL is VARCHAR(255). You store the encoded output of a slow password hash (bcrypt, argon2id, scrypt), never a raw MD5 or SHA-256, and you never query the table by password.