Traditionally, Red Teaming has always put an extensive focus on environments with an on-premises network managed by Active Directory. The MITRE ATT&CK framework (https://attack.mitre.org/) includes a number of TTPs for these environments, such as the exploitation of Active Directory-specific services and scenarios (e.g. Kerberos, NTLM issues, escalation to Domain Admins). However, nowadays a large number of companies are migrating to cloud services to the point that the majority of their critical data is now hosted on these services. When performing a Red Team engagement, it is therefore crucial to take this into account and tailor the objectives of the assessment to include the company’s cloud infrastructure.
Dionach’s Red Team recently performed an engagement against an organisation which was particularly concerned about their data hosted on AWS. Although the organisation had an on-premises domain, the business-critical information was hosted on the cloud, and therefore compromising their AWS environment became the main objective of the assessment.
The Red Team engagement was structured in three main phases, which will be described in greater detail in this blog post:
- In-Phase: during this phase, Dionach’s Red Team breached the external perimeter of the organisation, obtaining access to the internal network through an advanced targeted phishing scenario.
- Through-Phase: in this second phase, Dionach’s Red Team enumerated the internal domain looking for opportunities to move laterally and formulated an attack plan with the goal of reaching the objective.
- Out-Phase: in the last phase of the assessment, Dionach’s Red Team escalated their privileges on the on-premises network, and subsequently identified a critical flaw in the AWS environment which allowed them to achieve the final objective.
In-Phase
During the in-phase, Dionach performed reconnaissance against the target organisation, in order to identify potential entry points inside the internal network from the internet, such as the exploitation of insecure services exposed online. However, none were identified, and therefore Dionach’s Red Team decided to perform a phishing campaign against selected victims.
The department targeted by Dionach’s Red Team was the sales team. A member of Dionach’s Red Team posed as a potential customer interested in buying the organisation’s services, and arranged a call with one of their sales representatives. The primary goal of the call was to persuade the victim to open a malicious document disguised as a network diagram. The pretext given was that opening this document would provide them with essential information which will be needed to offer a final quote.
In order to maximize the campaign’s success, the following techniques and precautions were applied:
- The document was delivered via a SharePoint link, which was pasted on a Teams chat during the scoping meeting. This was done to bypass potential mail spam filters.
- The real executable file was hidden using HTML smuggling techniques and obfuscated JavaScript code.
- A number of AV and EDR evasion techniques were implemented using custom code.
- A sample network diagram was shown to the victim upon execution of the file to avoid raising suspicion.
- The result of the social engineering attack was successful. The sales representative executed the malicious file which established a command and control (C2) channel to Dionach’s Red Team C2 infrastructure, granting the team remote access to the organisation’s internal network.
Through-Phase
After internal access has been achieved, the next step for Dionach’s Red Team was to enumerate relevant information on the network in order to formulate an attack strategy that could be used to reach the AWS environment. As part of this phase, a number of activities were performed:
- Active Directory enumeration, with the goal of identifying developers or servers with specific keywords in their name or description fields (such as “Amazon”, “AWS”, “Cloud”)
- Enumerate Active Directory Certificate Services (ADCS), with the aim of identifying misconfiguration and escalate privileges on the on-premises domain.
- Targeted Kerberoast attacks against only privileged service accounts, in an attempt move laterally on the network.
- File shares enumeration, with the objective of identifying any reference to the organisation’s AWS environment.
As part of this enumeration phase, a number of interesting findings were identified on the target environment:
- A number of servers had “AWS” or “Cloud storage” in their description attribute.
- One of the certificate templates was affected by the well-known ESC1 vulnerability.
- A large number of backups were identified on a network share accessible by the compromised user. These backups were confirmed to be of systems which were indeed hosted on AWS, however the live systems were only hosted in the cloud, therefore although this finding did give an indication of the data stored in AWS to Dionach’s Red Team, it was not considered a compromise of the cloud environment.
This led the Red Team to formulate an attack plan, which was executed in the last phase of the engagement.
Out-Phase
In the last stage of the assessment, Dionach executed a number of tactics and techniques which allowed the Red Team to escalate their privileges on the on-prem domain, move laterally to the cloud environment and compromise the AWS environment using a critical misconfiguration.
In the previous phase, Dionach identified a critical vulnerability in one of the certificate templates (ESC1), which allowed authenticated users to obtain a certificate on behalf of any user, including administrators. More information on ADCS vulnerabilities can be found at the following URL:
https://posts.specterops.io/certified-pre-owned-d95910965cd2
The following command to obtain the certificate on behalf of the domain administrator user “CORP\djones” was executed through the malicious implant with a modified version of the “InlineExecute-Assembly” BOF[https://github.com/anthemtotheego/InlineExecute-Assembly] to minimise the chance of detection:
Certify.exe request /ca:dc01.corp.local-DC-CA /template:<VulnerableTemplate> /altname: djones
Once the certificate was obtained, it was trivial for Dionach’s Red Team to obtain a TGT ticket for the domain administrator user by issuing the following command:
Rubeus.exe asktgt /user:<domain-admin> /certificate:cert.pfx /password:<certificate-password> /ptt
With the newly obtained administrator privileges, the Red Team attempted to move laterally to the cloud environment by abusing the data protection API (DPAPI). In short, being administrator of the domain allows the attacker to retrieve the master backup key from the domain controller, which would allow them to decrypt secrets on any domain system. These secrets include saved passwords, Windows Vaults, browser credentials and cookies. Using this approach, Dionach attempted to decrypt secrets stored on developer’s laptops, which were identified during the previous phase by analysing Active Directory computer account attributes. First, the domain backup key was obtained from the domain controller by using a tool such as “dploot”:
dploot backupkey -d <domain> -k <DC-IP>
Using the newly obtained key, it was possible to extract secrets from the target system using a tool such as “donpapi”. After a number of attempts, Dionach successfully identified a laptop from which a developer signed in on AWS from Firefox and Chrome , and saved their password in the browser.
Logging in with this account on AWS provided a first access to the cloud environment of the target organisation. However, the user was not an administrator on AWS, therefore privilege escalation was still required to reach the objective.
Analysis of the user’s permission revealed that a number of low privileged permissions were assigned to the user, however this user was also assigned the “SupportUser” policy:
This policy grants the user permissions to troubleshoot and resolve issues in AWS, and with this privilege it is also possible to display IAM roles information, which was proven to be critical for privilege escalation. Upon further investigation, Dionach’s Red Team identified a critical vulnerability in one policy, which was seen to be overly permissive. The following extract shows how the “AssumeRole” action is granted to the “*” principal, which means that any AWS user (including external accounts) can assume that role.
This is a straightforward attack and can be executed with “aws cli”, even from an account external to the target AWS environment:
$ aws sts assume-role –role-arn arn:aws:iam:<role/policy> –role-session-name <name>
Once the role is assumed by editing the “~/.aws/credentials” file with the above information, Dionach’s Red Team reviewed permissions policies that are attached to the role in an attempt to escalate privileges. This led to the discovery of an attached policy which had the “iam:AttachRolePolicy” permission assigned:
Further analysis confirmed that this had the AttachRolePolicy
This is highly insecure, as it would allow anyone with this role to attach a privileged permission to the policy, such as “AdministratorAccess”. Once again, this was straightforward to exploit using the “aws cli”. Once the previous credentials are copied into a new profile in “~/.aws/credentials”, the following command could be issued to compromise the environment:
$ aws iam attach-role-policy –role-name <role> –policy-arn arn:aws:iam::aws:policy/AdministratorAccess –profile exploit
This in fact added the “AdministratorAccess” policy, as shown below:
Before:
After:
By chaining these misconfigurations together, Dionach Red Team successfully compromised the organisation’s AWS environment and achieved the main objective of the engagement, highlighting critical flaws in both the on-premises and cloud infrastructure.
Conclusion
This blog post demonstrated how an attacker could successfully leverage vulnerabilities on the on-premises domain to ultimately pivot into the Cloud environment, and how it is possible to finally escalate privileges by abusing critical misconfigurations in AWS.
Although Cloud environments can be configured securely and in line with industry best practices, developers should always be aware of the possibility of introducing critical vulnerabilities in such environments. When building a hybrid environment, it is also crucial to secure the on-premises domain too, as an attacker with domain administrator privileges on a typical Active Directory domain can move laterally through the network using a large number of techniques, and in some cases, it is only a matter of time until they compromise your most critical data.
In terms of detection and response, the target organisation did not detect the exploitation flow performed by Dionach Red Team, which revealed a gap in endpoint and network monitoring. Dionach’s Red Team helped the organisation to close the gap by arranging several technical meetings with the organisation’s security department. During the technical meetings Dionach’s Red Team discussed the types of logs that should be implemented, and the rules required to generate accurate security alerts for improving detection and response time for an internal investigation.
Would your organisation be able to detect the following indicators of compromise (IOC)?
- Targeted phishing against sales representative
- Periodic C2 traffic to an external domain at unusual times
- Active Directory enumeration and ADCS exploitation
- Large number of SMB connections made to a number of systems
- Unusual logins for the compromised AWS account
These are only some of the TTPs that were illustrated as part of this blog post, and only a small percentage of the TTPs which are executed as part of a full Red Team engagement. Dionach’s Red Team services are aimed at testing your detection and response capabilities with the goal of improving your resilience against real-world attacks and discovering critical vulnerabilities within your environment. Reach out to us today to discover how our Red Team services can protect your assets and enhance your defence strategies.