Tag Archives: bec

Beyond Zero Trust: Identity-First Security Strategies That Actually Reduce Risk in 2026

Posted on by
Reply

A Breach That Didn’t Break In — It Logged In

The email looked routine.

A finance employee received a vendor payment request — well-written, contextually accurate, referencing an actual project. Nothing screamed “phish.” Attached was a short voice note from the CFO explaining the urgency.

The voice sounded right. The cadence, the phrasing — even the subtle impatience.

Moments later, a multi-factor authentication (MFA) prompt appeared. The employee approved it without thinking. They had approved dozens that week. Habit is powerful.

The breach didn’t bypass the firewall.
It didn’t exploit a zero-day vulnerability.
It didn’t even evade detection.

It bypassed identity confidence.

By the time the security team noticed anomalous financial transfers, the attacker had already authenticated, escalated privileges, and pivoted laterally — all using valid credentials.

In 2026, attackers aren’t breaking in.

They’re logging in.

And that reality demands a shift in how we think about security architecture. Zero Trust was a necessary evolution. But in many organizations, it’s stalled at the network layer. Meanwhile, identity has quietly become the primary control plane — and the primary attack surface.

If identity is where trust decisions happen, then identity is where risk must be engineered out.

A hacker is seated in front of a computer fingers poised over the keyboard They are ready to break into a system and gain access to sensitive information 6466041

Zero Trust Isn’t Enough Anymore

Zero Trust began as a powerful principle: “Never trust, always verify.” It challenged perimeter-centric thinking and encouraged segmentation, least privilege, and continuous validation.

But somewhere along the way, it became a marketing label.

Many implementations focus heavily on:

  • Network micro-segmentation

  • VPN replacement

  • Device posture checks

  • SASE rollouts

All valuable. None sufficient.

Because identity remains the weakest link.

AI Has Changed the Identity Battlefield

Attackers now leverage AI to:

  • Craft highly personalized spear phishing emails

  • Generate convincing deepfake audio and video impersonations

  • Launch MFA fatigue campaigns at scale

  • Automate credential stuffing with adaptive logic

The tools available to adversaries have industrialized social engineering.

Push-based MFA, once considered strong protection, is now routinely abused through prompt bombing. Deepfake impersonation erodes human intuition. Credential reuse remains rampant.

Perimeter thinking has died.
Device-centric thinking is incomplete.
Identity is now the primary control plane.

If identity is the new perimeter, it must be treated like critical infrastructure — not a checkbox configuration in your IAM console.

The Identity-First Security Framework

An identity-first strategy doesn’t abandon Zero Trust. It operationalizes it — with identity at the center of risk reduction.

Below are five pillars that move identity from access management to risk engineering.

Pillar 1: Reduce the Identity Attack Surface

A simple Pareto principle applies:

20% of identities create 80% of risk.

Privileged users. Service accounts. Automation tokens. Executive access. CI/CD credentials.

The first step isn’t detection. It’s reduction.

Actions

  • Inventory all identities — human and machine

  • Eliminate dormant accounts

  • Reduce standing privileges

  • Enforce just-in-time (JIT) access for elevated roles

Standing privilege is latent risk. Every persistent admin account is a pre-approved breach path.

Metrics That Matter

  • Percentage of privileged accounts

  • Average privilege duration

  • Dormant account count

  • Privileged access review frequency

Organizations that aggressively reduce identity sprawl see measurable decreases in lateral movement potential.

Reducing exposure is step one.
Validating behavior is step two.

Pillar 2: Continuous Identity Verification — Not Just MFA

MFA is necessary. It is no longer sufficient.

Push-based MFA fatigue attacks are common. Static authentication events assume trust after login. Attackers exploit both.

We must shift from event-based authentication to session-based validation.

Move Beyond:

  • Blind push approvals

  • Static login checks

  • Binary allow/deny thinking

Add:

  • Risk-based authentication

  • Device posture validation

  • Behavioral biometrics

  • Continuous session monitoring

Attackers use AI to simulate legitimacy.
Defenders must use AI to detect deviation.

Useful Metrics

  • MFA approval anomaly rate

  • Impossible travel detections

  • Session risk score trends

  • High-risk login percentage

Authentication should not be a moment. It should be a monitored process.

