Phishing detection automation for Office 365 with Wazuh and Shuffle

At a glance

What this is: This is a walkthrough of detecting phishing in Office 365 with Wazuh and Shuffle, showing how email IOCs can be parsed, correlated, and routed into automated response.

Why it matters: It matters because phishing increasingly crosses into identity governance, account compromise, and credential abuse, so IAM and security teams need email-triggered detection and containment workflows that connect with broader access-control and incident-response processes.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read Wazuh's phishing detection walkthrough for Office 365 and automated response

Context

Phishing is still effective because it targets trust, not just technology. Email controls can filter obvious spam, but they often fail when attackers use realistic messaging, malicious links, or attachment-based payloads that move quickly into account compromise or broader intrusion paths.

This article sits at the intersection of email security, incident response automation, and identity risk because Office 365 abuse often begins with a user or mailbox and then expands into access, data exposure, or privileged workflow abuse. The key governance gap is not whether alerts exist, but whether they can be enriched and acted on before the attacker progresses.

For identity and security teams, the practical question is how to connect detection signals from email to containment actions without creating brittle manual triage. That is a typical control problem in modern environments, especially where mailbox access and delegated permissions can become part of the attack path.

Key questions

Q: How should security teams automate phishing response without losing control?

A: Start by automating the repetitive parts of the workflow, such as enrichment, deduplication, campaign correlation, and safe containment actions. Keep analyst approval for actions that could affect users broadly or remove access from critical accounts. The goal is faster, more consistent decisions, not blind execution of every alert.

Q: Why do phishing controls need to connect email security with IAM and incident response?

A: Because phishing rarely ends at the inbox. It often leads to credential capture, mailbox compromise, or delegated access abuse, which are identity problems as much as email problems. When email detections are tied to identity and response workflows, teams can contain attacks faster and reduce the chance of account-level escalation.

Q: What breaks when phishing IOC lists are stale or poorly governed?

A: Detection quality drops quickly, and analysts either miss active campaigns or drown in false positives from outdated indicators. In practice, stale lists create blind spots in URL, domain, IP, and hash matching, which weakens automated triage and makes containment decisions less reliable.

Q: Should organisations automate mailbox containment actions or keep them manual?

A: Automate low-risk containment steps such as tagging, routing, and enrichment first, then reserve user-impacting actions for review. That balance gives teams speed without surrendering governance, especially when email systems are tied to account access and business-critical communications.

Technical breakdown

How Office 365 phishing detection uses Microsoft Graph permissions

The workflow depends on delegated Microsoft Graph permissions to read and, in some cases, act on Office 365 mailboxes. That matters because the integration is only as trustworthy as the OAuth consent model behind it. If the app registration, client secret, or consent scope is too broad, the monitoring path itself becomes a privileged access surface. The article also shows how mailbox retrieval, attachment enumeration, and filtering logic can be chained so suspicious messages are gathered centrally before response logic runs.

Practical implication: review delegated and application permissions as privileged access, not just integration setup.

How IOC extraction and CDB lists turn email into actionable signals

Wazuh uses custom detection logic and constant database lists to compare extracted URLs, domains, IPs, and hashes against known bad indicators. This shifts email analysis from raw message inspection to structured matching, which is easier to automate and audit. The strength of the design is that it separates extraction from correlation, letting the workflow normalise message content before generating alerts. The weakness is that list quality and update discipline determine detection coverage, especially against fast-changing phishing infrastructure.

Practical implication: treat IOC list maintenance as a live control, not a one-time configuration task.

Why SOAR closes the gap between alerting and containment

Shuffle is used to orchestrate the response sequence after Wazuh identifies suspicious content. That is the real value of SOAR in phishing handling: the system can enrich alerts, pass them through decision logic, and trigger actions such as mailbox updates or message relocation without waiting for an analyst to perform each step manually. In practice, this reduces dwell time for malicious mail and helps preserve analyst capacity for triage decisions that still require human judgment.

Practical implication: define which response steps can be automated safely and which still require analyst approval.

Threat narrative

Attacker objective: The attacker wants to convert a trusted email channel into a foothold for credential theft, malware delivery, or downstream data exfiltration.

1. Entry occurs through a deceptive email that bypasses user suspicion and delivers a malicious link, domain, or attachment into the mailbox.
2. Credential harvesting or payload execution follows when the user engages the message, opening the path to account compromise, ransomware staging, or data theft.
3. Impact is achieved when the attacker uses the mailbox foothold to exfiltrate data, expand access, or deliver malware into the organisation's workflow.

NHI Mgmt Group analysis

