Attackers Can Use Your Admin Tools to Spy, Spread, and Steal

January 26, 2018
Vectra AI Security Research team
Attackers Can Use Your Admin Tools to Spy, Spread, and Steal

In my last blog, I spoke about a financial customer performing pen testing and how I helped the blue team detect the red team as it carried-out an attack. I’m back again today with another story from the trenches.

This time, I’ve been working with a customer in the manufacturing sector who recently deployed me. As before, this customer prefers to remain anonymous to keep cybercriminals in the dark about their newly developed security capabilities. To stay on top of their game, they routinely run red team exercises.

One of hardest parts about finding hidden attackers inside your network is when their behaviors blend in with regular user behaviors. If I’m an attacker, the first thing I’d look for are your network admin tools because they are trusted by default.

Understanding the difference between attacker behavior and acceptable user behavior becomes an exercise in spotting the nuances between the two and providing greater context about what else is associated and how threat behaviors progress through the attack lifecycle.

It is even harder to find attacker behaviors when they have access to security tools that are already running on your network. For example, a software distribution tool like Microsoft SCCM is totally legitimate in an enterprise. But it creates noise that looks like the remote execution of files, which is exactly what an attacker would do.

Security tools must create filters to remove the noise. However, it is probably an attack if the machine starts performing command-and-control actions that are not trusted. Most tools end up missing this attacker behavior because they already filtered the tool out as noise. Attackers know how these security tools work.

In the recent pen testing exercise with our manufacturing customer, the red team covertly acquired access to a Nessus scanner that was ordinarily used by the blue team to look for exposed assets.

The blue team taught me about the Nessus scanner early on so I could learn how it is used and by whom. The security team likes to know when scans occur and does not want me to interpret Nessus scans as attacks because they represent an approved behavior.

That would just make more work for my fellow security analysts. And it’s my job to filter out the noise so they can focus on deeper incident investigation, remediating problems, and learning how to ensure that the network can adapt.

As the pen test progressed, I noticed several reconnaissance and lateral movement behaviors emanating from the Nessus scanner and they occurred in a sequence I had not seen before.

I immediately concluded that an unauthorized person had commandeered the Nessus scanner.

The first attacker behaviors I detected were classic IP port sweeps and port scans. I then noticed a large set of internal darknet scans against IP ranges that the security team wouldn’t normally scan.

To save time, I correlated the attack behaviors and contextual information so the blue team could see that the red team was trying to locate hosts in subnet ranges that had not previously existed on the network.

I continued to monitor the network scanning activity. Although the recon behaviors were suspicious, I gave it a medium threat score because I didn’t see associated behaviors later in the attack lifecycle that would indicate an attacker had moved deeper into the network.

After scanning for some time, I noticed that the red team discovered a set of servers running vulnerable databases and another with weak admin passwords. I quickly saw the red team pivot to the lateral movement phase of the attack lifecycle, which included SQL injection, automated replication, and a brute-force attack against admin passwords.

In real time, I correlated all these attacker behaviors to the host used by the red team and the servers in the data center that they compromised. As I watched the attacks make their way through the attack lifecycle, I reassigned them with a critical threat score and a high-certainty level.

My blue team colleagues—people just like you—took swift action to isolate the red team and stopped them in their tracks before they could progress to more damaging attack phases like data exfiltration.