Pillar 3: Identity Telemetry & Behavioral Baselines

First-principles thinking:
What is compromise?

It is behavior deviation.

A legitimate user logging in from a new country at 3:00 a.m. and accessing sensitive financial systems may have valid credentials — but invalid behavior.

Implementation Steps

  • Build per-role behavioral baselines

  • Track privilege escalation attempts

  • Integrate IAM logs into SOC workflows

  • Correlate identity data with endpoint and cloud telemetry

Second-order thinking matters here.

More alerts without tuning leads to burnout.

Identity alerts must be high-confidence. Behavioral models must understand role context, not just user anomalies.

Security teams should focus on detecting intent signals — not just login events.

Pillar 4: Machine Identity Governance

Machine identities often outnumber human identities in cloud-native environments.

Consider:

  • Service accounts

  • API tokens

  • Certificates

  • CI/CD pipeline credentials

  • Container workload identities

AI-powered attackers increasingly target automation keys. They know that compromising a service account can provide persistent, stealthy access.

Critical Actions

  • Automatically rotate secrets

  • Shorten token lifetimes

  • Continuously scan repositories for hardcoded credentials

  • Enforce workload identity controls

Key Metrics

  • Average token lifespan

  • Hardcoded secret discovery rate

  • Machine identity inventory completeness

  • Unused service account count

Machine identities do not get tired. They also do not question unusual requests.

That makes them both powerful and dangerous.

Pillar 5: Identity Incident Response Playbooks

Identity compromise spreads faster than traditional breaches because authentication grants implicit trust.

Incident response must evolve accordingly.

Include in Playbooks:

  • Immediate token invalidation

  • Automated session termination

  • Privilege rollback

  • Identity forensics logging

  • Rapid behavioral reassessment

Identity Maturity Model

Level Capability
Level 1 MFA + Basic IAM
Level 2 JIT Access + Risk-based authentication
Level 3 Behavioral detection + Machine identity governance
Level 4 Autonomous identity containment

The future state is not manual triage.

It is autonomous identity containment.

Implementation Roadmap

Transformation does not require a multi-year overhaul. It requires disciplined sequencing.

First 30 Days

  • Conduct a full identity inventory audit

  • Launch a privilege reduction sprint

  • Review MFA configurations and eliminate push-only dependencies

  • Identify dormant and orphaned accounts

Immediate wins come from subtraction.

First 90 Days

  • Deploy risk-based authentication policies

  • Integrate identity telemetry into SOC workflows

  • Begin machine identity governance initiatives

  • Establish behavioral baselines for high-risk roles

Security operations and IAM teams must collaborate here.

Six-Month Horizon

  • Implement behavioral AI modeling

  • Automate session risk scoring

  • Deploy automated identity containment workflows

  • Establish executive reporting on identity risk metrics

Identity becomes measurable. Measurable becomes manageable.

Real-World Examples

Example 1: Privilege Reduction

One enterprise reduced privileged accounts by 42%. The measurable result: significant reduction in lateral movement pathways and faster containment during simulated breach exercises.

Example 2: MFA Fatigue Prevention

A financial services firm detected abnormal MFA approval timing patterns. Session anomaly detection flagged behavior inconsistent with historical norms. The attack was stopped before funds were transferred.

The lesson: behavior, not just credentials, determines legitimacy.

Measurable Outcomes

Identity Control Risk Reduced Measurement Method
JIT Privilege Lateral movement Privilege duration logs
Risk-based MFA Phishing success Approval anomaly rate
Token rotation Credential abuse Token age metrics
Behavioral baselines Account takeover Session deviation scores
Machine identity inventory Automation abuse Service account audits

Security leaders must shift from tool counts to risk-reduction metrics.

Identity Is the New Control Plane

Attackers scale with AI.

They automate reconnaissance. They generate deepfake executives. They weaponize credentials at industrial scale.

Defenders must scale identity intelligence.

In 2026, the organizations that win will not be those with the most tools. They will be those who understand that identity is infrastructure.

Firewalls inspect traffic.
Endpoints enforce policy.
Identity determines authority.

And authority is what attackers want.

Zero Trust was the beginning. Identity-first security is the evolution.

The question is no longer whether your users are inside the perimeter.

The question is whether your identity architecture assumes breach — and contains it automatically.

