Treasury’s breach ran through a remote-support key the agency never held

The week

On December 30, 2024, the U.S. Department of the Treasury sent Congress a letter no agency wants to write. A China state-sponsored actor, it said, had accessed some of its user workstations and unclassified documents earlier that month.

The way in was not a clever exploit against Treasury’s own defenses. It was a key: a digital secret, a long string of characters that one computer system presents to another to prove it is trusted. This particular key belonged to BeyondTrust, a third-party provider, and it was used to secure a cloud-based remote technical support service.

Remote support is the software your help desk uses when it says, “Let me take a look at your screen.” A technician, sitting somewhere else, sees what you see and can move your mouse, open your files and run commands on your machine. “Cloud-based” means the service runs on the vendor’s computers on the internet, not on the customer’s own servers. The vendor’s key is what tells each Treasury computer that an incoming support session is legitimate.

According to Treasury’s letter, the attacker obtained that key and used it to bypass the service’s security and remotely reach workstations in Treasury’s Departmental Offices. The intruder arrived holding the same credential the real help desk used, and Treasury’s machines let it in.

BeyondTrust had notified Treasury of the problem on December 8, and the compromised service was taken offline. Treasury called the event a major cybersecurity incident, a formal designation that triggers reporting to Congress, and said it was working with CISA, the federal government’s civilian cybersecurity agency, and the FBI.

Later reporting added a detail that raised the stakes. Offices affected included the Office of Foreign Assets Control, which administers sanctions. That is the part of Treasury that decides which foreign people, companies and governments are cut off from the U.S. financial system, which makes its internal documents of obvious interest to a foreign state.

There was a second thread that same month. BeyondTrust also disclosed vulnerabilities, meaning flaws in the software that an attacker could use to break in, in its remote support products. CISA added one of them to its catalog of known exploited vulnerabilities, a public list of flaws that attackers are actually using in the wild and that federal agencies are required to fix.

Put together, the week told a simple and uncomfortable story: one of the most trusted tools inside a government department had become the attacker’s front door, through a secret the department never held.

Take the help desk at any large organization on a Monday morning. A finance analyst cannot open a spreadsheet. A lawyer’s laptop will not connect to the printer. A senior official’s email has stopped syncing. In each case, a technician who may be in another building, another city or another country clicks a button, and within seconds is looking at the user’s screen and fixing the problem.

That everyday convenience is what remote support software exists to provide, and it exists for good reasons. Help desks need to see and control a user’s screen, and with a distributed workforce that has to happen over the network. IT operations usually buys the tools, deploys them everywhere and treats them as utilities, in the same mental category as the office printers.

The Treasury incident showed what they are in security terms: a privileged path into every endpoint where they are installed, secured partly by keys and infrastructure the customer does not control. “Privileged” means it carries more power than an ordinary user. An “endpoint” is any device at the edge of the network where a person actually works: a laptop, a desktop, a terminal at a branch counter.

That path has four segments, and each needs its own control. First, the organization has to know every remote access path that exists. Second, it has to know who holds the keys that authenticate the vendor’s service to its endpoints. Third, it has to limit what a session can do once it starts. Fourth, it has to detect when a session is misused. The segments do not overlap, and together they run from the vendor’s cloud to the user’s desk. Most agencies, and most private organizations, had parts of all four and the whole of none.

Master keys held by someone else

Remote support works like a set of master keys handed to a trusted locksmith who does not live in your building. He works for a company that has keys to many buildings, and he can let himself in whenever a tenant calls. Most of the time that is exactly what you want. The danger lies in someone copying his key ring.

Technically, the arrangement has three parts. A small program, usually called an agent, is installed on each computer the help desk may need to reach. A central service coordinates sessions, deciding who may connect to which machine. And a technician console lets support staff start sessions and take control.

In a cloud-delivered tool, that central service is run by the vendor on its own infrastructure. Each customer’s agents “phone home” to the vendor’s service, and the service vouches for technicians using cryptographic keys. A cryptographic key is simply a secret number that lets one system prove its identity to another. If you have the key, systems believe you are who the key says you are.

This model is popular for sound reasons. The customer does not have to run servers, apply updates to the coordination service or worry about keeping it available. The vendor handles all of that, across thousands of customers at once. But the same design means trust between the vendor’s service and the customer’s endpoints rests on secrets the vendor manages. The customer has, in effect, outsourced part of its front-door security to someone else.

Why attackers love these tools

Remote support software is built to do what an attacker wants to do: reach a machine from far away, see everything, control everything and often run commands with administrator rights. Its traffic is expected on the network, so it rarely looks suspicious. Attackers also install legitimate remote management tools after gaining a foothold, because the traffic looks normal.

The four controls, from the vendor’s cloud to the user’s desk

1. Inventory: every path into the endpoint

