Jet Mariano

Tag: cybersecurity

  • DKIM Security: How Signing and Key Rotation Stop Email Spoofing

    Introduction

    DKIM (DomainKeys Identified Mail) is one of the most effective ways to verify that an email truly came from your organization. But many companies misunderstand one crucial truth:

    DKIM is only as strong as the protection of its private key.

    If attackers obtain your DKIM private key, they can sign email that appears cryptographically legitimate — even if it comes from a malicious server. This is why key length, rotation, and protection matter just as much as turning DKIM “on.”

    Section 1 — What DKIM Actually Does

    DKIM works by attaching a digital signature to every outbound message.
    It ensures:

    • The message hasn’t been altered
    • The sender is authorized
    • The domain identity can be verified

    The core elements are:

    1️⃣ DKIM Selector (s=)

    Identifies which key is used.
    Example:
    s=mail2025;

    2️⃣ DKIM Domain (d=)

    The domain signing the message.
    Example:
    d=example-corp-secure.com;

    3️⃣ Public Key (Published in DNS)

    Stored in a TXT record:
    mail2025._domainkey.example-corp-secure.com

    4️⃣ Private Key (kept hidden on the mail server)

    This is the key attackers target.
    It signs every outbound message.

    Section 2 — Why Private Keys Must Be 2048-bit Minimum

    Attackers today can break 1024-bit DKIM keys.

    • Cloud computing
    • GPU farms
    • Distributed cracking

    This is why Microsoft and major ESPs recommend 2048-bit keys.

    Weak DKIM = forged trust.

    Section 3 — Why You Must Rotate DKIM Keys Regularly

    Even a strong key becomes weaker over time:

    • Keys leak
    • Keys get copied
    • Keys get exposed in old backups
    • Misconfigured systems reuse keys
    • Bad actors gather DNS data for months

    Weekly or monthly rotation is considered best practice in regulated industries like banking.

    Rotation protects your domain even if an attacker manages to obtain an older key.

    Section 4 — How an Attacker Exploits DKIM

    If the private key is stolen:

    • They can sign malware
    • They can sign phishing
    • They bypass SPF failures
    • They pass DKIM alignment
    • They pass DMARC alignment
    • Email goes straight to inbox

    This is why DKIM alone is not enough.

    Section 5 — Why DKIM Matters

    • Prevents email tampering
    • Builds domain trust
    • Enables DMARC “reject” mode
    • Protects your brand
    • Reduces false positives
    • Ensures message integrity

    But DKIM is only strong if the private key is protected and rotated.

    Conclusion

    Most executives think DKIM is “set it and forget it.”
    But email security today requires:

    • Strong 2048-bit DKIM keys
    • Regular rotation
    • Tight private key protection
    • Monitoring through Proofpoint and EOP
    • DMARC enforcement

    This is not optional anymore — especially for banks.

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

  • DMARC (Domain-based Message Authentication, Reporting & Conformance)

    Introduction

    DMARC (Domain-based Message Authentication, Reporting & Conformance) is the control system that tells receiving email servers what to do when a message fails SPF or DKIM. Without DMARC, attackers can spoof your domain freely.

    Section 1 — What DMARC Does

    DMARC:

    • Protects your domain from spoofing
    • Defines how mail servers should handle failures
    • Provides visibility into fraud attempts
    • Supports brand protection
    • Enables full enforcement (“p=reject”)

    Section 2 — DMARC Tags and Their Meaning

    1️⃣ v=DMARC1

    Protocol version. Always DMARC1.

    2️⃣ p= (Policy)

    Tells receiving servers what to do:

    • p=none → Monitor only
    • p=quarantine → Send failures to spam
    • p=reject → Block failures entirely (best practice for banks)

    3️⃣ rua= (Aggregate Reports)

    Where daily XML reports are delivered.
    Example:
    rua=mailto:[email protected]

    4️⃣ ruf= (Forensic Reports)

    Receives detailed failure samples (PII-sensitive).
    Example:
    ruf=mailto:[email protected]

    5️⃣ fo= (Failure Options)

    Controls what triggers forensic reporting.
    Common:
    fo=1 → Send forensic report on any SPF/DKIM failure.

    Section 3 — Example of a DMARC Record

    v=DMARC1;
