Ravindra BagaleCourses & study guides मराठी Track your progress

31. SOC, SIEM and Incident Response

31.6 The Incident Response Lifecycle

By Last updated:

Quick answer: the short, self-contained version of this lesson is the guide Incident Response Plan for Beginners (First 24 Hours).

The widely used NIST incident response lifecycle (NIST SP 800-61) has four phases:

  1. Preparation – plans, contacts, tools, logging, backups and training before anything happens.
  2. Detection and Analysis – spot the incident (SIEM alert, user report, GuardDuty), confirm it and understand its scope.
  3. Containment, Eradication and Recovery – stop the spread, remove the attacker, restore systems safely.
  4. Post-Incident Activity – lessons learned, fix root causes, improve detection.

Many trainings also use the six-step PICERL model: Preparation, Identification, Containment, Eradication, Recovery, Lessons learned. Same idea, more steps.

Worked example (fictional): "Shivneri Traders" web server compromise

Phase What the team did
Detection Wazuh alert: many failed SSH logins, then Accepted password for user deploy from an unknown IP at 02:10. Then a new user support2 was created.
Analysis L2 checked /var/log/secure, last, /etc/passwd, crontab and running processes; found a crypto-miner in /tmp and a cron job restarting it.
Containment Security group changed to allow only the office IP; attacker IP blocked; EBS snapshot taken before changes to preserve evidence (Chapter 28).
Eradication Removed support2, the cron job and the miner; changed all passwords; disabled SSH password login, keys only (Chapter 32).
Recovery Rebuilt the server from a clean AMI, restored the site from backup, monitored closely for two weeks.
Lessons learned Root cause was a weak password on deploy with SSH open to the world. Actions: key-only SSH, fail2ban, MFA on the AWS console, a Wazuh rule for "new user created".

In India, certain cyber security incidents must be reported to CERT-In within a short time limit under its 2022 directions (details in Chapter 34), so the IR plan must include who reports and how.

Ravindra Bagale's Tip

After a hack, students immediately delete or reboot the server – and then the evidence is gone! First isolate it and take a snapshot/image, then clean it. And if you just rebuild without knowing "how they got in" (the root cause), the attacker will come back the same way.

Lab

Write a one-page incident report for the Shivneri Traders example using the headings: Summary, Timeline, Impact, Root cause, Actions taken, Lessons learned. Then simulate the start of it in your lab: create a user support2 on the agent VM and confirm Wazuh raises an alert for the new user.

SOC quick reference

Need Where / what
Linux SSH/sudo logs /var/log/secure (RHEL/Amazon Linux), /var/log/auth.log (Ubuntu/Kali)
Web logs /var/log/httpd/, /var/log/nginx/
Windows logons Event IDs 4624 success, 4625 failure, 4720 user created
AWS CloudTrail, GuardDuty, VPC Flow Logs
Free lab SIEM Wazuh (manager + agents)
IR phases (NIST) Preparation, Detection and Analysis, Containment/Eradication/Recovery, Post-incident
IR phases (NIST)

Real incident: City of Vicksburg ransomware – systems offline, 911 still up (Oct 2026)

1. What happened On 1 October 2026, the City of Vicksburg, Mississippi detected a ransomware cyberattack and temporarily shut down city computer systems, Mayor Willis Thompson said in public statements covered by local and security press (2–3 October 2026). 911, police, fire, and utility services remained operational. In-person utility payments could be delayed; officials said there would be no penalties or service terminations while systems were unavailable. The city worked with external cybersecurity specialists and partners (reporting also mentioned coordination with law enforcement / state partners) to investigate and restore systems securely. Officials were still determining whether personal or confidential information of customers, contractors, vendors, employees, or business partners was accessed. The city had not publicly named a ransomware group or confirmed initial access method or data theft at the time of those reports. Treat all details as reported — do not invent ransom amounts or victim counts. Educational framing only.

2. How the hack happened (public reporting only – high-level) 1. Attackers struck municipal IT systems with ransomware (exact entry path not confirmed publicly — do not invent phishing, VPN, or CVE details). 2. City leaders chose containment: take affected computer systems offline to stop spread and protect remaining operations. 3. Critical public-safety functions (911 / police / fire) and utilities were kept available — a deliberate IR design, not "everything down". 4. Parallel track: restore securely with outside specialists while investigating possible data access for breach-notification duties. 5. Communications to residents covered payment delays and that essential services continued — IR includes public messaging, not only technical fixes.

3. How to stop it / defend (this chapter: incident response) - Preparation: IR plan that lists which systems are safety-critical vs deferrable (911 vs counter payment PCs). - Detection → fast containment: isolate infected segments / take systems offline before ransomware walks sideways. - Preserve evidence (images/logs) before wipe/rebuild; engage IR partners / law enforcement when municipal or citizen data may be involved. - Immutable / offline backups of city finance and citizen portals; test restores on a schedule. - MFA + least privilege on remote admin; segment OT/utility and public-safety networks from general office malware paths.

