Jet Mariano

Tag: IT Administration

  • Why RFC Email Standards Are Not Enough: A Real Look at Modern Email Security

    🛡 How Email Spoofing REALLY Works (With a Safer Example)

    Even though RFC standards gave us SPF, DKIM, and DMARC, the core SMTP protocol is still trust-based. That means attackers can abuse the protocol whenever a mail server is misconfigured or doesn’t enforce authentication.

    SMTP actually has two places where the “sender” can be declared:

    1. MAIL FROM (SMTP envelope)
    2. From: (message header inside DATA)

    Both of these can be forged.

    Here is a safe, fictional example showing what a spoofing attack looks like when the attacker controls their own SMTP server. NONE of this uses real domains or copyrighted examples.

    Example: Attacker Spoofing a CEO Email (Fictional Domain)

    S: 220 mail.hacker-smtp.test Ready
    C: HELO mail.hacker-smtp.test
    S: 250 Hello
    C: MAIL FROM:[email protected]
    S: 250 Ok
    C: RCPT TO:[email protected]
    S: 250 Accepted
    C: DATA
    S: 354 End data with .
    C: Subject: Immediate Action Required
    C: From: [email protected]
    C: To: [email protected]
    C:
    C: Hi Bob,
    C: Please review this file urgently:
    C: https://malicious-link.test
    C:
    C: Thanks,
    C: Jane
    C: .
    S: 250 Message accepted
    C: QUIT
    S: 221 Closing connection

    What happened here?

    • The attacker never touched the real domain’s server.
    • No SPF, DKIM, or DMARC was involved.
    • They simply declared themselves as [email protected].
    • The receiving system, if unprotected, trusts the SMTP envelope + header.

    This is why:

    • Email security must be enforced on the RECEIVING side.
    • SPF/DKIM/DMARC without an email security gateway (ProofPoint, Barracuda, Cisco, etc.) is NOT enough.

    🛡 Why SPF and DKIM Alone Can Be Faked

    Attackers don’t guess your DNS records—
    They retrieve them using public DNS queries.

    Example: How Hackers Pull Your DKIM Public Key

    nslookup -type=txt selector1._domainkey.yourdomain.com

    Example: How Hackers Retrieve Your SPF Policy

    nslookup -type=txt yourdomain.com

    Your actual records are public by design.

    Attackers do not break DKIM or SPF—
    they simply copy what’s public and send email from a server you do not control.

    This leads to the two main spoofing paths:

    Two Ways Attackers Deliver Spoofed Email

    1. Using Their Own SMTP Server

    • Full control
    • Can impersonate envelope sender and header
    • Can ignore security standards
    • Can replay your SPF/DKIM values
    • Can build reputation over time

    2. Using Someone Else’s SMTP Server

    • Open relay servers
    • Misconfigured mail servers
    • Free public spoofing tools (many exist)
    • Requires no authentication
    • Still bypasses SPF/DKIM because enforcement happens at the receiver

    🧩 Why You STILL Need ProofPoint or an SEG

    • RFC standards are voluntary
    • SPF/DKIM/DMARC are not enforcement engines
    • They only give a pass/fail signal
    • Your mail flow only becomes safe when paired with:
    1. ProofPoint BEC + EAC protection
    2. Malicious payload scanning
    3. Impostor Detection™
    4. Header anomaly detection
    5. Authentication-layer reputation scoring
    6. Threat intelligence for known bad SMTP sources

    No SPF/DKIM/DMARC setting—no matter how perfect—
    can stop a spoof that comes from an SMTP server across the world.

    Only a receiving enforcement engine can.

    Over the years I have worked with high end filtering solutions in multiple large enterprise environments. The dashboards have changed but their purpose has stayed the same.

    Their goal is to strengthen the RFC standards that are not strong enough on their own.

    Here are the RFCs that define the foundation of email authentication:

    • SPF — RFC 7208
    • DKIM — RFC 6376
    • DMARC — RFC 7489

    These standards are important but incomplete. Even with perfect configuration you can still get spoofing attempts, executive impersonation, phishing, and vendor fraud. The RFC by itself cannot stop the modern threat landscape.

    Below is a clear breakdown of why.

    Defense Wins Championships and Email Security Works the Same Way

    In basketball you cannot win with offense alone. You win when you have strong defense and efficient offense working together.

    Email follows the same pattern.

    SPF is offense
    DKIM is offense
    DMARC is offense

    They validate. They authenticate. They enforce the rule book.

    But attackers do not care about the rule book.
    They bypass these RFC standards every day.

    This is why you need a real defense layer.

    This is where filtering tools like Proofpoint or Barracuda add the protection the protocols cannot provide.

    Why SPF, DKIM, and DMARC Are Not Enough

    Even when perfectly configured these protocols only protect part of the message.

    SPF

    Checks the MAIL FROM envelope.
    Attackers spoof the visible Header From instead.

    DKIM

    Signs the headers.
    Attackers send unsigned mail from lookalike domains.

    DMARC

    Requires alignment.
    Attackers bypass alignment through friendly name tricks and unicode abuse.

    This is why even major companies with mature security still deal with spoofing.

    The RFCs do not cover every modern attack vector.

    What Third Party Filtering Tools Actually Do

    Filtering solutions provide the defense layer that SPF, DKIM, and DMARC cannot offer.

    They detect:

    • impersonation
    • behavior anomalies
    • malicious intent
    • lookalike domains
    • CEO fraud
    • malicious URLs
    • dangerous attachments
    • unknown senders
    • unusual source locations
    • suspicious API behavior
    • threat reputation changes

    They analyze behavior rather than relying only on protocol alignment.

    Without this layer your domain becomes an easy target.

    What Happens When Security Is Too Tight

    When filters are over configured these are the problems you will see:

    • executive emails going to junk
    • vendors trapped in quarantine
    • delayed messages
    • business interruptions
    • unhappy management
    • slow communication
    • loss of confidence in IT

    Security must be layered not suffocating.

    The Five Layers of Modern Email Security

    This approach is what works in every large enterprise environment.

    1. User Training

    Teach users how spoofing works.
    Show them friendly name manipulation.
    Awareness reduces risk.

    2. Proper Microsoft 365 Configuration

    Connectors. Accepted domains. Transport rules.
    Everything must be configured correctly.

    3. SPF, DKIM, and DMARC

    The RFC standards still matter.
    Alignment must be correct.

    4. Third Party Filtering Solutions

    Proofpoint. Barracuda. Mimecast.
    They provide what the RFC cannot.

    5. APM Monitoring

    Dynatrace. Splunk. AppDynamics.
    These tools detect environmental issues that affect mail flow.

    APM identifies:

    • abnormal MAIL FROM attempts
    • spikes in DKIM failures
    • SMTP conversation problems
    • delays before Proofpoint
    • anomalies at the DNS level

    This gives early warning before a threat becomes a major issue.

    Final Thought

    Email is the number one attack surface in every company.
    The truth is simple.

    You get what you pay for.

    If you go cheap your domain becomes a soft target.
    You will deal with spoofing
    You will deal with ransomware
    You will deal with compromised accounts
    You will deal with vendor fraud

    If you invest in complete layered defense your organization becomes a bad target.

    This is how modern email security works today.

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

  • Secure Automation with PowerShell SecretManagement: Simplifying Credential Management for IT Pros

    Introduction:
    In enterprise environments, automation is only as secure as the credentials it uses. Hardcoding passwords into scripts is a security disaster waiting to happen. Enter PowerShell SecretManagement — a cross-platform module that allows IT professionals to store, retrieve, and manage credentials securely while keeping scripts clean, compliant, and automation-ready.

    Description & Guide:

    1. What is SecretManagement?
      The SecretManagement module provides a unified way to work with secrets across different vaults like Windows Credential Manager, Azure Key Vault, KeePass, or HashiCorp Vault — without locking you into a single storage provider.
    2. Installing the Modules
    Install-Module Microsoft.PowerShell.SecretManagement
