Inside O365-Attack-Toolkit: How Red Teams Weaponize Microsoft's Own OAuth Flow
Hook
The most dangerous Office 365 attacks don't exploit bugs—they exploit trust. O365-Attack-Toolkit proves that a user clicking 'Allow' on an OAuth consent screen can be more devastating than any zero-day vulnerability.
Context
Traditional phishing attacks against Office 365 users have evolved dramatically over the past decade. Early attackers relied on stealing usernames and passwords through fake login pages, but modern defenses like multi-factor authentication (MFA) rendered these approaches increasingly ineffective. Even when attackers successfully harvested credentials, MFA prompts would block their access.
The security industry's response—mandatory MFA, conditional access policies, and credential-based threat detection—created an arms race that forced attackers to innovate. The solution they found was elegantly simple: stop stealing credentials and start stealing consent. OAuth consent phishing, also called 'illicit consent grant attacks,' exploits the trust users place in the familiar Azure AD consent screen. When a user clicks 'Accept' to grant an application access to their mail, files, or calendar, they're handing over API access that bypasses traditional authentication controls entirely. O365-Attack-Toolkit represents the maturation of this attack vector, providing red teams with a complete framework for demonstrating how consent phishing enables persistent, interactive access to compromised Office 365 tenants.
Technical Insight
O365-Attack-Toolkit implements a three-tier architecture that separates phishing, token management, and post-compromise operations. The toolkit begins with an Azure AD application registration—a legitimate application created in Microsoft's identity platform. This application requests extensive Microsoft Graph API permissions including Mail.ReadWrite, Files.ReadWrite.All, and Contacts.Read. The critical architectural decision here is requesting delegated permissions rather than application permissions, which means actions appear to come from the user rather than the application itself.
The phishing endpoint serves a convincing OAuth consent page. When a victim clicks through, Azure AD redirects them back to the toolkit's callback URL with an authorization code. The toolkit exchanges this code for access and refresh tokens, which it stores for ongoing operations. Here's a simplified representation of how the token exchange works in Go:
func exchangeCodeForToken(code string, clientID string, clientSecret string, redirectURI string) (*oauth2.Token, error) {
conf := &oauth2.Config{
ClientID: clientID,
ClientSecret: clientSecret,
RedirectURL: redirectURI,
Scopes: []string{"Mail.ReadWrite", "Files.ReadWrite.All", "Contacts.Read"},
Endpoint: oauth2.Endpoint{
AuthURL: "https://login.microsoftonline.com/common/oauth2/v2.0/authorize",
TokenURL: "https://login.microsoftonline.com/common/oauth2/v2.0/token",
},
}
token, err := conf.Exchange(context.Background(), code)
if err != nil {
return nil, err
}
return token, nil
}
The post-compromise interface is where O365-Attack-Toolkit diverges from typical data exfiltration tools. Rather than automatically downloading all emails and files (which generates massive API traffic), it provides an interactive web interface that lets operators search specific mailboxes, read individual messages, and selectively access OneDrive files. This design decision reflects a sophisticated understanding of detection engineering—batch operations create obvious anomalies in Microsoft's Cloud App Security logs, while sporadic, targeted access mimics legitimate user behavior.
The file replacement functionality demonstrates particularly clever tradecraft. Traditional Office macro attacks require replacing a legitimate document with a malicious one containing macros, which often changes file hashes and triggers DLP systems. O365-Attack-Toolkit instead uses the Microsoft Graph API's PATCH method to update file content in place:
func replaceFileContent(accessToken string, driveID string, itemID string, newContent []byte) error {
url := fmt.Sprintf("https://graph.microsoft.com/v1.0/drives/%s/items/%s/content", driveID, itemID)
req, _ := http.NewRequest("PUT", url, bytes.NewReader(newContent))
req.Header.Set("Authorization", "Bearer "+accessToken)
req.Header.Set("Content-Type", "application/octet-stream")
client := &http.Client{}
resp, err := client.Do(req)
if err != nil {
return err
}
defer resp.Body.Close()
if resp.StatusCode != http.StatusOK && resp.StatusCode != http.StatusCreated {
return fmt.Errorf("failed to replace file: %s", resp.Status)
}
return nil
}
This approach maintains the original file's metadata, sharing permissions, and SharePoint location while replacing its contents. For red team operations, this means an operator can identify a frequently accessed Excel spreadsheet in a finance team's OneDrive, replace it with a version containing malicious formulas, and wait for the next legitimate user to open it.
The toolkit's token refresh mechanism ensures persistent access without requiring the victim to re-authenticate. Microsoft Graph API refresh tokens remain valid for extended periods (often 90 days by default), and the toolkit automatically exchanges them for new access tokens when the current one expires. This persistence layer operates entirely through Microsoft's legitimate token infrastructure, making it nearly impossible to distinguish from a normal OAuth application's behavior.
Gotcha
The toolkit's effectiveness depends entirely on successful OAuth consent, which is increasingly difficult to obtain against mature organizations. Microsoft's conditional access policies can restrict which applications users can consent to, and many enterprises now disable user consent entirely, requiring administrator approval for all third-party applications. When an attacker registers a new Azure AD application for phishing, it appears in tenant audit logs with details about the requesting account, making it traceable if defenders know where to look.
Detection capabilities have also evolved significantly. Microsoft Defender for Cloud Apps can flag suspicious OAuth applications based on uncommon permission combinations, low usage patterns, or applications registered by recently created Azure AD accounts. The toolkit's interactive Graph API usage generates API logs that mature SOCs can baseline and monitor for anomalies. While less obvious than batch exfiltration, an operator suddenly accessing hundreds of SharePoint files they've never touched before will still trigger behavioral analytics in sophisticated environments. Additionally, the toolkit provides no built-in obfuscation for its web interface or callback infrastructure, meaning blue teams can fingerprint and block its phishing pages once they identify them. Organizations using advanced email security gateways that scan OAuth consent links may also block the initial phishing vector entirely.
Verdict
Use if: You're conducting authorized red team engagements or penetration tests where demonstrating OAuth consent phishing risk is critical for stakeholder awareness. This toolkit excels at showing security teams exactly how attackers leverage Microsoft's legitimate infrastructure against them, and it's invaluable for testing whether your organization's conditional access policies, OAuth app governance, and SOC detection capabilities actually work against real-world techniques. It's also useful for security researchers studying the intersection of social engineering and cloud application security. Skip if: You're looking for an automated data exfiltration tool or you're working against organizations with mature OAuth governance (you'll likely get caught). Also skip if you're not comfortable with the legal and ethical implications—this toolkit's entire purpose is simulating attacker behavior, and using it without explicit authorization crosses into criminal territory. Organizations with basic Microsoft 365 E3 licensing and minimal security team maturity should start with simpler security awareness demonstrations before deploying sophisticated OAuth attack simulations.