4. How to take care so it won't happen again (checklist) - [ ] Written IR runbook: who decides "systems offline" vs "keep 911 up". - [ ] Asset + dependency map for citizen-facing apps vs emergency services. - [ ] Offline/immutable backups + last successful restore date. - [ ] Tabletop once a year: ransomware on city hall IT — contain, message public, investigate data exposure, recover. - [ ] CERT-In / local cybercrime reporting contacts in the plan (India students: map the same habit to your org + CERT-In timelines in Ch.34). - [ ] After recovery: credential/session reset, re-scan, lessons-learned ticket that changes detection rules.

Source: The Record (Recorded Future News), Jonathan Greig, 2 October 2026 (Mayor Willis Thompson statements; city working with FBI, DHS, state officials, and private cybersecurity experts; 911/emergency services not impacted; utility payments affected; investigation into possible personal/confidential data access ongoing; no public ransomware group or ransom amount disclosed).

Check if you're safe: Website Security Checklist

Real incident: Spandana Sphoorty Financial (India) – ₹7.8 crore left a company bank account in a cyber fraud (Nov 2026)

1. What happened

In this lesson you learnt the incident response lifecycle: notice fast, contain the damage, investigate, recover, and learn. This Indian case shows why every minute counts when money is leaving a bank account.

  • Spandana Sphoorty Financial, a listed Indian microfinance lender, said on Monday 2 November 2026 that it found a cyber fraud on 1 November 2026.
  • About ₹7.8 crore (about $822,300) was moved from one of its bank accounts to 82 beneficiary accounts.
  • The company said it stopped the affected services at once, asked its bank (name not disclosed) to reverse the transfers and freeze the beneficiary accounts, and filed a complaint on the National Cyber Crime Reporting Portal.
  • It also said it would pursue recovery and an insurance claim. Reuters and Economic Times BFSI covered the disclosure the same day.
  • Public reporting so far describes unauthorized bank transfers. Exact how-the-attacker-got-in details (malware, stolen login, fake payment instruction, etc.) were not published in those first reports.

2. How the hack happened (public reporting only – high-level)

  1. On 1 November 2026, money left a company bank account in many transfers to outside beneficiary accounts.
  2. Staff or controls noticed the unauthorized activity.
  3. The company treated it as a cyber fraud incident, stopped the hit services, and asked the bank to reverse and freeze.
  4. It reported the case on the national cybercrime portal so police and banks can work the trail.
  5. A full forensic picture of the entry path was still developing in the first public reports.

3. How to stop it / defend (this lesson: incident response)

Why: when money is leaving, speed beats a perfect report. Contain first, then dig.

Controls you can use:

  1. Dual control for payments. One person prepares a transfer; another person, on a separate login, must approve it. Big or new beneficiaries need a phone call on a known number.
  2. Alerts on unusual payment volume. Many transfers in a short time, or many new beneficiaries, should wake a human at once.
  3. Keep a kill switch. Know who can freeze the bank channel and stop the payment service in minutes (Example 1–2).
  4. Preserve evidence. Export bank statements, payment logs, and login history before you wipe anything (Example 3).
  5. Report fast. Bank reverse request, freeze request, cybercrime portal, and (for listed firms) exchange rules.
  6. Assume the payment path is dirty until proven clean: rotate the banking login, MFA device, and any API keys used for payouts.

Example 1: write down the exact time you first noticed (UTC and IST).

  1. On the response laptop, run date -u
  2. Output: like Sun Nov 1 14:22:01 UTC 2026.
  3. What it means: every later log line is compared to this "noticed at" time. Convert to IST for the Indian team notes.

Example 2: pull the last payment lines from your own app log (your system only).

  1. On the payments host you own, run grep -i "transfer\|beneficiary\|NEFT\|IMPS\|RTGS" /var/log/app/payments.log | tail -n 20
  2. Output: lines like ... NEFT to ACCOUNT-xx SUCCESS 950000.
  3. What it means: you now have a short list of recent transfers to hand to the bank and to IR.

Example 3: see who logged in recently on the ops box.

  1. On the Linux jump host used for banking ops, run last -ai | head
  2. Output: like opsuser pts/2 203.0.113.88 Mon Nov 1 13:58.
  3. What it means: an odd IP or odd time next to a payment window is a lead. Do not delete these logs.

