Centralize evidence
Bring phishing-related web and system events into Splunk rather than inspecting separate logs manually.
← Back to projects
Project 06 / Cybersecurity
Ethical Phishing & Cyber Defense Evaluation System
A controlled academic cybersecurity environment that connects ethical phishing simulation with Apache log collection, Splunk SIEM analysis, structured field extraction, dashboards, and network-level observation.
01 · SourceApache access logsHTTP requests and responses
→02 · TransportUniversal ForwarderMonitor and send events
→03 · AnalysisSplunk EnterpriseIndex, Regex, SPL, dashboards
Supporting evidence · EttercapSeparate host discovery and traffic observations in the authorized lab
Simplified, documented log pipeline. The report's broader conceptual architecture is not presented as independently verified end-to-end integration.
The problem
Phishing simulation and defensive monitoring are often treated as separate exercises.
The project report identifies a visibility gap: phishing-awareness exercises can measure how users react, while server, network, and SIEM tools separately collect technical evidence. When those activities are isolated, it is difficult to trace a suspicious interaction from the simulated event through the generated web and network logs and into the defensive monitoring workflow.
The project therefore explored a unified lab where controlled phishing activity could be observed through Apache logs, centrally collected in Splunk, transformed into structured fields, queried with SPL, visualized in dashboards, and compared with network observations from Ettercap.
Project objectives
Evaluate the complete path from controlled activity to defensive evidence.
Structure raw logs
Turn Apache access events into useful fields that can support filtering, reporting, and investigation.
Analyze suspicious patterns
Use SPL searches and visualizations to study HTTP activity and other indicators in the controlled environment.
Add network context
Use Ettercap observations to compare host and connection behaviour with the application-level evidence seen in Splunk.
System design
A multi-layer lab links controlled phishing activity, web-server evidence, SIEM analytics, and network observation.
The report's architecture combines an ethical phishing layer with log collection and forwarding, Splunk-based indexing and monitoring, dashboards, and supporting security tools. Apache provides web-access evidence, the Universal Forwarder transports the monitored access log, Splunk performs indexing and analysis, and Ettercap adds a separate network observation perspective.
Controlled simulationauthorized lab activity
→
Apacheaccess & error logs
→
Universal Forwarderlog transport
→
Splunkindex · extract · search · visualize
Important scope: this is an academic, controlled evaluation environment. The public case study focuses on defensive engineering and does not reproduce captured credentials or operational attack instructions from the report.
Implementation
The useful engineering work is in making the evidence pipeline function end to end.
Virtualized lab and network preparation
Ubuntu and Kali Linux systems were used in an isolated environment. The report documents static addressing, connectivity checks, and separate systems for the Splunk server and Apache server so data could move predictably through the lab.
Apache and Splunk service setup
Apache generated web-access events while Splunk Enterprise provided the central search and analysis platform. A dedicated non-root Splunk service account was used rather than running the service as root.
Universal Forwarder pipeline
A dedicated web index and apache_access source type were configured. The Forwarder monitored Apache's access log and transmitted the events to Splunk through the configured receiving pipeline, followed by service restart and ingestion verification.
Permissions and operational debugging
The Splunk service initially needed permission to read the Apache log owned by root:adm. The report documents resolving that dependency so the Forwarder could continuously monitor the source file.
Custom Regex field extraction
Raw Apache events were not sufficient for structured reporting. After Splunk's automatically generated extraction was inaccurate, a custom regular expression was refined to expose fields including client IP, timestamp, method, URI, status code, request size, referrer, and user agent.
SPL search and visualization
The extracted fields were then used with Splunk Search Processing Language for filtering, field-based analysis, deduplication where needed, tabular views, top-value analysis, and visual summaries.
Network observation with Ettercap
Ettercap supplied a second source of defensive evidence by showing hosts, connections, plugin-based indicators, and abnormal communication patterns inside the controlled test network.
Implementation evidence
Sharper source screenshots show the actual lab environment more clearly.
These screenshots come from the original source captures instead of low-resolution report-page exports. The portfolio keeps the emphasis on defensive engineering and security visibility, so any credential-capture results or submitted-secret screenshots are intentionally excluded from the public case study.
Modeling and controlled simulation
Splunk collection, parsing, and analysis
web index.
Network observation with Ettercap
Select any evidence image to inspect it in the full-screen viewer
Results
Apache access events were collected, structured, and investigated in Splunk.
Apache events reached Splunk
The report verifies successful ingestion into the configured web index with the apache_access source type.
Raw data became structured
The custom extraction exposed meaningful HTTP fields, allowing field-aware searches and report generation instead of treating Splunk as only a raw-text search engine.
SPL supported investigation
Searches, filtering, statistics, deduplication, tables, and visualizations were used to make suspicious access behaviour easier to interpret.
Network observations complemented SIEM data
Ettercap's host and connection views added contextual evidence around traffic generated inside the controlled environment.
The report demonstrates functionality and an end-to-end lab workflow. It does not provide independently validated production benchmarks, a measured enterprise-scale detection rate, or evidence of commercial deployment, so this case study does not claim those outcomes.
Engineering learnings
The project is strongest as a log-engineering and security-observability case study.
01 · Collection is only the first step
Receiving events in a SIEM does not automatically make them useful. Correct source typing and field extraction determine whether analysts can query and report on the data effectively.
02 · Permissions are part of the data pipeline
A perfectly configured forwarder still fails if its service account cannot read the source logs. Operational Linux configuration was therefore part of the engineering problem.
03 · Automatic parsing is not always enough
The report explicitly records that Splunk's automatically generated extraction was inaccurate, leading to a custom Regex solution and verification against the real Apache events.
04 · Multiple evidence sources improve interpretation
Application logs, SIEM searches, dashboards, and network observations each expose different parts of the same controlled event sequence.
Future improvements
Separate demonstrated functionality from the report's proposed next stage.
Potential next steps include more diverse log sources, robust alert validation, stronger reporting, and carefully evaluated anomaly detection. These remain future directions. These are future directions, not features presented here as already implemented.