Reza's Case Study on Incident Response

🟠 A Study Notes and Theory Blog Exclusive

Reza Kenji Khan didn’t plan on skipping lunch that Thursday.

He had just wrapped up his morning change control meeting and was heading toward the breakroom for ten minutes of solitude: black coffee, no distractions. Then the first alert flashed across his dashboard.

SIEM ALERT: Multiple Failed Logins from CFO_ Account on Finance-01.

Annoying, but not urgent. Then the red flags started waving.

The CFO was on a flight to Zurich. The login attempts were from two physical locations at once. And the IP whitelist on Finance-01 had quietly been removed during a routine patch test the night before.

The war room activated. Quietly. Efficiently. Reza stood up and walked into the storm.

What Was Prepared

Rymar Tech’s incident response program had been matured over multiple quarters. Reza had helped refine it himself. In CISSP terms, this was Preparation, the first phase of the six-step lifecycle.

Everyone on the security operations team knew their role. Documentation was centralized. Playbooks were embedded in the ticketing system. Escalation contacts were preloaded into the IR tracker and printed in hardcopy in every conference room.

Reza didn’t hesitate.

“Marty, log all actions from here forward. Victor, start the bridge. Jenny, isolate the endpoint.”

This wasn’t the first time they had seen an alert. But the difference between a security alert and a full-blown incident is not the presence of compromise—it is the presence of readiness.

What Was Detected

The team entered the Detection and Analysis phase of incident response.

Reza reviewed packet flows using their internal network intrusion detection system. No signs of exfiltration yet. But Finance-01 was running background scripts that looked like enumeration activity. The attacker was probing group policies and attempting lateral movement.

Logs from the endpoint detection platform revealed a vulnerability exploit via DLL sideloading. The technique pointed to a threat actor with experience in privilege escalation, likely not an amateur.

More disturbing was that a malformed PDF had been opened three hours earlier. Reza correlated that moment with the first unusual log entries. The attacker had breached initial access and was gaining foothold.

The incident was now confirmed. Not a false positive. Not a fluke.

What Was Contained

This was the Containment phase. Fast action, minimal disruption.

The finance subnet was temporarily resegmented using a VLAN shift. Affected systems were removed from the domain. DNS entries were redirected. All outbound connections from that node were blocked while Reza verified if command-and-control callbacks had been established.

No panic. Just control.

The attacker’s initial access point was neutralized. The team disabled affected accounts and began rotating service credentials. MFA was reapplied to high-privilege users.

They were not wiping yet. Wiping was for eradication. This was still the window for analysis and boxing in the threat.

Reza maintained containment until forensics confirmed that no data had been copied or transmitted outside the environment.

What Was Removed

Now came Eradication.

The payload was found embedded in a PDF sent from what appeared to be a vendor partner. It bypassed filters due to a misconfigured data loss prevention rule that had been on Reza’s backlog for two months.

Classic.

The attacker had installed persistence mechanisms, including scheduled tasks and an obfuscated startup registry key. All were identified, removed, and the endpoint was scrubbed using their internal forensics tools.

They then reimaged Finance-01 to eliminate any doubt.

System logs were captured. Hashes were generated for legal and compliance purposes. The infected files were quarantined and submitted to the malware analysis team for reverse engineering.

What Was Restored

This was Recovery, the stage where too many organizations get sloppy. Reza would not allow that.

Finance-01 was rebuilt using the latest golden image. System hardening was verified. The most recent verified backup was restored after passing integrity checks. A new monitoring agent was installed with stricter alerting thresholds.

The server was not rejoined to the domain until it passed an out-of-band inspection and configuration audit.

Business resumed quietly. No executive emails went undelivered. No payment processing missed a beat.

To the outside world, it was a normal Thursday.

What Was Learned

The final phase was not technical. It was human. It was Lessons Learned.

The team gathered the next morning, no suits, no titles. Just analysts and engineers with notepads and espresso.

Reza led the debrief. The IR tracker was reviewed. Every action and timestamp dissected.

They identified the exact gap that allowed the DLP rule to be bypassed. They admitted the IP whitelist removal was not properly reviewed during change control. They accepted that MFA enforcement exceptions were granted too liberally to high-value targets.

Reza made no speeches. Just one final remark:

“This one didn’t cost us. The next one might. Let’s be ready for that one.”

CISSP Takeaway

Incident response is not a checklist. It is a practiced mindset.

If you are studying for the CISSP, do not just memorize the six steps. Visualize them. Picture the war room. Imagine the log review. Feel the pressure of the phone bridge going live while your SIEM burns red.

That’s how Reza studied. That’s how you should study.

Because one day your screen will blink and the alerts will stack up. You will not rise to the occasion. You will fall to your level of preparation.

And what you do next will define you as a CISSP.