Purple Team 1: SIEM & CVE-ridden Agent VS. unprivileged insider

Malicious Insider threat simulation

Insider threats themselves have seen a rise in occurrence earlier this decade, but more relevant to this writeup is the fact that such contexts make great testing scenarios: This means getting a full taste of SIEM rule efficiency and protocols in an environment that allows for vertical maneuvers and under-the-radar techniques.

The goal of this homelab simulation is to calibrate a SIEM-agent local infra setup and to test stealth techniques; I will create more complex sequel scenarios in the future, involving factors such as modern machines and AI. **28.Aug.2026

• Manager: siemBuntu 172.16.227.131
• Target agent: basic_pentesting 172.16.227.150 (**customized https://www.vulnhub.com/entry/basic-pentesting-1%2C216/) - Attacker: artix 10.62.181.249

Wargame plan:

1. Attacker gets guest access (unpriv) to ubuntu 16.04 agent;
2. Manager receives first SIEM alerts;
3. After initial foothold, attacker 10.62.181.249 conducts recon and weaponization stage;

• The goal is to correlate as many logs to attacks and respectively to conduct as much CIA impact.
• The insider should aim to avoid detection when using attacking machine (unknown device in local network).

Attacker privileges: Guest account on Agent and LAN access.

Monitoring policy: Only logs correlating to MITRE ATT&CK techniques or to GDPR, HIPAA or Firewall entries with rule.level (severity evaluation) that is > 7 will be noted here.

Wargame's Stages

Both virtual machines are powered on, Wazuh dashboard is open on host machine with all services running as expected. Let's hack!

I. Initial Foothold

As previously stated, the threat actor here is an insider who has access to a Guest session within the Ubuntu agent VM. Login was successful, but the server is secured in such a way that does not allow unnecessary actions: No NMAP, curl or exploit tools installed for instance, which is ideal from a IAM perspective.

For this scenario, the insider decides that the best way to impose CIA impact while maintaining the required stealth is targeting Confidentiality, so the main threat vector should be active data exfiltration: The threat is backdooring

II. Reconaissance

What is not ideal is the Ubuntu version used by Agent VM. Running

uname -r && cat /etc/os-release

will reveal the fact that the Agent is running a version from the Age of Terry Davis (ubuntu 16.04). This itself is a sign that the machine may be running other outdated processes which may be mapped to CVEs; Since the insider threat actor has access to the network, the question is if to preserve stealth or to risk detection by 'connecting' the attacking device and also running an Nmap scan;

Before going in guns-blazing, it would be better to look for threat vectors: With the aforementioned tactic of affecting Confidentiality beforehand, the first attack would be to create a backdoor script on the guest machine.

— Blue team note: Every time guest logs in, a new group and user is created. If any hypothesis related to events is created by the security side, it will be assumed as insider threat automatically.

III. Weaponization

Achieving a backdoor would have meant both enhanced stealth and evolved threat vector, except the target machine correctly applied a policy to enable only necessary incoming traffic (port 1514:1515/tcp for agent functionality). It is quite ironic, that the target applied a strict-necessity traffic policy but they did not patch any vulnerabilities. This calls for the next logical step: Recon on attacker machine (10.62.181.249)

II/2. Tooling-based recon

A stealth nmap scan was not able to reveal any TCP services. It is up to the insider to select from one of the many kernel/OS CVEs indexed by metasploit.

Note: There I realized that I had made the mistake of overhardening the agent machine's firewall to the point where it became nearly invisibible to the LAN, denying any scan or exploit. Ended up only allowing two patched ports, remediated at this part by restarting machine with ufw disabled: Logged in from privileged and reverted to vanilla ufw config.

III. Weaponizing CVE exploit

A fresh -sV -sS scans shows that the machine's administrators have now activated more TCP ports, including for Apache server 2.4.18, CVEs are plenty, but they are NOT stealthy; Some include path traversal, and most common denial of service. Another open service was ProFTPD-1.3.3c, which can lead to compromise of assets. For convenience purposes, I resorted to the metasploit framework console for obtaining the exploit. The command which transitioned to the next killchain phase was

use unix/ftp/proftpd_133c_backdoor

IV. Delivery

To establish a backdoor, the attacker resorts to default exploit configuration, which establishes a reverse shell; This naturally failed, since while the first connection (attacker -> target) lands, the reverse connection (target -> attacker) does not reach as intended since both machines are in different subnets.

Setting custom payload fixed the error, where 'set payload cmd/unix/bind_perl' in the console configures a bind shell instead, where the attacking flow fits the context.

V. Exploitation

As seen in the image above, the FTP connection did not trigger any critical rules, aligning with the initial stealth objectives. The backdoor succeeded with root privileges secured by the insider.

Backdoor source: 10.62.181.249 destination: 172.16.227.150

From there on, attacker can perform actions such as deleting Wazuh agent files to make the endpoint 'go AWOL' from the SIEM dashboard.

Debrief

### Cyber Kill Chain evaluation

Scenario peculiarity: Initial foothold preceded recon;

• Attack flow became congested at stage II to stage III, where any attack vector hypothesis was met by stiff resilience from the defensive customization by the target admin. -> Compromise by reconfiguring was needed to create two threat vectors (TCP ports 21, 80).
• Threat actor ran an automated scan from their own IP address which raised a good deal of alerts, especially path traversal related, and is the only realistic point that the defending party would have picked up on a real attack.
• The latter part of Weaponization stage was when the exploited vulnerability started being elaborated on by attacker.

Stages IV-V were when the problem became beyond stopping from a detection standpoint (providing security operations did not thoroughly investigate the malicious activity on HTTP); Exploit was obtained and launched on 10.62.181.249.

### NIST CSF evaluation

Identify — Improper assessment for needs of patching and vulnerability remediation.

Protect — Since in the end firewall was disabled by privileged and was the only factor which allowed malicious access (besides the guest login), it can be stated that firewall configuration was the critical decisive factor in progressing on the Cyber Kill Chain.

Detect — Manager-agent SIEM link was properly set up but not configured to catch some of the malicious traffic.

Respond — While not covered in this post (took more time than initially intended to cover response, read "Lessons Learned"), the valid solution once the threat vector was exploited and impact noticed would be to isolate the machine and conduct threat hunting, which would have led back to the conspicuous HTTP traffic.

Recover — Anything related to the system is in total control of the threat actor by the end, so most of the recovery planning should focus on the LAN's other devices in case of threat propagation.

### Lessons learned

From a purple hat perspective, issues have arisen as a side effect of biting more than I can chew: A hardened, unconventional VM and attack techniques that would require heavy query filtering and rule customization by SIEM for proper detection.

• Intended goal was reached (stealth + CIA impact + detection footprint recognition, here time-based filters revealed the pattern clues).

Blue Team lessons:

• The personal lab setup is not enough to detect more complex TCP/ socket traffic; Rule customization and AI assisted pipelines will be implemented in the future, along with related technologies such as SOAR.

Red Team lessons:

• Kernel & OS CVEs should be investigated the very last as they require the most complexity (reliance on misconfigurations/ dependency packages); Ports which require prioritized attention are TCP 21, 22 and 80.