Microsoft has confirmed, after some days of speculation, that its internal corporate network was compromised earlier this autumn. The attackers had access for several weeks before being detected. The initial vector, on the available reporting, was a QAZ trojan installed on an employee's home computer.
This is a significant incident. Worth writing about properly because the implications go well beyond the specific facts.
What is being reported
The public reporting, sparse as it is, suggests:
- An employee's home computer was compromised by a QAZ trojan, probably via an emailed attachment.
- The trojan provided remote access to the home computer.
- The attacker used the home computer to access the employee's Microsoft VPN connection to the corporate network.
- Once on the corporate network, the attacker moved laterally for several weeks.
- The attacker had access to some source code — Microsoft has been careful to say that the major products' source was not accessed, but unspecified "future product" source was viewable.
- The attack was eventually detected through network traffic analysis on the corporate side.
The attribution is being reported as a group based in St. Petersburg, Russia. This attribution is, in my experience, more confident than the technical evidence usually supports; treat it with appropriate scepticism.
Why this matters beyond the specific incident
Four reasons.
Microsoft is among the best-resourced security operations on the planet. Their internal security team is large, well-funded, and operates under more sustained pressure than almost any other organisation. If Microsoft's network can be compromised, most other organisations cannot expect to do better with substantially fewer resources.
The vector is structural. The compromise did not exploit a novel zero-day; it exploited the standard pattern of home-computer compromise followed by VPN-mediated lateral access. This pattern is generic and applies to essentially every organisation with remote workers. The defensive responses are similarly generic but require organisational discipline that is hard to deploy.
The dwell time was significant. Several weeks before detection. The standard "detect quickly, respond quickly" model fails when the attackers are careful. Most organisations' detection capabilities do not catch careful attackers within weeks.
The asset definition is shifting. Source code is being treated as a strategic asset whose theft is a national-security-adjacent concern. The economic and political stakes around this kind of incident are higher than they were just a few years ago.
What the incident teaches operationally
A few things, written for my own use.
The home-computer is now part of the corporate threat model. Any employee who connects to corporate resources from a home computer puts that home computer's security posture into the company's threat model. The traditional perimeter — "protect the corporate network" — is insufficient when home computers are inside the perimeter via VPN. The implications:
- Corporate VPN endpoints should require some level of host integrity verification before granting full access.
- Employees' home computers, when used for work, should follow corporate security standards.
- Sensitive operations should require additional authentication beyond standard VPN credentials.
None of these are easily-deployable at most organisations. They are, however, the structural answer.
Lateral movement after initial compromise is the killer. The QAZ trojan on the home computer was a starting point; the value came from the lateral movement on the corporate network. This is the same observation the consultancy incident showed. The defences against initial compromise are necessary but not sufficient; the defences against lateral movement are equally important.
The specific defensive measures:
- Network segmentation that limits what any single compromised host can reach.
- Authentication that does not rely on transitive trust (so a compromised account cannot use cached credentials to access other resources).
- Privileged-account separation, so that admin-level access requires explicit re-authentication.
- Monitoring for lateral-movement patterns, which have characteristic shapes that can be detected.
Most organisations have some of these. Few have all of them. The full suite is operationally expensive but is the structural answer.
Source code is leak-target-grade information. This was not obvious at the start of 2000; it is, after the Microsoft incident, fully obvious. Organisations that produce or hold source code now need to think about it as a strategic asset with its own protection requirements.
Detection time is the variable that matters most. The few-weeks dwell time is bad; an industry-leading detection programme would catch this in days; an exemplary one in hours. The variance between organisations is large. The variance is correlated with maturity of structured logs, network monitoring, and the forensic-readiness disciplines I have been writing about.
The QAZ trojan itself
A short technical note. QAZ has been around since mid-2000; this is not the first organisation to be hit by it.
The trojan is a Windows worm that:
- Spreads via shared folders on the local network and via mass mail.
- Replaces
notepad.exewith itself, copying the original notepad to a backdoor location. - Listens on a TCP port (default 7597) for remote commands.
- Phones home to specific email addresses to report compromised hosts.
Detection: the modified notepad.exe has a different file size than the legitimate one. Process monitoring can catch the listening port. Network monitoring can catch the outbound phone-home.
Removal: replace notepad.exe with a clean version, kill the running process, ensure the registry persistence is removed. Standard cleanup.
The specific trojan is, on its own, modest. The damaging part of this incident is the pattern of how it was used as a foothold — a standard trojan plus standard lateral-movement plus an attacker patient enough to operate quietly. The combination is the threat model, not any one component.
What I am taking from this
Three things, for my own work and for the friends I support.
The threat-model conversation should include lateral movement. I have been writing about perimeter security extensively. I should be writing more about internal-network defence. The next year's posts will skew that direction.
Source code protection deserves explicit thought. For organisations I help that produce code, the question of "what is the security architecture around source" should be more explicit. Most have not thought about this.
Detection dwell time deserves measurement. Organisations that have not measured their detection latency cannot be deliberate about reducing it. Building visibility into how long it takes to notice something — through tabletop exercises, deliberate red-teaming, simulated incidents — is a discipline that should be more widespread.
A closing observation
The Microsoft incident is, in some sense, normalising. If it can happen to Microsoft, it can happen to anyone. The mental shift from "compromise is for organisations that did not invest enough in security" to "compromise is something that happens to all organisations, and the question is how it is detected and contained" is a healthier mental model. It is also, on the evidence of the past three years, the correct mental model.
For my own writing: I expect this incident to mark a small inflection point in how I think and write about defence. The probability of compromise is no longer the main variable; what happens after compromise is increasingly the central question.
More as the year develops.