Monday mornings are supposed to be boring.
You know—just coffee. Email. Routine checks.

Instead, mine started with spam—the kind that should not have made it through.

I had blocked the exact same spam payload days earlier. I tested it. I watched it fail. Everything worked.
So when it suddenly appeared again, I didn’t panic—I got suspicious.

Step one: trust staging, distrust production

I replayed the spam submission on the staging site.
Blocked.

Then I tried it on the live site.
Accepted. Went straight through.

At first, it didn’t sink in deeply. My initial thought was, “Maybe a plugin is broken or needs an update.” It happens—we all know that.
But that difference told me something important: production had drifted from what I trusted. And drift is where incidents hide.

Step two: the quiet red flag

I logged into the live site and immediately saw something worse than spam.

Security plugins were disabled.

Not broken.
Not misconfigured.
Disabled.

That’s the kind of thing that never happens accidentally.

So I opened the activity logs.

Step three: the weekend login that didn’t belong

There it was.

A legitimate user account logged in around midnight over the weekend.
Minutes later, security plugins started going dark.

I did the simplest and most powerful thing in incident response:
I asked the user.

They said, “I didn’t log in.”

Then they added something casually devastating:
“I was logged out of my email too.”

At that moment, the incident classified itself.

This wasn’t a bug.
This wasn’t a mistake.
This was credential compromise.

And this is where it really hit me.

All the security knowledge I’d gathered over the past months started flashing through my head—the Google Cybersecurity Course, TCM SOC 101. It hadn’t even been long since I finished the course. At first, everything felt overwhelming: what do I do first? Like a SOC in a WP Security Incident?

Then I remembered one of the most important lessons drilled into us:
Be calm.

I escalated immediately. And out of curiosity, I started digging—step by step.
“I never knew I listened this well in class. Sometimes I think I’m lagging behind, but this proved otherwise.”

Step four: attacker behavior, not attacker noise

Digging deeper, the pattern became clear:

Defenses disabled first
File access tools installed
A blog post published with a malicious download link
Hidden code added that ran automatically
File permissions locked to slow cleanup

This wasn’t a bot smashing buttons.
This was a human taking their time.

The kind of attacker who assumes you won’t notice.

Step five: containment beats curiosity

After escalation and approval, I moved fast:

Malicious content removed
Persistence disabled
File permissions reset
Site restored from a trusted backup
All credentials rotated
Two-factor authentication enforced
Access reduced
Repeated login attempts blocked

Then came the least glamorous part of security work: rebuilding what was lost.

What this incident taught me

Real attacks are quiet
Never neglect backups
Logs matter more than alerts
Credential compromise looks “legitimate” inside systems
WordPress is not just a CMS—it’s an application

This was my first WordPress security incident.

It won’t be my last.

But next time, the timeline will be shorter—and that’s the win.

I never knew this experience would give me so many butterflies.
It’s a new kind of feeling.