4. How to take care so it won't happen again (checklist)

  • [ ] Every payment needs two people, and new beneficiaries need an out-of-band check.
  • [ ] Unusual payment volume wakes a real person within minutes.
  • [ ] I know who can freeze the bank channel and stop the payment service.
  • [ ] Bank statements, payment logs and login history are saved before any wipe.
  • [ ] Banking passwords, MFA and payout API keys are rotated after a fraud.
  • [ ] The cybercrime portal / bank complaint numbers are written in the IR runbook.

Source: The Hindu Business Line / Reuters, "Spandana Sphoorty Financial reports cyberattack involving its bank account", 2 November 2026; Economic Times BFSI, "Spandana Sphoorty reports Rs 7.8 crore cyber fraud, transactions routed to 82 beneficiary accounts", 2 November 2026.

Ravindra Bagale's Tip

When money is leaving, do not wait for a perfect forensic report. Freeze the channel, stop the service, save the logs, then dig. Spandana moved in that order on day one.

Check if you're safe: Password Strength Checker

Real incident: Yatra Online (India) – listed travel company told exchanges and CERT-In about a cyber-security incident (Nov 2026)

1. What happened

In this lesson you learnt that a good response includes telling the right people early, even while you are still measuring the damage. This Indian listing shows that pattern.

  • On 2 November 2026, Yatra Online Limited, an Indian online travel company listed on NSE and BSE, filed a SEBI Regulation 30 intimation of a cyber-security incident.
  • The company said the event did not have any material impact on core business operations, financial performance or business continuity.
  • It said a detailed assessment was underway, and that remedial and preventive measures were being implemented.
  • It confirmed it had notified CERT-In, India’s national cyber incident agency.
  • The NSE exchange filing gives no attack method, no malware name, and no count of records. So this box teaches the disclosure and IR steps you can see in public, not a guessed technical story.

2. How the hack happened (public reporting only – high-level)

  1. The company experienced a cyber-security incident (details not in the first filing).
  2. Management assessed that core ops and finances were not materially hit.
  3. It started a deeper assessment and started fixes and prevention steps.
  4. It notified CERT-In and informed NSE and BSE under Regulation 30.
  5. Further public detail, if any, would come in later updates once the assessment finishes.

3. How to stop it / defend (this lesson: incident response)

Why: early, honest notice to CERT-In, customers and (when required) exchanges buys you trust and help, even when the full story is not ready.

Controls you can use:

  1. Have a one-page IR card. Who calls CERT-In, who calls the bank, who drafts the exchange note, who freezes logins.
  2. Preserve logs before you rebuild. Web, auth, app and cloud audit logs for the last 48 hours at least (Examples 1–2).
  3. Write times in IST and UTC. Indian filings and CERT-In tickets need clear clocks (Example 3).
  4. Say what you know and what you do not. Yatra’s filing said “assessment underway” and “no material impact” – that is better than silence or a guess.
  5. Rotate likely secrets while you investigate: admin passwords, API keys, session stores, and vendor access.
  6. Plan the next update. When the assessment ends, publish what was accessed, what was not, and what customers should do.

Example 1: confirm recent web logs still exist on a server you own.

  1. On your web host, run ls -lt /var/log/nginx/ | head
  2. Output: like -rw-r----- 1 nginx nginx access.log-20261102.gz.
  3. What it means: yesterday’s access log is still on disk. Copy it to the IR evidence folder before any cleanup.

Example 2: list logs touched in the last two days.

  1. Run sudo find /var/log -name '*.log' -mtime -2 -printf '%TY-%Tm-%Td %p\n' | sort
  2. Output: lines like 2026-11-02 /var/log/auth.log.
  3. What it means: you have a short inventory of evidence files to bag for CERT-In / forensics.

Example 3: record the local timezone used on the box.

  1. Run timedatectl | grep -E 'Time zone|Local time'
  2. Output: like Local time: Mon 2026-11-02 22:03:58 IST.
  3. What it means: every timestamp in your notes can be labelled IST correctly for Indian regulators.

4. How to take care so it won't happen again (checklist)

  • [ ] IR card names who calls CERT-In, legal, exchange filings and customers.
  • [ ] Logs are copied out before rebuilds or wipes.
  • [ ] Notes use clear IST/UTC times.
  • [ ] First public words say what is known, what is not, and what is being done.
  • [ ] Admin secrets and vendor access are rotated during the assessment.
  • [ ] A follow-up update is planned when the assessment finishes.

Source: Yatra Online Limited, NSE/BSE Regulation 30 filing "Intimation of Cyber Security Incident" (Jyoti Chawla), 2 November 2026; Business Upturn / exchange-based reports summarizing the same filing, 2 November 2026.

Ravindra Bagale's Tip

When the full story is not ready, still tell CERT-In and (if you are listed) the exchanges what you know and what you are doing. Silence is worse than "assessment underway".

Check if you're safe: Password Strength Checker