1.1 Teaser Overview

To be honest, switching careers to cybersecurity at 54 after 36 years in airport operations was pretty intimidating. I didn't know much about computers when I started, and this lab pushed me way out of my comfort zone. But building this SIEM setup showed me that security is mostly about a mindset I already have. Managing an airport means tracking a ton of moving parts, spotting bottlenecks before they cause trouble, and following strict safety rules. Dealing with a SIEM dashboard is the exact same thing, just on a screen instead of an airfield.

Every time the data pipeline broke—like when the Python server logs wouldn't show up or the text editor scrambled my XML config files—it just felt like a giant puzzle. Fixing those broken permissions and redirecting those log files gave me the same exact feeling I get when I finally solve a tough Sudoku or KenKen grid. The setbacks weren't failures; they were just the puzzles I needed to solve to understand how the data actually flows.

In the final section of this report, I will share my deep reflections on this project. I'll break down my biggest engineering takeaways, explain why you can never trust out-of-the-box software settings without creating massive blind spots, and show how my decades of supervisory experience translate directly into real-world digital defense.

1.2 Introducing Yourself to the Cyber Community

My name is Bret Roper, and my journey into the world of technology comes from a unique professional background. For 36 years, I worked as an airport operations professional, serving most recently as a supervisor managing complex, real-world systems. While that career was fulfilling, at 54 years old, I realized I wanted a transition that offered both a deeper mental challenge and long-term financial stability. I didn't know much about computers when I started this academic transition, but I had a strong desire to learn how digital systems operate from the ground up.

Hobbies and Hands-On Interests

Outside of my studies, my passion for strategic problem-solving and diagnostics shows up in my personal hobbies:

  • Golf and Fishing: Activities that require patience, situational analysis, and constantly adjusting to environmental variables.
  • Furniture Restoration: I love buying old furniture and repurposing it. This satisfies my desire to take a legacy structure, figure out its structural needs, and rebuild it into something strong and functional.
  • Mind Puzzles: I naturally gravitate toward analytical games like crosswords, Sudoku, and KenKen, where success relies completely on deductive reasoning and working within strict rule parameters.

Why Cybersecurity?

What ultimately drew me to cybersecurity is how naturally these interests overlap with digital defense. In aviation management, success relies on keeping a massive array of moving pieces organized and troubleshooting sudden disruptions under strict rules. I quickly realized that tracking down a security threat inside a network uses those exact same core skills.

Cybersecurity is essentially the ultimate high-stakes puzzle. This hands-on SIEM monitoring project has allowed me to turn my natural curiosity into practical technical knowledge, proving that it is never too late to pick up a keyboard and master a new domain.

  1. Setup

Baseline Modification Strategy

To make my baseline modification, I appended a custom <localfile> block to the agent configuration file located at /var/ossec/etc/ossec.conf. This block explicitly instructs the Wazuh agent to monitor our custom web application file at /var/log/python_server.log using a generic syslog text format.

Choosing the syslog format over the standard Apache setting was an important setup trick for this lab environment. If I had configured Wazuh to use the Apache format, the monitoring engine would expect every incoming log entry to look exactly like a highly structured, professional Apache web server log. Because our built-in Python testing server outputs a simple, stripped-down text string, Wazuh would get confused by the missing fields, view the input as malformed data, and silently drop the logs entirely before they ever reached our dashboard.

By changing the format parameter to syslog, I essentially told Wazuh to avoid overthinking the data structure and treat every incoming log entry as a plain, generic sentence. Switching to syslog successfully disables those rigid, unforgiving web layout syntax checks. This keeps our data pipeline open and flowing so that our raw web traffic is successfully transmitted to the manager, allowing us to accurately track incoming 404 brute-force patterns without crashing the agent.

Troubleshooting: The Nano Editor Trap

During the pasting process inside the Linux nano text editor, my closing XML tags got completely jumbled up with the local file text. I successfully resolved this formatting mess directly inside the terminal by using Ctrl + K to quickly delete the broken lines of code and Alt + U to step backward and undo my mistakes one at a time.

  1. Experiment Time!

With our logging pipeline fully configured and the Wazuh agent actively monitoring the play-server endpoint, it was time to step into the role of the attacker. The primary goal of this testing phase was to run active adversary simulations to see if our SIEM could catch malicious behavior in real-time, helping us validate whether our defensive monitoring rules actually work.

The Attack Platform and Lab Environment

