This post contains a writeup, as well as my overall experience at C3X Dark Cloud Rising.

About

C3X Dark Cloud Rising took place over the course of May 1st and 2nd. This CTF was not a traditional puzzle-solving CTF, but an attack/defend type CTF where each team would play the role of Incident Response for a fictional company that just got attacked. 5 Teams representing Seneca College, Fanshawe College, Sheridan College, Mohawk College, and the Univeristy of Ottawa attended, with me and some friends representing the Seneca team.

Each team was responsible for hunting down threats, as well as providing live status update meetings to the competition organizers (as well as some volunteers) that played the “Business Team”, which represented the company. Winning the competition meant we had to solve as many challenges as possible, as well as give informative and professional status updates to the business teams.

Each team was given a console (graciously sponsored by Elastic), which had both a Kibana instance as well as a Kibana Security SIEM instance. There were a few challenges that required the use of Azure Sentinel, which was also provided. Along with these tools, challenges were laid out on CTFd in the format of Level 1, Level 2, and Level 3, according to the timeline in the following scenario.

Note: This was not a live environment, but a log replay.

Scenario and Challenges

Going into the competition, we were given access to the Kibana’s, and no knowledge of what’s going on. Our goal initially was to look for any signs of threats which correlated with the challenges on CTFd.

Level 1

Level 1 challenges required threat hunting to be done on the Windows 10 Workstation, where initial access was given to the attacker. Shortly into the first few minutes, we found a malicious Excel file that had Macro’s enabled. This file created a reverse shell connection to a machine on the internet, and was originally sent via a spear-phishing email to the user tturner, who ended up opening it through OneDrive. It was unclear if tturner's credentials were compromised, as we found no evidence of any suspicious logons with his account.

Once the attacker got initial access, they started downloading additional malware that would run various console commands to gather network information (Note the clever use of shortened Cmdlets to help avoid detection).

For persistence, the attacker created a Scheduled Task that would continuously install the malware , as well as added a registry key that would run the malware on startup.

This showed us that the user helpdesk-admin had been compromised. It is likely that tturner didn’t have administrative privileges on this machine, since the attacker supplied credentials for the helpdesk-admin user to create the Scheduled Task. Both these persistence mechanisms would run the ZoomInstaller.exe malware, along with Command-line arguments specifying a C2 server and port.

We discovered that ZoomInstaller.exe launched the actual Zoom executable, as well as created three separate reverse shell connections to the C2 server.

Level 2

Level 2 has now begun, as the attacker began performing additional reconnaissance and looked for ways to escalate privileges to get around the network.

We found common reconnaissance commands being ran manually, as well as findstr.exe to look for potential cleartext password files.

These efforts to find credentials were successful, as the attacker began accessing a file named Creds.txt, which is likely where the credentials for a user stennant were compromised, as well as the IP address of another machine.

It turns out that all of this information is being written to a file manually, named sales_report.txt.

Once this file is written to, it is archived and exfiltrated via SCP. We see the attacker creating an SSH key before exfiltrating.

Later we find more privilege escalation to a new account named jsmith, through the use of a script that would replace a native Windows script in C:\TaskScripts. Before the script was replaced, we saw the attacker enumerating the permissions for that directory using the Get-ACL cmdlet, and it is implied that helpdesk-admin had permissions to modify files.

The attacker used curl to download a tool known as procdump (originally from sysinternals) from their server.

Around this time we also noticed the attacker creating a new user and adding them to the local administrators group for persistence. We needed to take note of this fraudulent user (msendak) for triage at the end of the investigation.

Now back to the binary. procdump was downloaded directly into the TaskScripts folder and was executed by Task Scheduler to dump lsass.exe which gives the attacker access to an abundance of information, but most importantly usernames and passwords.

Since procdump is a Windows binary, its likely that it wasn’t flagged by Windows Defender or any other AV on the machine. After lsass was dumped, it was exfiltrated to the attackers server and cracked to reveal some credentials.

A bit later, we see that an RDP session was created using the jsmith account to another machine named jumpbox. It was clear that the jsmith account was now compromised, as well as another machine on the network.

Once on jumpbox, the attacker begins performing a ton of reconnaissance activity through Powershell. Every possible recon cmdlet that you can think of was ran.

This ended up being the result of a popular tool named PowerView being ran shortly after it was downloaded onto the box.

All of the standard output from these recon commands were placed into a file named AD_file, which can be found being exfiltrated after all the commands were finished running.