Phishing response is now an identity-adjacent control problem, not just an email filtering problem. The article shows that mailbox access, delegated permissions, and response orchestration all sit inside the same operational chain. That means email security teams and IAM teams cannot work in silos when phishing is a route to account abuse or workflow compromise. Practitioners should treat mailbox integrations as part of the access perimeter.

The most useful named concept here is email-to-identity escalation path. A phishing message is not only a message problem when it can trigger credential capture, mailbox manipulation, or delegated access misuse. In mixed environments, that path often becomes the first step into broader identity compromise. Organisations should map email-triggered actions into identity risk scenarios rather than stopping at inbox hygiene.

Automated triage is only effective when the correlation logic is governed like a security control. CDB lists, parsing rules, and workflow branches can reduce noise, but they also introduce policy decisions about what counts as malicious and what is safe to auto-handle. That governance discipline matters because over-automation can hide misses while under-automation leaves analysts buried in repetitive work. Practitioners should version and test these workflows as formal controls.

Phishing defence remains typical of environments where detection exists but containment is still partially manual. The article's design reflects a common maturity stage: teams can identify suspicious mail, but still need integration work to convert that detection into coordinated response. That is not a failure of tooling alone. It is a sign that response design, mailbox governance, and security operations still need tighter integration.

IAM and SOC teams should expect email abuse to keep intersecting with access governance. Office 365 remains a high-value control plane because it is both a communication surface and an identity-adjacent access surface. When attackers can exploit it, the response model must include permission review, mailbox trust boundaries, and incident containment. Practitioners should build shared ownership for those controls now.

What this signals

Phishing automation is increasingly a governance question because the response path now touches permissions, workflow logic, and evidence handling. Teams that can enrich alerts but cannot standardise containment will keep relying on manual triage, which is where speed and consistency usually fail.

Email-to-identity escalation path: organisations should expect phishing controls to be assessed by how well they interrupt account abuse, not just by how many messages they quarantine. The useful metric is whether a suspicious email can still become a credential or mailbox incident before containment finishes.

For practitioners

• Map mailbox integrations to privileged access Review Microsoft Graph consent scopes, client secrets, and delegated permissions as sensitive access paths. Keep the integration limited to the minimum mailbox actions needed for detection and response, and document who can grant or revoke those permissions.
• Separate extraction, correlation, and response logic Design phishing handling so IOC parsing, indicator matching, and containment actions are distinct control stages. That makes it easier to test each layer, reduce false positives, and prove which step caused a response event.
• Maintain phishing IOC lists as operational policy Update domain, URL, IP, and hash lists on a defined cadence, and retire stale indicators when campaigns change. Use change control so list updates are auditable and tied to specific detection outcomes.
• Automate only the containment actions that are safe Use SOAR to move or tag suspicious email, enrich alerts, and route cases, but require human review for actions that affect users, business mail flow, or account permissions.

Key takeaways

• Phishing remains a control-plane issue because email, identity, and response automation are now linked in the same attack path.
• The article's value is operational: it shows how IOC extraction, list-based correlation, and SOAR workflows can move phishing handling from manual triage to structured containment.
• The weak point is governance, not detection alone, because delegated permissions and automated response actions must be scoped and reviewed like any other privileged access path.

Key terms

• Security Orchestration, Automation and Response: SOAR is a workflow automation layer that executes response actions using predefined playbooks. It helps security teams standardise repetitive tasks, but its value depends on accurate detection input and well-designed handoffs from investigation to action.
• Microsoft Graph: Microsoft Graph is the access and data layer that connects Microsoft 365 services, including mail, files, chats, and sites. In Copilot workflows, it becomes the retrieval surface that determines what information the assistant can assemble into a response.
• Constant Database list: A constant database list is a static lookup structure used to compare extracted indicators against known values. Security teams use it to turn raw strings such as URLs, domains, IPs, and hashes into matched signals that can drive alerting and automation.

What's in the full article

Wazuh's full blog post covers the implementation detail this analysis intentionally leaves at a higher level:

• Step-by-step Microsoft Graph app registration and delegated permission setup for Office 365 monitoring
• Full Wazuh rule and CDB list configuration for URL, domain, IP, and hash-based phishing detection
• Shuffle workflow wiring for email retrieval, IOC extraction, alert enrichment, and mailbox containment
• Testing examples for suspicious URLs, domains, IP addresses, and malicious attachments

👉 The full Wazuh post includes the workflow configuration, custom rules, and test cases used to validate phishing containment.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is suited to practitioners who need to connect identity controls to wider security operations and lifecycle governance.