Introduction Link to heading

This lab is an emulation of Alphv/BlackCat ransomware group where we are faced with a ransomware breach with techniques including VPN and MFA compromise, ransomware & C2 deployment, credentials stealing, local privilege escalation and lateral movement. On these lab we are provided with a Windows 11 VM prepped with a bunch of forensic related tools and evidences including ELK SIEM instance access to search across all the logs provided (Azure logs,Windows Event logs ), Triage Image which represent the filesystem of the host at recorded date and cvs file listing filenames and associated metadata such as timestamp, hashes,size etc and lastly we have ProcessedEvidences that contains bunch of csv files that came from EricZimmerman tools output such as registry hives, parsed event logs, master file tables and many others.

I decided to take this lab because i’m interested in the threat hunting or DFIR in general field in general and this lab sounds like a great target to sharpen my skills into these fields.

Lab overview Link to heading

“Here is an overview of the lab’s scoping notes:

Waifu University's cyber team has called you after their IT teams reported a number of servers with files that 
aren't opening and have a strange extension.

On your scoping call, the victim also said they had identified a ransom note stating their data has been stolen. 
When asked about any earlier signs, the victim mentioned some strange, failed login activity early in March 2024
in their Entra ID, but wasn't of concern at the time...

Ransomware will typically avoid system files to not cause crashes in the system, which also happens to be where 
a lot of forensic evidence is! You have been provided triage images of the hosts and log exports from the 
relevant systems.

The Waifu University team took triage collections from the affected hosts using the account WAIFU\kscanlan6 at 
approximately 2024-03-07 05:00:00 UTC. Consider activity after this point related to the response.

Additionally, we have the network diagram of the infected part of the Waifu University network:

Chain of events Link to heading

The attack consisted of four main phases:

Phase 1 - Initial Access and Foothold : The threat actor initiated the attack by first compromising an Azure account of an employee through bruteforce and MFA fatigue attack, gaining access to the jumpbox server in the Waifu University network.

Phase 2 - Lateral Movement : The threat actor used several privilege escalation techniques and the Cobalt Strike platform, to move laterally between the victim’s hosts and Azure environment through RDP connections.

Phase 3 - Data Exfiltration and Additional Lateral Movement : The threat actor compromised other servers on the network, such as the domain controller and SQL server, from which it can exfiltrate sensitive data.

Phase 4 - Extortion Attempts : The ransomware is deployed by the threat actor that urged Waifu University to ‘act quickly’ , likely threatning them to pay a ransom otherwise it will publish sensitive information such as Employee personal data or private financial information …

Phase 1 - Initial Access and Foothold Link to heading

Initial Access via Entra ID Link to heading

Our security team mentioned that there was a number of failed logons to the victims Identity Provider (Entra ID). To begin the investigation, we must examine failed logon attempts as they can indicate potential unauthorized access attempts.

On march 3rd around 11:01 to 11:54, several failed logon attempts were identified in the Azure logs. These attempts can be identified through the sign-in error code 50126: Error validating credentials due to invalid username or password.

The threat actor attempted to authenticate on 8 distinct account :

The fact that all authentication attempts share the same user agent can indicate that these authentication attempts was performed by the same person: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36.

On the same logs , we can also determine that the threat actor’s location is from the USA.

What we can also see is each authentication attempt was made from a different IP address, all of them share a similar pattern : 3.12.21*.*

A whois lookup reveal that he threat actor used Amazon AWS as a cloud provider to proxy their requests.

Now that we’ve identified several failed logon attempts, one question remains : did one of these attempts resulted in a successful authentication ? As you might guess the answer is yes.

To find the succeed authentication, we will filter out signin error code 50126 which, as previously seen correspond to failed logon attempts. Also, we can filter out the signin error code 0 too because it indicate an authentication requirement already satisfied.

While searching for signin error code 0 seems like a good approach at the first glance, in practice it generate a large amount of logs related legitimate users already authenticated or system and services accounts , thats why we filter these out to reduce the number of logs and focus on relevant one and i will repeat the process during the entire lab, If at any point i filter out data without explicitly stating why, it is most likely to reduce the volume of logs generated.

Since our earlier analysis suggests the threat actor is operating from the USA, we will use that information and apply it as additional filter.

This query gives us a lot of useful information First, the most frequently targeted user name is Ignazio Vanderplas with User Principal Name (UPN) is ivanderplas1@waifu.phd. Secondly, majority of logs correspond to signin error code (Authentication failed during strong authentication request) which has the following authentication details in message field of the logs:

