Wazuh Agents
AWS Deployment • Detection Engineering • Threat Simulation • SOC Investigation
Project Type: Cloud-Based SIEM Monitoring Lab
Tools Used: Wazuh (SIEM), AWS EC2, AWS Lightsail, Windows Server, Ubuntu Linux
Focus Areas: File Integrity Monitoring, Privilege Escalation Detection, Linux Authentication Monitoring
Environment: AWS-based deployment consisting of a Wazuh manager and monitored Windows and Linux endpoints.
Objective: Simulate realistic attacker behaviour, detect suspicious system events through SIEM monitoring, and investigate alerts using a structured SOC-style workflow.
Simulations: Registry persistence, unauthorized account creation for privilege escalation, and repeated SSH authentication failures simulating brute-force activity.
The lab environment was built in AWS to simulate a small security monitoring setup with one Wazuh manager and two monitored endpoints. Although this is a small and rather compact lab, it still demonstrates the same principle used in larger SOC environments: multiple systems generate logs, those logs are forwarded to a central analysis point, and suspicious behaviour is investigated from there.
The Wazuh manager was installed on an Ubuntu EC2 instance and acts as the central log analysis point for the lab. A Windows Server EC2 instance was configured as the Windows endpoint and monitored for event log activity, file changes, and registry changes. An Ubuntu Lightsail instance was configured as the Linux endpoint and monitored for authentication and system activity. A third device (JackWindows) is also configured but not demonstrated throughout this lab
Both the Windows Server and Linux agent were configured to communicate with the same Wazuh manager. This made it possible to review suspicious events from multiple operating systems through one monitoring platform rather than checking each host individually.
The Wazuh manager was installed first so that the two monitored endpoints could later be connected to it. Once the manager was active, the Windows and Linux agents were installed and their configurations were updated so that they forwarded logs to the manager for analysis.
The Wazuh manager was installed on the Ubuntu EC2 instance using the official Wazuh installation script:
curl -sO https://packages.wazuh.com/4.7/wazuh-install.sh sudo bash wazuh-install.sh -a
The Windows endpoint was then deployed on a Windows Server EC2 instance. The Wazuh agent was installed and the ossec.conf configuration was updated so that the agent pointed to the Wazuh manager. After the agent service started, the endpoint was confirmed as connected.
The Linux endpoint was deployed on Ubuntu Lightsail. The Wazuh agent was installed, the agent configuration was updated to point to the same Wazuh manager, and successful registration was verified once the service came online.
curl -s https://packages.wazuh.com/4.x/agent/install.sh | sudo bash sudo nano /var/ossec/etc/ossec.conf
The Wazuh manager requires several network ports to allow agents to register, forward security logs, and allow administrators to securely access the monitoring platform. The following ports were enabled:
Wazuh analyses incoming log data using a rule-based detection engine. Each event collected from monitored endpoints is evaluated against predefined detection rules designed to identify suspicious behaviour associated with attacker activity. A common theme during my Security+ studies was the emphasis placed on the difference between a Security Information and Event Management (SIEM) and a Security Orchestration, Automation and Response (SOAR). Before we continue looking at the three simulations, I think it's relevant to distinguish a key difference between them. A SIEM does more than store logs: it actively evaluates them for correlations such as indicators of compromise and behaviours that match known attack patterns aiding in the identification of threats. A SOAR goes one step futher and leverages automation as a response to a particular incident.
To evaluate the monitoring environment, several attacker techniques were simulated that commonly appear during real intrusions. These activities reflect different stages of attacker behaviour including persistence, privilege escalation, and credential abuse.
In many incidents, attackers first gain a foothold on a system, then attempt to maintain access, increase privileges, and expand control over the environment. The simulations in this lab were selected to mirror that progression across both Windows and Linux endpoints.
The simulated sequence in this lab can be summarized as follows: after initial access, the attacker establishes persistence on Windows through a startup registry modification, escalates privileges through unauthorized account creation and administrator group assignment, and then attempts credential abuse through repeated failed SSH authentication attempts on Linux.
When alerts were generated, a consistent triage process was followed. First, the alert details and affected host were reviewed. Next, surrounding logs were correlated to understand context. The initiating account or process was then identified, and finally the behaviour was assessed to determine whether it reflected expected administration or suspicious attacker activity.
This scenario focuses on persistence. Persistence refers to techniques that allow an attacker to maintain access to a system even after a reboot or user logging off unbeknown to them. On Windows systems, one common method is modifying the startup-related registry keys so that a malicious or unauthorised programme automatically launches when the Operating System (OS) starts.
To simulate this behaviour, a value was added to the Windows Run registry key. This created a startup entry that would automatically execute the chosen binary whenever the system booted. Because this registry path is commonly abused by malware, it is a valuable location to monitor within a SIEM environment.
Wazuh generated a detection alert after identifying the registry modification. In a production environment, this type of alert would indicate that a high-risk configuration area had been altered and would require further validation. The analyst would need to determine whether the change was part of a legitimate software installation or whether it represented unauthorized persistence behaviour. In real investigations, this matters because persistence often allows attackers to survive reboots and regain execution without needing to exploit the system again.
MITRE ATT&CK is a widely used framework that documents common adversary tactics and techniques observed in real intrusions. Mapping alerts to MITRE ATT&CK helps analysts understand not just what happened, but why the behaviour is important within the broader context of an attack chain.
| Tactic | Technique | ID | Why It Applies |
|---|---|---|---|
| Persistence | Boot or Logon Autostart Execution | T1547 | The registry Run key was modified so a program would launch automatically during startup. |
| Defense Evasion | Modify Registry | T1112 | The Windows registry was altered in a way that could be used to maintain access or alter system behaviour. |
This scenario focuses on privilege escalation. Privilege escalation occurs when an attacker gains higher levels of access than originally intended, often to perform administrative actions, disable security controls, or move laterally through an environment.
To simulate this behaviour, a new local user account was created and then added to the local Administrators group. This is significant because the creation of unauthorized privileged accounts is a common post-compromise technique. It allows an attacker to maintain access using a legitimate-looking identity while gaining the permissions needed to control the host.
Wazuh generated a detection alert after identifying both the account creation and administrative group membership change. This type of activity is high risk because a newly created privileged account can be used immediately for persistence, system control, or further attacker actions. In a real SOC, this alert would often be prioritised for immediate review because administrative accounts can quickly be used to disable protections, access sensitive files, or pivot to additional systems.
A further investigation into this log message confirms that the user account was created and then shortly after was added to a security-enabled local group confirming privilege escalation
Privilege escalation is often a turning point in an intrusion because it allows an attacker to move from limited access to full control of a host. Mapping the behaviour to MITRE ATT&CK helps analysts classify the activity according to known adversary techniques and document it consistently.
| Tactic | Technique | ID | Why It Applies |
|---|---|---|---|
| Persistence | Create Account | T1136 | A new local account was created, which could be used to maintain access to the system. |
| Privilege Escalation | Account Manipulation | T1098 | The newly created account was added to the Administrators group to gain elevated permissions. |
This scenario focuses on credential access and brute force activity. Brute force attacks involve repeated authentication attempts against an account or service in the hope of guessing a valid password.
To simulate this behaviour, repeated failed SSH login attempts were generated against the Linux host. Authentication logs were then collected and monitored by Wazuh. Failed SSH activity is important to detect because repeated failures can indicate password guessing, automated login attempts, or credential stuffing against exposed services.
Wazuh generated a detection alert based on repeated failed authentication attempts. In a production SOC environment, this type of alert would lead analysts to investigate whether the activity came from known infrastructure, whether a valid account was eventually compromised, and whether firewall or account lockout controls should be strengthened. This matters because repeated failed authentication is often an early sign of brute-force activity or an attempt to gain initial access using stolen or guessed credentials.
Authentication abuse is an early and common step in many attacks. MITRE ATT&CK mapping helps analysts relate repeated failed logins to known credential access techniques and document how those attempts could progress into initial access if not stopped.
| Tactic | Technique | ID | Why It Applies |
|---|---|---|---|
| Credential Access | Brute Force | T1110 | Repeated authentication failures indicate password guessing against SSH accounts. |
| Initial Access | Valid Accounts | T1078 | If the attack succeeded, the adversary could gain access using compromised legitimate credentials. |
Across the three simulated attack scenarios, the SIEM platform successfully detected suspicious behaviour originating from both Windows and Linux systems. Each alert provided useful context including the affected host, timestamp, and the rule logic that triggered the detection.
From an analyst perspective, the investigation process involved reviewing alert metadata, correlating related logs, and determining whether the behaviour represented legitimate administrative activity or potential attacker behaviour. This reflects how SOC teams use centralized monitoring platforms to reduce investigation time and improve visibility across multiple systems.
These investigations demonstrate how a SIEM can help analysts identify suspicious activity early and begin incident response before an attacker gains long-term control of the environment.
The detection techniques demonstrated in this lab reflect monitoring practices commonly used in enterprise security operations centres. Registry monitoring, account management alerts, and authentication monitoring are core components of many SIEM deployments because they provide visibility into attacker behaviour that often occurs after initial compromise.
Even in a small lab, the same principles apply: logs from multiple systems are collected, suspicious behaviour is identified through rule-based detections, and analysts use that information to investigate potential compromise. In larger enterprise environments, this model scales across many hosts, cloud assets, and user accounts.
At the same time, these detections have limitations. Advanced attackers may attempt to evade detection through log tampering, living-off-the-land binaries, or credential theft techniques that generate limited logging. In production SOC environments, detections like these would usually be supplemented by additional controls such as endpoint detection and response, network monitoring, and behavioural analytics to improve overall visibility.