[BreachExchange] Hacking Team postmortem is something all security leaders should read

Inga Goddijn inga at riskbasedsecurity.com
Wed Apr 20 20:04:36 EDT 2016


http://www.csoonline.com/article/3058764/security/hacking-team-postmortem-is-something-all-security-leaders-should-read.html

Hacking Team is back in the news again. Last weekend, the person
responsible for Hacking Team's meltdown posted a recap of the incident
<https://ghostbin.com/paste/6kho7>, including a detailed overview of how
they hacked the Italian firm.

It's a fascinating read on its own, but the postmortem should be essential
reading for anyone that supports or manages a security program.

Hacking Team is an Italian company that sells intrusion and surveillance
tools to governments and law enforcement agencies. Nine months ago, their
world was rocked after someone exfiltrated nearly 400GB of data form their
network
<http://www.csoonline.com/article/2944333/data-breach/hacking-team-responds-to-data-breach-issues-public-threats-and-denials.html>,
including source code and contracts.

The irony is that Hacking Team developed tools that enabled hostile
governments to do the exact things that were done to them, so many in the
security industry experienced no small amount of schadenfreude at their
expense. Over the weekend, the person responsible for the Hacking Team data
breach, Phineas Fisher, outlined the hack from start to finish
<http://www.csoonline.com/article/3057980/security/hacker-this-is-how-i-broke-into-hacking-team.html>
.

"You used to have to sneak into offices to leak documents. You used to need
a gun to rob a bank. Now you can do both from bed with a laptop in hand,"
Phineas Fisher wrote.

"That's the beauty and asymmetry of hacking: with 100 hours of work, one
person can undo years of work by a multi-million dollar company..."

To be clear, what happened to Hacking Team is a classic example of a
targeted attack. Few organizations could outlast an attacker with
knowledge, time, and resources. At the same time, the way Hacking Team
managed and developed their network did them no favors.

Fisher took the time to reverse engineer some firmware in an embedded
device and develop a new exploit. This Zero-Day vulnerability enabled
persistent access, because he used it once (and only once) to plant a
backdoor into the network.

Ultimately, a poorly configured iSCSI was Hacking Teams downfall, but there
were other issues too – such as services deep within the network exposed to
less secure subnets, MongoDB instances with no authentication, backups that
had passwords stored in plaintext, as well as weak passwords everywhere –
including on critical systems.

[*See Also: In Pictures: Hacking Team's hack curated*
<http://www.csoonline.com/article/2944732/data-breach/in-pictures-hacking-teams-hack-curated.html>
]

So what are some takeaways form the post-hack outline? Sarah Clarke, from
infospectives.co.uk <http://infospectives.co.uk>, shared some of her
thoughts on the matter, including the fact that everyone's threat level
just went up a bit.

"Despite being almost a decade away from the network coalface, I, without
much trouble, and a little help from my friends, could do everything
listed. What will stop me is fear of prosecution, ethics, and a strong
analytical ability to see short, medium, long-term implications," she said.

Considering the outline and processes documented by Phineas Fisher, Clarke
did what many security leaders would and searched for "what's next" – what
can organizations with concerns about these types of attacks monitor for?

If your organization faced a similar attack, what would common enterprise
monitoring tools spot, if configured correctly? What amendments to IDS/IPS,
log monitoring, vulnerability scanning, pen test scoping, SIEM alerting, or
alert analysis need to be made or augmented?

Andy Settle, head of special investigations for Austin-based Forcepoint,
had some additional thoughts, which are produced below.

"The attack was targeted and had every intention of getting in. This type
of threat needs to be addressed by asking 'when?' and not simply 'if?' Once
inside the company network, the hacker managed to traverse the company
infrastructure with little difficulty," he said.

"Protecting the soft-skinned inner workings of an organizational
infrastructure is equally important. Minimizing the services within a
company network is just as essential to minimizing those presented to the
outside world."
Monitor & Assess:

Firewall logs can give advanced warning of these types of attacks. Network
mapping, port scanning and enumeration may well be countered by the
firewall and Intrusion Prevention Devices (IPS) but to not monitor and
assess the data they produce is to lose the Indicators & Warnings (I&Ws)
that could indicate that something was likely to happen.
Updates & Patching:

"There should be no surprise that updates and patching are essential.
[Phineas Fisher] was able to exploit a known vulnerability within the
network management system Nagios. Interestingly, the attacker became aware
of the Nagios system only after they "spied" on the sysadmins," Settle
explained.
Separation of Networks:

This attack was possible because backup and management networks that should
have been segregated were not. Separation of operational and management
networks is a useful technique for protecting infrastructure, especially
when the management network requires administrative privileges. In this
attack, [Phineas Fisher] was able to interrogate and dump the email server
backup images.
Watch and Protect the Privileged:

We often say that one of the greatest challenges is monitoring those with
privileged accounts. Many organizations, especially government related
require security clearances to protect from the insider threat. However,
what this incident teaches us that once in, the bad guys make a beeline for
the sysadmins to monitor their activities in order to gain greater
knowledge and understanding of the company and its infrastructure.

"There is somewhat of a mind-set change here, should we not be monitoring
the privileged users and their workstations? Not because we do not trust
them, but for their own protection and to ensure they are too are not being
watched by network sniffers, key-loggers etc.?" he added.
Egress Monitoring:

"One final observation is that a lot of data was ex-filtrated. Why was this
not noticed? This is hardly uncommon in attacks where intellectual property
is the target. Implementing a Data Theft or Data Loss Prevention (DTP/DLP)
solution and monitoring will lessen the likelihood and potential impact of
this type of attack," Settle said.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20160420/53837a53/attachment.html>


More information about the BreachExchange mailing list