p=reject;
rua=mailto:[email protected];
ruf=mailto:[email protected];
fo=1;
adkim=s;
aspf=s;

    adkim=s and aspf=s enforce strict alignment — critical for banks and regulated industries.

    Section 4 — Why DMARC Matters

    • Blocks domain impersonation
    • Reduces malware/phishing impact
    • Protects customers from fraud
    • Shields executives from spoofing
    • Enables brand trust
    • Essential for financial institutions

    Conclusion

    A strong DMARC policy (“reject”) is one of the strongest defenses against email spoofing — but only when SPF and DKIM are configured properly and regularly monitored.

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

  • 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 I Protected VIP Mailboxes in Exchange: My Experience Creating Shielded, Hidden, and Restricted Email Objects

    Intro

    In every organization — commercial, government, or religious — there are individuals whose roles require an extra layer of protection. These may include executives, legal teams, board members, or other high-visibility leaders. Their mailboxes must be shielded from noise, protected from internal misuse, and hardened against external threats.

    This blog shares how I implemented a VIP Exchange Protection Model in one of the most globally distributed environments I’ve ever worked in.
    All sensitive details are removed — but the principles and methods remain the same.

    Why VIP Mailboxes Need Extra Protection

    VIP users face unique risks:

    1. They are targets for impersonation

    Attackers attempt to spoof high-level leaders to gain authority over employees.

    2. They receive a high volume of inbound email attempts

    Even legitimate internal senders may unintentionally overwhelm their inboxes.

    3. They must focus on mission-critical responsibilities

    Unfiltered communication equals distraction and risk.

    4. Their mailboxes contain sensitive or privileged information

    Unauthorized access can lead to catastrophic consequences.

    The goal of the VIP model is simple:

    Only authorized individuals should be able to see, email, or discover these mailboxes.

    My VIP Protection Model (Redacted & Generalized)

    Below is the exact approach I used, without exposing private organizational information.

    1. Hide VIP Mailboxes From the Global Address List (GAL)

    This prevents the general population from seeing their email addresses.

    Set-Mailbox "VIP Mailbox" -HiddenFromAddressListsEnabled $true

    This ensures the mailbox exists — but only administrators know where it is.

    2. Restrict Who Can Email VIPs (Allow Lists Only)

    Instead of blocking all users, I inverted the model:

    Only a hand-selected, approved list of senders can email VIPs.

    I used:

    • Transport Rules
    • Moderation
    • Recipient Restrictions

    Example allow-list logic:

    Set-Mailbox "VIP Mailbox" -AcceptMessagesOnlyFrom @("Assistant1","Assistant2","SecurityOffice")

    If anyone outside this list tried to email the VIP:

    • The message was blocked,
    • Logged,
    • And optionally forwarded to a monitored mailbox for review.

    3. Prevent External Email Delivery Entirely

    For VIP mailboxes that should never receive external messages:

    Set-Mailbox "VIP Mailbox" -RequireSenderAuthenticationEnabled $true

    This enforces authenticated internal senders only.

    No anonymous sender.
    No spoofed external mail.
    No leakage.

    4. Apply Enhanced Anti-Impersonation

    This included:

    • DMARC alignment enforcement
    • Anti-spoofing engines (such as ATP / Defender)
    • Display name protection (“VIP Name Protection”)
    • Proofpoint Impostor Protection (in environments where I managed Proofpoint)

    I ensured VIP names could not be spoofed internally or externally.

    5. Enable Strict Audit Logging

    For VIP mailboxes:

    • Every access
    • Every folder action
    • Every send
    • Every delegate assignment

    …was logged and reviewed.

    Set-Mailbox "VIP Mailbox" -AuditEnabled $true

    This protected the VIP and the organization.

    6. Controlled Delegation

    VIP mailboxes should not have multiple delegates or dynamic permission assignments.

    Only essential individuals were allowed:

    • Executive assistants
    • Chiefs of staff
    • Security-approved personnel

    Least privilege.
    Zero trust.
    No exceptions.

    7. Role-Based Access Control (RBAC) For Admins

    Even administrators require controlled boundaries.

    I created RBAC roles to ensure:

    • Only specific admins could view or manage VIP mailboxes
    • No accidental changes
    • No unauthorized mailbox access

    This is premium-level Exchange governance.

    The Result

    By combining:

    • Hidden GAL entries
    • Sender allow-lists
    • External blocking
    • Anti-impersonation intelligence
    • Transport rules
    • Controlled delegation
    • RBAC
    • Audit trails

    …I built a VIP Exchange Protection Framework that:

    • Reduced risk
    • Eliminated unwanted emails
    • Protected sensitive correspondence
    • Honored the mission of the organization
    • Allowed leaders to focus on their responsibilities
    • Created a safer communication ecosystem

    This experience became one of the defining technical and spiritual stewardship assignments of my career.

    Final Reflection

    Protecting VIP mailboxes goes beyond technology — it’s stewardship, trust, and responsibility.

    When you guard a mailbox, you are guarding:

    • time,
    • focus,
    • privacy,
    • and the ability of leaders to do their work without distraction.

    Implementing this model taught me:

    Security is an act of service — not just configuration.

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

  • Email Spoofing Explained: How Attackers Do It and How DMARC Blocks Them

    Introduction

    Email is built on trust — and the original SMTP protocol (from 1982) was never designed with modern threat actors in mind. Attackers now exploit loose RFC rules, misconfigured servers, and public DNS to spoof legitimate senders and bypass basic filtering.

    This blog explains how spoofing actually works, why SPF/DKIM alone are not enough, and why DMARC alignment + Proofpoint is essential for stopping real-world business email compromise (BEC) attacks.

    1. Email Spoofing 101 — Why SMTP Allows It

    SMTP does not validate who the sender truly is.
    An attacker can control:

    a) The SMTP Envelope (“MAIL FROM”)

    Used for return-path, bounce messages, and SPF checks.

    b) The Email Header (“From:”)

    What the human sees in Outlook, Gmail, iPhone Mail.

    Both can be forged.
    That means an attacker can send:

    MAIL FROM: <[email protected]>
