Explore attack simulation and penetration testing


To test our security monitoring and response capabilities, we put significant emphasis on simulating real attacks in our environment as part of our Assume Breach philosophy. We have an in-house penetration testing team that regularly conducts attacks against service infrastructure. We also maintain an automated attack simulation system that regularly triggers small scale attacks. In other words, we attack ourselves constantly.

The goal of attack simulation is to validate our detection and response capabilities. Our attack simulation often focuses on "post-exploitation" activities. While our penetration testing is certainly used to identify new vulnerabilities and paths into the service, a major priority is testing what happens after compromise. Are we detecting the attack quickly enough? Are we able to effectively remediate and evict the attackers? Attack simulation and other forms of penetration testing allow us to answer these questions on an ongoing basis.

Attack simulation

Microsoft 365 utilizes an in-house offensive security team of full-time employees to conduct continuous penetration testing by simulating attacks against our systems. We call this team the Red Team. The Red Team attempts to compromise Microsoft systems without detection by discovering and exploiting vulnerabilities. Red Team efforts simulate real-world attacks and test the capabilities of the Microsoft 365 Security Response team.

In the context of internal penetration testing, the Microsoft 365 Security Response team is known as the "Blue Team." The Blue Team works to prevent, detect, and respond to Red Team attacks using our security monitoring systems and the security incident response process.

Two boxes containing the definition of Red Team and Blue Team. Red Team: Cybersecurity experts who constantly attempt to breach our own production services without detection to simulate attackers by advanced adversaries. Blue Team: Cyber defenders who use sophisticated security tools and techniques to detect and defeat the Red Team's efforts.

After the Red Team concludes an attack, they work together with the Blue Team to identify and resolve vulnerabilities discovered during the attack simulation. They also identify and implement process improvements based on lessons learned from the simulation. Any vulnerabilities discovered by the Red Team are retested in the next attack simulation against the service to verify improved detection and response capabilities and ensure vulnerabilities have been fully remediated.

Ongoing attack simulation helps Microsoft 365 to identify and fix new vulnerabilities before they can be exploited by real-world adversaries. In addition, these simulations improve our ability to detect attacks quickly and mitigate threats effectively. Red Team attack simulations are designed to simulate realistic attacks without adversely affecting our customers. Customer tenants are never the target of Red Team attacks, but Red Team penetration testing helps to ensure Microsoft 365 is prepared to prevent, detect, and respond to security threats.

Automated attack emulation

To help scale up attack simulation efforts, the red team has created an automated attack emulation tool that runs safely in select Microsoft 365 environments on a recurring basis. The tool has a wide variety of predefined attacks that are constantly being expanded and improved upon to reflect the evolving threat landscape. In addition to broadening the coverage of red team testing, it helps the blue team validate and improve their security monitoring logic. Regular, ongoing attack emulation provides the blue team with a consistent and diverse stream of signals that can be compared and validated against their expected response, leading to improvements in Microsoft 365's security monitoring logic and response capabilities.

Service team application penetration testing

Individual service teams participate in penetration testing of their applications as part of the Security Development Lifecycle (SDL). This testing is designed to discover flaws so they can be remediated before production release. Service teams conduct two kinds of penetration testing as part of SDL. General penetration testing of service team applications is conducted at a minimum of every six months. Additional penetration testing for specific kinds of software vulnerabilities, such as deserialization exploits, is conducted when necessary as part of security review before production release.

Third-party penetration tests

To supplement internal penetration testing, Microsoft 365 engages third-party penetration testers to perform annual penetration tests. Third-party penetration testers are certified through the Council of Registered Security Testers (CREST). Independent penetration tests use the Open Web Application Security Project (OWASP) top 10 framework and custom tooling to maximize test coverage of the Microsoft 365 environment. Vulnerabilities detected through independent penetration tests are tracked using ticketing tools and assigned to service team owners for remediation. These tickets remain open until vulnerabilities are fully remediated.

Microsoft Bug Bounty Program

The Microsoft Bug Bounty Program allows independent security researchers who find vulnerabilities in Microsoft 365 Services to disclose them to Microsoft for a reward. This program incentivizes individuals to disclose bugs to Microsoft, enabling mitigation before they can be exploited by real-world attackers. The Microsoft Bug Bounty Program supplements active penetration testing of Microsoft 365 Services.

Learn more