To run these attack simulations safely without crashing any critical systems, I utilized a mix of powerful cybersecurity testing tools across our lab network:

  • Atomic Red Team (ART): A highly framework-driven security tool that allows us to run small, automated scripts (called "atomic tests") to simulate specific adversary behaviors mapped directly to the real-world MITRE ATT&CK framework.
  • PowerShell Core (pwsh): A cross-platform terminal shell running natively on our Linux environment, which allowed me to safely launch and control the Atomic Red Team framework directly on the target host.
  • Gobuster: An aggressive web application discovery utility designed to rapidly fuzz directories and search for hidden endpoints or missing pages. [1]

Experiment 1: Local Sudo Brute Force (MITRE ATT&CK T1110.001)

To fully document Experiment 1, I ran an automated local brute-force simulation by analyzing the raw backend activity recorded inside /var/log/auth.log on the target host. Examining this endpoint data first reveals a rapid, sub-second loop of successful authentication events instead of individual password failures:

  • Successful Execution Receipt: sysadmin : TTY=pts/0 ; PWD=/home/sysadmin ; USER=root ; COMMAND=/usr/bin/id
  • Accompanying Session Telemetry: PAM: Login session opened immediately followed by PAM: Login session closed

This structural log pattern proves that the simulation script interacted cleanly with active system binaries, causing the host operating system to register successful administrative session configurations rather than failed login attempts.

The purpose of this test was to verify whether the Wazuh SIEM could detect localized authentication attacks targeting administrative entry paths in real-time. In a real-world scenario, this method simulates an adversary who has already established an initial, low-privileged foothold on a Linux endpoint and is aggressively attempting to guess local passwords to escalate privileges to root. To execute the simulation cleanly without causing system instability, I logged into the terminal interface of the Ubuntu play-server, dropped into an elevated PowerShell Core environment via sudo pwsh, manually imported the Atomic Red Team framework manifest file, and launched Invoke-AtomicTest T1110.001 -TestNumbers 5 while explicitly mapping the command to the local /home/sysadmin/AtomicRedTeam/atomics directory.

My initial hypothesis predicted that the rapid injection of password guesses inside the shell would generate immediate, high-frequency authentication errors. On the Wazuh Dashboard, searching within the Last 15 minutes window was expected to reveal a massive visual event spike triggering Rule 5503 (PAM: User login failed) or Rule 5712 (SSHD brute force) compiled into a high-severity alert banner. However, the actual dashboard metrics completely disproved this prediction, as filtering for failed authentication rule IDs returned zero results. Instead, auditing the precise timestamp window around 13:17 EDT revealed a rapid cascade of successful operational rule loops, specifically Rule 5402 (Successful sudo to ROOT executed), Rule 5501, and Rule 5502.

From a Security Operations Center (SOC) perspective, these results highlight the vital importance of tracking automated frequency rather than relying solely on traditional "failed" event triggers. While a standard system administrator might legitimately log a single instance of a sudo session opening and closing during routine maintenance, seeing this exact sequence repeat multiple times within milliseconds exposes the automated footprint of a script abusing local parameters. To defend against this signature, my personal takeaway from the lab is that defenders must establish an operational baseline first so they can recognize sub-second frequency anomalies. Based on the course materials, the best defense strategy is to implement advanced correlation rules within the SIEM manager that automatically escalate a cluster of low-level Rule 5402 logs into a high-severity alert the moment they fire in rapid, automated succession.

Experiment 2: Sudo Command Enumeration Testing

To fully document Experiment 2, I ran a controlled variation test by looking directly at the raw telemetry inside /var/log/auth.log on the play-server endpoint. Examining this file reveals the exact, isolated text string generated when a user passes a passive privilege check instead of an active exploit payload:

  • Captured Log Receipt: sysadmin : TTY=pts/0 ; PWD=/home/sysadmin ; COMMAND=list
  • Accompanying Telemetry Footprint: PAM: Login session opened and PAM: Login session closed appearing simultaneously around the execution block.

This factual data receipt proves that while a permission check still initializes standard backend session tracking mechanisms, it creates a distinct syntax entry block that explicitly registers the final command argument as a list request.

The purpose of this test was to determine whether the Wazuh SIEM would trigger the exact same baseline alert on a passive privilege check command as it did on our active privilege escalation simulation. The method kept every environment variable identical to our original test, but altered a single operational parameter by executing a permission list request instead of a standard binary execution string. I hopped onto the terminal of the Ubuntu play-server, executed the sudo command with the list flag, and immediately pivoted back to the Wazuh dashboard to check the telemetry using the exact same timeline and metadata filters.

