top of page
  • Writer's pictureORNA

Mistakes, Delays, and Negligence Costs Effective Incident Response

Updated: Jul 7, 2022

I always say that technology is like a house of cards. Anyone who works within the IT industry in some capacity, from programmers writing and debugging lines of code to digital forensics experts and incident responders, knows that avoiding mistakes is imperative, especially when it comes to business-critical assets.

For those who operate in administrative or security capacities, let me remind you how essential your role is when faced with a threat actor who is determined to find a way inside your network.

After all, this is exactly the goal - to find an overlooked mistake: a misconfiguration, a missing patch, a software backdoor mistakenly left within the code. And if hackers fail to discover a vulnerability, the persistent threat actor will resort to social engineering tactics to accomplish their goal.

It shouldn't come as a surprise that my success as a former Black Hat hacker was almost exclusively based on the mistakes made by others.

Every advance I made against a target was another instance where someone made a mistake. Even seemingly innocuous errors can lead to a major compromise. Therefore, a level of prudent paranoia is merited in order to avoid such errors that cause downtime, data loss, and the loss of customer trust.

A Ransomware Incident, a Single Door Left Open

Recently, cybersecurity researchers at Forescout investigated a security incident involving the BlackCat ransomware, also known as ALPHV. The malware found its way into a network simply due to a common security vulnerability that had been left unpatched. For three years…

It’s rather curious that a security patch had been available since 2019. However, so often oversight is the cause of avoidable security incidents. This means that the vulnerability caused the network to face the public domain, and it was only a matter of time before someone discovered it and attempted to exploit it for malicious use.

The security incident was an SQL injection vulnerability that existed in an unpatched and outdated SonicWall SRA appliance. After the injection was launched, the attackers then gained access to the usernames and passwords table. The credentials were then used to gain access to ESXi servers, where the ransomware payload was launched.

As a hacker, old vulnerabilities that most people would assume have been fixed are almost always the reason why the systems that have them are compromised. Once they’re discovered, the rest is easy pickings.

But then again, there are internet-facing computer systems still running antedated operating systems like Windows XP. If they can be found, they offer hackers easy access, since technical support for the operating system was discontinued on April 8, 2014.

Don’t Delay With Timely Incident Responses

Years ago, I used to use a little piece of malware written by the W|tchD0ct0r called the .dll Bomber, if my memory serves me correctly. I used a variety of remote access trojans to maintain my connection to a remote host, as a contingency in case I was detected and booted from the system.

One of the first objectives post intrusion was to determine who was logged into the system or network. This could allude to whether or not my connection would be detected quickly by a vigilant systems administrator.

Next, I would check which antivirus program was installed (if any) and install a backdoor undetectable to that antivirus, if I didn’t downright disable it altogether. If I lost my connection, I always had a way back in. Then, I took control of the event logs and modified them.

If my connection was detected, most of the time a competent system administrator terminated my connection and then immediately launched an incident response to determine how I broke in. Sometimes they actually found the vulnerability, which for me, was usually a misconfigured or poorly protected network protocol. However, by modifying the event logs, I made that endeavor a little more difficult.

Other times the system administrator chose to watch and see what I’d do. But in a panic, having realized that my connection had been realized, and not having time to modify or wipe my logs, I quickly uploaded the.dll Bomber, in an effort to corrupt the file system, which replicated itself until the hard drive capacity was reached. That was my fail-safe in order to obfuscate any traces of evidence from my connection, as best I could.

The longer it takes to eliminate a threatening connection, the more damage they will be able to cause. Once the connection is severed, an incident response triage can begin to assess the damage caused to the system.

Solving delays in an incident response is simple. Regularly rehearsing responses helps strengthen readiness and shortens the time it might take to prepare to launch into respective roles.

Remember this, most skilled threat actors have an offensive response of their own in the event that they have mere seconds before losing connectivity. So be tactically ready and don’t delay or make mistakes in the deployment of your response plan.

An article by

Jesse McGraw

Edited by

Ana Alexandre




Rome wasn't built in a day, but your SOC might be.


Weekly cyber insights

Thanks for submitting!

bottom of page