This is a write-up of the DetectLog4j challenge by Cyberdefenders. The challenge can be found here.
Scenario
For the last week, log4shell vulnerability has been gaining much attention not for its ability to execute arbitrary commands on the vulnerable system but for the wide range of products that depend on the log4j library. Many of them are not known till now. We created a challenge to test your ability to detect, analyze, mitigate and patch products vulnerable to log4shell.
Tools used for this challenge
- Autopsy
- VirusTotal
- Cyberchef
Write-up
Question 1 - What is the computer hostname?
To try something new and mix up the tooling used for maximum learning experience, I decided the give Autopsy a shot.
When loading in the image Autopsy will parse the operating system information. The operating system information shows that the hostname of the computer is vcw65.
An alternative way of getting the hostname of the computer is using a tool like Registry Explorer and view the following key in de SYSTEM registry hive: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ComputerName\ComputerName
Question 2 - What is the Timezone of the compromised machine?
Something really cool I learned is that you can view the registry hives with Autopsy. The timezone information is stored in the SYSTEM registry hive, which is located in Windows\System32\config.
Open the hive and go to ControlSet001 and click on TimeZoneInformation, this shows the TimeZoneKeyName is Pacific Standard Time.
Since most forensic reports use the UTC timezone, I assumed we need to convert PST to UTC.
As shown in the picture below the time difference is 8 hours, so the right answer is UTC-8.
Question 3 - what is the current build number on the system?
Autopsy was used to view the SOFTWARE registry hive, which contains information about the build number. The product version information including the build number is stored in the following key: HKLM\Software\Microsoft\Windows NT\CurrentVersion
As shown in the picture below this key provides product version information, including the build number.
Question 4 - what is the computer IP?
The answer to this question can also be found in the registry. The IP addresses of the various network interfaces are stored under:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces
As shown in the picture below the IP address is 192.168.112.139.
Question 5 - What is the computer IP?
This information can be found in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters as shown in the picture below:
Question 6 - When was myoussef user created?
When loading in the image Autopsy will parse the OS Accounts information, which show the creation time of the different user accounts.
OS accounts information show that myoussef was created on 2021-12-28:07:57:23 CET. However, this was the wrong answer, the timestamp first had to be converted to UTC. The right answer to this question is: 2021-12-28 06:57:23 UTC
Question 7 - What is the user mhasan password hint?
The answer to this question can be found in the same Autopsy view as used for question 6.
As shown in the picture below the password hint is: https://www.linkedin.com/in/0xmohamedhasan/
Question 8 - What is the version of the VMware product installed on the machine?
This question can easily be answered with Autopsy. All the installed programs are parsed and will be shown with one click. After clicking on Installed Programs (89) search through the list until you find the VMware products. As shown on the picture below the version is: 6.7.0.40322.
Question 9 - What is the version of the log4j library used by the installed VMware product?
VMware published an article on its products being vulnerable to log4j and how to mitigate the risk: According to the article the vulnerable library should be stored in the following location: C:\Program Files\VMware\vCenter Server\common-jars\log4j-core-2.11.2.jar
If we navigate to this directory the following files are present:
As described in the article the vulnerable library </b>log4j-core-2.11.2.jar</b> is being used by VMware. An alternative way of finding the log4j library would be by using one of the many open source scanners. The GitHub repository of NCSC-NL has a lot of the available scanners.
Question 10 - What is the log4j library log level specified in the configuration file?
After a bit of searching on Google I found a website describing a file named log4j.properties. The website said the following over this properties file: The log4j.properties file is a log4j configuration file which keeps properties in key-value pairs. By default, the LogManager looks for a file named log4j.properties in the CLASSPATH.
This sounds like it could contain the answer to this question. An index search in Autopsy was created to locate the file and view its content. As shown in the picture below the category is set to INFO.
Question 11 - The attacker exploited log4shell through an HTTP login request. What is the HTTP header used to inject payload?
I was unable to answer this question based on the analyzed evidence. However, on Google I found a blog post describing how to the exploit log4j in the VMware product. This blog post describes that the vulnerability Is in the X-Forwarded-For header of the vCenter SSO login page. This was also the right answer to this question.
Question 12 - The attacker used the log4shell.huntress.com payload to detect if vcenter instance is vulnerable. What is the first link of the log4huntress payload?
A search was created in Autopsy to search for the substring huntress.com. The search returned 5 results, but only the websso.log and audit_events.log seem relevant.
Since the log4j vulnerability is in the SSO login page, I started with investigating the websso.log. This log contained multiple entries with the string log4shell.huntress.com. However, the first payload is: log4shell.huntress.com:1389/b1292f3c-a652-4240-8fb4-59c43141f55a
Question 13 - When was the first successful login to vsphere WebClient?
I was unable to find login information in the websso.log, so I decided to move on to the audit_events.log. According to Google the vSphere Single-Sign On process writes audit events to the audit_events.log file in the /var/log/audit/sso-events/ directory.
The first event with a successful login is shown below: [audit_events.log, 2021-12-28T20:39:29.349Z {“user”:”administrator@vsphere.local”,”client”:”fe80::7c68:4669:c33c:90a3%5”,”timestamp”:”12/28/2021 12:39:29 PST”,”description”:”User administrator@vsphere.local@fe80::7c68:4669:c33c:90a3%5 logged in with response code 200”,”eventSeverity”:”INFO”,”type”:”com.vmware.sso.LoginSuccess”}
Question 14 - What is the attacker’s IP address?
Searching through the audit_event.log the IP address 192.168.112.128 was identified, which was the correct answer to this question.
2021-12-29T01:58:58.790Z {“user”:”mlabib@VCW65”,”client”:”192.168.112.128”,”timestamp”:”12/28/2021 17:58:58 PST”,”description”:”User mlabib@VCW65@192.168.112.128 logged in with response code 200”,”eventSeverity”:”INFO”,”type”:”com.vmware.sso.LoginSuccess”}
Question 15 - What is the port the attacker used to receive the cobalt strike reverse shell?
Often Cobalt strike is deployed with a Base64 encoded PowerShell command. Before parsing all the Windows event logs, I started by simply opening Microsoft-Windows-PowerShell%4Operational.evtx to identify possible deployment with PowerShell.
In the second entry of this Windows Event Log, a remotely executed command was identified.
In this event a block of Base64 encoded code was found, which was decoded with Cyberchef. The decoded text gave some clues like the malicious IP addresses found earlier and an user-agent string.
Mandiant their speakeasy tool was used to emulate this command. Unfortunately, speakeasy was not installed in my home setup. However, it was installed in the forensic lab at the office I work. https://github.com/mandiant/speakeasy
The reverse shell was received on 192.168.112:128:1337
Question 16 - What is the script name published by VMware to mitigate log4shell vulnerability?
VMware published an article on mitigating the log4shell vulnerabilities.
Below is a snipped of this article:
IMPORTANT: vc_log4j_mitigator.py will now mitigate CVE-2021-44228 and CVE-2021-45046 on vCenter Server end-to-end without extra steps. This script replaces the need to run remove_log4j_class.py and vmsa-2021-0028-kb87081.py independently. However, it is not necessary to run if you’ve already used those in your environment.
The answer to this question: vc_log4j_mitigator.py
Question 17 - In some cases, you may not be able to update the products used in your network. What is the system property needed to set to ‘true’ to work around the log4shell vulnerability?
Apache published an article about the log4j security vulnerabilities. In this article the following mitigation measure is mentioned:
setting system property log4j2.formatMsgNoLookups or environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true for releases
The answer to this question is: log4j2.formatMsgNoLookups
Question 18 - What is the script name published by VMware to mitigate log4shell vulnerability?
The Apache article about the log4j security vulnerabilities, described log4j version 2.15.0 was the version fixing the CVE-2021-44228 vulnerability.
Question 19 - Removing JNDIlookup.class may help in mitigating log4shell. What is the sha256 hash of the JNDILookup.class?
The earlier identified file log4j-core-2.11.2.jar was extracted out of Autopsy. This file can be found in the following location: \VMWare\vCenter Server\VMWare Identity Services\log4j-core-2.11.2.jar
The cool thing about jar files is the fact you can extract the content like you can with a ZIP file. In the extracted content JNDILookup.class was identified. The SHA256 hash value was calculated by PowerShell with the command shown in the picture below.
The answer to this question is: 0F038A1E0AA0AFF76D66D1440C88A2B35A3D023AD8B2E3BAC8E25A3208499F7E
Question 20 - What is the script name published by VMware to mitigate log4shell vulnerability?
After analysing the JNDILookup.class the value java:comp/env/ was identified.
Question 21 - What is the executable used by the attacker to gain persistence?
If you think about persistence one of the first things you think about are the Run keys. This information is stored in the NTUSER.DAT. This file contains the settings and preferences for each user. The NTUSER.DAT file of the user Administrator.WIN-B633EO9K91M contained an interesting entry as shown in the picture below.
The NTUSER.DAT can be found by going to SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce
The answer to this question is: baaaackdooor.exe
Question 22 - When was the first submission of ransomware to virustotal?
During question 21 a file named baaaackdoor.exe was identified. The SHA256 hash value of this file was: f2e3f685256e5f31b05fc9f9ca470f527d7fdae28fa3190c8eba179473e20789
After submitting the SHA256 hash value to VirusTotal, the history of the sample can be seen. The history contains information as the creation time of the sample, the first time seen and the last submission.
The first time this sample was seen was on 2021-12-11 22:57:01 as shown in the picture below.
Question 23 - The ransomware downloads a text file from an external server. What is the key used to decrypt the URL?
Since I have no experience with reverse engineering a malware binary, I started by using Google to see if I could find the answer that way. In VirusTotal you can view the detection names given to the malware by the different antivirus solutions.
Most antivirus solutions detect the malware as Khonsari. With this knowledge I went to Google and found a great threat report analyzing the malware sample.
A snipped from the threat report: The most significant attempt at anti-analysis by the authors, is merely to utilize a basic string obfuscation technique. In more technical terms, strings within the sample are obfuscated by XOR’ing each string with a unique key, consisting of an eight character, alphabetic string. A simple Python script was written during analysis in order to reverse the obfuscation. The decrypted strings are shown below.
The threat report also shows some eight character alphabetic strings, which I tried as answer and luckily one of them worked! The answer to this question is: GoaahQrC
Question 24 - What is the ISP that owns that IP that serves the text file?
Again VirusTotal was used to answer this question, since it shows all contacted domains by the binary.
As shown in the picture an Amazon domain was contacted.
Question 25 - The ransomware check for extensions to exclude them from the encryption process. What is the second extension the ransomware checks for?
In the same threat report used to answer question 23, another extension is mentioned. The answer to this question is: ini.