Install-Module Microsoft.PowerShell.SecretStore

    3. Registering a Vault
    For a local secure store:

    Register-SecretVault -Name LocalVault -ModuleName Microsoft.PowerShell.SecretStore -DefaultVault

    4. Adding a Secret

    Set-Secret -Name MySQLAdmin -Secret (Get-Credential)

    5. Retrieving a Secret in Scripts

    $cred = Get-Secret -Name MySQLAdmin -AsCredential
Invoke-Sqlcmd -ServerInstance "SQL01" -Username $cred.UserName -Password $cred.GetNetworkCredential().Password

    6. Why This Matters

    • Eliminates plaintext passwords in scripts
    • Centralizes secret management for easier updates
    • Works seamlessly with CI/CD pipelines and scheduled tasks

    Conclusion:
    Security and automation don’t have to be enemies. With PowerShell SecretManagement, you can protect sensitive credentials without sacrificing automation speed or flexibility. For IT pros managing hybrid environments, this module is a must-have in your PowerShell toolbox.

    If you’d like to go beyond this post and see what Microsoft officially recommends, here are my go-to resources:

    Microsoft Docs – SecretManagement Overview

    Microsoft Docs – SecretStore vault extension

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

  • Migrating Azure AD Scripts to Microsoft Graph PowerShell: A Practical Guide for IT Administrators

    Introduction
    The AzureAD PowerShell module has served IT administrators for years, but it’s now officially deprecated in favor of the Microsoft Graph PowerShell SDK. While the change may feel like another “cloud shuffle,” migrating your scripts is not just a compliance move — it’s your ticket to a more powerful, secure, and future-proof automation toolkit. In this post, I’ll walk you through the essentials of converting your Azure AD scripts to Microsoft Graph, with clear side-by-side examples.

    Why Migrate?

    • Future Support: Microsoft Graph is actively developed; AzureAD is on life support.
    • Unified Endpoint: Graph covers Azure AD, Intune, Exchange Online, Teams, and more in one API.
    • Security: Better authentication methods, including secure app registrations and least-privilege scopes.

    Step 1 – Install Microsoft Graph PowerShell

    # Install the module