"authenticationDetails": [
    {
      "StatusSequence": 0,
      "RequestSequence": 1,
      "authenticationMethodDetail": "Pass-through Authentication; PTA AgentId: 75ce5fbc-5cce-4eb4-b7b5-ba626f27c778",
      "authenticationMethod": "Password",
      "authenticationStepDateTime": "2024-03-03T11:52:29.8355168+00:00",
      "authenticationStepRequirement": "Primary authentication",
      "succeeded": true
    },
    {
      "authenticationStepDateTime": "2024-03-03T11:52:29.8355168+00:00",
      "authenticationStepResultDetail": "MFA required in Azure AD",
      "authenticationStepRequirement": "Primary authentication",
      "succeeded": false
    }
]

That indicate the threat actor managed to pass the authentication with password. however, the legitimate account owner received a MFA notification on his phone and did not respond to it, preventing the threat actor to gain access to his account.

One hour later, at 13:02:12, we can observe in the logs a signin error code 50140 : This error occurred due to ‘Keep me signed in’ interrupt when the user was signing-in. By examining the logs message fields, we find the following authentication details:

"authenticationDetails": [
    {
      "StatusSequence": 0,
      "RequestSequence": 0,
      "authenticationMethod": "Previously satisfied",
      "authenticationStepDateTime": "2024-03-03T13:00:17.9135895+00:00",
      "authenticationStepResultDetail": "First factor requirement satisfied by claim in the token",
      "authenticationStepRequirement": "Primary authentication",
      "succeeded": true
    },
    {
      "authenticationMethod": "Mobile app notification",
      "authenticationStepDateTime": "2024-03-03T13:00:17.9135895+00:00",
      "authenticationStepResultDetail": "MFA completed in Azure AD",
      "authenticationStepRequirement": "Primary authentication",
      "succeeded": true
    }
]

Thats means that this time the account owner accepted the MFA notification, allowing the threat actor to authenticate successfully.

The threat actor used a technique know as MFA Fatique which involves flooding the victim of MFA request until one of these request is eventually accepted by the victim.

Looking the same logs on the properties field, we can see the ip used is 207.246.70.192

Using the following command on my terminal reveal the ssh fingerprint of this host:

ssh-keyscan -t ecdsa 207.246.70.192 | ssh-keygen -lf - -E md5

This fingerprint associated with this IP address is 97:2e:5d:5e:ca:d1:15:a9:51:ed:8b:0e:55:f1:6a:ee (ECDSA)

Breaching the University Link to heading

With the initial access point identified (compromise of Azure account of an internal employee), we will now investigate the threat actor’s first actions post-authentication.

Examining windows logs and filtering success authentications (event code 4624) for user ivanderplas1 just after the account compromise at 13:00, we find the nearest authentication event linked to the host CC-JMP-01, the jumpbox server. Additionally, the logs reveal the workstation name used which is 283d12e66790

The Microsoft Edge browsing history reveals that, upon accessing the host, the threat actor searched what is my ip and then go to the website whatismyip.com

Following the account compromise, the breached user initiated a PowerShell process that performed a DNS query.

To determine which domain was queried, we can examine Windows event logs (.evtx files) which can be found at C:\Windows\System32\winevt\logs\.

More specifically, we have to look at Sysmon event 22: DNSEvent on the sysmon log file Microsoft-Windows-Sysmon%4Operational.evtx Since i don’t like the default event viewer for this task, we will use Chainsaw, a powerful Windows event log parser, to extract relevant information efficiently.

The DNS query reveals a request to github.com, likely indicating that the attacker may have cloned a repository from GitHub.

To get more information, let’s look at Powershell history on Microsoft-Windows-PowerShell%4Operational.evtx event file:

The repository https://github.com/Flangvik/SharpCollection was cloned, with particular interest in SharpHound, a data collector for BloodHound written in C#.

Phase 2 - Lateral Movement Link to heading

Privilege Escalation Link to heading

We were informed by one of our analysts that the threat actor was querying service-related information on the beachhead host. Soon after, it seemingly obtained administrator access.

A few hours after cloning the GitHub repository, starting at 17:46, the threat actor ran several unusual commands.

Researching about these command led us to this article which is related to local privilege escalation in Active Directory written by xapax.

The privilege escalation technique shown on the logs above is called “unquoted service path” which consist at enumerate the services with unquoted path that contains space and then replace the binaries.

The logs likely indicate the use of the ‘unquoted service path’ privilege escalation technique. This method consists of enumerating services with unquoted paths that contain spaces and substituting their binaries to execute malicious code with higher privileges.

