What Red Teams can teach us
“No plan survives contact with the enemy” is one of the truisms of conflict. It’s somewhat (un)surprising how accurately this describes the cybersecurity posture of most organizations. Best laid plans can come crumbling down the minute an adversary tries something we did not account for, and this will not become apparent until it happens.
It is very easy to dismiss concerns like “your information can be stolen”, “you’ll lose all your critical data”, “you can be liable for losing your customers confidential information” until you’re actually hit by such an event, and, when that happens, your organization is too busy picking up the pieces to properly acknowledge the problem that caused it in the first place.
One way to (sometimes painfully) learn about the potential risks and identify the problems in an up-to-that-moment flawless infrastructure is to engage with a Red Team and have them perform an offensive operation against you. The downside is that, when these operations are performed, the results are often so disheartening that most organizations will trigger NDA clauses and keep the results confidential – making it harder for everyone else to learn from this experience.
CISA, the US agency tasked with implementing cybersecurity measures and policies, provides organizations, both public and private, the possibility of having Red Team operations done on their infrastructure – by a trustworthy party. Very recently, the agency published a report of one such exercise, and the description of the methods, techniques and procedures employed should make every CISO and IT leader consider if their own infrastructure would fare better than the unnamed organization in the report.
The setup
Last year, at the request of a critical infrastructure organization spanning multiple geographic locations, CISA conducted a Red Team Assessment exercise to test the defenses and identify the risks of this organization’s IT infrastructure. This organization, which remained unnamed in the report, was considered to have a “mature cyber posture”.
The goal of the exercise was to gain access into the organization’s network infrastructure and try to obtain access to critical information and systems.
Spoiler alert, it succeeded spectacularly.
The initial entry
In an impressive security feat, this organization’s public IP address space, encompassing over three million addresses, was not found to contain any exploitable vulnerable services or ports. This speaks to the level of security the organization possessed prior to this engagement, and is surely a pride point for the security team working there. This is quite the feat.
Given this, CISA’s Red Team (RT) had to employ different tactics to gain first entry. If the network isn’t vulnerable, then maybe the human element is. And so, using publicly available information from social networking sites (OSINT), the RT obtained detailed information about the personnel working at the organization – specifically, in the IT team. By identifying the email naming scheme from a few publicly visible email addresses , the RT no longer needed to find emails for all the key personnel, just their names, and could create the email addresses for other individuals that were not publicizing that information. Armed with this knowledge, the RT engaged in phishing activities targeting specific individuals, with content specifically tailored to them (using their hobby information, for example). Two individuals responded and were engaged until they agreed to an online video call with members of the Red Team. To enter these video calls, the key individuals were tricked into accessing an RT-controlled website to download the video connection software, which included a remote control “feature”. This gave the RT immediate access to two different workstations inside the network, belonging to two IT administrators.
Owning the network
With the proverbial foot in the door, the RT moved to map the network. They identified the existence of a number of other workstations and domain controllers (it was a Windows-based environment), and queried the Active Directory for all the users and accounts present in the environment. This enabled further phishing attacks which led to access to a misconfigured server, from which they compromised the Domain Controller. This lateral movement was facilitated by an Active Directory-specific technique called “Golden Ticket Attack”, in which a special type of authorization token was used to create other authorization and impersonation accesses. While I won’t go into the specifics of this attack, as it is fairly involved and somewhat long to explain, it is based on the fact that there were services running with more privileges than they should, and it was possible to grant further privileges from the existing ones.
They extended this privilege granting mechanism to obtain privileged access to a Domain Controller. “Owning” a Domain Controller (DC) gives effective control over all other systems in that domain – workstations, other servers – sharing the authentication mechanism.
Owning the world
If you don’t know much about Windows’ Active Directory, the key aspect to keep in mind is that the DCs always need to see and communicate with all other DCs, or it can get out of sync really fast. So, even in geographically separated sites with very restricted network access between them, the firewalls permitted connections between DCs at different sites – and one of those was already under the RT’s effective control. Abusing this, they jumped to other DCs and were able to map and identify systems at other sites inside the organization, including a workstation used by an administrator, where they gained access to a password manager containing credentials for multiple privileged systems, and another where they found a “network diagram detailing the network boundaries” between sites, “cloud infrastructure” information, including trusted IP ranges – and the RT bought an IP address in that trusted range, which allowed it to access other systems it had not yet gained access to. And these events don’t even scratch the surface of what is contained in the report as additional movement.
The RT owned the network completely, and gained access to multiple business services. It effectively owned the organization’s IT world. And up to that moment, not a single alert had gone out, so they were still effectively undetected – confirming an industry trend, where most breaches go undetected for months. In fact, contrary to fictionalized accounts of hacking operations, a breach like this doesn’t happen with just a couple of mouse clicks and commands typed in a shadowy room.
The Red Team operation happened over a period of months (a predefined engagement time frame was agreed upon before starting) and this enabled the Red Team to perform its activities quietly, without triggering any alarms or monitoring thresholds. There’s a mantra to the effect of “the quieter you become, the more you are able to hear”, and it fits like a glove.
Until they wanted to.
After all of this, the Red Team wanted to test the organization’s response to security incidents, so they deliberately engaged in activities that should trigger monitoring alerts – like creating new users, exfiltrating data to outside servers, attacking outside servers from within the network, elevating privileges, deploying a fake ransomware attack to workstations (!) and several others, and the response was either non-existent or minimal at best.
The recommendations
The report provides some clear, actionable, recommendations that can extend beyond the target organization:
- Establish a baseline – identify what is normal activity on the network and services, and configure the monitoring to alert in case it falls outside these parameters
- Conduct regular assessments – to test both software and hardware, as well as procedures and training for the users and staff
- Enforce phishing-resistant MFA wherever possible.
For the target organization, in addition to these recommendations, CISA also suggested reducing permissions on systems that do not require them, having a plan in place to rotate service account passwords (the Kerberos account used in the Golden Ticket Attack still had the same password from when it was deployed – 10 years ago), hardening systems after initial deployment, as the default settings were very lax on some security aspects, improve monitoring and response as well as multiple other considerations.
How your organization approaches the recommendations will often be more telling of your overall security posture than the fact that there were problems to begin with – you can either accept them and improve, or dispute them and remain insecure. Learning from them is a good indicator of the maturity level of the security approach and the team responsible for it.
Final remarks
The report is incredibly detailed. While many other reports are available and are useful as learning instruments, the detail level on this one is superlative. As it stands, it is a valuable learning tool for any team, from Ops to Security to in-house Blue and Red Teams. It is also a wake-up call and a reality check for any organization that is (over-) confident about their security posture but hasn’t had any real event to prove (or disprove) this notion.
Also, the Human element continues to be the weakest link. The best security tools in the world are defeated by your user (or even sysadmin!) who clicks through an email link or downloads and runs third party software.
If you’re having trouble getting your board on-board (dad joke intended) with the necessary investments in IT, and cybersecurity in particular, you should use this report to reinforce your point – it could be your organization.
And, the main takeaway is this – it was just an exercise. Imagine the lengths that a properly motivated adversary would go to, even beyond what was accomplished by the RT in this exercise, if they decided to target your organization. Security risks are not just “marketing props” – they are real and present concerns which you dismiss at your, and your organization’s, peril.