Red Team Case Study – Multinational Insurance Group

Context

Prior to undertaking a mandatory CBEST engagement, a multinational insurance group engaged Cyndicate Labs to assess the security of the external perimeter and internal network by performing a CBEST-like Red Team engagement.

Scenarios and Objectives

Working alongside the client to utilise their budget efficiently, the following scenarios were agreed:

Scenario 1 – External

A motivated attacker utilising OSINT gathering techniques to uncover infrastructure, employees, passwords, and any other assets or information pertaining to the target organisation. This information will then be used to aid exploitation against the group. The Control Group also stipulated that physical intrusion, or other social-engineering is considered out of scope. Whilst Phishing was permitted to be undertaken, it should only be used as a last resort.

Objective 1 – gain access to sensitive data & compromise the internal network.

Cyndicate Labs initially performed passive enumeration and reverse engineered the groups mobile applications to identify infrastructure, employees, credentials, and any other data belonging to the organisation. Using Cyndicate Labs’ asset discovery tooling Cyntel, sixty-five (65) domains, five-hundred (500) subdomains, and thousands of employees were automatically identified.

Cyntel also identified thirteen (13) subdomains belonging to the organisation, that were pointing to cloud assets that no longer existed. With the Control Group’s permission, Cyndicate Labs re-registered each asset to gain control over the misconfigured subdomains. This meant the Cyndicate Labs Red Team, controlled assets belonging to the organisation with high trust-factor. This would have allowed for high reputation water-holing attacks to take place.

All traffic to these subdomains was logged and closely monitored while Cyndicate Labs consultants continued with further testing.

After compiling a list of employees and their job roles, further OSINT was performed against members of the cyber security, IT, and software engineering departments, as they likely held significant privileges over the group’s infrastructure. This quickly identified a personal GitHub belonging to a developer hosting various terraform scripts used to manage cloud, and in-house assets belonging to the group. Various clear-text credentials, IP ranges, API tokens, and secret keys were identified within the variable definition files of those scripts. This resulted in significant privileges over the organisation’s Azure estate and access to hundreds of Gigabytes (GB) of data within Azure Blob storage. One key finding was a 132GB VHD (Virtual Hard Disk) belonging to one of the groups perimeter web applications.

Due to the severity of findings, and the GitHub repository being publicly accessible for several months, Cyndicate Labs immediately alerted the client point of contact, before aiding the organisation in ensuring all credentials, API tokens, and secret keys disclosed within the repository were successfully revoked. Access logs were reviewed to ensure the information had not been abused by any malicious actors.

Following the remedial action, the logs from the subdomain takeover vulnerabilities were reviewed and it was identified that a small number of hosts within the organisation were still configured to use the compromised cloud assets. This resulted in further API keys and credentials being captured by the Red Team via the logging scripts.

After discussing the findings and potential paths to compromise the internal network, the client Control Group were satisfied and wished to proceed with the internal phase of testing (Scenario 2).

Scenario 2 – Malicious Insider

An assumed breach scenario whereby the Red Team seeks to obtain access to the groups most prized assets, as defined and agreed upon by the Control Group.

Objective 2 – Escalation of privileges

Cyndicate Labs were provided with a standard domain user account, reflecting that of an internal employee with no excessive permissions, which could be accessed externally via Azure Virtual Desktop. The objective set by the Control Group was to identify methods to gain sufficient permissions to be able to deploy a critical ransomware attack against the organisation.

Once authenticated to the environment, initial reconnaissance included identifying publicly accessible SMB shares within the target domain. This identified several open network file shares with various exposed clear-text domain and database credentials. These credentials provided the Red Team with administrator access to four (4) IIS servers. By deploying a custom ASPX web shell deploy to the web server, it was possible to further enumerate the IIS hosts without triggering endpoint protection software.

Enumeration of the hosts identified that two (2) of the IIS servers were significantly outdated, and therefore the endpoint detection software in-use by the organisation was not supported. To remediate this, the organisation had deployed Microsoft System Monitor (Sysmon) while they worked towards decommissioning the outdated hosts. Unfortunately, during its deployment the Sysmon configuration file was left on the host unprotected.

With knowledge of the endpoint detection software in use and the Sysmon configuration file, Cyndicate Labs emulated the setup and configuration within a lab environment to identify methods to execute a C2 payload without detection. Two (2) methods were developed, a Visual Basic Script (VBS) loader, and a modification to the existing Cyndicate Labs ASPX web shell to both disable Sysmon and execute raw shell code.

Using the compromised credentials, it was possible to update the ASPX web shell on the IIS web servers before accessing the shell via the web browser. Once updated, Cyndicate Labs executed shellcode within memory to establish an undetected command and control channel out of the organisations’ network. Cyndicate Labs also utilised several of the subdomain takeovers identified in the first scenario for C2 communications. As all traffic to the organisations own domain was inherently trusted by security tooling, this made the C2 communications incredibly difficult for the security team to identify.

As the DefaultAppPool IIS service account holds the ‘SeImpersonatePrivilege’ token by default on Windows, it was then possible to elevate privileges on each of the web servers. The Red Team returned to the lab environment to develop a method to extract clear-text credentials from memory without detection from the organisation’s endpoint detection software and Sysmon configurations. As a result, a further credential was obtained from an IIS server that had administrative access to an additional twenty (20) hosts. One of these hosts had a naming convention related to the data discovery platform “Varonis”, which also from reconnaissance, was known to have a service account with Domain Administrator privileges.

The above steps were repeated to laterally move to the identified Varonis machine, escalate privileges to SYSTEM level, and extract credentials from memory, resulting in a clear-text password for the Domain Administrator service account. As a result, administrative privileges were obtained over the entire Windows estate, allowing the deployment of ransomware against over three thousand Windows hosts.

Objective 3 – Compromise Customer & Underwriter Data

The organisation’s Control Group wished to gain an understanding of the technical skill level required for a malicious insider to successfully compromise and exfiltrate sensitive data from the estate.

To simulate a low-skilled attacker, the Red Team enumerated network file shares and Microsoft SharePoint to identify any world-readable sensitive data. This quickly identified clear-text domain & database credentials, invoices, hard drive backups, and a folder containing hundreds of Gigabytes of nightly database backups. Unfortunately, this folder also included an up to date, 500 Gigabyte backup of their main underwriting database. This included sensitive financial information, personal information, and intricate details of the underwriting records.

Database credentials identified on file shares also provided access to sensitive data, however as this required tooling to be introduced into the environment to successfully authenticate to the databases, this was considerably more difficult than simply browsing file shares.

Whilst it was proved to be feasible for a low-skilled attacker to obtain access to sensitive data, exfiltration was not so simple. At the request of the Control Group, Cyndicate Labs once again started from the perspective of a low-skilled attacker and attempted to exfiltrate data via common methods.

As the identified databases contained significant quantities of sensitive customer data, the Control Group provided a database containing sample data to be exfiltrated instead.

Common exfiltration methods such as utilising various protocols to upload data to an attacker-controlled server or uploading data to cloud services such as Microsoft OneDrive were blocked and quickly identified by the Blue Team. This concluded that whilst a low-skilled attacker may easily obtain sensitive data, they are less likely to successfully exfiltrate data from the Azure Virtual Desktop without detection.

The Red Team then increased the required skill level and used one of the subdomain takeover vulnerabilities identified earlier in testing. As this domain was inherently trusted by the organisations security tooling, it was possible to exfiltrate the database to host without alerting the Blue Team.