Let’s say you have a service path which is : C:\Program Files\vuln app\service.exe When windows attempt to start this service, it will check the following folders in order: 1 - C:\Program.exe 2 - C:\Program Files\vuln.exe 3 - C:\Program Files\vuln app\service.exe => the correct one In this example, the attacker can create a malicious programs at C:\Program.exe or C:\Program Files\vuln.exe that will be executed instead of the legitimate service.

The threat actor identified vulnerable services by executing findstr and wmic service get commands and they found Waifu Service, a misconfigured service that was subsequently hijacked.

Then, this service was started using the command net start “Waifu Service”.

The MITRE ATT&CK Framework classifies this technique as T1574.009 : Hijack Execution Flow: Path Interception by Unquoted Path.

To gather more details about this service, we searched the Windows event logs for all command lines containing the keyword ‘Waifu’:

As you can see in the logs, the service path for this waifu service is C:\ProgramData\Waifu Service\Waifu Bin\WaifuSC.exe, making it vulnerable to privilege escalation via an unquoted service path. The threat actor exploited this misconfiguration by placing his own malicious binary at C:\ProgramData\waifu.exe which was executed as NT AUTHORITY\SYSTEM (equivalent as root but for windows environment). This allowed them to hijack execution of the legitimate service which is located at C:\ProgramData\Waifu Service\Waifu Bin\WaifuSC.exe.

The hash of this binary can be found in the TriageImage evidence that we have acess to for the host CC-JMP-01, as this is where the binary was discovered. In these evidences, we will search inside the 2024-03-07T06_24_58_9181434_CopyLog.csv file because its less clicks than locate the binary and generate hash with powershell :D

Remote access Link to heading

Since we know the threat actor successfully executed a service with elevated privileges, let’s investigate further.

Few secondes after the execution of the malicious service, the threat actor established remote access using the ScreenConnect tool.

By looking closer at the commandline, we notice that the remote access tool communicated with the domain instance-i77ws2-relay.screenconnect.com.

Once the threat actor was able to escalate their privileges on the beachhead host, they ran an interesting payload.

The threat actor used the Windows File Manager trough ScreenConnect to modify the python binary located at C:\Program Files\Python312\python.exe.

Due to hash change that we can notice below, the threat actor has likely replaced the binary by his malicious payload.

Unfortunately, the sysmon event logs didn’t record any network activity due to The limitation of the configuration but we have access to a process dump of this python.exe binary.

While investigating about this binary, we find out that it was a Cobalt Strike Beacon.

By using CSCE tool (Cobalt Strike Beacon configuration extractor and parser) we can extract interesting information:

• The beacon was talking to the following ip: 207.246.70.192, the same IP we saw before
• The domain the beacon uses in the host header is screenconnect.dev

Phase 3 - Data Exfiltration and Additional Lateral Movement Link to heading

Accessing Volume Shadow Copies Link to heading

At 2024-03-05 at 21:23:17 the threat actor managed to access a volume shadow copy of the beachhead host. Based on the parent command line, this volume shadow copy was created by the following file : \663bc8c1-f975-4a03-ad75-02145ad1b7c4run.cmd.

Unfortunately we don’t have access to this file for further investigations on it since it was located on temp folder.

Looking Around The Network Link to heading

The logs indicate that the threat actor gained access to a network share, to get more information we filtered the logs using the event code 5140: a network share object is accessed.

Once we identified the share name, we ran a broader search for all command lines that interacted with this network share.

As seen in the logs, the threat actor successfully accessed a file named you-cant-see-this-cause-I-am-good-at-NTFS-permissions.txt .

Going back to the Cobalt Strike beacon, we can notice a file creation of Sharphound.exe , the data collector for Bloodhound already seen before. But after further investigation, there is no evidence that prove this tool was used.

Filtering the logs for event ID 4799: A security-enabled local group membership was enumerated, reveal that the threat actor enumerated the Administrators group.

Domain Dominance Link to heading

Earlier in this lab, we observed the threat actor exploiting a vulnerable service. Now, let’s see if any other services were installed. To do this, we can filter the windows logs using event ID 4697 : A service was installed in the system.

There are many services installed but one of them stand out due to unusual name: 8628f7b which was installed on the domain controller

Shortly after the service was installed,the threat actor managed to authenticated as CC-ADMIN on the Domain Controller, a key indicator that this authentication was done by the threat actor is the workstation name parrot.

This workstation name is associated with parrot OS which is a linux distribution based on Debian which is designed for security and privacy purposes. Fun fact, this is the distribution that i use personally.

Once the threat actor pivot to the domain controller, he used a tool called InjectDLL.exe from AADInternals, to inject the dll PTASpy.dll into another process that has pid 3616.

It appears that the threat actor exploited Azure AD PTA vulnerabilities to establish a backdoor and harvesting credentials.

