Location Research Breakthrough Possible @S-Logix pro@slogix.in

Hunting Web Configuration Tampering Against Caddy Web Servers Through Configuration-Integrity Monitoring and Automated Security Response

Description

Caddy is an open-source web server and reverse proxy that can serve web applications and route requests to backend services. It commonly uses the human-readable Caddyfile format to define site addresses, routing behavior, reverse-proxy destinations, request handling, logging, and other web-server functionality. Caddy also supports dynamic configuration through its administrative API.

The target web application in this use case is OWASP Juice Shop, an open-source deliberately insecure web application designed for security training, demonstrations, and security-tool testing. Juice Shop is built using technologies including Node.js, Express, and Angular.

In this architecture, Caddy is the primary web-server target, while OWASP Juice Shop is the backend web application placed behind Caddy. Caddy forwards requests received at its web endpoint to the Juice Shop backend through its reverse-proxy functionality.

Web-server configuration files are security-sensitive because unauthorized modifications can change how a web application processes requests. An attacker who obtains sufficient access to a Caddy host may modify the Caddyfile or another configuration component to redirect traffic, expose unintended services, alter request-handling behavior, weaken security controls, or introduce unauthorized routing rules.

Caddy supports configuration reloads through the caddy reload command and its administrative API. Configuration changes can therefore be applied to the running web server without unnecessarily stopping the service.

In this use case, a controlled Caddy web server is deployed on Ubuntu Linux inside an isolated VirtualBox laboratory. OWASP Juice Shop is deployed as the controlled backend application and placed behind Caddy so that changes to Caddy routing or reverse-proxy configuration can be observed through controlled web requests.

Kali Linux is used as the authorized security-testing platform. A controlled configuration-tampering scenario is created by modifying the laboratory Caddy configuration in a way that changes the expected routing behavior toward the Juice Shop application.

The security-monitoring layer uses Wazuh File Integrity Monitoring (FIM) to monitor Caddy configuration files. Wazuh FIM can detect file creation, modification, and deletion and supports real-time monitoring of specified Linux directories. It compares monitored file attributes and checksums against its stored baseline and generates alerts when changes are detected.

When unauthorized configuration modification is detected, the SOC workflow generates a security alert and invokes a controlled Wazuh Active Response action. Wazuh Active Response can execute predefined or custom scripts when specified rules or alert conditions are triggered.

The controlled response restores the approved Caddy configuration, validates the restored configuration, reloads Caddy using its supported configuration-reload mechanism, and verifies that the Juice Shop web application has returned to its known-good state.

OpenSearch is used for centralized investigation and correlation of configuration-integrity alerts, Caddy activity, response actions, and post-remediation validation.

The complete workflow demonstrates a SOC/MDR-style detection and response process in which Caddy configuration tampering is detected as a security event and automatically contained through controlled configuration restoration.

Complete Security Operations & Incident Response Workflow: Caddy Deployment → OWASP Juice Shop Deployment → Configuration Baseline → Configuration-Integrity Monitoring → Unauthorized Configuration Change → Wazuh FIM Detection → Security Alert → Event Correlation → Automated Response → Known-Good Configuration Restoration → Caddy Configuration Validation → Caddy Reload → Juice Shop Service Validation → OpenSearch Investigation → Post-Response Monitoring

Existing Security Problem

Application: Caddy Web Server with OWASP Juice Shop

Caddy provides the controlled web-server and reverse-proxy environment, while OWASP Juice Shop is the named backend web application used to demonstrate the effects of Caddy configuration changes. Caddy can forward incoming requests to a backend service, making it suitable for placing Juice Shop behind the web-server layer. The Caddyfile defines web-server behavior through directives and site configuration. Caddy also supports configuration management through its administrative API and reload workflow.

Existing Problem:

A Caddy deployment can be exposed to configuration-tampering risk when an attacker obtains unauthorized access to the host, configuration files, deployment pipeline, or administrative control interface. An unauthorized modification to a Caddy configuration can alter the routing or behavior of the web service without necessarily modifying the Juice Shop application itself.

The security problem is therefore:

