Phishing detection automation for Office 365 with Wazuh and Shuffle

At a glance

What this is: This is a Wazuh guide to automating Office 365 phishing detection and response by feeding email indicators of compromise into Wazuh and orchestrating actions through Shuffle.

Why it matters: It matters because email security is not just filtering anymore, it is detection, correlation, and response orchestration across identity, mailbox, and alerting controls.

Context

Phishing succeeds when email trust is treated as a filtering problem instead of a governance problem. Once a malicious message reaches the mailbox, defenders need a way to inspect the content, classify indicators of compromise, and trigger a consistent response path before the user or attacker can exploit the message further. That workflow becomes even more important in Office 365 environments, where mailbox access, delegated permissions, and downstream automation all intersect.

The article describes a practical control pattern for that gap: combine Wazuh detection with Shuffle orchestration and Microsoft Graph access to monitor Office 365 mail flow. The identity angle is real here because the workflow depends on delegated permissions, authenticated mailbox access, and controlled write actions against user mailboxes, which means the security question is as much about access governance as it is about phishing detection.

Key questions

Q: What breaks when phishing response is still handled manually in Office 365?

A: Manual handling breaks at the point where speed matters most. Emails can be parsed, forwarded, or acted on by users before analysts finish triage, which allows malicious links, attachments, or credential prompts to progress. Automation does not replace judgement, but it reduces the window in which an inbox becomes an active attack surface.

Q: Why do delegated mailbox permissions increase phishing automation risk?

A: Delegated permissions let the workflow act through a signed-in identity, so the automation inherits mailbox authority instead of operating as a passive observer. That makes the permission set high value and high risk. If the scope is broader than the use case, the workflow can unintentionally become a privileged path into email data and response actions.

Q: What are the signs that a phishing automation workflow is not being handled effectively?

A: Common signs include heavy manual case handling, repeated coding for simple branching logic, slow updates to detection or triage steps, and errors introduced during routine workflow changes. If analysts cannot test actions before deployment or cannot manage data transformations cleanly, the playbook is more likely to break under real incident volume and require constant rework.

Q: How should teams balance phishing automation with mailbox governance?

A: Teams should define what the automation may read, what it may change, and who can approve those changes. The right balance is a narrowly scoped workflow with auditable permissions and a containment action that is less disruptive than full manual response. That keeps automation useful without turning it into uncontrolled mailbox administration.

Technical breakdown

How email indicators become security events

The core mechanism is indicator extraction. Wazuh reads email content and attachments, parses URLs, domains, IP addresses, and hashes, then compares them with curated lists of known suspicious values. That turns raw mailbox data into structured detection signals that can be correlated with alerts. The important architectural point is that the detection layer is not trying to decide whether every message is malicious from first principles. It is normalising evidence so policy and response logic can work consistently across messages and tenants.

Practical implication: build phishing controls around structured IOC normalisation rather than manual review of individual messages.

Why delegated Microsoft Graph access changes the control boundary

Office 365 integration relies on Microsoft Graph permissions, in this case delegated access that allows Shuffle to act on behalf of a signed-in user. That is a governance decision, not just a technical setup step. Once a workflow can read, move, or mark email, the mailbox becomes an automation surface. Teams need to understand exactly which permissions are granted, how long they remain valid, and what the workflow can do if compromised or misconfigured.

Practical implication: treat Graph permissions as privileged application access and review them with the same discipline used for other high-risk integrations.

How SOAR closes the response gap

Shuffle adds orchestration so alerts do not stop at detection. In this pattern, Wazuh produces the signal, Shuffle enriches it, then workflow actions can move suspicious messages to junk or notify responders. That matters because phishing response is usually slowed by repetitive triage tasks rather than by the lack of a detection event. Orchestration only helps, however, when workflow logic is tightly scoped and tested, otherwise automation can magnify mailbox mistakes at scale.

Practical implication: constrain phishing automations to low-risk response actions first, then expand only after validation in a controlled environment.

Threat narrative

Attacker objective: The attacker wants the email to become a foothold for credential theft, malware delivery, or data theft before defenders can contain it.

1. Entry occurs through a phishing email that leverages user trust to land in the inbox and deliver a lure, malicious URL, or attachment.
2. Credential or indicator harvesting follows when the recipient interacts with the message or when the workflow extracts IOCs from its content.
3. Escalation happens when the message is used to trigger access to additional systems or to seed broader malicious activity such as ransomware delivery or data exfiltration.
4. Impact is reached when the organisation contains the email, blocks the indicators, or prevents the phishing message from becoming a wider compromise.

Breaches seen in the wild

