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

39. Malware Threats

39.6 Defence Stack – Practical Controls

By Last updated:

Quick answer: the short, self-contained version of this lesson is the guide EDR vs Antivirus: What’s the Difference.

Layered bachav (ek tool nahi):

Layer What Why
Email filtering + attachment sandbox Stop initial phish macros/links Most SME malware still starts in inbox
Patch OS + browsers + Office Close worm/drive-by holes WannaCry-class lessons
AV / EDR Signature + behaviour Fileless needs behaviour
Application allowlisting Only approved binaries Cracked tools / random EXE fail
Least privilege Users not local admin Ransomware blast radius shrinks
Macro / script control Block internet macros; log PowerShell Emotet-class paths
Backup + restore drills Offline / immutable Last line after encrypt
User awareness Report phish fast Humans = sensor

Linux lab tip (Amazon Linux style awareness host):

# Example: install ClamAV on a lab Amazon Linux / CentOS-class box YOU own
sudo yum install -y clamav clamd
sudo freshclam
sudo service clamd start
clamscan -r /home

Ubuntu/Kali notes: sudo apt install clamav OK on those distros; still isolate.

Red team (attacker) does Blue team (defender) detects / stops
Disables Defender / adds exclusion after admin theft Tamper protection; alert on exclusion changes; dual EDR where budget
Lives off land (powershell, wmic, bitsadmin) ASR rules / attack surface reduction; script logging; allowlisting
Encrypts with user rights across wide ACL shares Least privilege on file ACLs; separate admin; network share monitoring

Ravindra Bagale's Tip

"Turn off the free AV to boost games" – students do this, and sometimes so do shop-floor PCs. Use tamper protection + a central EDR policy. Interview: list 5 controls without saying only "install antivirus." Allowlisting + least privilege + backups = a senior answer.

Lab

Lab Win10 VM: Windows Security → confirm Real-time protection ON, Tamper protection ON, Controlled folder access experiment on C:\lab_docs. Linux lab VM: clamscan on a folder with EICAR. Document before/after. Shared folder to host Disable during malware labs.

Real incident: Osaka Metropolitan University – ransomware inside the virtualization platform stops about 500 servers (Oct 2026)

1. What happened

In the early hours of Friday 2 October 2026, Osaka Metropolitan University (OMU) in Japan, one of the country's largest universities, had a huge IT outage. At a press conference on Monday 5 October, the university said it believes the cause was a ransomware attack. Japanese media, quoting university officials, reported that the attackers got into the virtualization platform (the base system that runs many virtual servers on shared hardware) used by the university's information systems, and that about 500 servers stopped working. Broadcaster MBS also reported that much of the backup data was encrypted too, so it could not be used for a quick restore. The outage took down the internal network, email, academic and teaching systems, finance, payroll, HR, library services and the websites, and classes were cancelled until 8 October, with in-person classes planned again from 9 October. Data of at least 130,000 current and former students, staff and others (names, addresses, email addresses) may have been exposed, but the university has not confirmed that data was stolen. Systems for entrance-exam applications and enrolment kept working because they run on outside servers, and the university hospital said its electronic medical records were not affected. The attackers have not been named, and the university has not said whether a ransom was demanded. Educational framing only.

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

  1. The attackers got into the university's network (how they first got in is not public yet).
  2. They reached the virtualization platform – the layer under the servers. One platform runs hundreds of virtual servers, so whoever controls it controls all of them.
  3. From that one place they could hit about 500 servers at the same time, instead of attacking them one by one.
  4. Many backups were also encrypted, which suggests the backups could be reached from the same environment.
  5. Email, the network, teaching, payroll and other systems stopped together, and classes were cancelled.
  6. The systems hosted outside that environment (exam applications, enrolment) kept running – a live example of why separation limits damage.

3. How to stop it / defend (this lesson: layered defence)

  • Protect the virtualization platform like the crown jewels: put its management on a separate admin network, require MFA, use separate admin accounts (not normal staff logins), and patch it quickly.
  • Backups the attacker cannot touch: keep at least one copy offline or immutable (cannot be changed or deleted for a set time), protected by different credentials from the main systems – the "Backup + restore drills" row in the table above.
  • Segmentation: split important systems (payroll, email, student data) into separate zones, so one break-in does not stop everything.
  • Least privilege for admins: few people with full rights, and every admin action logged.
  • EDR and alerts: watch for mass encryption, backup deletion and strange admin logins at night, and alert the SOC at once (Chapter 31).

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

  • [ ] Make a list of your "one place controls many" systems: virtualization platform, backup server, domain admin, cloud admin console.
  • [ ] Check that each of them has MFA, a separate admin network and separate admin accounts.
  • [ ] Keep one backup copy offline or immutable, and write down the date of the last successful restore test.
  • [ ] Practise a full restore of one important system at least every quarter.
  • [ ] Keep a paper or offline plan for how teaching, payroll and communication continue if every server stops.
  • [ ] India students: colleges and universities here run the same kind of virtual servers – after a ransomware attack, report to CERT-In within the required time (see Ch.34), and never pay or negotiate alone.

Source: The Record from Recorded Future News, "Osaka Metropolitan University cancels classes after suspected ransomware attack", October 2026; Jiji Press / The Japan Times, "Data on 130,000 students and teachers possibly exposed, Osaka university says", 6 October 2026; Sankei Shimbun, 5 October 2026; MBS press-conference report as summarised by Security Measures Lab (rocket-boys.co.jp), 5 October 2026.

Check if you're safe: Website Security Checklist