Caddy Web Server → Trusted Caddy Configuration → Unauthorized Configuration Modification → Configuration-Integrity Deviation → Changed Web-Server Routing → Changed Juice Shop Access or Web Behavior → Security Monitoring Alert → Incident Investigation → Containment and Configuration Restoration

The proposed SOC architecture establishes a known-good Caddy configuration baseline, continuously monitors the relevant configuration files, detects unauthorized changes, generates security alerts, and automatically restores the approved configuration through a controlled response mechanism. It then validates the Caddy configuration and the Juice Shop service after remediation, while OpenSearch supports centralized investigation and incident-timeline review.

Attack

Specific Attack: Unauthorized Caddy Web Configuration Tampering

The controlled attack scenario evaluates whether unauthorized modification of a Caddy configuration can be detected and automatically remediated by the security-monitoring architecture. The modification is designed to produce a measurable change in Caddy routing behavior toward the OWASP Juice Shop application while remaining within the isolated laboratory.

When the file-integrity deviation is detected, Wazuh generates the corresponding security event. A controlled Active Response mechanism then restores the approved configuration and triggers the required Caddy configuration reload. The response is validated by checking configuration integrity and the behavior of the OWASP Juice Shop web application.

Attack Behavior:
Kali Linux / Authorized Security Tester
→
Identify Caddy Configuration
→
Obtain Controlled Write Access
→
Modify Caddy Configuration
→
Configuration-Integrity Deviation
→
Wazuh FIM Detection
→
Security Alert
→
SOC Event Correlation
→
Automated Active Response
→
Restore Known-Good Configuration
→
Validate Caddy Configuration
→
Reload Caddy
→
Validate OWASP Juice Shop Web Behavior
→
OpenSearch Investigation
→
Post-Response Monitoring

Security Concept

Configuration Integrity Monitoring and Automated Incident Response:

The primary security concept is configuration-integrity monitoring. Critical web-server configuration files should have an established known-good state against which subsequent modifications can be evaluated. Wazuh File Integrity Monitoring provides this capability by monitoring specified files and directories and detecting creation, modification, and deletion events.

For this use case, the Caddy configuration is treated as a critical security asset, while the OWASP Juice Shop application is used to demonstrate the resulting web-service behavior. The second security concept is automated security response. Detection alone does not immediately restore a tampered web-server configuration, so the SOC workflow connects the integrity alert to a controlled Wazuh Active Response action. The response script restores the approved configuration, validates it, and reloads Caddy using its supported configuration-reload mechanism. The resulting application behavior is then verified through controlled requests to the OWASP Juice Shop service.

The secure processing flow is:

Caddy Configuration
→
Known-Good Configuration Baseline
→
Wazuh FIM Monitoring
→
Configuration Change
→
Integrity Comparison
→
Change Detected
→
Security Alert
→
SOC Rule Evaluation
→
Automated Response Trigger
→
Known-Good Configuration Restoration
→
Caddy Configuration Validation
→
Caddy Reload
→
OWASP Juice Shop Web-Service Validation
→
OpenSearch Investigation
→
Incident Closure / Continued Monitoring

Defensive Mechanism

Known-Good Configuration Baseline

A verified Caddy configuration containing the approved Juice Shop reverse-proxy routing is preserved as the approved security baseline.

Purpose

Provide a trusted reference for identifying unauthorized configuration changes.

Critical Configuration Monitoring

The Caddy configuration file and relevant configuration directories are monitored by Wazuh FIM.

Purpose

Detect unauthorized creation, modification, or deletion of monitored web-server configuration files.

Real-Time Integrity Detection

Wazuh FIM is configured for real-time monitoring of the designated Linux configuration path.

Purpose

Reduce the detection delay between configuration tampering and SOC alert generation.

Checksum and Attribute Validation

Wazuh compares monitored file checksums and attributes with its stored integrity baseline.

Purpose

Identify configuration-integrity deviations that may indicate unauthorized modification.

Configuration-Change Alerting

A Wazuh security rule evaluates the detected configuration-change event.

Purpose

Convert a raw file-integrity event into an actionable SOC security alert.

Security Event Correlation