Install-Module Microsoft.Graph -Scope CurrentUser

# Update if already installed
Update-Module Microsoft.Graph

# Connect with interactive sign-in
Connect-MgGraph -Scopes "User.Read.All", "Group.ReadWrite.All"

# Confirm connection
Get-MgContext

    Step 2 – Side-by-Side Script Conversion

    Example: Get all Azure AD users
    AzureAD Module:

    Connect-AzureAD
Get-AzureADUser -All $true

    Microsoft Graph:

    Connect-MgGraph -Scopes "User.Read.All"
Get-MgUser -All

    Example: Get members of a group
    AzureAD Module:

    $groupId = (Get-AzureADGroup -SearchString "Sales Team").ObjectId
Get-AzureADGroupMember -ObjectId $groupId

    Microsoft Graph:

    $groupId = (Get-MgGroup -Filter "displayName eq 'Sales Team'").Id
Get-MgGroupMember -GroupId $groupId

    Example: Create a new group
    AzureAD Module:

    New-AzureADGroup -DisplayName "Project A Team" -MailEnabled $false -SecurityEnabled $true -MailNickname "ProjectATeam"

    Microsoft Graph:

    New-MgGroup -DisplayName "Project A Team" `
    -MailEnabled:$false `
    -SecurityEnabled `
    -MailNickname "ProjectATeam"

    Step 3 – Updating Authentication
    With Microsoft Graph, you can fine-tune permissions at sign-in instead of granting broad directory access:

    Connect-MgGraph -Scopes "User.ReadWrite.All", "Group.ReadWrite.All"

    Only request the scopes you actually need — this aligns with least privilege best practices.

    Step 4 – Testing and Verification
    Before replacing scripts in production, run them in a test tenant or a non-production environment. Compare outputs from AzureAD and Graph to ensure parity.

    Conclusion
    Migrating from AzureAD to Microsoft Graph PowerShell is more than just a rewrite — it’s a forward-looking investment. Once you adapt, you’ll unlock richer APIs, cross-service automation, and security benefits that AzureAD simply can’t match. My advice? Start small: pick one script, convert it, and test until you’re confident. Once you see the gains, the rest will follow naturally.

    For official guidance and best practices from Microsoft, check out these resources:

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

error: Content is protected !!