SalineBreeze-2

Platform: HackTheBox | Type: SOC/DFIR | Difficulty: Easy | Author: D3v0o0Nu11 | Date: 2026-02-10

Scenario

Your boss was so impressed with your research skills that you've been "rewarded" with a new task: malware analysis. Your mission is to investigate a piece of malware linked to the infamous cyber espionage group, Salt Typhoon. They've been targeting critical infrastructure, and it's up to you to uncover their tactics and techniques.

Key Questions

1. What indicators of compromise exist?
2. What attack chain / MITRE techniques were used?
3. What is the full timeline?

Investigation Timeline

Evidence Analysed

• Tools: python, powershell, strings, ghidra.
• Artifacts: registry.

Detailed Investigation

1. In this case, we are tasked with performing a malware analysis on a .ps1 file that is suspected to be linked to an infamous cyber-espionage group known as Salt Typhoon.
2. Upon a quick review of the provided PowerShell script, we can clearly identify encrypted strings and an AES-based decrypt-and-execute loader logic.

ONEDRIVED.PS1

1ST QUESTION --> ANS: REDACTED

1. While reviewing online articles about Salt Typhoon, one article curated by Trend Micro describes a DEMODEX rootkit infection chain that used the same PowerShell script name as the one we have now.

2. Also note that it will also drop a DLL named msmp4dec.dll.

3. The article also states that, based on Trend Micro telemetry, they identified specific commands used by the threat actor to make the script functional.

4. Let's try that on our sandbox.

5. Comparing the results of executing the PowerShell script with and without the password mentioned in the article shows different outcomes.

6. When the password is used, the script executes without errors.

7. It also dropped the same DLL name documented in the article.

8. This briefly concludes that we are dealing with the Demodex malware family.

2ND QUESTION --> ANS: REDACTED

1. Previously we identified an encoded base64 strings which utilized as AES object creation.

2. Decoding the base64 strings shall revealed -> System.Security.Cryptography.AesManaged.

3. It means the related line actually referred as:

 ps1 read-only • copy allowed Copy
$0 = New-Object System.Security.Cryptography.AesManaged

1. It is also important to note that, since there is no explicit mode assignment, the AES mode defaults to CBC with PKCS7 padding.

3RD QUESTION --> ANS: REDACTED

1. Upon reviewing the script again, it is clear that the variable $k is used to store the first argument passed by the user.
2. The argument passed is password@123.

4TH QUESTION --> ANS: REDACTED

1. Previously we identified password@123 indeed the correct one.

5TH QUESTION --> ANS: REDACTED

1. Since we already know which encryption is used to obfuscate the payload, we can attempt to decrypt it using the same encryption logic (AES-256-CBC).
2. In this case, I used a customized Python script to decrypt the payload:

 py read-only • copy allowed Copy
from Crypto.Cipher import AES
import base64

def decr(enc, argp):
    key = argp.ljust(32, '0')
    keyb = key.encode('utf-8')
    iv = bytes(16)
    
    encr_data= base64.b64decode(enc)
    cipher = AES.new(key_bytes, AES.MODE_CBC, iv)
    
    decr_bytes = cipher.decrypt(encr_data)
    
    # Remove PKCS7 padding
    padding_length = decr_bytes[-1]
    decr_bytes = decr_bytes[:-padding_length]
  
    res = decr_bytes.decode('utf-8')
    
    return res

encrypted_string = "" # pass the encrypted payload here
key = "password@123"
try:
  result = decr(encrypted_string, key)
  print(f"Decrypted content: {result}")
except Exception as e:
  print(f"Decryption failed: {e}")

1. Great! After decrypting the payload, we can now identify the value assigned to the variable $cregvalue.

2. In the top lines of the script, the value "midihelp" is assigned to the variable $cregvalue.

6TH QUESTION --> ANS: REDACTED

1. To identify the SHA-256 checksum, based on the script logic, we simply need to decode the Base64-encoded bytes and then calculate the checksum.