Configuration-integrity events are correlated with Caddy and Ubuntu activity.

Purpose

Provide context for determining whether the configuration change is expected or suspicious.

Automated Configuration Restoration

A controlled Wazuh Active Response script restores the approved Caddy configuration when the defined tampering alert is triggered.

Purpose

Automatically return the monitored Caddy configuration to the known-good security state.

Configuration Validation

The restored Caddy configuration is validated before the active configuration is reloaded.

Purpose

Prevent an invalid or corrupted configuration from being applied to the running web server.

Controlled Caddy Reload

The validated configuration is applied using the supported Caddy reload mechanism.

Purpose

Restore the intended web-server behavior without unnecessarily stopping the running service.

Administrative API Protection

The Caddy administrative API is restricted to the intended local or controlled management interface.

Purpose

Reduce the risk of unauthorized direct control of the Caddy configuration.

Post-Response Service Validation

The Caddy-to-Juice-Shop web path is tested after automated remediation.

Purpose

Confirm that the restored configuration produces the expected application behavior.

Centralized Security Investigation

OpenSearch is used to correlate integrity alerts, Caddy events, response execution, and validation results.

Purpose

Provide a complete investigation timeline for the configuration-tampering incident.

Security Tools

Web Server / Reverse Proxy: Caddy

Caddy provides the controlled web-server and reverse-proxy environment.

Purpose
  • Host the web-service entry point.
  • Receive HTTP/HTTPS requests.
  • Route requests to OWASP Juice Shop.
  • Apply the Caddy configuration.
  • Provide the configuration target for integrity monitoring.

Target Web Application: OWASP Juice Shop

OWASP Juice Shop provides the named backend web application for the laboratory. It is an open-source deliberately insecure web application intended for security training and security-tool testing.

Purpose
  • Provide a real, named web application behind Caddy.
  • Act as the backend service for Caddy reverse proxying.
  • Provide observable web-service behavior.
  • Allow before-and-after validation of Caddy configuration changes.
  • Provide a reproducible open-source laboratory application.

Configuration Interface: Caddyfile

The Caddyfile provides the human-readable configuration used to define the laboratory web-server behavior.

Purpose
  • Define the site configuration.
  • Define the Juice Shop reverse-proxy route.
  • Define routing behavior.
  • Establish the known-good configuration.
  • Provide the monitored configuration asset.

Configuration Management Interface: Caddy Admin API

Caddy provides an administrative API for managing the active configuration.

Purpose
  • Support controlled configuration loading.
  • Support configuration management.
  • Support configuration reload operations.
  • Maintain controlled configuration administration.

Security Monitoring Tool: Wazuh

Wazuh provides File Integrity Monitoring and Active Response capabilities for security monitoring and controlled remediation.

Purpose
  • Monitor Caddy configuration files.
  • Detect configuration modifications.
  • Generate security alerts.
  • Trigger automated response actions.
  • Record response activity.

File Integrity Monitoring Module: Wazuh FIM

Wazuh FIM establishes and monitors the integrity state of designated files and directories.

Purpose
  • Establish file-integrity baselines.
  • Detect file modification.
  • Detect file creation and deletion.
  • Record checksum and attribute changes.
  • Generate integrity alerts.

Automated Response Module: Wazuh Active Response

Wazuh Active Response executes a controlled response script when the configured security rule is triggered.

Purpose
  • Restore the approved Caddy configuration.
  • Trigger controlled remediation.
  • Record response execution.
  • Support automated incident containment.

Security Analytics Tool: OpenSearch

OpenSearch provides centralized investigation and correlation of security events.

Purpose
  • Search Wazuh alerts.
  • Correlate configuration changes.
  • Investigate Caddy activity.
  • Review response execution.
  • Preserve the incident timeline.

Security Testing Platform: Kali Linux

Kali Linux provides the authorized security-testing environment for generating controlled configuration-tampering activity.

Purpose
  • Generate controlled configuration-tampering activity.
  • Validate FIM detection.
  • Trigger the laboratory security workflow.
  • Verify automated remediation.
  • Perform post-remediation validation.

Operating System: Ubuntu Linux