My initial hypothesis predicted that the system would still generate an event under the primary filter because any invocation of the administrative binary forces the underlying operating system to validate user clearance. I expected that even though I was only listing my current privilege mappings rather than running an operational application, the authentication logs would still record a successful validation event and trip the baseline Rule ID 5402. However, the actual dashboard telemetry completely disproved this prediction, as refreshing the security timeline graph revealed absolutely no new alerts under our active search parameter.

This experiment taught me an essential lesson about the precise match conditions used by SIEM decoders. The baseline Rule ID 5402 does not simply trigger a warning anytime a user types the word sudo. This absence of an alert indicates that the manager's default rule set likely drops the event because the string format deviates from the expected operational schema. Because the list command merely queries user access rights without passing a traditional file path, the log structure changes just enough to fall completely outside the rule's narrow matching boundaries. From a defender's perspective, this means a narrow default rule set can create a massive operational blind spot, allowing an attacker to map out local system permissions without making a single sound on the main security dashboard.

Custom Wazuh Alert Rule

This custom rule hooks into the standard baseline alert engine. It targets specific field extractions and forces an absolute string validation to flag whenever a user attempts to spawn an interactive root shell interface via sudo, immediately escalating the alert to a high-severity Level 10:

xml

<group name="linux, syslog, sudo_abuse,">
  <rule id="100054" level="10">
    <if_sid>5402</if_sid>
    <field name="data.command">^/bin/bash$|^/usr/bin/bash$|^/bin/sh$|^/usr/bin/sh$|^/bin/zsh$|^/usr/bin/zsh$</field>
    <description>Suspicious Shell Spawning via Sudo Execution</description>
    <mitre>
      <id>T1548.003</id>
    </mitre>
  </rule>
</group>

Enter fullscreen mode Exit fullscreen mode

Use code with caution.

Severity Escalation Rationale & False-Positive Mitigation

While I am keeping this initial custom rule narrow to catch direct shell interpreters as a clear starting example, a defender can easily expand this field regex block in production to monitor other high-risk GTFOBins bypass utilities like vim, less, find, or python. To avoid the massive false-positive risks associated with generic substring matching or unanchored word boundaries, the configuration utilizes explicit field filtering (data.command) coupled with rigid start (^) and end ($) regular expression anchors. This specific syntax completely eliminates the risk of accidentally matching benign background activity—such as custom maintenance scripts execution streams or application directory folders containing the characters "sh" or "bin"—while ensuring absolute cross-distro compatibility across standard paths and symlinked structures. I deliberately escalated this to a Level 10 alert because the baseline rule (Rule 5402) fires at a low-level Level 3, which simply means a normal, routine administrative action took place. Jumping straight to Level 10 strips away that background noise and immediately flags a critical event for the SOC team: a user is no longer just running an application, but is explicitly breaking out into a permanent, unrestricted root terminal interface.

Hardening & Verification Checklist

  • Enforce Least Privilege: Audit /etc/sudoers to eliminate any wildcard user blocks (ALL=ALL) that grant unnecessary system-wide execution permissions.
  • Restrict Passwordless Sudo: Eliminate broad NOPASSWD flags for standard user accounts, ensuring a second layer of authentication is required before root commands execute.
  • Monitor Binary Abuse: Implement custom SIEM alerts (like Rule 100054) to explicitly monitor and flag when sudo is used to launch utilities listed on the GTFOBins registry. In my active play-server test, this framework would have instantly escalated and flagged the attack pattern if the payload command had been changed from the safe /usr/bin/id query to a restricted /bin/bash terminal request.

Experiment 3: Aggressive Directory Fuzzing (MITRE ATT&CK T1595.003)

To fully document Experiment 3, I ran an aggressive web directory fuzzing simulation by inspecting the raw event pipeline data that we successfully routed into /home/sysadmin/python_web.log. Examining this endpoint source file directly reveals the precise text string generated by our automated attacks:

  • Captured Attack Receipt: 127.0.0.1 - - [29/Jul/2026:08:36:30 +0000] "GET /signup HTTP/1.1" 404 207
  • Accompanying Telemetry Footprint: Continuous rapid repetitions targeting unique hidden endpoints like /security and /random in identical timestamps.

This structural data receipt proves that our offensive tool successfully flooded the target host, forcing the background listener application to generate thousands of explicit HTTP 404 error codes.