Organizations nearly always run more remote access tools than they realize. The help desk tool is one. Others arrive with vendor support contracts, with medical or industrial equipment, with software bought by individual departments, or as legacy tools nobody removed.

The control is an inventory of approved tools and the network paths they use, plus a technical block on everything else. Application allowlisting, a setting that lets only approved programs run, can stop unapproved tools from running. Egress rules, which govern what traffic may leave the network, can stop them from reaching vendor relay servers. CISA and partner agencies had published guidance on securing remote monitoring and management software in 2023 that covered much of this.

The inventory should record, for each tool, the vendor, whether it is cloud-hosted or self-hosted, which endpoints carry its agent and who owns the relationship. That last field matters more than it looks. A tool with no owner is a tool nobody is reviewing.

2. Key custody: whose secret opens the door

At Treasury the attacker used a key belonging to the vendor’s cloud service. The agency did not hold that key and could not rotate it. (Rotating a key means replacing it with a new one so that any copy an attacker holds stops working.) That is the defining feature of cloud-delivered support tools. A stolen vendor key is, in effect, a stolen credential to the customer’s estate.

The dependency cannot be removed, but it can be narrowed. A self-hosted deployment keeps infrastructure and keys under the agency’s control, at the cost of running it. Where cloud delivery is preferred, contracts can set requirements for how the vendor stores and rotates keys and how its own staff access them. They can also require notice of suspected compromise within hours.

Architecture helps most. A design in which a vendor key alone cannot start a session, because an agency-side approval or agency-held certificate is also required, turns a vendor compromise into an attempted intrusion rather than a successful one. A certificate here is another kind of digital credential, one the customer issues and controls.

The question for every vendor is direct: if your key is stolen, what can an attacker do in our environment, and how would we know?

3. Session constraints: limiting what support can do

Remote support sessions are usually all-powerful by default. The technician sees everything, controls everything and can often run commands with elevated rights. That is convenient and dangerous.

Constraints include requiring the user at the endpoint to accept each session, limiting technicians to defined groups of machines, restricting privilege elevation, enforcing time limits and recording sessions for review. For offices that handle sanctions, investigations, financial systems or sensitive personnel data, remote support may warrant stricter rules, a separate tool instance or in-person support only.

Unattended access, where a technician can connect without a user present, is the most dangerous mode and should be reserved for servers and kiosks with a documented need. If nobody is sitting at the machine, nobody can notice that the cursor is moving on its own.

Each constraint adds friction to help desk work, which is why they are relaxed over time. A busy support team under pressure to close tickets will, quite reasonably, ask for exceptions. The settings should therefore be reviewed on a schedule as well as at deployment.

4. Detection: noticing when the tool is misused

The final control assumes the others may fail. Remote support activity should flow to central logging and be watched for anomalies: sessions at odd hours, sessions to machines a technician does not normally support, sessions from unexpected infrastructure, and sessions with no matching help desk ticket.

Matching sessions to tickets is a simple and effective check that few organizations automate. Every legitimate support session should exist because someone asked for help. A session with no request behind it is, at minimum, worth a phone call.

Detection also depends on the vendor. Agencies should know what telemetry, meaning the activity data, the vendor collects, whether it monitors its own service for compromise and how quickly it shares indicators. Indicators are the fingerprints of an attack, such as suspicious internet addresses or file names, that let customers check whether they were touched. At Treasury the vendor detected the problem and told the customer, which mattered. Contracts should make that behavior an obligation rather than a courtesy, with a defined format for sharing indicators.

What one stolen support key exposes

A stolen supplier key let attackers into the Treasury office that administers sanctions, and the fallout runs through risk registers, supplier oversight, the mission itself and the cost of cleanup.

Risk concentration. A single remote support tool can reach every laptop in the organization. That makes it one of the most concentrated risks most leaders have never heard named. In a risk register, it deserves the same attention as access to the treasury function or the payments system.

Third-party exposure. The Treasury case is a supply chain story. The agency’s own defenses were bypassed because a supplier’s secret was stolen. Every organization that buys cloud services is making the same kind of bet, and boards are increasingly asked by regulators and auditors how they oversee it.

Mission and reputation. When the affected office administers sanctions, the damage goes well beyond cleanup costs. It touches national policy, diplomatic relationships and public confidence. For a bank, the equivalent might be client confidentiality; for a hospital, patient privacy and clinical safety.

Accountability. Remote support tools tend to fall between chairs. IT operations owns the help desk, security owns the risk, procurement owns the contract and the business owns the data being protected. When something goes wrong, each can reasonably say the tool was someone else’s to govern. A leader who names a single accountable owner for privileged access, including the help desk’s tools, removes that ambiguity before it matters.