Ubuntu hosts Caddy, OWASP Juice Shop, and the monitored security components in the isolated laboratory.

Purpose
  • Host Caddy.
  • Host the Juice Shop backend.
  • Store the monitored configuration.
  • Run Wazuh agent components.
  • Execute the automated response script.
  • Generate host-level security telemetry.

HTTP Validation Tool: cURL

cURL is used to validate the behavior of the Caddy web service before and after configuration changes.

Purpose
  • Test the normal web service.
  • Detect behavior changes after tampering.
  • Validate restored routing.
  • Confirm post-remediation Juice Shop access.
  • Provide repeatable validation evidence.

Virtualization Platform: VirtualBox

VirtualBox provides the isolated security laboratory for the Ubuntu and Kali Linux virtual machines.

Purpose
  • Host Ubuntu and Kali Linux.
  • Isolate configuration-tampering tests.
  • Provide controlled networking.
  • Support repeatable SOC validation.
  • Prevent impact on external systems.

Process

STEP 01

Step 1: Prepare the Isolated Caddy Security Operations Laboratory

  • Create the Ubuntu Linux virtual machine for the Caddy web server.
  • Prepare the Kali Linux security-testing virtual machine.
  • Configure isolated laboratory networking.
  • Assign controlled laboratory IP addresses.
  • Verify communication between the authorized systems.
  • Confirm that all configuration-tampering tests remain restricted to the laboratory.
Tools: VirtualBox + Ubuntu + Kali Linux
STEP 02

Step 2: Install the Caddy Web Server

  • Install the approved Caddy release on Ubuntu.
  • Verify the installed Caddy version.
  • Start the Caddy service.
  • Confirm that Caddy starts without configuration errors.
  • Record the initial Caddy version and service status.
  • Preserve the initial configuration for security-baseline creation.
Tools: Caddy + Ubuntu
STEP 03

Step 3: Deploy OWASP Juice Shop

  • Deploy the OWASP Juice Shop application on the Ubuntu laboratory system.
  • Start the Juice Shop backend service.
  • Verify that Juice Shop is accessible on its local backend port.
  • Confirm that the application loads correctly before placing it behind Caddy.
  • Record the normal Juice Shop response.
  • Preserve the application state as the service baseline.
Tools: OWASP Juice Shop + Ubuntu
STEP 04

Step 4: Place OWASP Juice Shop Behind Caddy

  • Configure Caddy as the web-server entry point.
  • Configure the Caddyfile with the approved site address.
  • Configure the reverse_proxy directive to forward requests to the Juice Shop backend.
  • Start or reload Caddy using the approved configuration.
  • Access the Juice Shop through the Caddy endpoint.
  • Confirm that Caddy successfully forwards requests to Juice Shop.
  • Record the expected application response.
Tools: Caddy + Caddyfile + OWASP Juice Shop + cURL
STEP 05

Step 5: Identify the Caddy Configuration Assets

  • Identify the active Caddyfile or configuration source.
  • Identify any imported Caddy configuration files used by the deployment.
  • Identify the Caddy data and log locations relevant to the laboratory.
  • Identify the Caddy administrative endpoint.
  • Confirm which configuration files are security-critical.
  • Record the configuration paths for integrity monitoring.
Tools: Caddy + Ubuntu
STEP 06

Step 6: Establish the Known-Good Caddy Configuration

  • Review the complete laboratory Caddy configuration.
  • Verify the approved Juice Shop reverse-proxy destination.
  • Verify the intended site route.
  • Verify the expected logging configuration.
  • Validate the configuration before establishing it as the security baseline.
  • Preserve a read-only copy of the approved configuration.
Tools: Caddy + Caddyfile + Ubuntu
STEP 07

Step 7: Validate the Normal Caddy and Juice Shop Configuration

  • Validate the approved Caddy configuration.
  • Start or reload Caddy using the approved configuration.
  • Verify successful service operation.
  • Submit normal HTTP/HTTPS requests.
  • Confirm that Caddy forwards requests to Juice Shop.
  • Confirm that the expected Juice Shop response is returned.
  • Record the baseline service behavior.