From: Jane Doe <[email protected]>

    …even though they do not own that domain.

    2. Step-by-Step: How Attackers Use SMTP to Forge Email

    (Everything below uses neutral demonstration domains to avoid referencing any real organization.)

    S: 220 mail.fake-sender.net SMTP Ready
C: HELO mail.fake-sender.net
S: 250 Hello
C: MAIL FROM:<[email protected]>
S: 250 OK
C: RCPT TO:<[email protected]>
S: 250 Accepted
C: DATA
S: 354 Start mail input
C: Subject: Urgent – Please Review
C: From: [email protected]
C: To: [email protected]

Hi Bob,
Please review this document:
https://malicious-link-example.net/file

Thanks,
Jane
C: .
S: 250 Message accepted
C: QUIT
S: 221 Goodbye

    Important:
    This is exactly how attackers craft spoofed email — the same RFC-compliant commands a normal email client uses.

    3. How Attackers “Harvest” SPF and DKIM Using DNS

    Attackers don’t guess your DNS settings.
    They simply query them publicly, like anyone else on the internet.

    Example: Retrieving DKIM Keys

    nslookup -type=txt selector1._domainkey.victim-of-spoofing.com

    This returns the DKIM public key, which attackers use to craft more believable spoofing attempts (not to break DKIM, but to mimic structure).

    Example: Retrieving SPF Records

    nslookup -type=txt victim-of-spoofing.com

    Result:

    "v=spf1 include:_spf.example-email.net -all"

    Attackers now know:

    • what legitimate sending systems you use
    • how strict your SPF policy is
    • which vendors to impersonate

    SPF & DKIM are public, and attackers rely on that.

    4. Why SPF and DKIM Alone Are Not Enough

    SPF checks the envelope (MAIL FROM).
    DKIM checks the message integrity.

    But both fail in these common scenarios:

    SPF Fails When:

    • A scammer spoofs only the header From
    • Email is forwarded
    • Attackers use free SMTP servers with permissive policies

    DKIM Fails When:

    • Sender uses a domain with no DKIM at all
    • Attackers spoof domains they do own
    • Emails pass through weak relays

    This is why companies get spoofed even with “perfect” SPF/DKIM.

    5. DMARC Alignment — The Real Line of Defense

    DMARC requires:

    ✔ SPF Alignment

    Envelope domain must match header From domain.

    ✔ DKIM Alignment

    DKIM signature domain must match the header From.

    If neither aligns, DMARC instructs receivers to:

    • none — monitor only
    • quarantine — send to spam
    • reject — block outright

    Reject is where spoofing finally dies.

    6. Two Ways Attackers Deliver Spoofed Email

    This is critical for interview-level mastery:

    1️⃣ Using Their Own SMTP Server

    Attackers set up a server where:

    • they control all DNS
    • they can configure any RFC behavior
    • they can impersonate any domain

    This allows highly believable spoofing.

    2️⃣ Using Vulnerable Third-Party SMTP Servers

    Attackers often search for:

    • misconfigured mail relays
    • open SMTP relays
    • free spoofing services

    Both methods work unless DMARC reject + Proofpoint is in place.

    7. Why Proofpoint Completes the Protection

    Even with DMARC reject, attackers still spoof:

    • VIP names (“Display Name Spoofing”)
    • Lookalike domains (e.g., companny-secure.com)
    • Legitimate cloud providers that DMARC trusts
    • OAuth-compromised accounts (EAC)

    Proofpoint adds:

    • Identity threat intelligence
    • Imposter protection (BEC Defense)
    • Lookalike domain analysis
    • Behavioral anomaly detection
    • URL rewriting + sandboxing
    • Real-time classification

    Without Proofpoint, DMARC is only half of the defense.

    Conclusion

    Attackers rely on the weaknesses of SMTP’s original design, public DNS records, and domains they control. That’s why spoofing is still one of the most common and dangerous forms of cyberattack worldwide.

    The only way to fully protect executives, employees, and customers is:

    ✔ SPF
    ✔ DKIM
    ✔ DMARC (reject)
    ✔ PLUS Proofpoint’s identity + behavioral controls

    This is the combination that stops real-world BEC/EAC attacks.

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

  • How BEC (Business Email Compromise) and EAC (Email Account Compromise) Work, and How Proofpoint + EAC Controls Stop Them

    Introduction

    BEC (Business Email Compromise) and EAC (Email Account Compromise) are the two most financially damaging email-based attacks today.
    They bypass traditional spam filters, they target humans—not firewalls—and they abuse trust instead of malware.

    Microsoft 365 alone cannot fully protect against these attacks.
    That’s why organizations use Proofpoint, DMARC alignment, and strict authentication controls—to verify identity, stop impostors, and prevent fraudulent requests from reaching inboxes.

    This blog explains:

    • How BEC works
    • How EAC happens
    • What attackers exploit
    • Why RFC email standards make impersonation easy
    • How Proofpoint + EAC controls shut these attacks down

    Perfect material for any advanced interview panel.

    What Is Business Email Compromise (BEC)?

    BEC is when attackers pretend to be:

    • your CEO,
    • your CFO,
    • your HR director,
    • a vendor,
    • or someone with financial authority

    …with the goal of manipulating employees into:

    • wiring money
    • changing direct deposit info
    • sending W-2s
    • releasing confidential documents
    • approving purchases

    🔸 The key point:

    BEC uses identity deception, not malware.
    No attachments.
    No links.
    Just social engineering in a clean email.

    How BEC Works (Step-By-Step)

    1. Reconnaissance

    Attackers scrape:

    • LinkedIn
    • Company directory leaks
    • Press releases
    • Vendor invoices
    • Social media

    They map who communicates with whom.

    2. Identity Impersonation

    They spoof:

    • Display names
    • Envelope sender
    • Reply-To address
    • SPF-valid lookalike domains

    Example:
    [email protected] →
    [email protected]

    3. Thread Hijacking

    They do this by compromising a vendor mailbox and replying inside an existing email chain.

    4. Social Engineering

    The attacker sends a “clean” request:

    • “Are you available?”
    • “I need this wire sent ASAP.”
    • “Can you update this banking information?”

    5. Financial Fraud

    Once the attacker has the employee’s trust — the money is gone.

    What Is Email Account Compromise (EAC)?

    EAC is when the attacker actually logs in to a real mailbox.

    Not spoofing.
    Not faking.
    Real access.

    How they gain access:

    • MFA fatigue
    • Password reuse
    • Legacy protocol with no MFA
    • OAuth token theft
    • Malware stealing credentials
    • Phishing pages identical to Microsoft login

    Once inside, attackers:

    • Set up hidden forwarding rules
    • Delete MFA alerts
    • Change mailbox rules
    • Hijack vendor threads
    • Sit silently and wait for financial conversations

    EAC is dangerous because the attacker uses your real domain, your real mailbox reputation, your real account.

    This is why simply having SPF, DKIM, and DMARC does not stop EAC.

    Why Proofpoint Is Needed (Beyond RFC Email Standards)

    RFC email standards allow spoofing by design.

    Attackers can:

    • abuse SMTP commands
    • spoof the “MAIL FROM”
    • spoof the “From:” header
    • use free SMTP servers
    • harvest SPF/DKIM values via nslookup
    • build near-perfect domain clones

    Example:

    nslookup -type=txt _dmarc.victim-domain.com
