PS Eclipse: Tracing BlackSun Ransomware Through Splunk Logs

Introduction

This write-up covers my run through PS Eclipse on TryHackMe, a medium-difficulty blue-team room built around a ransomware infection. The setup: I'm playing a SOC analyst at an MSSP, and a client has reported that a machine belonging to an employee named Keegan is still running, but some files on it now carry a strange extension. Nobody knows yet whether this is really ransomware or something else. My job was to open Splunk and work out what happened using only what was already logged.

Like the other Splunk rooms I've written up, there's no exploitation involved here, just reading. Sysmon and DNS logs sat in Splunk waiting to be queried, and the room worked question by question: find one artifact, use it to narrow the next search, repeat until the whole chain from initial download to ransom note becomes visible.

Phase 1: Spotting the Rogue Binary

Objective:_ find the executable that had no legitimate reason to be running._

I started broad with EventCode=1 (process creation) to see everything that had executed on the box, piped it into a table of Image and CommandLine, and deduplicated on Image to cut 69 raw events down to a short list of distinct binaries. Skimming that list turned up one path that didn't belong: an executable running from C:\Windows\Temp , sitting right next to an ordinary whoami.exe call, not somewhere a legitimate process would normally live.

Key Finding: OUTSTANDING_GUTTER.exe, executing from C:\Windows\Temp\OUTSTANDING_GUTTER.exe.

Phase 2: Tracing the Delivery Command

Objective:_ recover the address the binary was actually downloaded from._

Finding the binary doesn't say how it got there. Attackers commonly use PowerShell to stage payloads, so I added powershell as a keyword to the same EventCode=1 search, narrowing the results down to 20 events tied to PowerShell activity.

Opening the CommandLine field's top values surfaced a base64-encoded -enc string, the kind of thing attackers lean on so a command doesn't read as plain text in the logs.

Running it through CyberChef (From Base64, then Decode text as UTF-16LE, the encoding PowerShell uses for -EncodedCommand ) unpacked it into a full one-liner: it disabled Windows Defender's real-time monitoring, then pulled the binary from an ngrok tunnel into Temp, before chaining straight into the scheduled-task commands that showed up later.

I pulled the URL out and ran it through CyberChef's Defang URL operation before writing it down.

