I never imagined cybersecurity would become part of my life. For years, it felt like a world meant for other people — people who grew up technical, people who understood the language of logs and alerts. I was busy building a different kind of life, one that had nothing to do with SIEM dashboards or process creation events.

And then someone stole a piece of me. The most valuable piece of any person - their identity.

It didn’t happen with flashing warnings or dramatic breaches. It happened quietly — through paperwork, credit applications, and digital fingerprints I didn’t know how to read. I remember the moment I found out - the shock, the confusion, the anger, and the hollow feeling of realizing I had no idea how it happened or how to stop it. There’s a particular kind of vulnerability that comes from knowing someone slipped into your life through a door you didn’t even know existed.

That moment stayed with me.

So when I reached a point in my life where I wanted to challenge myself — really challenge myself — I chose cybersecurity. A mid‑life career change, zero experience, and a determination born from being hurt once and refusing to be scared the same way again. I wanted to rebuild my confidence and learn the very systems that failed to protect me.

This SIEM project wasn’t just an assignment. It was a way of taking back control. A way of proving to myself that I could understand the signals, the warnings, the stories hidden inside a system. It was the first time I felt like I wasn’t standing on the outside of cybersecurity looking in — I was finally stepping into the room. TripleTen became the place where I decided to arm myself, because knowledge is the greatest weapon you can have. So this is where I introduce myself as a former waitress with a photography business who once had her identity stolen, left to deal with the with the outcome for years, who needed a change in life in my 50s. Although it had been 20 years, that incident was never far from my memory. When I was presented with the opportunity to learn the trade of the future, it was that incident that made me choose yes. Just having the knowledge is a great victory for me but if I could help just one person, in any capacity with my cybersecurity knowledge, then I know I made the right choice.

This project didn't just teach me how to configure a SIEM - it taught me how to see the signals that once felt invisible. It showed me how much power there is in understanding what your system is trying to tell you, and how learning to read those signals can change the way you see yourself. In my final thoughts, I'll share the biggest lessons I learned, the confidence I gained, and why this project became a turning point in my cybersecurity.

Replicable Procedure for Implementing My SIEM Modification

My modification was integrating Windows Defender logs into Wazuh so my SIEM could detect malware events.

1. Open Event Viewer: Applications and Services Logs → Microsoft → Windows → Windows Defender → Operational
2. Confirm the Operational log is enabled.
3. Open the Wazuh agent config: C:\Program Files (x86)\ossec-agent\ossec.conf
4. Add the Defender event channel: Microsoft-Windows-Windows Defender/Operational eventchannel
5. Save the file.
6. Restart the Wazuh agent service.
7. Verify ingestion in Wazuh Manager: Security Events → Windows Defender

Mistake Made During Setup
[!failure]

I forgot to restart the Wazuh agent after editing the configuration file.

Because of this, Wazuh never reloaded the new log source, and Defender events didn’t appear. Restarting the agent fixed everything instantly.

Experiment #1

FAILED LOGIN ATTEMPTS
Description-
I intentionally entered the wrong password on ad01 several times to generate authentication failures.

Expected Event IDs

• 4625 — Failed Logon

• 4771 — Kerberos pre‑auth failed

• 4776 — NTLM authentication failed

Results-
Wazuh displayed failed login alerts showing:
• username
• logon type
• failure reason
• source IP

*It was the first time I saw how clearly Windows records authentication attempts.

Experiment #2

EICAR MALWARE DETECTION
Description-
I downloaded the harmless EICAR test file to trigger Windows Defender.

Expected Event IDs

• 1006 — Threat Detected

• 1116 — Malware Detected

• 5007 — Settings changed

Results-
Defender immediately quarantined the file and generated Event ID 1006. Wazuh displayed the alert with full metadata, proving my modification worked.

Experiment #3

SYSMON PROCESS CREATION(Event ID 1)
Description-
I ran a simple script that launched cmd.exe and powershell.exe to generate Sysmon Event ID 1.

Expected Event IDs

• Sysmon Event ID 1 — Process Creation

Results-
Sysmon captured:

• process name
• parent process
• command line
• user
• GUID

Wazuh displayed each event with full detail.

Mistake Made During Experiments-

[!failure]
I assumed Sysmon was already installed — it wasn’t.

My first attempt produced no Sysmon logs. Installing Sysmon fixed the issue.

Summary of Findings-

Across all three experiments, I learned that a SIEM is only as powerful as the visibility you give it:

• Failed logins showed authentication behavior.

• EICAR proved Defender logs were integrated.

• Sysmon revealed process behavior and system activity.

*Each experiment taught me how to read signals that once felt invisible.

Advice on avoiding mistakes

[!tip]• Always restart the Wazuh agent after changing the configuration.

• Always confirm Sysmon is installed before running Sysmon experiments.

*These two checks would have saved me hours.

The coolest thing I learned

The coolest thing I learned was how much information a system quietly records — and how empowering it feels to finally understand it.

One piece of advice

Don’t be afraid of mistakes. Every misstep teaches you something essential. Break things, fix them, and keep going.

My favorite resource

Sysmon‑Modular by Olaf Hartong — it helped me understand Sysmon’s event structure and gave me confidence to explore deeper.

Thank you (gratitudes)!

Thank you to TripleTen for giving me the structure and support to take on something I once thought was impossible.

And thank you to myself — for choosing to walk through a door I never saw, into a world I never thought I could belong to.

REFERENCES-

Microsoft Defender Antivirus Event Reference

Author: Microsoft Corporation
Affiliation: Microsoft Learn Documentation Team
Date Published: Updated continuously (most recent major revision 2024)
Why It Was Useful: This resource provides authoritative definitions for Windows Defender Event IDs such as 1006, 1116, and 5007, which were essential for validating malware detection during the EICAR experiment.
Microsoft Defender threat events

Windows Security Log Event ID Documentation

Author: Microsoft Corporation
Affiliation: Microsoft Learn — Windows Security Auditing Date Published: Updated 2023–2024
Why It Was Useful: This documentation explains authentication‑related events like 4625, 4771, and 4776, which formed the backbone of your Failed Login Attempts experiment and helped confirm proper SIEM ingestion.
Windows failed login event IDs

Sysmon (System Monitor) Official Documentation

Author: Mark Russinovich & Microsoft Sysinternals Team
Affiliation: Microsoft Sysinternals
Date Published: Updated 2024
Why It Was Useful: This reference defines Sysmon Event ID 1 and its metadata fields (Image, CommandLine, ParentImage, ProcessGuid), enabling accurate validation of process creation logs in Wazuh.
Sysmon Event ID 1 process creation

Wazuh Windows Agent & Event channel Documentation

Author: Wazuh Engineering Team
Affiliation: Wazuh, Inc.
Date Published: Updated 2024
Why It Was Useful: This documentation explains how Wazuh ingests Windows Defender, Sysmon, and Security logs using the and eventchannel configuration, directly supporting your Modification #1 implementation.
Wazuh Windows agent setup

MITRE ATT&CK Technique T1110 — Brute Force

Author: MITRE Corporation
Affiliation: MITRE ATT&CK Threat Intelligence Program
Date Published: Updated 2024
Why It Was Useful: This technique outlines brute‑force behavior patterns and aligns with your Failed Login Attempts experiment, providing industry‑standard justification for monitoring authentication failures.
MITRE ATT&CK T1110