🔥 Fired, he deleted 180 VMs out of revenge! 🚨💻

It's rare, but it happens all the time. How can you protect your company's IT assets?

I was reading this article from CISOAdvisor¹, "Fired, he deleted 180 QA virtual machines," about the guy from India who, after being fired, simply logged into the server and wiped out all the company’s virtual machines.

The worst part? It wasn’t an impulsive attack—he had already planted a backdoor before leaving. The damage was massive, causing operational delays and significant financial losses ($678K), as the company had to rebuild the entire testing environment. Now, the former employee is facing criminal charges and could get a tough sentence, while the company scrambles to strengthen its security controls to prevent another "ex" from getting the same idea.

This wasn’t the first case, and it won’t be the last. About five years ago, something similar happened at Cisco². In 2018, a former employee who had resigned from the company decided to leave his mark before walking away. Five months after his departure, he gained unauthorized access to Cisco’s systems and deleted 456 virtual machines used for Webex, the company’s video conferencing platform.

This wasn’t just an act of sabotage—it disrupted services for over 16,000 users and forced Cisco into a race against time to restore data and minimize damage. He accessed the systems using still-active credentials and executed destructive commands through scripts. The attack resulted in millions of dollars in losses for Cisco, both in infrastructure recovery and reputational damage. Eventually, he was convicted in the U.S., fined, and sentenced to prison.

Incidents like this highlight the critical need for strict access control measures, especially during employee offboarding, to ensure that critical systems aren’t left vulnerable to acts of revenge.

I remembered a case—not exactly the same, but the closest I’ve personally experienced. Many years ago, I was working as a contractor for a software house, developing Java systems for a government client in a Linux environment.

At the time, cryptocurrencies were just starting to take off, and a lot of people were rushing to make money with crypto mining.

Some systems were experiencing extreme slowdowns. I analyzed the architecture—it was built with Java, Hibernate, and Oracle—but unfortunately, I didn’t have direct access to the server, only to the code, so I could look for potential bottlenecks. After hours of analysis, running profiling on a test server, tweaking cache settings, and making performance adjustments, I hit a dead end. Nothing justified the slowdown, so I had to request access to the production server and conduct an analysis alongside the client’s employee.

First interesting discovery: when I accessed the VM via SSH, the CPU usage suddenly dropped, and the system ran normally. But as soon as I logged out, the CPU spiked again, causing severe slowdowns in the application.

Investigating as root, I was in for a surprise—I found a Monero mining script running on the server. The script was cleverly designed to pause whenever someone logged into the system and resume mining as soon as no one else was logged in, except for the script’s own user.

At first, I thought it was just an external breach—after all, there were plenty of vulnerabilities in applications back then that allowed remote execution of scripts. For example, Apache Solr and Elasticsearch had exploits around 2012/2018 where anyone could run a wget command via a simple search query.

But that wasn’t the case. After digging through the logs, I found out that it was an internal job—a client’s own employee had installed the mining script. Even worse, he was an infrastructure analyst, so he had the access but not much programming knowledge. He had simply copied the script from some forum and followed the instructions.

He probably didn’t even make $100, but it cost him his job. Unfortunately, I can’t name the companies involved since his dismissal was published in the government’s official records, and it wouldn’t be too hard to connect the dots.

Obviously, I wasn’t involved in his dismissal or the confrontation—I was just a third-party consultant. But later, I heard that the guy had no idea he was doing something wrong or that it could harm anyone.

Apparently, he was also mining crypto on his own machine and even on university computers.

GOD.

Just like a mining script can cripple system performance, other scripts can cause even more damage—removing software, copying data elsewhere, granting third-party access, and more.

Now, imagine something like this exporting customer data—this isn’t just a security failure; it’s a data breach.

One of the most overlooked aspects in cases like this is the impact on privacy and data protection. When a former employee still has access to critical systems, it’s not just the infrastructure at risk—it’s also personal data. Deletion or leakage of sensitive information can result in compliance violations under almost every modern privacy regulation, leading to fines and reputational damage. And let’s not forget: insider threats are harder to detect and mitigate because they often come from someone who already knows the system’s architecture and weak points.

These cases highlight the fact that internal threats remain one of the biggest security risks for any organization. Whether it’s revenge or simply exploiting overlooked gaps, ex-employees can cause massive damage if access controls and monitoring aren’t properly enforced. Human error and lack of processes, like failing to revoke credentials or perform continuous audits, make these situations possible.

1. https://www.cisoadvisor.com.br/demitido-ele-deletou-180-maquinas-virtuais-de-qa/

2. https://threatpost.com/cisco-employee-convicted-deleting-webex-accounts/162246/