AshtonAng
Work

Things I've built

A working list. Each one taught me something specific, and the notes under every project say what.

Showing 11 of 11

Detection & response TryHackMe Boogeyman 3 room banner, a shadowy figure with a scythe outside a door marked CEO Room

TryHackMe: Boogeyman 3

A capstone investigation from TryHackMe's SOC Level 1 path. One fake PDF on the CEO's machine, followed through Kibana to a DCSync and ransomware on the domain controller two hours later.

The only evidence was an Elastic stack with two days of logs. I traced an HTA dropper through a scheduled task, a fodhelper UAC bypass, Mimikatz and pass-the-hash, a plaintext password in a readable IT automation script, PowerShell remoting to a second workstation, and finally DCSync and ransomware on DC01. My first search came back empty because Kibana was still set to the last 15 minutes, and a filter I thought I'd applied never actually ran, so I learned to check the query bar before trusting any hit count.

  • Elastic
  • Kibana
  • KQL
  • Incident investigation
  • MITRE ATT&CK
Read the write-upSOC Level 1 certificate
Certification TryHackMe certificate of completion for the SOC Level 1 learning path, issued to Ashton Ang Wu Zun, dated 23 September 2026

TryHackMe — SOC Level 1

Completed the SOC Level 1 learning path on TryHackMe, 65 hours 29 minutes covering the material a tier-1 SOC analyst is expected to know.

Runs through log analysis, SIEM fundamentals, endpoint and network security, and phishing and threat intel triage, closing with a set of incident investigation exercises. Most of the hands-on side overlapped with what I'd already built in my own SOC homelab, so this filled in the parts of the theory I'd skipped past or half-learned on my own.

  • SOC
  • SIEM
  • Incident response
  • Log analysis
  • Blue team
Verify certificate
Competition TFC CTF 26 certificate of participation for Ashton Ang Wu Zun, team NxT, placed 162nd of 1,027 teams

TFC CTF 26 — solo

Ran TFC CTF 26 solo under the handle NxT, a CTFtime-rated event with a 77.08 weight.

Placed 162nd of 1,027 teams as a solo entry, with 7 challenges solved across cryptography, misc, and OSINT. The linked write-ups cover the approach for each solve.

  • CTF
  • Cryptography
  • OSINT
  • Misc
  • Solo
Results & write-upsAll write-ups
Competition Kaspersky{CTF} certificate of participation for NxT, ITE College West, dated 30 August 2026

Kaspersky{CTF} 2026 — NxT

Competed with NxT in the Kaspersky{CTF} 2026 Asia regional league, representing ITE College West.

NxT placed 69th with 736 points and 9 challenges solved across pwn, reverse engineering, cryptography, misc, and AI. The linked team write-ups document the root cause and exploit path for every solve.

  • CTF
  • Pwn
  • Reverse engineering
  • Cryptography
  • AI security
Team resultsChallenge write-ups
Detection & response Suricata alerts for an nmap scan listed beside the host sensor's unrelated log noise

SOC Homelab

A rebuilt two-layer SOC lab, Wazuh watching the host and Suricata watching the wire, built around one question: what does network monitoring catch that host monitoring doesn't.

I kept Wazuh, the host-layer SIEM from the original lab, and added Suricata as a second, network-layer sensor, then ran the same three attacks at both and compared what each one actually saw. An nmap scan turned out structurally invisible to the host, since a SYN scan never completes a connection. A rebuilt 2017 Samba exploit landed root that only the network layer could prove, straight off the wire, because nothing on the host was pointed at the right signals. A cron-based fake beacon got logged by the host in full and never once turned into an alert. Closing part of that last gap meant writing my own Suricata rule and chasing a false lead through a real pre-existing decoder bug before finding the actual problem.

  • Wazuh
  • Suricata
  • Docker
  • IDS/IPS
  • Detection engineering
  • MITRE ATT&CK