Info & Help: Advancing Your Identity Strategy

Identity-first security is not a product deployment. It is an operational discipline.

If your organization is:

  • Struggling with privilege sprawl

  • Experiencing MFA fatigue attempts

  • Concerned about AI-driven impersonation

  • Lacking visibility into machine identities

  • Unsure how to measure identity risk

The team at MicroSolved, Inc. can help.

For over three decades, MicroSolved has assisted enterprises, financial institutions, healthcare providers, and critical infrastructure organizations in strengthening identity governance, incident response readiness, and security operations maturity.

Our services include:

  • Identity risk assessments

  • Privileged access reviews

  • IAM architecture design

  • SOC integration and telemetry tuning

  • Incident response planning and tabletop exercises

If identity is your new control plane, it deserves engineering rigor.

Reach out to MicroSolved to discuss how to reduce measurable identity risk — not just deploy another control.

Security is no longer about keeping attackers out.

It’s about making sure that when they log in, they don’t get far.

 

 

* AI tools were used as a research assistant for this content, but human moderation and writing are also included. The included images are AI-generated.

Methodology: MailItemsAccessed-Based Investigation for BEC in Microsoft 365

Posted on by
Reply

When your organization faces a business-email compromise (BEC) incident, one of the hardest questions is: “What did the attacker actually read or export?” Conventional logs often show only sign-ins or outbound sends, but not the depth of mailbox item access. The MailItemsAccessed audit event in Microsoft 365 Unified Audit Log (UAL) brings far more visibility — if configured correctly. This article outlines a repeatable, defensible process for investigation using that event, from readiness verification to scoping and reporting.

Objective

Provide a repeatable, defensible process to identify, scope, and validate email exposure in BEC investigations using the MailItemsAccessed audit event.

Phase 1 — Readiness Verification (Pre-Incident)

Before an incident hits, you must validate your logging and audit posture. These steps ensure you’ll have usable data.

1. Confirm Licensing

  • Verify your tenant’s audit plan under Microsoft Purview Audit (Standard or Premium).

    • Audit (Standard): default retention 180 days (previously 90).

    • Audit (Premium): longer retention (e.g., 365 days or more), enriched logs.

  • Confirm that your license level supports the MailItemsAccessed event. Many sources state this requires Audit Premium or an E5-level compliance add-on.

2. Validate Coverage

  • Confirm mailbox auditing is on by default for user mailboxes. Microsoft states this for Exchange Online.

  • Confirm that MailItemsAccessed is part of the default audit set (or if custom audit sets exist, that it’s included). According to Microsoft documentation: the MailItemsAccessed action “covers all mail protocols … and is enabled by default for users assigned an Office 365 E3/E5 or Microsoft 365 E3/E5 licence.”

  • For tenants with customised audit sets, ensure the Microsoft defaults are re-applied so that MailItemsAccessedisn’t inadvertently removed.

3. Retention & Baseline

  • Record what your current audit-log retention policy is (e.g., 180 days vs 365 days) so you know how far back you can search.

  • Establish a baseline volume of MailItemsAccessed events—how many are generated from normal activity. That helps define thresholds for abnormal behaviour during investigation.

Phase 2 — Investigation Workflow (During Incident)

Once an incident is underway and you have suspected mailboxes, follow structured investigation steps.

1. Identify Affected Accounts

From your alarm sources (e.g., anomalous sign-in alerts, inbound or outbound rule creation, unusual inbox rules, compromised credentials) compile a list of mailboxes that might have been accessed.

2. Extract Evidence

In the Purview portal → Audit → filter for Activity = MailItemsAccessed, specifying the time range that covers suspected attacker dwell time.
Export the results to CSV via the Unified Audit Log.

3. Correlate Access Sessions

Group the MailItemsAccessed results by key session indicators:

  • ClientIP

  • SessionId

  • UserAgent / ClientInfoString

Flag sessions that show:

  • Unknown or non-corporate IP addresses (e.g., external ASN)

  • Legacy protocols (IMAP, POP, ActiveSync) or bulk-sync behaviour

  • User agents indicating automated tooling or scripting

