A case study in structured intelligence analysis

In recent weeks DarkLab helped a large international company conduct a threat hunting exercise in their infrastructure following a network breach.

The initial investigations revealed that threat actors infiltrated the network using legitimate and likely stolen credentials on a Citrix server hosted in a European subordinate of our client. From there, however, the DarkLab team discovered two sets of activities. One led to the exfiltration of large amount of data, another one to the deployment of the REvil ransomware, also known as Sodinokibi. We previously reported on how ransomware operators are increasingly stealing data from their victims to threaten its release if their ransom demands are not met. It seemed therefore possible that the two sets of malicious activities were carried by the same threat actor.

Indeed, the initial entry point was the same, and the stolen data was uploaded to Mega, a popular data hosting site previously used by REvil operators. However, some other aspects of the malicious actions did not add up. For instance, data was exfiltrated weeks after the ransomware was deployed, which would have been inconsistent with previously observed tactics, techniques and procedures (TTPs) of ransomware operators. Also, the activities that led to ransomware deployment and those that ended up stealing data exploited commonly used but different toolsets. While in one incident Cobalt Strike was used as the attacking tool on day one, the other set of activities involved PSExec the day after. Since Cobalt Strike has a Psexec built-in we started doubting whether the two incidents were carried out by the same hacker.

Assessing pieces of conflicting evidence can be messy and potentially lead to the wrong conclusion. In order to analyse existing evidence in an unbiased and objective manner, DarkLab analysts resolved to employ a traditional intelligence analysis technique used by intelligence professionals since the 1960s. Despite its age, the Analysis of Competing Hypothesis (ACH) remains a useful framework to answer difficult questions in a way that removes analyst’s potential biases or misconceptions.

Our analysts created a table like the below, where pieces of evidence are given a credibility and relevance score, before evaluating their consistency with different hypothesis. The hypothesis with the highest score is considered the most likely.

In our case we considered the following hypothesis:

H1: Incident 1 and 2 were carried out by the same attacker

H2: Incident 1 and 2 were carried out by two different attackers

H3 Incident 1 and 2 were carried out by more than two attackers

Fig 1 – ACH table

By considering the evidence collected as consistent (C), not applicable (N), or inconsistent (I) with each of the hypothesis, a final score is calculated. H2 scored the highest
indicating it was clearly the most likely hypothesis. This suggested that indeed different threat actors were separately involved in the ransomware deployment and data exfiltration.

In this way, we were able to use a fact-based, objective analysis of the available intelligence to our advantage in a live threat hunting exercise. In particular, our threat hunting team was able to treat the incidents as separates, with significant implications for their efforts in detecting and mitigating the breaches.

Further details on the incidents

Our forensic investigation identified how the ransomware attack lasted a total of five days, while the threat actor that stole the data was able to remain undetected in the network for almost six weeks. In both cases, the number of hosts compromised was significant and threat actors were able to move across different countries’ networks without being detected.

The REvil operator used the legitimate remote access solution AnyDesk as a backdoor, and eventually deployed the ransomware to over 1000 servers and workstations in Hong Kong and the UK. Ironically, the ransomware interfered with the callbacks the second attacker had already established on 10 machines. All their established call-back connections on the compromised servers were gone after the ransomware attack. They were therefore forced to restart from the initial compromised Citrix server in the UK. From there, they used Cobalt Strike for lateral movement and privilege escalation on multiple accounts in Hong Kong, US, and India. This second attacker collected hundreds of gigabytes of data from different servers, staged them internally, comprossed them, and eventually uploaded them to a Mega cloud server.

Mitigation

The presence of two separate attackers within the network of a large conglomerate indicates the significant challenges that large organisations with tens of thousands of endpoints can face. Deploying standard policies on such a large estate can be challenging, but we strongly suggest organisations to:

• Enable Multi-Factor Authentication (MFA) for all remote access
• Enforce strong password policies, proper Active Directory-based mechanisms, or a managed password solution to protect Domain Administrators account
• Tighten cloud file storage usage, some solutions offer built-in micro segmentations that can help prevent attackers accessing your data
• Consider employing Managed Detection and Response services to automatically and proactively mitigate threats in a 24/7 manner

Indicators of Compromise

Host-based

Filename	MD5	Description
payload.txt	f5dd8644b011a6ecaf405ee9bc5c6852	Cobalt Strike implant callback
beac.exe	500286eaf9eb11b34eb413bb0df5543b	Cobalt Strike implant callback
55.exe	500286eaf9eb11b34eb413bb0df5543b	Ransomware
Beta.exe	90e6ea15ed18005b431e135186d57abf	Ransomware

Network-based

Value	Description
82.31.145[.]121	Infiltration IP
94.7.101[.]89	Infiltration IP
158.174.247[.]194	Infiltration IP
212.80.217[.]174	Call back IP
51.83.165[.]21	Call back IP
fairyschool[.]art	C2 domain for baec.exe

Feel free to contact us at [darklab dot cti at hk dot pwc dot com] for any further information.