FCSC2023 - APT Style
This following challenge of the FCSC was divided into 7 parts. It was not the hardest but a very cool one. We had to find a persistence mechanism within a Windows installation ISO. Then, deobfuscating a PowerShell script, retrieving a binary that was no longer available on GitHub, and reversing it to find C2 connection information.
As a CISO, you anticipate
latethe migration of the user workstations in your fleet to Windows 10. To do so, you ask one of your colleagues to prepare an installation ISO, and due to the critical importance of the safety of this installation medium, you decide to test it. You notice strange behaviors on the newly installed machine… You then decide to dissect this ISO to understand where these behaviors are coming from.SHA256(
Win10_22H2_French_x64.iso) =6b308977cecc9b6d8aa50a8ddabdacdf01394b0819d5978141ed61862c61143f.
APT Style 1/7
Description
What object triggers the malicious behavior? The expected answer is the object’s path.
What group of attackers employs a similar method? The expected format is UNCXXXX.
The final flag is in the format FCSC{<path>:UNCXXXX}
Resolution
First, instead of installing the ISO, we will mount it with WinCDEmu.
To determine which files have been modified on the ISO, we will use Hasher, to calculate a hash for each file present on the mounted disk.
We found sites online that allow us to download ISOs of the same version as our ISO by searching for the name of our ISO, which contains the version. To ensure that we have a version provided by Windows, we can check the hash of the file. Then, we mount the ISO in the same way as before and use Hasher to calculate the hashes.
Next, we will compare the hashes present on the two disks. We notice that the only different file is install.wim. This file is a Windows deployment image file that is used to store a complete image of a Windows installation.
|
|
It is possible to mount this type of file with dism (Deployment Image Servicing and Management). We directly launch KAPE to save time on the extraction and parsing of IOCs.
|
|
Now that we have retrieved and parsed the artifacts, we can look for the answers to the question. In the statement, we are talking about a path without giving an example of a path on the disk as a flag format. If we have already done some forensic CTFs, we can easily guess that it will be a registry key.
If the statement, had been about a file on disk, a quick win could be to look at the last modified files.
1PS > Dir C:\temp -r | ? {! $_.PSIsContainer} | sort LastWriteTime | select -last 10
We use Registry Explorer from Eric Zimmerman, to look at the last modified registry keys in the SOFTWARE and SYSTEM hives, which are often used for persistence on the system and not tied to a specific user. The only keys modified after September 8th are Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\Microsoft\Windows\Speech\SpeechModelDownloadTask and Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks\{4D595DA6-BC59-47AE-A527-EC01FCE2E615}. These two objects correspond to a scheduled task.
Going to the second key, we get the launch path of the task \Microsoft\Windows\Speech\SpeechModelDownloadTask.
Finally, to find the attacker group, searching for windows installer backdoor APT leads directly to the Mandiant article on the UNC4166 group, which also uses schedule tasks as a backdoor in Windows installers.
Flag
FCSC{\Microsoft\Windows\Speech\SpeechModelDownloadTask:UNC4166}
APT Style 2/7
Description
What element was removed to hide this malicious behavior from Windows? The expected answer is the path of the removed element.
What group of attackers employs a similar method? The expected answer is the name of the group.
The flag is in the format FCSC{<path>:<group name>}.
Resolution
To answer this question, we searched for hide schedule task windows and quickly found an article by Qualys that indicates it is possible to make a task “invisible” by deleting the SD key in HKLM\Software\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\<TASK_NAME>. It also mentions that the group HAFNIUM uses this technique.
We can confirm this lead by going to HKLM\Software\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\Microsoft\Windows\Speech\SpeechModelDownloadTask where the SD key is not present.
Furthermore, we can find the key and its content in the deleted keys.
Flag
FCSC{\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\Microsoft\Windows\Speech\SpeechModelDownloadTask\SD:HAFNIUM}
APT Style 3/7
Description
What file is used as the base for timestomping the malicious files? The expected answer is the full path of the file in the format : FCSC{<path>}.
Resolution
To retrieve the filename used for timestomping, we first need to get the content of the scheduled task in HKLM\Software\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks\{4D595DA6-BC59-47AE-A527-EC01FCE2E615}\Actions
|
|
The scheduled task downloads a script OneDriveUpdater.ps1 (below) from Github and executes it.
|
|
We can copy all the parts with reordering (without potentially dangerous Invoke) and look for the corresponding string:
|
|
We modify the script accordingly to the output.
|
|
The script will modify the timestamp on the folders and files in the files variable using the values from C:\Windows\win.ini for the timestomping.
Flag
FCSC{C:\Windows\win.ini}
APT Style 4/7
Description
What technique is used by the attacker to execute the malicious payload? The expected answer is the complete ID of the technique in the MITRE ATT&CK matrix format: FCSC{TXXXX.XXX}.
Resolution
To identify the technique used to run the payload, we refer to the MITRE Hijacking, since it involves DLL hijacking. In particular, we find the DLL Search Order Hijacking technique used here because we place our DLL in the same folder as the executable, which first searches for the DLL to load in memory in the same path as itself
However, in my opinion, the correct answer should have been
T1574.002(see below). Adversaries may execute their own malicious payloads by side-loading DLLs. Similar to DLL Search Order Hijacking, side-loading involves hijacking which DLL a program loads. But rather than just planting the DLL within the search order of a program then waiting for the victim application to be invoked, adversaries may directly side-load their payloads by planting then invoking a legitimate application that executes their payload(s).
Flag
FCSC{T1574.001}
APT Style 5/7
Description
Note: It appears that the attacker has removed the malicious DLL from their online directory… The administrator who observed the malicious behavior installed it on 15/03/2023.
What is the serial number of the certificate used to sign the malicious DLL? The expected answer is in the format FCSC{<serial number>}.
Resolution
To find the malicious DLL that has been deleted, we go to the Github repository to potentially find traces of the file in the commits. However, in this case, there is only one commit.
Using web.archive.org, we found a snapshot from March 15th with different commit dates than in the current repository.
According to the previously viewed PowerShell script, the malicious DLL is version.dll. It can be verified by calculating the hash of the other DLL and checking the signatures on VirusTotal.
Finally, to retrieve the serial number of the certificate, the following command is performed:
|
|
Flag
FCSC{43BB437D609866286DD839E1D00309F5}
APT Style 6/7
Description
Note: It appears that the attacker has removed the malicious DLL from their online directory… The administrator who observed the malicious behavior installed it on 15/03/2023.
Which machine is targeted by the malicious payload? The expected answer is the machine name in the format FCSC{<name>}.
Resolution
By opening the DLL in IDA, we can find the name of the targeted machine. Alternatively, using strings also works well.
Flag
FCSC{DESKTOP-3BY599R}
APT Style 7/7
Description
Note: It appears that the attacker has removed the malicious DLL from their online directory… The administrator who observed the malicious behavior installed it on 15/03/2023.
Which C2 is contacted by the malicious payload? The flag is in the format FCSC{IP:PORT}.
Resolution
The easiest way to solve this challenge is to take a snapshot of a VM, rename it toDESKTOP-3BY599R (don’t forget to disconnect it from the Internet just in case), and launch Wireshark. Then, in a folder that must include version.dll and verslon.dll, run OneDriveStandaloneUpdater.exe.
The legitimate DLL
verslon.dllis necessary because by looking at the exports table we can see that the DLL acts as a proxy.
We observe the traffic in Wireshark, which allows us to obtain the IP and port.
The other way to do it is to reverse engineer the application.
At the start of the DLL, the program first calls the GetModuleHandleA function to obtain a handle to the ntdll.dll module. It then calls GetProcAddress several times to obtain pointers to various functions defined in ntdll.dll, including ZwOpenProcess, wCreateSection, NtMapViewOfSection, ZwCreateThreadEx, NtDelayExecution, and ZwClose.
Next, the program creates a snapshot of the running processes on the system using the CreateToolhelp32Snapshot function. It then iterates through the list of processes using the Process32First and Process32Next functions. For each process, it checks if the process executable file name matches RuntimeBroker.exe. If it does, it opens a handle to the process using ZwOpenProcess.
Then, there is an XOR operation between the key nljM8AUq0Bb4LU9L7BhfrycmTwum and the shellcode that will be executed.
Optimization seems to give trouble to IDA which does not detect the correct variable associated with the shellcode buffer.
We use CyberChef to decrypt the shellcode.
By opening it in IDA, we obtain the IP and port of the C2.
Flag
FCSC{192.168.56.1:1337}