Treasury’s breach ran through a remote-support key the agency never held
Attackers reached Treasury workstations with a stolen key that secured a vendor’s cloud remote support service. Remote support is privileged access by another name, and governing it takes four controls along the path from vendor to endpoint, most of which agencies only partly had.
Looking Back revisits one week at a time, from January 2020 to today, and asks what it meant for the banks, health systems and public agencies we serve. The series was written in 2026, with the benefit of hindsight, and each article says which week it looks back on.
The week
On December 30, 2024, the U.S. Department of the Treasury informed Congress that a China state-sponsored actor had accessed some of its user workstations and unclassified documents earlier that month. According to Treasury’s letter, the attacker had obtained a key used by BeyondTrust, a third-party provider, to secure a cloud-based remote technical support service. With it, the attacker bypassed the service’s security and remotely reached workstations in Treasury’s Departmental Offices. BeyondTrust had notified Treasury on December 8, and the compromised service was taken offline. Treasury called the event a major cybersecurity incident and said it was working with CISA and the FBI. Later reporting said offices affected included the Office of Foreign Assets Control, which administers sanctions. BeyondTrust also disclosed vulnerabilities in its remote support products that month, and CISA added one to its catalog of known exploited vulnerabilities.
Remote support software 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. 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.
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.
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. Attackers also install legitimate remote management tools after gaining a foothold, because the traffic looks normal.
The control is an inventory of approved tools and the network paths they use, plus a technical block on everything else. Application allowlisting can stop unapproved tools from running, and egress rules 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.
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. That is the defining feature of cloud-delivered support tools: trust between the vendor’s service and the customer’s endpoints rests on secrets the vendor manages. 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. 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?
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. Each constraint adds friction to help desk work, which is why they are relaxed over time. The settings should therefore be reviewed on a schedule, not only at deployment.
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.
Detection also depends on the vendor. Agencies should know what telemetry the vendor collects, whether it monitors its own service for compromise and how quickly it shares indicators. 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.
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 use it across many clients at once, which multiplies the effect of one stolen key.
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. It described the group using stolen API keys and credentials to reach downstream customers, the same pattern in a broader form. Remote access products remained a frequent source of entries in CISA’s catalog of known exploited vulnerabilities through 2025. The joint advisory on Medusa ransomware that March named remote access software among the tools used for entry and movement, as a later article in this series discusses. Federal agencies also faced budget and staffing pressure in 2025, which made disciplined inventories and session reviews harder to sustain. Of the four controls, key custody has proved hardest to improve, because it depends on how the vendor built its service.