4. Quantify Exposure

  • Count distinct ItemIds and FolderPaths to determine how many items and which folders were accessed.

  • Look for throttling indicators (for example more than ~1,000 MailItemsAccessed events in 24 h for a single user may indicate scripted or bulk access).

  • Use the example KQL queries below (see Section “KQL Example Snippets”).

5. Cross-Correlate with Other Events

  • Overlay these results with Send audit events and InboxRule/New-InboxRule events to detect lateral-phish, rule-based fraud or data-staging behaviour.

  • For example, access events followed by mass sends indicate attacker may have read and then exfiltrated or used the account for fraud.

6. Validate Exfil Path

  • Check the client protocol used by the session. If the client is REST API, bulk sync or legacy protocol, that may indicate the attacker is exfiltrating rather than simply reading.

  • If MailItemsAccessed shows items accessed using a legacy IMAP/POP or ActiveSync session — that is a red flag for mass download.

Phase 3 — Analysis & Scoping

Once raw data is collected, move into analysis to scope the incident.

1. Establish Attack Session Timeline

  • Combine sign-in logs (from Microsoft Entra ID Sign‑in Logs) with MailItemsAccessed events to reconstruct dwell time and sequence.

  • Determine when attacker first gained access, how long they stayed, and when they left.

2. Define Affected Items

  • Deliver an itemised summary (folder path, count of items, timestamps) of mailbox items accessed.

  • Limit exposure claims to the items you have logged evidence for — do not assume access of the entire mailbox unless logs show it (or you have other forensic evidence).

3. Corroborate with Throttling and Send Events

  • If you see unusual high-volume access plus spike in Send events or inbox rule changes, you can conclude automated or bulk access occurred.

  • Document IOCs (client IPs, session IDs, user-agent strings) tied to the malicious session.

Phase 4 — Reporting & Validation

After investigation you report findings and validate control-gaps.

1. Evidence Summary

Your report should document:

  • Tenant license type and retention (Audit Standard vs Premium)

  • Audit coverage verification (mailbox auditing enabled, MailItemsAccessed present)

  • Affected item count, folder paths, session data (IPs, protocol, timeframe)

  • Indicators of compromise (IOCs) and signs of mass or scripted access

2. Limitations

Be transparent about limitations:

  • Upgrading to Audit Premium mid-incident will not backfill missing MailItemsAccessed data for the earlier period. Sources note this gap.

  • If mailbox auditing or default audit-sets were customised (and MailItemsAccessed omitted), you may lack full visibility. Example commentary notes this risk.

3. Recommendations

  • Maintain Audit Premium licensing for at-risk tenants (e.g., high-value executive mailboxes or those handling sensitive data).

  • Pre-stage KQL dashboards to detect anomalies (e.g., bursts of MailItemsAccessed, high counts per hour or per day) so you don’t rely solely on ad-hoc searches.

  • Include audit-configuration verification (licensing, mail-audit audit-set, retention) in your regular vCISO or governance audit cadence.

KQL Example Snippets

 
// Detect burst read activity per IP/user
AuditLogs
| where Operation == "MailItemsAccessed"
| summarize Count = count() by UserId, ClientIP, bin(TimeGenerated, 1h)
| where Count > 100

// Detect throttling patterns (scripted or bulk reads)
AuditLogs
| where Operation == "MailItemsAccessed"
| summarize TotalReads = count() by UserId, bin(TimeGenerated, 24h)
| where TotalReads > 1000

MITRE ATT&CK Mapping

Tactic Technique ID
Collection Email Collection T1114.002
Exfiltration Exfiltration Over Web Services T1567.002
Discovery Cloud Service Discovery T1087.004
Defense Evasion Valid Accounts (Cloud) T1078.004

These mappings illustrate how MailItemsAccessed visibility ties directly into attacker-behaviour frameworks in cloud email contexts.

Minimal Control Checklist

  •  Verify Purview Audit plan and retention

  •  Validate MailItemsAccessed events present/searchable for a sample of users

  •  Ensure mailbox auditing defaults (default audit-set) restored and active

  •  Pre-stage anomaly detection queries / dashboards for mailbox-access bursts

Conclusion

