Write-ups — _1n1t

Forensics 2025

Iced

The attacker used a legitimate Windows binary to drop malicious code — living off the land. Then layered obfuscation on top to make it harder to detect. Goal: find the payload, strip the obfuscation, recover the flag.

Disk ForensicsPowerShell AnalysisDeobfuscationBase64strings

Full Investigation

Finding the suspicious file

Browsed the disk image manually. One directory stood out immediately:

\Iced\AppData\LocalLow\Microsoft\CryptnetUrlCache\Content

This path is not where user files belong. It gets abused by malware to stash scripts or downloaded content. Inside was a file that looked nothing like a normal system file.

Extracting readable content

Ran strings * on the directory to pull readable text from the binary. Out came a long, heavily obfuscated PowerShell command. Random-looking at first glance — but several patterns were immediately recognizable:

String formatting with numbered placeholders (-f operator) to reconstruct the command from fragments
Junk token Cvx inserted everywhere to break pattern matching
Character encoding tricks using [Char] casts
Indirect execution via Invoke-Expression (IEX)

Removing the junk token

Near the end of the script was this:

.replace('Cvx', [string][char]39)

So Cvx was being substituted with a single quote at runtime — it was pure noise added to frustrate static analysis. Strip it, and the real command structure becomes visible.

Evaluating the safe parts

Instead of running the whole thing (obviously bad), I only evaluated the string formatting and replacement sections in PowerShell. This revealed the real inner structure:

Invoke-Expression(
  [System.Text.Encoding]::Unicode.GetString(
    [System.Convert]::FromBase64String("...")
  )
)

Classic. Base64-encoded payload, decoded at runtime and executed. The encoded string itself was split using + symbols to make it harder to copy-paste.

Extracting and cleaning the Base64

Joined the fragments, then applied one more replacement the script used:

.Replace(([Char]106+[Char]89+[Char]79), [String][Char]34)

That translates to: replace jYO with a double quote. After applying it, the final Base64 payload was clean:

JGZsYWcgPSJGbGFnWXtkNDFkOGNkOThmMDBiMjA0ZTk4MDA5OThlY2Y4NDI3ZX0i

Decoding — flag recovered

Decoded the Base64 string. Result:

$flag = "FlagY{d41d8cd98f00b204e9800998ecf8427e}"

Download Write-up →

DFIR 2024

The Final Hop

SOC alert for lateral movement in an AD environment. Domain controller accessed by a suspicious account. A few hours later a critical app server went dark — local Administrator password changed without authorization. Reconstruct the attack chain and recover the changed password.

FTK ImagerWiresharkJohn the RipperOpenSSLRDP/TLS DecryptionPKCS#12

Full Investigation

Finding the certificate

Mounted Case.ad1 with FTK Imager. Found server.pfx in the Downloads folder. A PKCS#12 file — holds the server certificate and private key. Password protected. This is the key to decrypting RDP traffic if RSA key exchange was used.

Cracking the PFX password

python3 pfx2john.py server.pfx > server.hash
john --wordlist=/usr/share/wordlists/rockyou.txt server.hash

Password: whatever. Classic rockyou hit.

Extracting the private key

openssl pkcs12 -in server.pfx -nocerts -nodes -out privatekey.pem -password pass:whatever

Outputs an unencrypted PEM file starting with -----BEGIN PRIVATE KEY-----. This is what Wireshark needs.

Loading the key into Wireshark

RDP traffic was on 192.168.75.172:3389. In Wireshark: Edit → Preferences → Protocols → TLS → RSA Keys List. Added the key file with protocol set to rdp. Wireshark reparsed the capture and decrypted the TLS stream.

Flag recovered

Right-clicked a TLS packet → Follow → TLS Stream. Flag was in the decrypted RDP session:

Asu{D0_Y0U_TRU5T_RDP_CERT?}

Download Write-up →