• EmeraldWhale Git config credential theft: Tokens in exposed .git/config files let EMERALDWHALE clone private repositories and steal more than 15,000 cloud credentials.
• Schneider Electric Jira breach 2024: Credentials linked to a Lumma infostealer infection gave Hellcat access to Schneider Electric's Jira; 40GB and 400,000 user rows claimed.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Phishing response is now a mailbox governance problem, not only a filtering problem. Once attackers can reach cloud email systems, the security issue shifts from blocking every message to controlling what happens after an indicator appears. That makes detection, triage, and response orchestration part of the same control plane. For practitioners, the implication is clear: email security programmes need policy-driven response paths, not just gateway rules.

Delegated mailbox automation creates a new trust boundary around identity. The moment a workflow can read and act on Office 365 mail through Microsoft Graph, it becomes a privileged non-human actor that must be governed like any other access path. That means scoped permissions, lifecycle oversight, and auditability matter as much as detection content. Practitioners should review automation access as part of identity governance, not leave it inside the SOC tooling stack.

Indicator-driven phishing defence is strongest when it is operationalised as a closed loop. The article’s combination of Wazuh, CDB lists, and Shuffle illustrates a pattern that moves from evidence collection to automated containment. Email triage latency: this is the control gap the workflow is designed to reduce, and it becomes a reusable concept for other mailbox and collaboration threats. Teams should look for places where manual review still sits between detection and response.

Open source detection and orchestration lower integration friction, but they do not lower governance requirements. Security teams still have to validate list quality, response scope, permission boundaries, and exception handling. That is especially important when the automation touches user mailboxes or other identity-linked services. The practitioner conclusion is to govern the automation path with the same rigour as the threat path.

This pattern aligns most closely with NIST CSF detection and response outcomes, but the identity control question remains central. Email automation cannot be treated as a pure SOC optimisation because it depends on mailbox permissions and delegated application access. The practical outcome for teams is to connect phishing response design to access governance, not to separate the two.

From our research library:

• The IBM/Ponemon 2025 Cost of a Data Breach Report found that phishing-initiated breaches cost an average of $4.8M each.
• Read next: Identity Provider and SSO Security Guide

What this signals

Email phishing defence is becoming an identity-linked automation problem. Once a workflow can read and move mailbox content through delegated access, the control surface is no longer just the filter engine. Teams need to decide whether the automation is governed as a privileged application, a SOC playbook, or both. The safer answer is both, because email containment touches permissions, auditability, and user trust at the same time.

Email triage latency is the real pressure point. Suspicious mail that is detected but not acted on still creates exposure, especially when users are targeted with credential harvesting lures or malicious attachments. The most useful automation is the kind that shortens the path from indicator to containment without broadening mailbox authority beyond what the task requires.

For practitioners

• Scope Microsoft Graph permissions tightly Use the minimum Mail.ReadWrite and related delegated permissions required for the workflow, then review who can approve, renew, or revoke them on a set cadence.
• Treat phishing indicators as governed content Maintain and version-control URL, domain, IP, and hash lists so additions are traceable, reviewed, and removable when false positives appear.
• Separate detection from containment actions Use one workflow to enrich and classify messages and a second, narrower workflow to move suspicious mail to junk or notify responders after validation.
• Test automated response against benign and malicious samples Replay suspicious URLs, domains, IP addresses, and attachments in a controlled mailbox so you can confirm parsing, matching, and response logic before production use.
• Monitor for mailbox access drift Check that the monitored account, application registration, and webhook path still match the approved design after admin changes or tenant policy updates.

Key takeaways

• Phishing controls fail when they stop at detection and do not connect mailbox signals to a governed response path.
• The article’s workflow shows how email indicators, Microsoft Graph permissions, and orchestration can be chained into one containment process.
• The strongest control lesson is to narrow delegated access, version the indicator lists, and validate automation before it reaches production.

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.
• Indicator Of Compromise: A measurable sign that suspicious or malicious activity may have occurred, such as an IP address, hash, domain, email, or credential artifact. In operational programmes, an IOC only matters when it can be normalized and used in detection or response workflows.
• Delegated permissions: Delegated permissions are access rights granted through another identity, application, or administrative relationship rather than directly to the end user. They matter because revoking the visible account does not always remove the underlying authority, which can preserve access after offboarding.
• Message Triage Automation: Message triage automation is the use of rules, scoring, or machine learning to classify, quarantine, and prioritise suspicious email without relying on manual review for each item. In practice, it reduces analyst workload and shortens the time between detection and containment when threats arrive at scale.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management for practitioners who need to govern machine-driven access paths. It helps identity and security teams connect access control, automation, and lifecycle oversight across real-world programmes.