Key Artifact: hxxp[://]886e-181–215–214–32[.]ngrok[.]io

Phase 3: Confirming the Delivery Tool

Objective:_ pin down exactly which binary ran that encoded command._

With the encoded string in hand, I reused it as a filter alongside the powershell keyword and read the Image field on the matching event. It confirmed the command ran through the legitimate PowerShell binary itself, not a renamed copy or a look-alike. The evasion here was never about the process name, it lived entirely in the encoding.

Key Finding: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

Phase 4: Building In Persistence

Objective:_ find the command that gave the binary a way to relaunch on its own._

Next question was whether the attacker set up a way back in. Filtering EventCode=1 on the binary's own name and pulling the CommandLine field's top values surfaced a schtasks.exe call that created a scheduled task, triggered off a custom Applicationlog event rather than a normal schedule, and set to run as SYSTEM. An unusual trigger paired with the highest privilege level available is a good way to make a task blend into normal log noise while still guaranteeing it runs.

Key Artifact: "C:\Windows\system32\schtasks.exe" /Create /TN OUTSTANDING_GUTTER.exe /TR C: \Windows\Temp\COUTSTANDING_GUTTER.exe /SC ONEVENT /EC Application /MO *[System/EventID=777] /RU SYSTEM /f

Phase 5: Confirming the Privilege Level

Objective:_ verify which account actually ran the task, and how._

Creating a task is one thing, running it is another. I tabled User against CommandLine for every event tied to the binary and deduplicated on CommandLine for a clean side-by-side view. It showed NT AUTHORITY\SYSTEM executing the matching schtasks /Run command, confirming the scheduled task didn't just exist, it actually fired with SYSTEM-level rights.

Key Finding: NT AUTHORITY\SYSTEM; "C:\Windows\system32\schtasks.exe" /Run /TN OUTSTANDING_GUTTER.exe

Phase 6: Uncovering the C2 Channel

Objective:_ find where the binary was phoning home._

With execution and persistence confirmed, the next step was checking whether the binary talked to anything outside the box. Filtering on its name together with EventCode=22 (DNS query) returned a small set of five events, all resolving to a single QueryName: a second ngrok subdomain, distinct from the one used to deliver the payload. That fits a C2 beacon riding on a legitimate tunneling service to blend into normal outbound traffic.

defang.

Key Artifact: hxxp[://]9030–181–215–214–32[.]ngrok[.]io

Phase 7: Finding the Second-Stage Script

Objective:_ locate the PowerShell script staged alongside the binary._

Since the binary lived in C:\Windows\Temp, I filtered EventCode=11 (file creation) for that same folder and the .ps1 extension, then tabled and deduplicated on TargetFilename. Most of the hits were PSScriptPolicyTest noise, files Windows generates on its own when checking script-execution policy, but one entry broke that pattern: a plainly named script.ps1 , sitting in the same folder as the malicious binary.

Key Finding: C:\Windows\Temp\script.ps1

Phase 8: Naming the Script by Its Hash

Objective:_ work out what the generically named script actually was._

A file called script.ps1 gives away nothing on its own, so I searched directly on that filename and opened the Hashes field, which returned its SHA1, MD5, and SHA256 in one line.

Pasting the SHA256 into VirusTotal came back with 31 out of 54 vendors flagging it as malicious, and the community-assigned name attached to that hash was BlackSun.ps1, tying the generic filename on disk to a known ransomware family.

Key Artifact: BlackSun.ps1 (SHA256: E5429F2E44990B3D4E249C566FBF19741E671C0E40B809F87248D9EC9114BEF9)

Phase 9: Locating the Ransom Note

Objective:_ find where the ransom note landed on disk._

Once the script's identity was confirmed, finding its impact meant going back to EventCode=11 and filtering for .txt, the typical ransom-note extension. That returned the note sitting in Keegan's own Downloads folder, inside a randomly named subdirectory rather than a predictable path. It's a small touch, but it makes the file slightly harder to search for or clean up automatically.

Key Finding: C:\Users\keegan\Downloads\vasg6b0wmw029hd\BlackSun_README.txt

Phase 10: Tracking the Wallpaper Change

Objective:_ find the image file used to replace the desktop wallpaper._

Ransomware that drops a text note often swaps the desktop wallpaper too, as a harder-to-miss scare tactic, so I repeated the previous filter with .jpg in place of .txt. It returned a single file-creation event: an image written to the machine's shared Public Pictures folder rather than Keegan's own profile, meaning the change would greet anyone who logged into that machine, not just him.

Key Finding: C:\Users\Public\Pictures\blacksun.jpg

Reconstructed Timeline

Pulled together, these findings line up into a single narrative, the kind of timeline that would go straight into an incident report:

1. An encoded PowerShell one-liner disabled Windows Defender's real-time monitoring, then downloaded OUTSTANDING_GUTTER.exe from an ngrok tunnel into C:\Windows\Temp.

2. A scheduled task was created to relaunch the binary on a custom Application-log trigger, set to run as NT AUTHORITY\SYSTEM.

3. The task fired, confirming the binary executed with SYSTEM-level rights.

4. The binary beaconed out over DNS to a second ngrok subdomain, its command-and-control channel.

5. A second-stage script, script.ps1, was staged in the same Temp folder and later identified by hash as BlackSun.ps1.

6. BlackSun encrypted files on the machine and dropped a ransom note, BlackSun_README.txt, into the victim's Downloads folder.

7. The desktop wallpaper was replaced with blacksun.jpg in the shared Public Pictures folder. That was the visible sign that the machine had been hit.

This write-up is part of my ongoing series documenting CTF challenges as I build my portfolio in cybersecurity. I approach each challenge from both offensive and defensive perspectives, because understanding both sides is what makes a well-rounded security professional.

If you're also on the journey toward a SOC or Security Engineering role, feel free to connect — I'm always happy to discuss techniques and share resources.