Tools: Caddy + OWASP Juice Shop + cURL + Ubuntu
STEP 08

Step 8: Configure Wazuh File Integrity Monitoring

  • Install or configure the Wazuh agent on the Ubuntu Caddy host.
  • Identify the Caddy configuration file and required configuration directory.
  • Configure Wazuh FIM to monitor the selected configuration path.
  • Enable real-time monitoring for the designated Linux directory where appropriate.
  • Restart the Wazuh agent to apply the monitoring configuration.
  • Verify that the monitored configuration is visible to Wazuh.
Tools: Wazuh FIM + Ubuntu + Caddy
STEP 09

Step 9: Establish the File-Integrity Baseline

  • Allow Wazuh FIM to record the initial configuration state.
  • Verify the baseline checksum and file attributes.
  • Confirm that the approved Caddy configuration is stored as the reference state.
  • Generate a harmless, controlled file-integrity test.
  • Verify that Wazuh can detect the test modification.
  • Restore the original configuration after validation.
Tools: Wazuh FIM + Caddyfile + Ubuntu
STEP 10

Step 10: Configure Caddy and Host Security Logging

  • Configure Caddy access logging for the laboratory site where required.
  • Configure Caddy runtime logging as appropriate.
  • Ensure relevant Ubuntu service events are available for monitoring.
  • Confirm that Caddy configuration activity can be correlated with host events.
  • Forward the relevant logs to the Wazuh agent.
  • Verify that security telemetry is being collected.
Tools: Caddy + Wazuh + Ubuntu
STEP 11

Step 11: Create the Controlled Configuration-Tampering Scenario

  • Preserve the original approved Caddy configuration.
  • Use Kali Linux as the authorized security-testing system.
  • Simulate an attacker with controlled write access to the configuration.
  • Modify a non-destructive laboratory Caddy routing or reverse-proxy parameter.
  • Ensure the modification produces a measurable configuration-integrity difference.
  • Do not introduce destructive commands or affect external systems.
  • Record the exact modification as attack evidence.
Tools: Kali Linux + Caddyfile + Ubuntu
STEP 12

Step 12: Validate Caddy Behavior After Configuration Tampering

  • Apply the controlled tampered configuration only within the laboratory.
  • Reload Caddy using the controlled test configuration.
  • Submit HTTP/HTTPS requests to the affected laboratory site.
  • Compare the response with the known-good baseline.
  • Record the changed routing or web behavior.
  • Preserve the tampered configuration as incident evidence.
  • Do not allow the tampered configuration to remain active after the detection test.
Tools: Caddy + OWASP Juice Shop + cURL + Ubuntu
STEP 13

Step 13: Detect the Configuration Change Through Wazuh FIM

  • Modify the monitored Caddy configuration.
  • Wait for the configured real-time integrity event.
  • Verify that Wazuh detects the modification.
  • Review the affected file information.
  • Confirm that the event identifies the configuration-integrity deviation.
  • Record the corresponding Wazuh alert.
  • Preserve the alert as security evidence.
Tools: Wazuh FIM + Caddyfile + Ubuntu
STEP 14

Step 14: Configure the SOC Detection Rule

  • Identify the Wazuh FIM alert associated with the Caddy configuration change.
  • Create or refine a detection rule for the monitored Caddy configuration.
  • Assign an appropriate security severity to the event.
  • Configure the rule to distinguish the monitored configuration from unrelated file changes.
  • Test the rule using a controlled configuration modification.
  • Verify that the expected security alert is generated.
Tools: Wazuh + Wazuh Rules + Caddy + Ubuntu
STEP 15

Step 15: Configure the Automated Security Response

  • Create a controlled Active Response command.
  • Configure the response script to restore the approved Caddy configuration.
  • Configure the response to execute only for the intended Caddy-tampering alert.
  • Validate the response script before enabling automated execution.
  • Configure the appropriate execution location and timeout behavior.
  • Record the Active Response configuration.
Tools: Wazuh Active Response + Custom Response Script + Ubuntu
STEP 16