Cost of the response. Even when no money is stolen, an intrusion through a trusted tool is expensive to unwind. Investigators have to work out which machines were reached, what was viewed and what may have been taken. The tool itself may have to be switched off, which leaves staff without help desk support until a replacement path is in place. Every one of those steps is slower and costlier when nobody can say in advance where the tool is installed or what it was allowed to do.

Multiplication. The four controls apply well beyond government. Banks use remote support on branch and contact center endpoints. Health systems use it on clinical workstations and devices. Managed service providers, the outside firms many organizations pay to run their IT, use it across many clients at once, which multiplies the effect of one stolen key.

A county finds five tools where it expected one

Say a county government has 3,000 staff and a small IT team. Its help desk uses a cloud remote support tool installed on every county laptop, including those in the finance office and the sheriff’s department.

When a new IT director arrives, she asks for a list of every remote access tool in use. The team names the help desk product. A two-week review finds four more: one bundled with the 911 dispatch system, one used by the vendor that maintains the payroll software, one installed years ago by a departed contractor, and one a single department bought on a credit card. Nobody owned two of them.

She then asks the help desk vendor the key custody question. The answer is that a session can start with the vendor’s credentials alone. The county changes its configuration so that sessions to finance and law enforcement machines require the user to click “accept,” and negotiates a contract clause requiring compromise notification within hours.

Finally, the team connects session logs to its ticketing system. In the first month, a handful of sessions have no matching ticket. All turn out to be legitimate shortcuts by busy technicians, but the habit of asking is now in place. The work needed no large budget. It required someone to treat the help desk tool as what it is: a master key.

Habits that hold, and habits that slip

The habits that work are not exotic. In a well-run organization:

• There is one current list of approved remote access tools, each with a named owner, and everything else is blocked by default.
• Leaders know, for each cloud-delivered tool, whether a vendor key alone can open a session, and have pushed for a second, customer-held factor where it cannot be avoided.
• Unattended access is the exception, documented and limited to servers and kiosks.
• Sensitive teams have stricter session rules, or a separate tool instance.
• Every session is logged centrally and checked against a help desk request.
• Contracts oblige vendors to report suspected compromise quickly and in a usable format.

The failures are equally recognizable:

• Treating the tool as a utility. Because it was bought by IT operations, security never reviewed it as a privileged access system.
• Counting only the obvious tool. The help desk product is inventoried; the tools that came with equipment and vendor contracts are not.
• Assuming the vendor’s security is the customer’s security. It is a dependency, not a substitute.
• Letting friction win. Controls switched on at launch are gradually relaxed over the following year.
• Logging without looking. Session records exist but nobody compares them with anything.

Who holds the keys

These questions need no technical knowledge to ask, and the answers will tell a leader a great deal.

1. How many remote access tools are installed across our devices today, and who owns each one?
2. If a vendor’s key were stolen tomorrow, what could an attacker do in our environment, and how would we know?
3. Can a remote session start without anyone at our end approving it? Where, and why?
4. Do we check every remote session against a help desk request? What happened the last time one did not match?
5. What do our contracts require vendors to tell us about a compromise, and how fast?

The Treasury breach did not require a new kind of attack. It required a trusted tool, a vendor-held secret and an organization that, like most, had not fully mapped the path between them. Closing that path is a management task as much as a technical one, and it starts with asking the questions above.

With hindsight

In March 2025 Microsoft reported that Silk Typhoon, the China-linked group widely reported as behind the Treasury intrusion, had shifted to targeting IT supply chain providers, including remote management and cloud application vendors. Rather than attacking organizations one at a time, the group was going after the companies that serve many organizations at once.

Microsoft described the group using stolen API keys and credentials to reach downstream customers. An API key is a digital pass that lets one piece of software talk to another automatically. This was the same pattern seen at Treasury, in a broader form.

The tools themselves stayed in the firing line. Remote access products, including SimpleHelp and ConnectWise ScreenConnect, continued to appear in CISA’s catalog of known exploited vulnerabilities in 2025. The joint advisory on Medusa ransomware that March named remote access software among the tools used for entry and movement. Ransomware is malicious software that locks up an organization’s files until a payment is made; that remote support tools featured in such attacks shows the risk was not limited to espionage by nation-states.

Federal agencies also faced budget and staffing pressure in 2025, which made disciplined inventories and session reviews harder to sustain. That is a reminder that these controls are not a one-time project. They depend on people having the time to keep lists current, review settings and follow up on odd sessions.

Of the four controls, key custody has proved hardest to improve, because it depends on how the vendor built its service. A customer can inventory its tools, tighten session rules and watch its logs on its own. It cannot redesign a vendor’s product. What it can do is ask the key custody question at purchase and at renewal, favor designs that require a customer-held approval, and write notification duties into the contract.

Convenience and privilege tend to travel together. The tools that make work easiest across a dispersed organization are often the ones with the widest reach. Knowing which tools those are, and who holds their keys, is now a basic part of governing an organization’s risk.