When investigating a BEC incident, possession of high-fidelity audit data like MailItemsAccessed transforms your investigation from guesswork into evidence-driven clarity. The key is readiness: licence appropriately, validate your coverage, establish baselines, and when a breach occurs follow a structured workflow from extraction to scoping to reporting. Without that groundwork your post-incident forensics may hit blind spots. But with it you increase your odds of confidently quantifying exposure, attributing access and closing the loop.

Prepare, detect, dissect—repeatably.

References

  1. Microsoft Learn: Manage mailbox auditing – “Mailbox audit logging is turned on by default in all organizations.”

  2. Microsoft Learn: Use MailItemsAccessed to investigate compromised accounts – “The MailItemsAccessed action … is enabled by default for users that are assigned an Office 365 E3/E5 or Microsoft 365 E3/E5 license.”

  3. Microsoft Learn: Auditing solutions in Microsoft Purview – licensing and search prerequisites.

  4. Office365ITPros: Enable MailItemsAccessed event for Exchange Online – “Purview Audit Premium is included in Office 365 E5 and … Audit (Standard) is available to E3 customers.”

  5. TrustedSec blog: MailItemsAccessed woes – “According to Microsoft, this event is only accessible if you have the Microsoft Purview Audit (Premium) functionality.”

  6. Practical365: Microsoft’s slow delivery of MailItemsAccessed audit event – retention commentary.

  7. O365Info: Manage audit log retention policies – up to 10 years for Premium.

  8. Office365ITPros: Mailbox audit event ingestion issues for E3 users.

  9. RedCanary blog: Entra ID service principals and BEC – “MailItemsAccessed is a very high volume record …”

 

* AI tools were used as a research assistant for this content, but human moderation and writing are also included. The included images are AI-generated.

Record-Breaking BEC Recovery: A Case Study and Future Implications

Posted on by
Reply

Executive Summary

INTERPOL’s recent recovery of over $40 million in a Business Email Compromise (BEC) scam marks a significant milestone in cybercrime prevention. This case study examines the incident, its resolution, and the broader implications for business cybersecurity.

Incident Overview

A Singapore-based commodity firm fell victim to a sophisticated BEC scam, resulting in an unauthorized transfer of $42.3 million to an account in Timor Leste. The scam exploited a common vulnerability in business processes: the manipulation of vendor email communications to redirect legitimate payments.

Resolution

  1. Rapid Reporting: Upon discovery, the victim company promptly alerted local authorities.
  2. International Cooperation: INTERPOL’s Global Rapid Intervention of Payments (I-GRIP) team was activated.
  3. Fund Recovery: $39 million was initially recovered, with an additional $2 million seized during follow-up investigations.
  4. Arrests: Seven suspects were apprehended, demonstrating the effectiveness of international law enforcement collaboration.

Key Takeaways

  • Evolving Threat Landscape: BEC scams continue to pose a significant and growing threat to businesses globally.
  • Importance of Swift Action: Rapid reporting and response were crucial in recovering a substantial portion of the stolen funds.
  • International Cooperation: The success of this operation highlights the effectiveness of coordinated global efforts in combating cybercrime.

Future Implications for BEC Compromises

  1. Adaptive Cybercriminal Tactics:
    • Expect more sophisticated, multi-layered scams designed to evade detection.
    • Potential shift towards higher-volume, lower-value attacks to avoid triggering large-scale investigations.
  2. Enhanced Prevention Strategies:
    • Implementation of AI-driven email authentication systems.
    • Adoption of blockchain technology for transaction verification.
    • Development of more robust and frequent employee training programs.
  3. Advanced Response Mechanisms:
    • Potential development of global, real-time financial transaction monitoring systems.
    • Increased integration of cybersecurity measures within standard business processes.

Recommendations for Businesses

  1. Implement rigorous email authentication protocols.
  2. Establish and regularly update vendor verification procedures.
  3. Conduct frequent, comprehensive cybersecurity training for all employees.
  4. Develop and maintain relationships with local law enforcement and cybersecurity agencies.

Contacting I-GRIP

In the event of a suspected BEC attack:

  1. Immediately contact your local law enforcement agency.
  2. Provide all relevant details of the suspected fraud.
  3. Request that your case be escalated to INTERPOL if it involves international transactions.
  4. For general information on international cybercrime reporting, visit www.interpol.int.

By staying informed and proactive, businesses can significantly mitigate the risks associated with BEC scams and contribute to a more secure global business environment.