Step 16: Execute the Automated Configuration Restoration

  • Repeat the controlled Caddy configuration-tampering activity.
  • Allow Wazuh FIM to detect the modification.
  • Verify that the configured security rule generates the expected alert.
  • Verify that the Active Response action is triggered.
  • Confirm that the approved Caddy configuration is restored.
  • Record the response execution event.
  • Verify that the tampered configuration is no longer the active configuration.
Tools: Wazuh FIM + Wazuh Active Response + Caddy + Ubuntu
STEP 17

Step 17: Validate and Reload the Restored Caddy Configuration

  • Validate the restored Caddy configuration before applying it.
  • Confirm that the configuration passes the Caddy validation process.
  • Reload the running Caddy configuration using the supported reload mechanism.
  • Verify that Caddy remains operational.
  • Submit normal HTTP/HTTPS requests.
  • Confirm that the original Juice Shop routing behavior is restored.
  • Preserve the reload and validation evidence.
Tools: Caddy + caddy reload + OWASP Juice Shop + cURL + Ubuntu
STEP 18

Step 18: Investigate the Incident Through OpenSearch

  • Forward Wazuh configuration-integrity alerts to OpenSearch.
  • Search for the Caddy configuration-change event.
  • Correlate the FIM alert with Caddy and Ubuntu activity.
  • Identify the time of the configuration modification.
  • Identify the automated-response execution event.
  • Review the configuration-restoration result.
  • Correlate the event with the Juice Shop service validation.
  • Preserve the complete incident timeline.
Tools: Wazuh + OpenSearch + Caddy + Ubuntu + OWASP Juice Shop
STEP 19

Step 19: Perform Final SOC Detection and Automated Response Validation

  • Repeat the controlled configuration-tampering scenario.
  • Verify real-time Wazuh FIM detection.
  • Verify the corresponding security alert.
  • Verify automated Active Response execution.
  • Verify restoration of the known-good configuration.
  • Verify Caddy configuration validation.
  • Verify successful Caddy reload.
  • Verify restoration of normal Juice Shop web-service behavior.
  • Review Wazuh security evidence.
  • Review OpenSearch investigation evidence.
  • Compare pre-response and post-response behavior.
  • Confirm that the configuration-integrity monitoring and automated response workflow operates as intended.
Tools: Caddy + OWASP Juice Shop + Kali Linux + Wazuh FIM + Wazuh Active Response + OpenSearch + cURL + Ubuntu

Outcome

  1. A controlled Caddy web-server environment is successfully deployed on Ubuntu Linux within an isolated VirtualBox security-operations laboratory.
  2. OWASP Juice Shop is deployed as the named backend web application behind Caddy, providing a reproducible open-source application for validating the effects of Caddy configuration changes.
  3. A verified known-good Caddy configuration baseline containing the approved Juice Shop reverse-proxy routing is established and preserved as the reference state for configuration-integrity monitoring.
  4. Wazuh File Integrity Monitoring is configured to monitor the critical Caddy configuration assets and detect unauthorized configuration modifications in the laboratory.
  5. A controlled Caddy web configuration-tampering scenario is generated, demonstrating how an unauthorized modification can change the expected routing behavior toward the Juice Shop application.
  6. Wazuh detects the configuration-integrity deviation and generates a security event that can be investigated through the SOC monitoring workflow.
  7. Wazuh Active Response automatically executes the defined remediation action when the configured Caddy-tampering detection condition is triggered.
  8. The automated response restores the approved Caddy configuration, validates the restored configuration, and reloads Caddy using the supported configuration-management workflow.
  9. Post-response testing confirms that Caddy again routes requests to the approved OWASP Juice Shop backend and that the expected web-service behavior is restored.
  10. OpenSearch provides centralized investigation and correlation of configuration-integrity alerts, Caddy activity, automated-response events, Juice Shop service validation, and post-remediation evidence.
  11. The complete Caddy configuration-tampering detection and automated security-response workflow is demonstrated, covering configuration-baseline creation, Wazuh FIM monitoring, controlled tampering, security-alert generation, SOC event correlation, automated Active Response, configuration restoration, Caddy validation and reload, Juice Shop service verification, OpenSearch investigation, and final incident-response validation.