The purpose of this test was to determine if our SIEM could successfully detect aggressive, automated web application enumeration and asset discovery patterns (MITRE ATT&CK T1595.003). In a real-world production environment, this scenario simulates an outside threat actor using automated scanning software to rapidly guess file paths on a public-facing corporate web server, trying to hunt down hidden management panels, forgotten developer portals, or exposed backup files. To execute the attack, I booted up the lightweight Python server on port 8000 and fired the Gobuster directory fuzzer tool from the terminal command line, running a rapid brute-force loop against 4,615 distinct directory paths using the common system wordlist.

My initial hypothesis predicted that running this aggressive scan would instantly trigger a massive visual spike on our dashboard timeline, generating high-frequency alert blocks under Rule ID 31101 (Web server 404 error). However, the actual dashboard metrics completely disproved this prediction at first due to a critical pipeline error where the background Python target web server was run without configuring standard output redirection. Instead of writing the server events into a physical storage layout that my endpoint collector could actively watch, Python dumped its raw event text strings directly onto the open terminal console monitor screen. Because the Wazuh Agent cannot natively monitor volatile standard terminal text output, it caused a complete visibility blackout where the SIEM engine generated zero dashboard alerts despite our offensive tool blasting thousands of automated directory queries against the port.

I successfully resolved this visibility mistake by killing the background process and re-architecting the execution command to redirect output into a permanent log file using the command: python3 -m http.server 8000 > /home/sysadmin/python_web.log 2>&1 &. This taught me that network connection statuses can be highly deceiving; even though an agent monitor explicitly confirms a machine is connected, the SIEM will remain entirely blind to attacks until you manually verify that raw logs match the exact path parameters configured inside your tracking rules. Once fixed and rerun, the data successfully streamed to the manager, displaying a huge vertical bar chart representing thousands of web errors hitting all at once.

Custom Wazuh Alert Rule

To catch this automated behavior before an attacker discovers an exposed file, I drafted a custom alert rule designed to flag scans hunting for known backup extensions or admin folders, escalating standard 404 logs from a Level 5 up to a high-priority Level 10:

xml

<group name="web, accesslog, attack,">
  <rule id="100031" level="10">
    <if_sid>31101</if_sid>
    <match>\.bak|\.zip|config|admin|secret</match>
    <description>Suspicious Administrative Directory Enumeration Attempt</description>
    <mitre>
      <id>T1595.003</id>
    </mitre>
  </rule>
</group>

Enter fullscreen mode Exit fullscreen mode

Use code with caution.

Hardening & Verification Checklist

  • Implement Network Rate Limiting: Configure a defensive utility like Fail2ban or a Web Application Firewall (WAF) to drop external connections when an IP exceeds a set threshold of 404 errors per second.
  • Disable Server Indexing: Tighten web app configurations to prevent directory listing, ensuring that even if an attacker finds a valid directory, they cannot view the files within it.
  • Monitor Log Streams: Implement custom SIEM alerts (like Rule 100031) to explicitly monitor and flag when gobuster or other aggressive fuzzing tools are utilized. In my active play-server test, this framework would have instantly escalated and flagged the attack pattern if the fuzzer had targeted paths matching the restricted .bak or admin keyword definitions.

4.1 Summary of Experimental Findings

Experiment 1: Local Sudo Brute Force

Our first experiment proved that automated password guessing inside a local shell creates a rapid, sub-second loop of successful process actions rather than individual password failure drops. The SIEM bypasses traditional validation filters, grouping the attack into Rule 5402 (Successful sudo to ROOT executed) logs that fire within milliseconds of each other.

Experiment 2: Sudo Command Enumeration

Our second experiment disproved the hypothesis that any use of the administrative binary would trigger the same baseline rule. Executing sudo -l to passively list system permissions generates a distinct syntax entry that falls completely outside Rule 5402's strict match constraints, demonstrating how an attacker can quietly map privileges without generating dashboard noise.

Experiment 3: Aggressive Directory Fuzzing

Our final experiment exposed a critical pipeline vulnerability where a lightweight application logging directly to terminal standard output leaves the SIEM entirely blind. Redirecting the background data stream to a persistent file instantly enabled the agent to intercept the automated brute-force pattern, rendering an aggressive visual timeline spike of Rule 31101 (Web server 404 error) events.

4.2 Advice on Avoiding Mistakes

