Blue Core Research
Contact Us
Story of a Cyberattack
How can a day with the potential to be the worst in your career turn out positive or even pretty good? This fictional story describes realistic events from a day of a breach when things happened right. See what it takes to make it happen.

The Attack Begins

The blip of a new email flashed on Cora’s screen. It was yet another alert from Core Audit, and it wasn’t the first one of the day. But a quick glance at the SQLs and adrenaline jolted her awake. It felt like caffeine was pumping directly into her brain. That is not a false positive. It’s an attack. Someone is successfully running an SQL injection attack through the application and into the database.

Cora Blue is a DBA in the security team and understood exactly what was happening. That is the first stage of the attack. The intruder is trying to determine if the application is vulnerable and gather information about the type of database and the tables inside it. So far, it’s probably just a script collecting information, but depending on how good this attacker is, it will soon graduate to a full-blown data breach. It could take days, sometimes hours, but in the worst case, it can be a few minutes before they start to exfiltrate data. There’s no time to waste.

Taking Action

Cora knows what she needs to do. Even though taking the application offline will probably be enough in this case, the policy demands shutting down both the application and the database. As a senior member of the security team, she has the permissions required to do that. Better safe than sorry, and a few minutes later, everything is down and offline. While the systems were going offline, she sent a message to the notification group. That will get to the response team and everyone else that needs to know.

By the time the response team assembled, Cora got a chance to glance through the Core Audit forensic information. It looks like the hackers were still in the discovery phase, and nothing was taken. She found the App Server the attack came from and the time. From the SQLs, she could even guess the compromised area of the application – the first part of the SQL is the original code with the table and columns of the original query.

Now that the team is all on Zoom there are two immediate objectives. Getting the application and database back online safely is important as the helpdesk is probably already getting calls. It’s a good thing they were part of the notification chain. But more pressing is how they got into the network, whether they are still inside, and what else needs to be done immediately to stop this attack in its tracks.

The small response team includes Cora Blue, who identified the event and is also the database expert of the team. Brandon Reese, the know-it-all sysadmin. Randall Shield who controls the network. And Audrey Cortez, who represents upper management.

What Happened?

Cora quickly explains what happened: a SQL injection attack hit the database through app server CBR002 starting at 14:35, but the app server and database were shut down before anything was taken. Audrey commends her for her diligence and quick response. That’s not the first time the team gets together and everyone knows Audrey can talk for a while. But they also know she doesn’t mind being interrupted, especially when time is precious. And before Audrey can continue, Brandon politely interrupts sharing his screen showing a grep of the Apache logs.

The logs clearly show the rapid fire of the HTTP requests that caused the SQL injection and the IP that sent them. It looks like the attack came from the VPN IP range. As Brandon continued to Core Audit to look at the application auditing forensic screens, Randall, the network admin, found the DHCP IP assignment showing the attack came from the home computer of Holly Ackerman, the administrative assistant for one of the VPs.

A few seconds later, Brandon also found the attack in the Core Audit forensics confirming it was Holly’s login in the application. While no one in the team knows Holly well, she doesn’t seem very computer savvy and probably never heard the term SQL Injection. Someone must have taken over her home computer and used it to launch the attack.

Neutralizing the Threat

Either way, the team disables Holly’s account logging her out of the VPN. The helpdesk team will call her to explain, the security team will later start to investigate her computer, and the Windows team will eventually help her reinstall it. Brandon sends a short email update to the breach notification group which will kick that into motion.

The team believes that at this point the attack is mostly contained. They need to see if Holly’s user was used anywhere else, get the database online, find the problem in the application, and figure out how to get it online safely. Also need to investigate Holly’s PC to figure out how someone got in, though she probably just clicked on the wrong email.

The day is not over, but it looks like they prevented the worst.

How did they Succeed?

Let’s review some of the key points that made this story a success for the security team.

First of all, despite a perimeter breach that was probably unavoidable, they had a database IDS solution that recognized the anomalous data access and sent an alert. Core Audit was pivotal in triggering the response. Without that alert, this story would have been very different. It would be months before they found out about the attack, and probably only as a result of a notification from law enforcement. The response team would then be analyzing a months-long data breach, trying to determine how many systems were compromised and who they should notify that their data was stolen.

Secondly, Cora Blue, a knowledgeable and trained cybersecurity DBA got the alert. She knew what to look for and recognized the attack. She also had forensic information about the database activity to support immediate action. Without Core Audit, there is no forensic information about every SQL and no way to determine what transpired in the database.

There were also simple policies telling Cora how to respond, and she had the permissions needed to take action and stop the attack in its tracks.

The team assembled quickly, was small enough to operate efficiently, and had knowledgeable people with access to all the systems. The team met many times before and had a good working relationship. It was also not the first time they attempted to respond to an attack as everyone knew exactly what to do.

Everything can work out well when you get alerts, have supporting forensic information, and have talented, trained people, that know what to do.