CIOs and CSOs are increasingly turning to Red Teaming to assess their organisations’ cyber resilience. A red team exercise is a simulated, targeted cyber-attack that mirrors the tactics, techniques and procedures used by real hackers, writes Andrew Scott, Assurance Regional Lead, Scotland at Context Information Security
These exercises often start from a ‘no-knowledge’ perspective and don’t offer instant gratification: they typically last between four and six weeks and result in a better understanding of the security risks and what steps can be taken.
Red Team findings are very different from penetration testing findings. Key to this is the wider scope of the Red Team, not just from a technology side, but also from the People and Processes perspective.
Obtaining real data on what a simulated attacker was doing on a network when the Security Operations Centre were unable to track them is invaluable in helping mature the team and technologies in the SOC.
At Context, we have been performing Red Team engagements for some 20 years, but have based the findings in this article on tests carried out in the last six years from Europe, US and Asia Pac and across industries from finance, retail, regulators and healthcare to Governments and media organisations.
From these engagements we have analysed the findings to identify key ‘pivot points’ in the simulated attacker’s interaction with the target. These are the enabling weaknesses that turned the attack from an annoying intrusion to a potential disaster for the customer.
Red Teaming Engagements: The Findings
Lack of Patching and Unsupported Software
The fact that patching reached third place won’t be a surprise to anyone, yet it continues to be a thorn in system administrator’s sides and a huge opportunity for attackers. Even in the enterprises that we find that have the basics fixed, such as a successful Windows update cycle setup, there is always other vulnerable software running that can be leveraged to increase access and attack other users or systems. The most common areas that we find opportunities to dig deeper into an organisation are:
- Third-party software. All software installed on a system needs maintenance and new versions and patches applied. Whether it’s FileZilla, the organisation’s management instrumentation or Chrome, all software needs to be considered as part of a patching cycle.
- Usually business applications exist on the network, and we find they are not well maintained and patched. Or there are no patches but the application relies on outdated software and no mitigating actions have been taken.
- OS updates. Although in a better place than third-party and hosted application patching, operating system patches are still not consistently and ubiquitously applied.
- Outdated OSs. Yes, we still find Windows 2003 and XP in organisations. Everyone knows they are bad, but they have not successfully eradicated them from their estates. Not only are these old systems outdated and vulnerable, they can also hold back connected modern systems from being able to use some of the latest security settings available.
- Out of support hardware. As with software, hardware goes out of support, get vulnerabilities and needs patching. Not supported but often not replaced, these can also be a treasure trove for attackers looking to gain additional access to a network.
- Browser plugins. With the use of a modern browser this is becoming less of a problem. However, Red Teams do still find an installed base of Flash, old versions of Java and Adobe products which mean that they are usually able to find a reliable way to gain access to people’s desktops if needed.
Network Segregation
In two-thirds of our Red Team engagements we find we can jump straight from our initial point of compromise and start interacting with the targeted ‘Crown Jewel’.
Ten years ago, we used to talk about the crunchy exterior of networks and the soft squishy interiors and this seems to still be very much in evidence. When any connected device can connect to any system, eventually one will.
With the rise of VDI based infrastructures, new software tools and advanced host-based firewalls available in most operating systems, organisations can address this problem without necessarily re-architecting.
Poor Credential Handling
And in first place… in fact this was the biggest surprise when compiling the stats.
While ‘getting Domain Admin’ is required on some tests, no one imagined that this would be the key to as much as 85 percent of Red Team engagements, a full 20 percent up on second place.
Delving into the results more deeply reveals several ways that credentials are exposed to a Red Team, divided into those that increase risks and those that result in instant failure.
The most common point of single failure is passwords, for powerful domain administrator level accounts, added to logon scripts, or saved on a file share ‘in case someone forgets’.
Often these repositories allow everyone on the network to read them, compromising the credentials. Sharing administration credentials, either between users or between accounts, makes compromising them much easier for the Red Team or an attacker to gain access to them. The other problems are all common issues, which every system administrator knows they shouldn’t do.
When it comes to issues that increase risks, rather than acting as single points of failure, they mostly feature account configuration options.
It is common to find high power accounts with passwords which have not changed for more than five years, or the local administrator across a whole organisation to have the same password on every PC.
But the standout is simply that passwords used on important accounts are too easy to guess, or crack because they are not complex enough.