Purple Teaming - Intelligence Driven Assurance

You don't know, what you don't know

Most organisations have adopted an annual cyber security programme which commonly includes penetration testing of internet facing systems and the "internal" network. These tests are valuable exercises which provide assurance that the environment is not affected by common misconfigurations and vulnerabilities.

However, they are not performing similar exercises which focus on their detection capability. It is assumed alerts are working as intended and making their way through processes, people and systems for triage and response. These processes can often include third party service providers who deliver level 1 and 2 triage before raising incidents to the internal security team. This introduces additional complexity, especially if the systems used by the internal security team and service provider are disparate or the third party is not diligent with raising alerts.

In the Office of the Australian Information Commissioner's (OAIC) "Concise Statement" document (https://www.oaic.gov.au/__data/assets/pdf_file/0025/221974/Australian-Information-Commissioner-v-Medibank-Private-Limited-concise-statement.pdf) which details the Medibank breach of 2022, it notes that:

"Medibank’s Endpoint Detection and Response (EDR) Security Software [REDACTED] generated various alerts in relation to the threat actor’s activity that were sent to a Medibank IT Security Operations email address. These alerts were not appropriately triaged or escalated by either Medibank or its service provider, [REDACTED], at that time."

This example may seem like a rare occurrence, but it is something we've seen frequently in environments. Expected logs are not being ingested into the Security Information and Event Management (SIEM) solution, logs are not in an appropriate format or alerts are not triggering for one reason or another. Fortunately the examples we've been exposed to have been less severe in nature. These issues with detection tend to go unnoticed until an incident or a red team exercise is performed.

In the Australian Cyber Security Centre's (ACSC) "Identifying and Mitigating Living Off the Land Techniques" advisory (https://www.cyber.gov.au/about-us/view-all-content/alerts-and-advisories/identifying-and-mitigating-living-off-the-land-techniques) they provide advice for mitigating Living of the Land (LotL) techniques. In the detection section of this advisory, they detail exactly how this issue can arise:

"Routinely verify that events are correctly logged, securely relayed to a centralized repository, and reliably trigger alerts. This is critical, as software and firmware updates, configuration adjustments, or system alterations can affect event logging and forwarding. This can potentially undermine log accuracy and alert efficacy."

Purple Team Exercises

Purple Team exercises aim to address the problem described above, by practically assessing detection and prevention capability. This is achieved by executing the techniques used by adversaries in the environment and determining whether compensating controls are effective by asking questions similar to the following:

• Did prevention controls mitigate the technique?
• Even if the technique was mitigated, was an alert raised?
• Was the alert raised to those responsible for escalation or response in a timely manner?
• If no alert was raised, is there evidence of the technique's execution in logs within the SIEM?
• What controls can be implemented to further harden systems against the technique?

The results of these exercises can provide assurance that controls (detection and prevention) are working as intended while also identifying areas that should be targeted with uplift. By performing similar exercises on a regular basis, organisations can also start to collect meaningful metrics about how their security controls have improved over time, which security controls are effective in practice and which controls are not justifying their cost.

Threat Intelligence

For organisations that are concerned with specific adversaries, Cyber Threat Intelligence (CTI) can be analysed and then used to deliver more tailored exercises. Thanks to the work and contributions of the security community and some companies, there are plenty of open source resources that can be leveraged for CTI. A notable example being MITRE ATT&CK's "Groups" (https://attack.mitre.org/groups/), which is a resource that details the techniques performed by various adversaries.

The ACSC in collaboration with other Western security agencies also publish threat advisories for adversaries targeting organisations in Australia. The threat advisories produced by the ACSC typically have a listing of techniques used by the adversary and techniques are already aligned with the MITRE ATT&CK for Enterprise Framework. This CTI can be leveraged to guide Purple Team exercises and provide assurance that controls are appropriate to deal with the techniques used by relevant threats.

Look at me, I am the threat actor now

To show the value of these exercises and how they can be performed, the remainder of this blog demonstrates the process of selecting, executing and assessing controls for a selected technique in a lab environment:

• Analysing CTI relevant to the organisation to identify techniques for execution
• Execution of a selected technique in the environment
• Assessing prevention and detection controls
• Identifying short and long term compensating controls to address gaps
• Implementing custom alerts using available log sources

Relevant CTI

For the example, the ACSC's "Understanding Ransomware Threat Actors: LockBit" threat advisory (https://www.cyber.gov.au/about-us/advisories/understanding-ransomware-threat-actors-lockbit) was analysed. This advisory was selected as LockBit affiliates (LockBit) have historically targeted organisations in Australia and Ransomware is a threat that most verticals are concerned with.

From April 1, 2022, to March 31, 2023, LockBit made up 18% of total reported Australian ransomware incidents. This figure includes all variants of LockBit ransomware, not solely LockBit 3.0.

The advisory provided a list of techniques used by LockBit affiliates which spans most tactics in the MITRE ATT&CK Framework. During a Purple Team exercise a number of the listed techniques would be executed with the exception of those not relevant for the environment.

The example technique selected for demonstration was:

• Technique: Exfiltration Over Web Service: Exfiltration to Cloud Storage
• MITRE ATT&CK ID: T1567.002
• MITRE ATT&CK Link: https://attack.mitre.org/versions/v13/techniques/T1567/002/
• ACSC Description: "LockBit affiliates use (1) Rclone, an open-source command line cloud storage manager or FreeFileSync to exfiltrate and(2) MEGA, a publicly available file sharing service for data exfiltration."

