Jet Mariano

Tag: Message Trace

  • Quick “Reflexes” Using PowerShell to Block Bad Actors: Emergency Transport Rules + Layer 3/7 Firewall Controls

    In modern cloud environments, threats don’t wait for meetings, approvals, or planning sessions.
    Sometimes an attack hits so fast that your only advantage is instinct, experience, and the ability to act immediately.

    Last month, I experienced exactly that — a coordinated impersonation attempt from multiple bad actors in Europe using public cloud hosting (GCP) as their relay. They created their own connectors and attempted to impersonate internal executives and accounting contacts.

    The attack bypassed standard controls because:

    • They used legitimate cloud IP ranges
    • They generated perfect SPF/DKIM passes
    • Their mail flow looked “clean” until you read the headers
    • They used crafted envelope senders + forged display names

    The only way to stop them instantly — before users were tricked — was to drop two transport rules at highest priority using PowerShell.
    These acted as “circuit breakers” until perimeter firewall rules could be deployed.

    Below is the exact PowerShell approach, redacted and rewritten for general use.

    🚨 Reflex Script #1 — Emergency “Kill Switch” Rule

    Purpose: If attackers are impersonating an internal address like [email protected], this rule blocks any external sender who uses that address in the envelope from or header from.

    # Connect to Exchange Online
Connect-ExchangeOnline

# Create emergency kill-switch rule
New-TransportRule -Name "KILL SWITCH: Block external spoofing of noreply" `
-FromScope External `
-HeaderContainsMessageHeader "From" `
-HeaderContainsWords "noreply@" `
-SetSCL 9 `
-StopRuleProcessing $true `
-Priority 0

    What this rule does instantly:

    • Stops external senders pretending to be noreply@
    • Sets SCL=9 so the message is quarantined or rejected (depending on policy)
    • Stops evaluation of all other rules — making it hit within milliseconds

    🚨 Reflex Script #2 — Block ALL External Senders Using a Protected Address

    Attackers often rotate payloads or try other internal addresses.
    This second rule blocks all attempts — even if they change tactics.

    New-TransportRule -Name "BLOCK ALL External From Protected Address" `
-FromScope External `
-SenderAddressMatchesPatterns "noreply@", "billing@", "alerts@" `
-SetSCL 9 `
-StopRuleProcessing $true `
-Priority 1

    You can modify the patterns depending on the address being abused.

    🛡️ Why This Worked Instantly

    These scripts bypass the UI delay and:

    • Apply before EOP content filters
    • Hit prior to Safe Links/Safe Attachments
    • Trigger even if messages pass SPF/DKIM/DMARC
    • Intercept mail before it reaches the user’s mailbox
    • Provide time to analyze, trace, and escalate

    This is why reflex PowerShell is critical for senior-level engineers — the GUI is too slow during live attacks.

    🔐 Permanent Fix: Layer 3 / Layer 7 Firewall Enforcement

    Once the immediate threat was stopped with PowerShell, the permanent fix required:

    Layer 3 (IP-based blocklists)

    Blocking:

    • Abused GCP IP ranges
    • Known threat actor networks
    • Anonymous compute nodes

    Layer 7 (Application-layer filtering)

    Policies included:

    • Block SMTP traffic from unknown hosts
    • Block unauthorized connector-based submissions
    • Strict URL filtering for phishing redirectors
    • Geo-blocking regions with no business presence

    Once these firewall measures were active, the PowerShell Kill Switch rules were safely disabled to avoid unnecessary mail flow impact.

    💡 Lessons Learned

    1. Bad actors are fast — you must be faster.
    2. Transport rules + PowerShell are your instant “circuit breakers.”
    3. SPF/DKIM/DMARC are not enough when attackers leverage cloud infrastructure.
    4. Layer 3 and Layer 7 controls create the “permanent seal.”
    5. Instant response + longer-term architecture = real protection.

    This is the type of real-world, battle-tested example that hiring panels want to hear.
    Not theory — lived experience.

    © 2012–2025 Jet Mariano. All rights reserved.
    For usage terms, please see the Legal Disclaimer.

  • How to Bypass Spam Filtering for Internal Senders Using PowerShell

    Intro:
    When internal emails from trusted coworkers suddenly stop showing up in your focused inbox or fail to trigger your Outlook rules, it’s easy to miss critical messages. In my case, one sender was previously blocked due to a spoofing incident, and although removed from the block list, her messages were still bypassing my folder rules—buried in the inbox. Message Trace confirmed the emails were delivered, but not filtered correctly. Here’s how I resolved the issue using PowerShell.

    🔍 Problem Recap:

    Despite the sender being trusted and allowed, her emails:

    • Skipped my Outlook inbox rules
    • Did not show up in Focused Inbox or designated folders
    • Were confirmed delivered via Message Trace
    • Were previously on the Blocked Sender List, but later removed

    The Exchange Admin Center (EAC) didn’t offer the flexibility I needed to create an accurate spam bypass rule. So I switched to PowerShell.

    🛠️ Solution: Create a Transport Rule via PowerShell

    Instead of struggling with the limited dropdowns in the modern Exchange portal, I used the New-TransportRule cmdlet to create a spam filter bypass rule in just a few lines.

    Here’s how:

    Connect-ExchangeOnline -UserPrincipalName [email protected]

New-TransportRule -Name "Bypass Spam Filtering from Trusted Senders" `
  -From '[email protected]','[email protected]' `
  -SetSCL -1

    What it does:

    • Matches emails from the listed senders
    • Sets SCL (Spam Confidence Level) to -1, meaning “do not treat as spam”
    • Ensures messages bypass all anti-spam filters and go straight to your inbox

    ⚡ Why Use PowerShell?

    The new Exchange Admin Center UI (EAC) lacks direct options to set SCL or bypass spam filtering with precision. PowerShell:

    • Provides full control
    • Is faster and more reliable
    • Allows batch configuration
    • Gives access to legacy controls like -SetSCL

    🔐 Notes:

    • Email addresses in the example are redacted for privacy
    • Make sure you have the Exchange Online PowerShell v3 module installed
    • You can verify the rule with:
    Get-TransportRule "Bypass Spam Filtering from Trusted Senders" | Format-List Name, From, SetSCL

    Conclusion:
    PowerShell remains the most powerful tool in any IT administrator’s arsenal—especially when the GUI can’t keep up. If you ever run into stubborn mail delivery or spam issues, consider creating targeted transport rules using PowerShell. It’s fast, clean, and gets the job done without frustration.

    © 2012–2025 Jet Mariano. All rights reserved.
    For usage terms, please see the Legal Disclaimer.

error: Content is protected !!