With all this information, the attacker now has extensive knowledge about the company’s Active Directory environment, and is planning their attack around the infrastructure. Level 3 begins with the attacker making their way onto another box on the second network named research.

Level 3

The first thing the attacker does after getting access to the research machine is downloads more malware off their server.

It was confusing to see how this malware was ran, because it wasn’t ran by any user. After more investigation, it turns out that there was a misconfigured service running on research, which was setup using NSSM. This service would run the file file.bat in C:\MyServicePath\. However, it had weak permissions which allowed the attacker to modify the file in any way and restart the service.

Judging from the logs, it was certain that the attacker ran Mimikatz as SYSTEM through this misconfigured service to escalate privileges.

Shortly after execution, we noticed that jsmith created a new session as ahu.

Checking ahu's previous logs before the breach (as well as close cooperation with the business team), we figured out that ahu was not only the CITO of the company, but also a domain admin.

The attacker was able to log into ahu's account as a result of the mimikatz malware being ran (mmdelta.exe), and her credentials ended up being stored as plain text.

Shortly before logging into ahu however, another attack was done to the AD that was unsuccessful.

It turns out that alongside Mimikatz, the attacker attempted to perform a Kerberoasting attack as well as DCSync.

As seen above, the attacker downloads a malicious toolkit named Rubeus, and begins the Kerberoast attack. We were able to see eight Kerberos tickets being requested as a result of the toolkit running.

One clear-cut IOC I found detecting these ticket requests was the change in encryption type. It seems that in our case, the Rubeus toolkit was requesting tickets with a weaker encryption type to more easily crack the Kerberos hash. In our case, we mostly saw ticket requests with encryption type 0x12 (AES256-CTS-HMAC-SHA1-96) before the attack. After the attack, we saw forged ticket requests with the encryption type 0x17 (RC4-HMAC).

What followed up was a DCSync attack. We noticed this by seeing the attacker use their Replicating Directory Changes permission by filtering for a unique GUID.

With this attack, the intention seemed to be to generate a Golden Ticket to the environment by targeting the krbtgt user.

However, no actual evidence of a Golden Ticket being generated successfully was found, which meant that this attack was unsuccessful. This ended up being the correct answer to a very stressful CTFd flag that only allowed one attempt. After finishing our investigation for this attack, we went back to monitoring ahu's account to see what was going to be done next.

Now that ahu's account is compromised, the attacker can do virtually anything they want on the AD network. At this point, the attackers motive was revealed.

We found multiple Git commands being run as both jsmith and ahu with a subtle difference.

The attacker was trying to edit some code in Project709\709\our-sat-code\scripts\, and push the changes. However, jsmith lacked the permissions to push code onto the git repo, and instead had to have ahu push the changes.

No successful git pushes were actually found though, even with ahu's account. To take a closer look, we used the Azure Sentinel instance that was provided.

Multiple failed sign in attempts were detected, as the user did not pass the MFA challenge.

Azure Sentinel provided us with some additional information as well, such as the User Agent of the logins and the source IP of the login.

At the end of the day, the attacker was unsuccessful in their initial objective, which was to modify the source code for one of the company’s repo’s. There was no evidence of project code exfiltration, but that does not mean that the attacker didn’t see the proprietary code.

Once we the investigation was fully complete, we planned out and presented our triage plan to remediate all the damage the attacker had done to the company network, this was our final business meeting before the competition ended.

Results

After a very close battle with Fanshawe college, our school (Seneca) finished first with a steady lead.

End of Day 1

End of Day 2

Our team finished all of the challenges on CTFd and wiped the entire scoreboard.

Additional Statistics

In the end, our status updates with the business teams netted us only a few points behind Fanshawe College.

Some questions were very stress inducing, such as 0x12 To Be or Not To Be, which asked us if a Golden Ticket was created with only one attempt allowed to asnwer the question. Even though all of the IOCs showed that a DCSync attack was underway, and the krbtgt account was targeted, we couldn’t find any evidence of a Golden Ticket being created, and had to confidently answer the question as “no” despite the possibility that we may have missed something.

This was a great training exercise that helped prepare us for the real world, as many situations require you (as a SOC or IR analyst) to find evidence of something before making any claim or assumption, and to believe in your abilities.

All in all, this CTF was a fantastic learning experience and I would attend it again if I wasn’t graduating. Maybe I’ll attend some similar competitions in the future, I heard OpenSOC is pretty good.