<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=116645602292181&amp;ev=PageView&amp;noscript=1">
Back to Blog

Lessons Learned from the Hacking Team Getting Hacked

We've discussed the Hacking Team in previous posts to emphasize how companies can study this complete model of a targeted campaign and improve their security. One of the more interesting questions that emerged after the Hacking Team breach was how did more than 400GBs of data on the organization manage to get shared publicly? Pretty much everything about the company was put on display including Exchange server data, source code, RAT installers, emails, sensitive documents and screenshots from employee machines. So much business-critical data was leaked other hackers could have used it to replicate the company.

As a cyber defender, this attack raises the question how do you get better at defense? One method is to start responding to potentially bad stuff, learn from your failures and slowly improve your defense for the next round of badness. A parallel option is to identify activities from documented past attacks or shared experiences and break down a large, complex attack into smaller digestible components. What activities were performed? What tools were used? Were they custom or off the shelf? How would I go about looking for this and comparing it to normal in my environment?

In the past these documented references were difficult to obtain and if you're serious about cyber defense then open source intelligence would be a core part of your research. Surprisingly, lately there’s been a lack of awareness around some very high profile activities that have produced some very relevant real-life targeted and persistent attack models.

The question of who published the Hacking Team data was recently answered when the person who hacked the organization took responsibility for the attack and released a step-by-step guide on the operation.

So what can we learn from the Hacking Team attack?

A human attacked the Hacking Team This means the attack was dynamic with a person deciding when to switch strategies to ensure that the attack was successful. It’s also worth noting that a person understands the work ethic and time that are required to pull off the attack.  

In this case, the attacker used 100 percent, fresh infrastructure mapped to new IPs and domains, and new tooling.

“So I used new servers and domains registered with new post and paid with new bitcoin address. In addition, I only used public tools and things that I wrote especially for this attack and changed my way to do some things to keep my normal forensic trace,” the attacker wrote in a post explaining the hack.

He also spent a considerable amount of time on recon, saying that the process was “tedious but a very important stage,” adding that the larger the attack surface, the easier it is to find a fault to exploit.

Ignore commodity malware at your peril Organizations may want to rethink the common practice of ignoring commodity malware. Those programs may be considered low-level security threats, but they offer a foothold into an enterprise and could serve as a starting point for a targeted attack. Even if the attackers who infiltrated a company aren't interested in this access, they could sell it to other hackers who would carry out the attack.

The Hacking Team attacker could have purchased access into almost any organization but didn’t take this path, writing that "thanks to painstaking Russians and their exploit kits, smugglers trafficking, and bot herders, many companies already have compromised computers within their networks.”

He also said that almost all Fortune 500 companies already have bots inside of them. However, since the Hacking Team is a small organization that employs security experts, they probably weren’t infected with bots. He decided against using spear phishing to infiltrate the Hacking Team since they help governments use this technique, meaning there’s a strong possibility  would recognize any exploit that relied on this tactic.  

Targeted attacks that don’t use malware are trending In all targeted attacks, adversaries eventually shift from using some malicious software package that violates an operating system to a set of off-the-shelf tools. Either these tools are thrown over the wall by the attacker or the attacker "lives off the land." We're now seeing more evidence of attackers not using any malicious software packages. They’re "living off the land" 100 percent.

"I wrote a backdoor firmware, and compiled several tools post-exploitation for embedded system,” said the attacker. “The backdoor serves to protect the exploit. Use the exploit only once and then return by the backdoor ago work harder to find and patch vulnerabilities."

Adversaries are also using PowerShell to carry out attacks, and the person behind the Hacking Team breach provided a primer on how to use this Windows tool for malicious activities.

"Powershell itself is also very powerful [7]. As there are still many 2003 and 2000 servers without powershell, you must also learn the old school [8], with tools like netview.exe [9] or the command windows "Net view". Other techniques that I like are:

1) Download a list of file names

With a domain administrator account, you can download all file names on the network with powerview: Invoke-ShareFinderThreaded -ExcludedShares IPC $, PRINT $, ADMIN $ | select-string '^ (. *) \ t' | % {$ _ Matches -recurse dir [0] .Groups [1]. | select fullname | files.txt -append out-file}

Did you learn something? Now what? Go on the offensive and start looking for non-signature / non-IOC activity in your environment. The point of proactive hunting is to not only understand what good looks like in your environment. It’s also to uncover bad activities that weren't discovered by your SIEM or other detection technologies.

Here's your homework. The attacker references PowerShell quite a bit in his techniques and tooling examples. How would you profile all PowerShell activity in your network? Start comparing and identifying interesting or suspicious uses of it.

Brad Mecha is a Compromise Assessment Lead at Cybereason.