Architecture Overview
Enterprise Virtual Environment
A comprehensive breakdown of my multi-VM infrastructure and live SIEM pipeline
I engineered a localized, enterprise-grade cybersecurity environment utilizing Oracle VIrtualBox. This architecture consists of custom NAT networks designed to safely route and segment traffic between four primary machines: a centralized Ubuntu-based SIEM, a primary Windows Server acting as a Domain Controller, a Windows 11 endpoint, and a Linux-based vulnerable web application. This foundational hypervisor setup allows for the deployment of Active Directory services and real-time defensive telemetry.
To ensure continuous monitoring of endpoint activity, I deployed and manually configured the Splunk Universal Forwarder across my Windows targets, as well as on my Linux desktop vm. By actively managing the inputs.conf and outputs.conf files within the system directory, I engineered a highly specific data pipeline. This configuration dictates the exact routing of both native Windows Security logs and Sysmon operational telemetry, shipping them off of my endpoints, and landing them directly into the centralized Ubuntu SIEM for real-time indexing and analysis.
To guarantee the SIEM indexes high-value, actionable data, I manually configured the inputs.conf file to target specific event channels. This configuration explicitly commands the Universal Forwarder to monitor core Windows Event Logs (Security, System, and Application) alongside dedicated telemetry from Microsoft Sysmon (Microsoft-Windows-Sysmon/Operational). Also, by controlling the ingestion at the endpoint level, the architecture reduces unnecessary log noise and optimizes search performance for the centralized indexer.
To protect the integrity of the data pipeline, I implemented System Access Control Lists (SACLs) directly on the Splunk Universal Forwarder configurations. By establishing granular Object Access auditing on the inputs.conf file, the Windows endpoint is forced to generate a high-priority Event 4663 alert if any user or process attempts to tamper with, modify, or delete the logging parameters. This ensures that any attempt to blind the SIEM is immediately recorded and flagged.
To establish a robust detection posture across the network, I configured advanced Group Policy Objects (GPOs) from the primary Domain Controller. By strictly enforcing 'Success and Failure' auditing for both Kerberos Authentication and Service Ticket Operations, the domain automatically generates critical security telemetry (such as Event IDs 4768 and 4769). This centralized policy ensures that all authentication attempts and potential lateral movement across the network are permanently logged and primed for SIEM ingestion.
Utilizing the Splunk Search & Reporting interface, I crafted targeted queries to isolate specific endpoint telemetry. By applying the machine name filter Win-Target02, the search effectively cuts through domain noise to return precise Kerberos authentication events generated by that exact endpoint. Expanding the indexed logs reveals the granular details of the Kerberos ticketing process. The capture of Event ID 4769 confirms that a Kerberos service ticket was successfully requested by the endpoint. This level of deep visibility allows for the active monitoring of lateral movement, privilege escalation attempts, and overall authentication health across the simulated enterprise network.
Next, I wanted to conduct a robust vulnerability assessment. I deployed the Greenbone Vulnerability Management (GVM) suite using Docker Compose. The command sudo docker-compose up -d successfully initialized all required microservices, ensuring a stable environment for subsequent scanning.
I explicitly and intentionally misconfigured a few common, well-known services. The easily identifiable services include openssh, telnet, ftp, and snmp. I intentionally misconfigured them so that my OpenVAS vulnerability scan would deliberately and quickly recognize the insecure attack surface of my network. I wanted to provide actionable results in my scan, as opposed to a low-risk grading. Most of the misconfigurations are easily reversible, and the entire process is being conducted on my privately established NAT network, to ensure that these temporary follies do not pose any real threat to my personal infrastructure.
As evidenced by the results, the OpenVAS scan successfully identified the insecure services that I deliberately introduced. This highlights the critical importance of regular, automated vulnerability scans. SNMP is rated as severe due to the default community strings present in the configuration file above. This could allow an attacker to perform reconnaissance by querying system information, running processes, and network connections.
Next, I installed impacket to demonstrate how an attacker performs a credential dump. This a common vector that gets exploited after an attacker uses reconnaissance tactics to gather information about your network. The script ~/.local/bin/secretsdump.py was directed against my domain controller, and as you can see sensitive password hashes and kerberos keys were made available in the Linux terminal of the attacking machine.
Additionally, I ensured that my Splunk Forwarder was properly configured so that the necessary event data needed to detect the attack was logged accordingly. The images of the Splunk user interface display a rapid succession of events 5156 and 4663, which could be a potential indicator of malicious activity. Event ID 5156 means that the Windows Filtering Platform has allowed a connection to proceed either inbound or outbound, and 4663 means an object was accessed.
Finally, I wanted to demonstrate effective security monitoring at the application-level. I installed OWASP's intentionally vulnerable Juice Shop application on my Linux desktop virtual machine. I configured it with the Nginx reverse proxy, that way I could target the backend API directly with canonicalized URL attacks.
Next, I installed the Zap penetration tester and examined Juice Shop. This enabled me to analyze certain parameters pertaining to classic attack vectors such as SQLi, XSS, SSRF, etc. While Juice Shop is a single page application, the lack of server-side input validation and parameterized queries allows malicious actors to bypass client-side restrictions and execute destructive commands directly against the backend database. You can see from the results of the test that the script '( is a permissible form of input, and could lead to a potential SQLi.
To finish things off, I constructed a Web Attack Payload Panel under the Splunk Dashboards section for my Linux desktop virtual machine. It utilizes a highly specific and developed SPL string to identify and record advanced forms of SQLi, XSS, SSRF, Command Injection, and Directory Traversal. The rest of the dashboards can be viewed under the Splunk Panels page on the menu.
The canonicalized URLs that I used to trigger SQLi and XSS events under this panel are as follows:
​
-For XSS:
​
http://192.168.10.40/rest/products/search?q=%3Ciframe%20src=%22javascript:alert('SOC%20Test')%22%3E
​
-For SQLi:
​
http://192.168.10.40/rest/products/search?q=apple'%20OR%201=1--