This technique was selected, as its execution is unlikely to be detected by out-of-the-box alerts for EDR solutions and does not involve overly technical steps. Additionally, the behaviour of the technique was captured in both endpoint and networking logs within the test environment.

Technique Test Case Template

To document the results of the technique's execution, a basic template was used to capture information. Using the information from the CTI, initial fields were populated:

Execute

Before downloading the RClone tool to the system that was used for testing, an account for the MEGA service (https://mega.io/), was created. This involved signing up with an email, password and then verifying the email address. MEGA have a free service offering which is sufficient to perform the technique. If there was a requirement to simulate the exfiltration of a large volume of data, a script could be used to upload and overwrite the same file.

With a MEGA account created, the RClone client (https://rclone.org/downloads/) was downloaded to the test system and the documentation reviewed to determine how RClone's MEGA (https://rclone.org/mega/) features could be used. The documentation details the process for configuring a MEGA account for use with the "config" command. This command caches credentials for use in subsequent commands.

Before running the required commands, the template was updated with the time of execution, the user the tool would be executed as and the name of the test system. Each individual executed command was also noted.

Once the credentials were configured, the copy command was used to perform the exfiltration by uploading the sample file to Mega.

With the file uploaded, execution of the technique was complete and observations recorded in the template. In this case, the technique was performed successfully and no security controls seemed to detect or prevent the technique:

Assess

Reviewing the results of execution, it was noted that no alerts were configured to detect the technique, and no controls prevented its execution.

Available security tools were then reviewed for evidence of the technique's execution. The lab environment where the example technique was executed, had the following tools and services configured:

• Elastic SIEM for centralised logging
• Elastic's EDR Agent for endpoints
• Sysmon configured with Swift on Security's Sysmon (https://github.com/SwiftOnSecurity/sysmon-config) configuration
• Squid HTTP proxy with SSL/TLS inspection forwarding access logs to the SIEM
• PfSense forwarding firewall and DNS logs to the SIEM

These systems and services were found to produce the following logs which captured the endpoint and network based behaviours of the technique:

Endpoint Logs

• Elastic EDR - process creation events
• Sysmon - process creation events (Event ID: 1)
• Sysmon - network connection events (Event ID: 3)
• Sysmon - DNS lookup events (Event ID: 22)

Network Logs

• PfSense - firewall network connection events
• PfSense - network device DNS lookup events
• Squid Proxy - HTTP proxy access events

For each log source, search queries were performed to identify the logs generated as a result of the technique. This step was performed to confirm that expected log sources were being ingested by the SIEM and the information contained in events was relevant, well formatted and the information correct.

After validating the logs were being ingested, the template was updated with the final details:

Analyse

In the test environment, there were no mitigating prevention controls, but log sources were being ingested which could be used to create custom alerts.

It may have been possible to implement prevention using the EDR solution through the use of a custom block rule for the RClone executable. This would be an acceptable short term fix. However, a more robust option would be to implement application control to prevent the execution of untrusted software. Application control would more reliably block RClone in addition to most other administrative tools listed in the CTI as being used by LockBit affiliates.

Prevention could have been implemented using the features of networking devices by adding domains associated with MEGA to a block list for the DNS service or the Squid proxy. If the networking devices supported it, domains categorised as "file sharing" could also be blocked if not used legitimately within the environment. The most ideal solution would have been to implement network access controls which "block by default, allow by exception". In most organisations this approach is only ever going to be a realistic control for servers or a subset of servers due to the impact on end user experience.

Remediate

After reviewing the executed technique, previously executed SIEM queries were reviewed to determine whether it may be possible to implement custom alerts. In the lab environment this was relatively simple as there were not any false positives. This is unlikely to be the case in real environments for most techniques.

If alerts were to be implemented for a real environment, a query would have to be drafted that would result in detection of the technique's behaviour, but with an acceptable level of false positives. Initially, alerts may need to be implemented with a lower priority until a baseline of normal activity could be defined.

To detect the use of RClone on the endpoint, a query for Sysmon process creation events was drafted which identified any events where the portable executable had an original file name of "rclone.exe". The original file name is a more ideal target for detection as it is slightly harder to modify when compared to the file name. Additionally, if the original file name is modified and the portable executable is signed, the signature will become invalid.

Despite the alert being likely to detect the particular method of exfiltration described in the CTI, it could be significantly improved by targeting other tools known to be used for by Ransomware groups for exfiltration.

To detect use of the MEGA service regardless of the tool used, a query was defined to identify any DNS lookup events where the registered domain was "mega.co.nz". The logs from the firewall were used for this query, rather than those produced by Sysmon. This would ensure detection of network connections to MEGA's services, even if Sysmon was not deployed to the endpoint where the technique was performed.

Once queries are drafted that reliably detect the technique, alerts can be created in the SIEM or EDR solution. Ideally, custom alerts should also be documented appropriately so that any member of the security team can easily access the required information to triage resulting alerts. Palantir have published their "Alerting and Detection Strategies Framework" on GitHub (https://github.com/palantir/alerting-detection-strategy-framework) which provides an excellent framework for alert documentation.

Repeat

After implementing the new alerts, the test was executed again. This time, two alerts were raised in the Elastic Security alert dashboard indicating they were working as expected.

Conclusion

Purple Team exercises are an effective approach to proactively identify gaps in an organisation's detection and response capability while collecting meaningful metrics on capability over time. By integrating CTI into exercises an organisation can gain assurance that they have implemented controls that are likely to be effective against the techniques used by adversaries likely to target them.