Read the summaryAttack: nmap scanAttack: Samba CVEAttack: C2 beaconHost-layer limits (DVWA)
Detection & response Splunk reporting 33,413,777 indexed events in the BOTSv1 dataset

Splunk BOTSv1

Two write-ups working through Splunk's own 33-million-event BOTSv1 training dataset as the defender, a website defacement and a ransomware outbreak on the same simulated network.

I loaded Splunk's pre-indexed BOTSv1 dataset, 33,413,777 events of Windows, Sysmon, firewall, and web traffic, and worked through both of its scenarios question by question instead of skimming to the answer key. Scenario 1 chases the Po1s0n1vy group through Joomla logs to a stolen admin login hiding in a session cookie. Scenario 2 traces a Cerber ransomware outbreak from a parking-lot USB drive through a steganographic payload hidden inside a jpeg. 29 questions total, and enough wrong turns across both, misread fields, a table command that silently dropped results, a file count contaminated by the wrong multivalue field, to make the right answers actually mean something.

  • Splunk
  • SIEM
  • Log analysis
  • Incident investigation
  • Ransomware
Scenario 1 — Batman?!Scenario 2 — Cerbus
Tooling & automation Terminal output showing the ranked alert report, grouped by detection rule

Mini SIEM

A Python tool that parses a Linux auth log once and runs four detection rules over it, then prints a ranked alert report.

It reads an auth.log, turns every SSH login line into a structured event with the status, user, IP and timestamp, then runs four rules over those events: a keyword match on the raw lines, a suspicious-IP watchlist, an off-hours check for logins between midnight and 6am, and a brute-force rule that fires when one IP racks up five or more failures inside a short window. The report counts alerts per rule so the loudest thing sits at the top. Standard library only. I built it as the next step up from my failed-login counter, because parsing once and detecting many times is the shape of the SOC work I want to do.

  • Python
  • Detection rules
  • Log parsing
  • Regex
  • SOC
Read the write-upSource
Offensive security A reverse shell on the target box running as the www-data user

Hack The Box: Oopsie

My first full Hack The Box machine, taken from a guest cookie to a shell on the box.

I chained four simple web vulnerabilities together to gain access into a system. An IDOR flaw that got me the administrator's account ID, editing browser cookies to trick the site, uploading and executing a reverse shell PHP script, and found a reused database password.

  • Hack The Box
  • Web exploitation
  • Burp Suite
  • Reverse shell
  • Linux
Read the write-up
Tooling & automation

SSH Failed Login Analyzer

A Python tool that reads a Linux auth log and reports which IP addresses keep failing to log in over SSH.

It scans auth.log for "Failed password" lines, pulls the IPv4 address out of each one with a regex, and counts attempts per address so the noisiest sources sit at the top. Standard library only, split into small read, count, and report functions with clear handling for a missing or unreadable file. I built it because triaging auth logs is the kind of work a junior analyst actually does, and I wanted to do it by hand before reaching for a bigger tool.

  • Python
  • Log parsing
  • Regex
  • SSH
Read the write-upSource
Networking

Subnet Scanner

A command line tool that finds live hosts on a network and checks which common ports they have open.

You give it a subnet in CIDR notation. It pings every address to find live hosts, then opens short lived TCP connections to common ports like SSH, HTTP, HTTPS, SMB, and RDP on each host that answered, and prints a table of hosts and their open ports. It runs on a thread pool, so a full subnet finishes in seconds instead of minutes, and it stays on the Python standard library. Building it made me separate the two questions a scan really asks: is this host alive, and is something listening behind that port.

  • Python
  • Networking
  • Port scanning
  • Threading
Read the write-upSource
Sockets

LAN Chat Room

A console chat app in Python that runs a server and connects multiple clients over a local network.

One machine runs the server, others join as clients by pointing at its local IP, and messages pass between them in real time. It was my first proper look at sockets and the client to server model, including the small frustrations of getting two machines to talk on the same network.

  • Python
  • Sockets
  • Networking
Read the write-upSource