Tips for System Setup

  • Enforce Strict XML Order: Use clean template files or non-interactive bash streams to inject blocks into ossec.conf. This entirely eliminates clipboard format scrambling and out-of-order parent-child structural boundaries.
  • Master Terminal Shortcuts: Memorize the exact utility keys for your specific console application before modifying critical system parameters. Relying on Ctrl + K to erase corrupt string rows and Alt + U to step backward saves significant diagnostic time.

Tips for Experimentation Time

  • Confirm Output Persistence: Match the logger structure directly to the capabilities of the ingestion decoder engine. Forcing the system to treat non-standard outputs as standard syslog text sentences bypasses rigid application checks and keeps logs from dropping.
  • Verify Endpoint Directories: Always search the filesystem using tools like find to map real tool paths rather than guessing documentation locations.
  • Elevate Session Permissions Early: Run framework scripts under sudo pwsh to grant explicit administrative write capabilities to shared temporary directories and prevent script crashes.

5.1 The coolest thing I learned

For me, the most eye-opening part of this lab was realizing that my 36 years as an airport operations supervisor actually gave me a massive head start in understanding security monitoring. I originally thought I was starting completely from scratch with technology, but tracking moving parts, watching for system bottlenecks, and maintaining strict safety compliance on an airfield requires the exact same high-consequence mindset as managing a SIEM dashboard. Finding out that my real-world operational background translates directly into digital defense was an incredible confidence booster.

5.2 One piece of advice

If I had to give another newcomer advice, it would be to never assume that a software package is protecting you just because it is running on default settings. Default configurations leave massive blind spots, and true security means rolling up your sleeves to audit raw logs and write sharp, targeted detection rules. Also, expect things to break along the way. When my text configurations got scrambled or the Python streams went dark, I didn't treat it as a failure—I just looked at it as a giant Sudoku or KenKen grid where I needed to logically find the missing piece to keep the data flowing.

5.3 My favorite resource

My absolute favorite resource was simply digging into the live /var/log/auth.log file on our Linux target system. Instead of just reading theory out of a textbook, being able to actively watch the raw text strings populate the terminal the exact second a simulation ran taught me how log generation and SIEM parsing mechanics function in a practical, hands-on way.

5.4 Thank somebody (x2)

I want to extend my gratitude to the open-source development community behind Atomic Red Team, with a special nod to researchers Matt Graeber and Casey Smith. As a 54-year-old student diving into tech for the first time, having access to their free framework allowed me to safely mimic real-world adversary behavior with simple commands so I could focus entirely on mastering log diagnostics and telemetry analysis.

  1. References

  2. Wazuh SIEM Deployment Guide

Wazuh Official Documentation. "Installation Guide: Step-by-Step Central Components Deployment." Published 2026. Available at Wazuh Documentation.

  • This installation guide was incredibly helpful for verifying that our central manager components were listening correctly on the network. I used it to make sure our server status was active before we ever tried to link our endpoint machine to the main dashboard.
  1. Red Canary Threat Emulation Framework

Red Canary. "Atomic Red Team: Open-Source Library for Adversary Emulation Controls." Powered by Red Canary. Published 2026. Available at Atomic Red Team Framework.

  • This documentation was essential for helping me set up and launch our local sudo security tests safely. It showed me how to manually import the framework manifest file using absolute paths so our attack scripts ran cleanly without throwing permission errors.
  1. MITRE ATT&CK Matrix for Enterprise

MITRE ATT&CK. "Abuse Elevation Control Mechanism: Sudo and Sudoers (T1548.003)." MITRE Corporation. Published 2026. Available at MITRE ATT&CK Matrix.

  • I used this matrix library to study how real-world hackers exploit weak administrative settings to gain absolute control over a Linux system. It helped me understand the exact attacker behavior we were trying to mimic during our privilege escalation lab.
  1. Gobuster Web Enumeration Utility

OJ Reeves. "Gobuster: Directory/File, DNS, and VHost Busting Automation Tool in Go." GitHub Repository. Published 2026. Available at Gobuster on GitHub.

  • This project documentation provided the exact command line arguments needed to fire up our aggressive directory scans on port 8000. It guided me on how to map our fuzzer directly to the system's built-in wordlists to test our application's response limits.
  1. Wazuh Agent Monitoring Specifications

Wazuh Official Documentation. "Log Data Collection and Local File Monitoring Configuration Guide." Published 2026. Available at Wazuh Agent Installation Guide.

  • This configuration guide was the ultimate lifesaver for fixing our broken Python web server visibility blackout. It explained how to rewrite our agent files to treat raw text files as generic syslog streams, which kept our data pipeline flowing straight to the dashboard.