If you are interested to learn more about this technique, i highly recommand to read this article which provide a deeper explanation of this technique.

In the article that i linked just above, we can find a link to the script install-PTASpy.ps1 which did exactly what we saw before according to the description.

Going back to the previously observed commands in the logs, now that we know the PID of the injected process (3616), we can search in the logs for the sake of confirmation.

As you can see, the process with PID 3616 (0xe20 in hex) is AzureADConnectAuthenticationAgentService.exe

This script also indicate that the credentials collected are written to the file C:\PTASpy\PTASpy.csv

On Mar 7, 2024 at 03:17:21.567, the threat actor accessed the stolen credentials.

By looking at the Entra ID login events in the Azure logs that occurred after the threat actor accessed CSV file containing the stolen credentials, we can deduce that the account cpecht7@waifu.phd was likely compromised.

Accessing the Good Stuff Link to heading

In the meantime, the threat actor also managed to gain access to the SQL server, as cc-admin user trough RDP (Remote Desktop Protocol) connection. One way to identify these RDP connection is by filtering the logs with event ID 1149 : Remote Connection Manager

Then, we got informed that the admins noticed a strange file in the documents folder of the admin user for the SQL server which was created during the intrusion.

To get more information about it, we can leave the SIEM and take a look at other evidences that we have, one of these are a output of parsed MFT which contains index of all files and directories on an NTFS drive, storing metadata like filenames, sizes, timestamps, etc …

Once we identified this filename as database.bak.rpt we can track the NTFS Entry ID changes in the USNJrnl ($J). By doing that, we are able to identify that the earliest MFT Entry ID for the file name is 369707 and was created March 07, 2024 at 03:09:24.

Phase 4 - Extortion Attempts Link to heading

Release the Ransomware UwU Link to heading

After filtering out irrelevant processes, we identified that print64.exe was executed shortly after the file’s creation, using the access token uwuwuwuwuwuwuw as an argument. This makes me wonder if the access token is necessary to just launch the binary or is it used as a key ? sadly, in the context of this lab i cant pull out the binary out of the virtual environment to analyze it through disassembler.

By examining our forensic evidence containing the filesystem (TriageImage of the Domain Controller), we identified a folder corresponding to the previously accessed network share. Within this folder, we discovered a .bat file which will just execute the ransomware with the access token.

Still exploring the file system on the Domain Controller with our Triage Image evidences, by navigate to the Downloads folder ot the CC-Admin user on the Domain Controller, we can see a text file that contains the instructions for the ransomware, it’s a classic for a ransomware that will probably ask the Waifu university to pay a ransom otherwise they will publish a sensitive informations.

Conclusion Link to heading

This APT emulation lab provided a practical material about investigation into a ransomware breach, emulating tactics used by the Alphv/BlackCat ransomware group. The exercise reinforced key aspects of threat hunting and forensic analysis, from identifying initial access vectors to tracking lateral movement, privilege escalation, data exfiltration, and ransomware deployment.

This lab served as an excellent opportunity to sharpen my forensic skills, making me more familiar with Azure and windows event logs, enhanced my ability to corelate event trough different data sources and discover quite useful tools suck as chainsaw used in this writeup and Eric Zimmerman utilities which was used by the lab creators to provide evidences.

I strongly recommend this platform to anyone interested in DFIR or threat hunting. The labs are well-designed, offering high-quality training at an affordable price. You can even start with a trial to see if it suits your needs. I completed this lab during my trial period and was so impressed that I’ve decided to subscribe and explore more labs.

Many thanks to the team that designed this lab !

References Link to heading

https://www.sygnia.co/blog/blackcat-ransomware/ https://cloudbrothers.info/en/entra-id-azure-ad-signin-errors/ https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/ https://learn.microsoft.com/en-us/entra/identity/monitoring-health/quickstart-analyze-sign-in https://stackoverflow.com/questions/71105618/how-to-compare-a-remote-host-fingerprint-to-the-fingerprint-of-a-different-host https://answers.microsoft.com/en-us/microsoftedge/forum/all/where-is-the-file-for-edge-history-stored/a6102594-d7ee-420d-afaa-77f2fc82b3ce https://xapax.github.io/security/#attacking_active_directory_domain/local_privilege_escalation/local_privilege_escalation/ https://attack.mitre.org/techniques/T1574/009/ https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc788055(v=ws.11) https://aadinternals.com/post/pta/ https://research.splunk.com/endpoint/ceaed840-56b3-4a70-b8e1-d762b1c5c08c/ https://blog.haboob.sa/blog/advanced-usn-journal-forensics