2. Since we also want to analyze the binary further, I saved the output. To decode and save it, I used a Python script.

 py read-only • copy allowed Copy
import base64, sys

strings = "" # the encoded strings.
res = base64.b64decode(strings)

### print(res)

out = 'decode_htb.bin'
with open(out, 'wb') as f:
    f.write(res)

GET SHA-256 CHECKSUM

O:\HTB
λ sha256sum decode_htb.bin
3b1c251b0b37b57b755d4545a7dbbe4c29c15baeca4fc2841f82bc80ea877b66 *decode_htb.bin

7TH QUESTION --> ANS: REDACTED

1. To identify the name of the malicious service, we need to detonate onedrived.ps1 again. However, this time, we execute Process Hacker first.
2. Using it, we were able to monitor the process names spawned by the PowerShell script.

PROCESS HACKER

1. Awesome! We found the newly created service name and the it's file location.

8TH QUESTION --> ANS: REDACTED

1. Based on our previous findings, the path to the malicious DLL is at C:\Windows\System32\msmp4dec.dll

9TH QUESTION --> ANS: REDACTED

1. To identify the registry path used to associate the service group (msgroup) with the malicious service, we can start by checking the registry key for the MsMp4Hw service.

2. Based on our findings above, we can conclude that the registry path HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost is used to associate the msgroup with the malicious service.

3. We can double-check it by visiting that location or we can also perform static analysis for the decrypted payload.

CHECKING THE REGISTRY PATH

THE LINE THAT SPECIFIES THE PATH

1. Nice! It is true.

10TH QUESTION --> ANS: REDACTED

1. Upon reviewing the code again, at the last line after the service installation. The service is invoked by this command -> Start-Service -name $svcname;

11TH QUESTION --> ANS: REDACTED

1. There are two ways to identify the Windows API imported by the malicious DLL to obtain the local computer name: you can use pestudio or ApiMonitor.

USING PESTUDIO

APIMONITOR

1. Now, to verify whether this is true, we can use ApiMonitor by attaching it to the PID of the malicious svchost.exe and enabling a filter for the GetComputerNameA win32 API function.

2. Great! It clearly shows GetComputerNameA is utilized to obtain our local computer name.

12TH QUESTION --> ANS: REDACTED

1. Again, there are several ways to identify the function responsible for initiating the service. In ApiMonitor, this can be identified by checking its threads.

2. On the other hand, using Pestudio is sufficient for static analysis by reviewing the exported functions.

13TH QUESTION --> ANS: REDACTED

1. Decompiling and pseudonym at ghidra, we can easily identified the hardcoded value for the used Sleep() function, it is 10000 milliseconds.

2. Great! We've briefly analyzed the malware.

Findings

1. Persistence mechanism — An autostart/persistence mechanism was established on the host (see timeline).
2. Initial access — As documented in the investigation steps.
3. Impact — As documented in the investigation steps.

MITRE ATT&CK Mapping

Answers / Flags

• 1ST QUESTION --> ANS: REDACTED
• 2ND QUESTION --> ANS: REDACTED
• 3RD QUESTION --> ANS: REDACTED
• 4TH QUESTION --> ANS: REDACTED
• 5TH QUESTION --> ANS: REDACTED
• 6TH QUESTION --> ANS: REDACTED
• 7TH QUESTION --> ANS: REDACTED
• 8TH QUESTION --> ANS: REDACTED
• 9TH QUESTION --> ANS: REDACTED
• 10TH QUESTION --> ANS: REDACTED
• 11TH QUESTION --> ANS: REDACTED
• 12TH QUESTION --> ANS: REDACTED
• 13TH QUESTION --> ANS: REDACTED

Lessons Learned

1. Demodex TTPs (associated with Demodex, Salt Typhoon / Earth Estries & Ghost Emperor).
2. PowerShell deobfuscation and reverse engineering (decrypt AES-256-CBC).
3. Dynamic malware analysis using FLARE-VM and Process Hacker.
4. Using API Monitor to capture win32 API function.
5. Static malware analysis using PEStudio and Ghidra.