nslookup -type=txt selector._domainkey.victim-domain.com

    Attackers see your exact SPF/DKIM configuration.
    They spoof accordingly.

    This is why relying on RFC standards alone is not enough.

    How Proofpoint Stops BEC and EAC

    1. Identity Protection

    Proofpoint checks:

    • display name anomalies
    • domain lookalikes
    • impossible travel
    • VIP impersonation attempts
    • internal vs external identity mapping
    • “Reply-To mismatch”
    • “Header vs Envelope mismatch”

    Microsoft EOP can do part of this,
    Proofpoint does it with far more accuracy.

    2. Vendor Fraud Protection

    Proofpoint fingerprints:

    • vendor sending behavior
    • previous conversation style
    • writing style
    • IP reputation

    If a vendor mailbox is compromised, Proofpoint detects the “change in sending personality.”

    This is one of the strongest EAC protections in the industry.

    3. DMARC Enforcement + Lookalike Domain Defense

    Proofpoint enforces:

    • Domain alignment
    • Display name behavior
    • Header-from authentication
    • Cross-identity matching

    Lookalike domains” examples (generic only):

    • company-secure.com
    • companny.com
    • c0mpany-support.com
    • company-mailservice.com

    These would pass traditional email filters.

    4. URL and Payload Isolation

    Even if links look clean, Proofpoint re-writes and detonates them.

    Although BEC rarely has links, EAC-based phishing almost always does.

    5. Machine Learning on Human Behavior

    Proofpoint analyzes:

    • who talks to whom
    • frequency
    • direction
    • urgency phrases
    • tone manipulation

    If the CEO normally never emails accounting at 10:30 PM on a Friday — the message gets flagged.

    Real-World Example (Anonymized)

    A vendor’s mailbox was compromised.
    The attacker replied inside an existing thread asking to update bank account numbers.

    Microsoft EOP didn’t block it — it came from a legitimate vendor domain.

    Proofpoint flagged:

    • anomalous IP
    • unusual writing style
    • “conversation thread hijacking detected”
    • vendor identity risk score

    Proofpoint blocked the message before it reached the user’s mailbox.

    This is exactly why companies invest in Proofpoint.

    Conclusion

    BEC and EAC are no longer “IT problems.”
    They are financial crimes, costing billions worldwide.

    Microsoft 365 gives strong baseline protection,
    but attackers today use identity manipulation, social engineering, and thread hijacking that bypass traditional signals.

    Proofpoint closes those gaps with:

    • identity defense
    • behavioral AI
    • vendor fraud detection
    • DMARC enforcement
    • mailbox compromise detection
    • impersonation protection

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

  • A Quiet Milestone in Our Family’s IT Journey

    Some victories don’t need spotlights when they’ve already made their mark in the heart.

    My son earned his Master’s in Cybersecurity—an achievement forged through discipline, persistence, and his own quiet fire. While others chase trends, he’s built a foundation. And while I never asked him to follow in my footsteps, he chose to walk beside them in his own way.

    This moment reminds me that legacy isn’t loud. It’s built in silence—line by line, late night by late night, passed through keyboards, keystrokes, and countless system logs. And while the world sees just a photo, I see a journey… a reflection of years of sacrifice, faith, and fierce intention.

    If I’m the blueprint, he is the upgrade.

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

  • Ransomware: What It Is and How I Survived Multiple Attacks

    Introduction
    Ransomware is a digital hostage situation—and it’s getting worse. It can freeze hospitals, paralyze billion-dollar businesses, and devastate small IT shops. I’ve survived multiple ransomware attacks in my career, and I’ll tell you how: I never put all my eggs in one basket. This blog explains what ransomware is, how it spreads, and how I protected myself. My defense? Layered backups. Not just the cloud—Veeam, Commvault, and old-school external drives.

    What is Ransomware?
    Ransomware is a form of malware that encrypts files and demands payment for the decryption key. It comes in two common forms:

    • Locker Ransomware: Locks you out of your device or system.
    • Crypto Ransomware: Encrypts your files and threatens to destroy or leak them if payment isn’t made.

    It often arrives silently—via phishing emails, malicious downloads, or exposed ports—and acts fast. In just minutes, entire systems can be taken hostage.

    Real-World: How I Survived Ransomware

    At Tarzana Medical Center, ransomware struck without warning. Medical data became inaccessible in minutes. I’ve seen even global giants like Ingram Micro fall victim to attacks.

    Yet every time, my systems stayed intact. Why? My systems always stayed intact—because I followed one simple rule: diversify your backups.

    Here’s how I stayed ahead of attackers:

    • I never relied solely on cloud backups (they can be corrupted or locked by the same attack).
    • I used Veeam for virtualized workloads, giving me granular recovery options.
    • I ran Commvault for enterprise-grade backup and disaster recovery.
    • I manually created offline backups to external drives and physically disconnected them to avoid remote encryption.

    This multi-layered approach allowed me to recover in hours—not days—and saved thousands in downtime and potential ransom.

    How Ransomware Spreads

    • Phishing emails with malicious attachments or links
    • Weak RDP access without MFA
    • Unpatched vulnerabilities in apps or OS
    • Rogue websites and drive-by downloads

    How to Prevent Ransomware Attacks

    1. Educate Your Team
      Train staff on email safety, suspicious links, and phishing red flags.
    2. Patch Everything
      Keep OS, firmware, and all third-party software up to date.
    3. Lock Down RDP & Admin Access
      Use MFA and limit RDP access with strict firewall rules.
    4. Deploy EDR or XDR Tools
      Use behavior-based endpoint protection—not just signature-based antivirus.
    5. Segment Your Network
      Don’t allow lateral movement. Use VLANs and access controls.
    6. Adopt a Backup Strategy That’s Offline-Friendly
      • Veeam for VM and application backup
      • Commvault for large-scale environment coverage
      • External drive backups add a final safety layer against data loss.
    7. Test Your Backups Frequently
      A backup that isn’t tested is a gamble. Run simulations regularly.

    Responding to a Ransomware Incident

    • Isolate the infected systems
    • Notify your incident response team or external partner
    • Do not pay the ransom—this only fuels more attacks
    • Restore from offline or clean backups
    • Report to authorities (FBI, IC3)

    Conclusion
    Conclusion
    Ransomware attacks are relentless—but with the right strategy, you can stay ahead.
    A strong backup routine, tested regularly, makes all the difference.

    Avoid relying on just one cloud backup. Use multiple layers—offline, cloud, and local.
    Act now—before a breach locks you out.

    —
    Jet Mariano
    Cloud Infrastructure Engineer | Cybersecurity Practitioner
    jetmariano.us

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

error: Content is protected !!