From JWT Manipulation to Splunk Analysis Investigating a Multi Stage Web Application Compromise

"Attackers exploit vulnerabilities. Investigators connect evidence. Great security professionals understand both."

How a chain of low-to-medium severity issues combined into a full system compromise — and how defensive analysis reconstructed the entire attack from the evidence left behind.

Most cyberattacks don't begin with a sophisticated zero-day exploit.

More often, they begin with a small oversight — an authorization check that trusts client-side data, an exposed diagnostic page, or credentials left where they shouldn't be. Individually, these issues may appear insignificant. Combined, they can provide an attacker with everything needed to compromise an environment.

In this case study, I document an end-to-end cybersecurity investigation conducted within a controlled laboratory environment. Starting with a low-privileged account, I reconstructed the complete attack path by combining offensive security techniques with defensive investigation methods. The engagement included JWT analysis, privilege escalation, web reconnaissance, Linux enumeration, network forensics using Wireshark, and SIEM-based log analysis with Splunk.

Rather than focusing on individual commands, this article explores the reasoning behind each step, the security implications of every finding, and the defensive lessons organizations can apply to reduce similar risks.

What You'll Learn

Throughout this investigation I demonstrate how to:

✔ Analyze insecure JWT implementations

✔ Identify authorization weaknesses

✔ Perform web application reconnaissance

✔ Enumerate Linux systems safely

✔ Conduct packet analysis with Wireshark

✔ Investigate authentication logs using Splunk

✔ Correlate evidence from multiple sources

✔ Produce actionable security recommendations

Incident Scenario

A web application used for internal file management has generated several security concerns after unusual authentication activity was detected. Initial indicators suggest that an attacker may have obtained unauthorized administrative access before moving laterally across the environment.

As the security analyst assigned to the investigation, my objective was to reconstruct the attack, identify every exploited weakness, recover available evidence, assess the overall business impact, and recommend practical remediation measures.

The assessment was performed inside an authorized cybersecurity training environment designed to simulate a realistic enterprise infrastructure.

Environment Overview

The target environment consisted of a Linux-based web application providing role-based access to internal operational data. The application relied on JSON Web Tokens (JWTs) for authentication and included an administrative interface used to manage sensitive archives and system resources.

Behind the web application, the infrastructure exposed several components that became relevant throughout the investigation, including a Linux server, archived incident data, network capture files, authentication logs, and system scripts. Individually, these components appeared unrelated; however, each played a critical role in reconstructing the attacker's actions.

The investigation combined offensive security techniques to identify and exploit security weaknesses with defensive analysis to validate findings, correlate evidence, and understand the complete attack chain. This approach closely reflects real-world incident response engagements, where investigators must combine multiple sources of evidence to determine how an intrusion occurred.

The primary technologies involved throughout the investigation included:

• Kali Linux — Security testing and enumeration
• JWT (JSON Web Tokens) — Authentication analysis
• DIRB — Directory enumeration
• SSH — Secure remote access to the target host
• Linux Command Line — Host enumeration and evidence collection
• Wireshark — Network traffic analysis
• Splunk Enterprise — Log analysis and incident investigation

Investigation Methodology

To ensure that evidence was collected systematically and that every finding could be validated, the investigation followed a structured methodology similar to those used during penetration testing and digital forensic engagements.

Rather than relying on a single vulnerability, the objective was to understand how multiple security weaknesses could be chained together to achieve complete system compromise. Each discovery informed the next stage of the investigation until sufficient evidence was gathered to reconstruct the entire attack path.

The investigation followed the workflow shown below.

Reconnaissance
        │
        ▼
Authentication Analysis
        │
        ▼
Privilege Escalation
        │
        ▼
Web Enumeration
        │
        ▼
Information Disclosure
        │
        ▼
Host Access (SSH)
        │
        ▼
Linux Enumeration
        │
        ▼
Network Forensics
        │
        ▼
SIEM Log Analysis
        │
        ▼
Evidence Correlation
        │
        ▼
Root Cause Analysis
        │
        ▼
Defensive Recommendations

Reconnaissance
        │
        ▼
Authentication Analysis
        │
        ▼
Privilege Escalation
        │
        ▼
Web Enumeration
        │
        ▼
Information Disclosure
        │
        ▼
Host Access (SSH)
        │
        ▼
Linux Enumeration
        │
        ▼
Network Forensics
        │
        ▼
SIEM Log Analysis
        │
        ▼
Evidence Correlation
        │
        ▼
Root Cause Analysis
        │
        ▼
Defensive Recommendations

Initial Access

The investigation began with access to the web application using a standard guest account.

Initial exploration confirmed that authentication was functioning as expected; however, several administrative features remained inaccessible due to role-based restrictions.

Instead of attempting password attacks or automated exploitation, the assessment focused on understanding how authorization decisions were enforced within the application. This follows a common penetration testing methodology in which authentication and session management mechanisms are evaluated before pursuing deeper exploitation.

During this phase, one observation immediately stood out: access restrictions were being enforced by information stored within the user's authenticated session. This prompted a closer examination of the authentication mechanism, ultimately leading to the first significant finding of the investigation.

Finding 1 — Insecure JWT Authorization

Observation

Inspection of the application's authentication mechanism revealed that session management relied on a JSON Web Token (JWT) stored within the browser. Decoding the token exposed several user attributes, including the authenticated username and the authorization role assigned to the current session.

Most importantly, the token contained the claim:

role : guest

role : guest

This immediately raised a concern. Rather than validating authorization exclusively on the server, the application appeared to rely on information stored within the client-controlled JWT.

Technical Analysis

JWTs are widely used to maintain authenticated sessions because they are lightweight and easy to verify. However, the information stored inside a JWT should never become the sole source of authorization.

During the investigation, the presence of a client-side role claim suggested that the application might be trusting values supplied by the user's browser rather than independently verifying permissions on the server.

To validate this hypothesis, the authorization claim was modified from:

role : guest

role : guest

to

role : admin

role : admin

A new token containing the modified payload was generated and replaced within the browser session.

Result

After refreshing the application, the previously restricted administrative interface became accessible without requiring additional authentication.

This confirmed that authorization decisions were being made based on a client-controlled JWT claim rather than secure server-side validation.

Security Impact

This vulnerability represents a classic example of Broken Access Control, one of the most critical categories in modern web application security.

If present in a production environment, an attacker could elevate privileges simply by modifying a JWT payload, potentially gaining unauthorized access to sensitive administrative functions without possessing legitimate administrator credentials.

Because the attack does not require password guessing or credential theft, exploitation is both efficient and difficult to detect when proper token validation is absent.

Analyst Note:_ Authentication confirms_ who a user is, while authorization determines what that user is allowed to do. In this case, authentication remained intact, but authorization failed because the application trusted client-controlled role information.

Remediation

The vulnerability could be mitigated by implementing the following controls:

• Perform authorization checks exclusively on the server.
• Digitally sign and verify JWTs using strong cryptographic algorithms.
• Never rely on client-controlled claims such as user roles for authorization decisions.
• Implement token expiration and secure key rotation.
• Log abnormal privilege changes and monitor failed token validation attempts.

Finding 2 — Sensitive Configuration Disclosure Through phpinfo()

Although administrative privileges had been successfully obtained, the investigation was not yet complete. Access to the administrative interface revealed several internal resources; however, most contained limited investigative value. One entry, however, stood out.

A development-related note referenced a diagnostic page with the message:

"Maybe phpinfo will help."

Rather than assuming all application resources were exposed through the user interface, the investigation shifted toward web application reconnaissance to identify hidden endpoints that might disclose additional information.

Web Reconnaissance

Modern web applications often contain endpoints that are not directly linked through the graphical interface. These resources may include development pages, backup files, administrative consoles, configuration files, or diagnostic utilities that remain accessible if they are not properly secured.

To identify such hidden resources, directory enumeration was performed using DIRB, a web content discovery tool that systematically requests common file and directory names against the target web server.

This process is frequently performed during penetration testing because exposed resources often reveal valuable information about the application's architecture, development practices, or security posture.

Observation

The enumeration process identified an unlinked resource:

phpinfo.php

phpinfo.php

Although this page was not accessible through the application's navigation menu, it remained publicly reachable from the web server.

At first glance, diagnostic pages such as phpinfo() may appear harmless because they are intended to assist developers during troubleshooting. However, when exposed in production environments, they frequently reveal sensitive configuration details that significantly aid attackers during the reconnaissance phase.

Technical Analysis

Accessing the discovered page displayed detailed runtime information about the PHP environment, including server configuration, enabled modules, environment variables, filesystem paths, software versions, and loaded extensions.

To determine whether sensitive information was present, the page contents were reviewed for security-relevant keywords.

Searching for the keyword "ssh" immediately revealed two environment variables:

SSH_USER
SSH_PASS

SSH_USER
SSH_PASS

These variables contained valid SSH credentials for the underlying Linux server.

Why This Matters

Information disclosure vulnerabilities are often underestimated because they do not immediately grant system access. However, they dramatically reduce the effort required for attackers to progress through later stages of an intrusion.

In this investigation, the exposed diagnostic page eliminated the need for password guessing, credential theft, or brute-force attacks. Instead, legitimate credentials were obtained directly from the application's runtime configuration, allowing authenticated access to the target system.

This illustrates how seemingly minor configuration mistakes can become critical when combined with other vulnerabilities.

Analyst Note:_ Information disclosure vulnerabilities rarely operate in isolation. Their true impact emerges when leaked information enables attackers to exploit additional weaknesses elsewhere in the environment._

Business Impact

If exposed within a production environment, publicly accessible diagnostic pages could reveal:

• System usernames
• Service credentials
• Internal filesystem paths
• Installed software versions
• Environment variables
• Database connection details
• Application secrets
• Server configuration settings

Such information substantially lowers the complexity of subsequent attacks and provides adversaries with valuable intelligence for privilege escalation and lateral movement.

Severity Assessment

Severity: High

Although the vulnerability does not directly execute malicious code, the disclosure of sensitive credentials enabled unauthorized access to the underlying infrastructure and significantly increased the overall impact of the attack chain.

Remediation

The following controls would significantly reduce the risk posed by this vulnerability:

• Disable phpinfo() on production systems.
• Remove diagnostic pages immediately after development and testing.
• Avoid storing secrets within environment variables that may be exposed through debugging interfaces.
• Restrict access to development resources using authentication and network access controls.
• Perform regular web content discovery during security assessments to identify unintentionally exposed resources.
• Implement automated configuration reviews to detect publicly accessible diagnostic utilities before deployment.

Finding 3 — Host Access and Linux System Enumeration

The disclosure of valid SSH credentials provided a legitimate pathway to investigate the underlying Linux server. Rather than exploiting additional vulnerabilities to obtain remote access, the investigation leveraged the exposed credentials recovered during the previous phase.

This transition marked a significant shift in the assessment. The investigation moved beyond the web application and focused on identifying artifacts stored directly on the operating system that could explain how the compromise unfolded.

Establishing Host Access

Using the recovered credentials, an authenticated SSH session was established with the target Linux server.

Unlike many penetration tests where remote shell access represents the final objective, obtaining shell access in this investigation marked the beginning of a deeper forensic examination. The primary objective was no longer exploitation, but evidence collection.

Once authenticated, the investigation focused on understanding the system's structure, identifying user-owned files, and locating artifacts related to the suspected security incident.

Linux Enumeration Strategy

Host enumeration is a critical stage during both penetration testing and incident response. Rather than making assumptions about the environment, investigators systematically examine the operating system to identify configuration files, hidden resources, user data, scheduled tasks, scripts, and logs that may provide additional context.

The investigation began with basic filesystem enumeration to establish situational awareness.

Initial observations identified several files of interest within the user's home directory, including:

• backup.sh
• vault
• note.txt

Although these files appeared unrelated at first glance, each ultimately contributed to reconstructing the complete attack chain.

Discovery of Hidden Artifacts

Security investigations rarely rely solely on visible files. Hidden directories frequently contain configuration files, temporary artifacts, credentials, or operational notes that provide valuable context.

To ensure no relevant evidence was overlooked, hidden files within the user's home directory were enumerated.

This process revealed a previously undiscovered file:

vault/.note.txt

vault/.note.txt

Unlike ordinary user documents, this hidden note served as an operational briefing that outlined the remaining stages of the investigation.

Evidence Collection

Rather than immediately executing available scripts or interacting with archived data, the hidden note was reviewed to understand the expected investigation workflow.

The briefing instructed the investigator to:

• Locate a network capture file.
• Recover the password protecting an archive.
• Review the backup script.
• Determine the correct archive.
• Import extracted logs into Splunk.

At this stage, the investigation became increasingly focused on evidence correlation rather than exploitation. Each task depended on information gathered during previous phases, reinforcing the importance of systematic evidence collection.

Static Analysis of System Scripts

One of the most valuable artifacts identified during enumeration was the file:

backup.sh

backup.sh

Rather than executing the script immediately, its contents were examined through static analysis.

This decision reflects an important principle of incident response and malware analysis: never execute an unknown script without first understanding its behavior.

Executing untrusted code can unintentionally modify evidence, trigger malicious actions, alter timestamps, or change the state of the system under investigation.

Instead, the script's logic was reviewed line by line to understand how it selected archived files.

Technical Analysis

Reviewing the script revealed several logical conditions that determined which archive represented the correct backup.

Instead of relying on trial and error, these conditions were evaluated manually.

After validating the required parameters, the investigation identified the correct archive as:

svc_cron_42.zip

svc_cron_42.zip

This approach ensured that the investigation remained evidence-driven while avoiding unnecessary modifications to the target environment.

Analyst Note:_ One of the most common mistakes during incident response is executing unknown scripts before understanding their behavior. Static analysis preserves evidence integrity while allowing investigators to determine a script's purpose safely._

Validation

Before interacting with the archive, the identified conditions were verified against the current system state to ensure the correct file had been selected.

This validation step reduced the likelihood of extracting irrelevant or misleading data and maintained the structured methodology followed throughout the investigation.

Business Impact

Although no vulnerability was exploited during this phase, the investigation highlighted an important operational concern.

Sensitive scripts, hidden notes, and archived operational data were accessible to authenticated users. In production environments, insufficient segregation of sensitive operational artifacts may expose information useful to attackers after an initial compromise.

Organizations should ensure that administrative scripts, operational documentation, and archived data are protected through least-privilege access controls and appropriate filesystem permissions.

Finding 4 — Network Forensics and Evidence Recovery

At this stage of the investigation, the correct archive had been identified; however, it remained inaccessible because it was protected by a password. Rather than attempting to bypass the encryption through brute-force techniques, the investigation followed the evidence gathered during host enumeration.

The operational briefing indicated that the required password could be recovered from previously captured network traffic. This shifted the investigation from host analysis to network forensics, where historical communications would be examined for evidence of credential exposure.

Locating the Network Capture

The first objective was to identify the location of the packet capture file within the Linux system.

Rather than manually searching through multiple directories, a system-wide search was performed to locate packet capture (.pcapng) files. This approach ensured that potentially valuable forensic artifacts were identified efficiently while minimizing unnecessary interaction with unrelated files.

The search located the following evidence file:

/incident/response/team/Network_traffic.pcapng

/incident/response/team/Network_traffic.pcapng

Preserving Evidence

Rather than analyzing the capture directly on the target system, the packet capture was transferred to the investigator's Kali Linux workstation using Secure Copy Protocol (SCP).

Conducting forensic analysis on a separate workstation is considered good practice because it reduces the risk of modifying evidence stored on the compromised system while allowing investigators to utilize specialized analysis tools.

Network Traffic Analysis

The recovered capture was opened in Wireshark, a widely used network protocol analyzer that enables investigators to inspect captured communications at the packet level.

Instead of reviewing every packet individually, the investigation focused on HTTP traffic, as previous findings suggested that sensitive application data might have been transmitted without adequate protection.

Applying protocol-based filters significantly reduced the amount of traffic requiring analysis and allowed the investigation to concentrate on application-layer communications.

Evidence Identification

Inspection of the captured HTTP requests revealed a custom HTTP header containing sensitive information.

One packet included the following header:

X-Archive-Key-Zip-Password

X-Archive-Key-Zip-Password

The corresponding value contained the password required to decrypt the previously identified archive.

Unlike encrypted HTTPS traffic, the HTTP communication exposed this information in plaintext, making it immediately visible to anyone capable of intercepting the network traffic.

Technical Analysis

This finding demonstrates one of the fundamental risks associated with transmitting sensitive information over unencrypted protocols.

Although the archive itself was password protected, the password was transmitted through a plaintext HTTP header. Consequently, the confidentiality provided by the archive encryption was effectively nullified because anyone with access to the captured traffic could recover the password without performing cryptographic attacks.

This illustrates an important security principle:

Encryption is only effective when the keys and passwords used to protect the data are transmitted securely.

Evidence Recovery

Using the recovered password, the correct archive was extracted successfully.

The archive contained a single file of investigative significance:

internal_audit.log

internal_audit.log

Rather than representing the final objective, this file became the primary source of evidence required to reconstruct the attack timeline.

Business Impact

Although archive encryption had been implemented, transmitting the decryption password through unencrypted HTTP communications defeated its purpose.

In production environments, similar weaknesses may expose:

• Backup archives
• Database exports
• Configuration packages
• Authentication credentials
• Encryption keys
• Sensitive internal documents

Attackers monitoring network traffic would be able to recover protected assets without needing to break the encryption itself.

Severity Assessment

Severity: High

The vulnerability did not reside in the archive encryption mechanism itself but in the insecure transmission of the password protecting the archive.

Remediation

The following controls would significantly reduce the likelihood of similar exposures:

• Enforce HTTPS across all web communications.
• Never transmit passwords or encryption keys through HTTP headers.
• Use secure key exchange mechanisms for protected archives.
• Encrypt sensitive communications using modern TLS configurations.
• Regularly inspect network traffic for plaintext credentials during security assessments.
• Implement Data Loss Prevention (DLP) controls to detect sensitive information transmitted over insecure channels.

Finding 5 — Authentication Log Analysis Using Splunk

Although the recovered archive represented a valuable source of evidence, the investigation was still incomplete. Understanding what happened required more than simply obtaining log files — it required reconstructing the attacker's activity from recorded events.

The extracted archive contained an authentication audit log named:

internal_audit.log

internal_audit.log

Rather than manually reviewing hundreds of log entries, the investigation leveraged Splunk Enterprise to centralize, filter, and correlate authentication events.

This phase shifted the investigation from evidence collection to incident reconstruction, enabling suspicious activity to be identified through structured log analysis.

Importing Evidence into the SIEM

The recovered log file was imported into Splunk using the default source type to preserve the original log structure.

Once indexed, the dataset became searchable, allowing authentication events to be filtered based on relevant fields and security indicators.

Using a SIEM platform instead of manually reading log files significantly improves an analyst's ability to identify suspicious behaviour, correlate events across large datasets, and investigate incidents efficiently.

Investigation Strategy

Rather than reviewing every event individually, the investigation focused specifically on authentication activity.

The objective was to identify:

• Failed authentication attempts
• Successful logins
• Suspicious authentication patterns
• Indicators of brute-force activity
• Evidence associated with the compromise

To isolate these events, authentication-related searches were performed within Splunk.

Observation

Analysis of the indexed logs revealed a large number of failed authentication attempts occurring over a relatively short period.

Among these events, one authentication request eventually returned a successful login status.

This pattern strongly suggested that repeated login attempts had preceded successful authentication, consistent with the behaviour commonly observed during brute-force attacks.

Unlike the earlier phases of this assessment — where valid credentials were recovered through information disclosure — this portion of the investigation focused on analysing historical evidence left behind by a previously completed attack.

Evidence Correlation

The successful authentication event contained an additional field labelled:

enc_data

enc_data

Unlike ordinary authentication metadata, this field contained an encoded value requiring further analysis.

Rather than treating the value as the final objective, it was considered another piece of forensic evidence that could help validate the reconstructed attack timeline.

Technical Analysis

The recovered value was identified as Base64-encoded data.

Base64 is not an encryption algorithm; it is an encoding scheme commonly used to represent binary information using printable ASCII characters.

Because Base64 provides no confidentiality, the encoded value was decoded to reveal its original contents.

The decoded result served as the final evidence artifact confirming that the investigation had successfully reconstructed the complete attack path.

Modern incident response rarely relies on a single source of evidence.

In this investigation, meaningful conclusions were reached only after correlating information obtained from:

• Web application analysis
• JWT authentication
• Directory enumeration
• Linux host artifacts
• Network traffic captures
• Authentication logs

Each individual artifact revealed only part of the overall picture. Together, they enabled the complete attack chain to be reconstructed with confidence.

Analyst Note:_ Effective incident response is not about finding a single critical log entry — it is about correlating multiple independent evidence sources until the complete sequence of events becomes clear._

Business Impact

Authentication logs provide one of the most valuable sources of evidence following a security incident.

When properly collected and retained, they enable investigators to:

• Identify unauthorized access attempts
• Detect brute-force activity
• Reconstruct attacker timelines
• Determine compromised accounts
• Validate containment efforts
• Support post-incident forensic analysis

Without centralized logging, much of this investigative capability would be significantly reduced.

Severity Assessment

Severity: Critical

The investigation demonstrated that weaknesses across authentication, configuration management, credential protection, and monitoring could be chained together to achieve complete compromise.

While no single issue was catastrophic on its own, their combined impact resulted in full administrative access and exposure of sensitive operational data.

Defensive Recommendations

The investigation identified several opportunities to strengthen the security posture of the environment.

Authentication Security

• Validate authorization decisions exclusively on the server.
• Enforce Multi-Factor Authentication (MFA) for privileged accounts.
• Implement account lockout policies after repeated failed login attempts.

Secure Configuration Management

• Remove diagnostic pages such as phpinfo() from production systems.
• Protect sensitive environment variables using dedicated secrets management solutions.

Network Security

• Encrypt all sensitive communications using HTTPS/TLS.
• Never transmit passwords or cryptographic keys in plaintext.

Monitoring and Detection

• Centralize authentication logs within a SIEM platform.
• Create alerts for repeated failed authentication attempts.
• Monitor unexpected privilege changes.
• Regularly review authentication activity for anomalous behaviour.

Lessons Learned

This investigation reinforced several important cybersecurity principles:

• Small misconfigurations can combine into major security incidents.
• Information disclosure frequently serves as the bridge between initial access and privilege escalation.
• Static analysis of scripts is safer than executing unknown code during an investigation.
• Packet captures can provide valuable forensic evidence but may also expose sensitive information if communications are not encrypted.
• Centralized log analysis enables investigators to reconstruct complex attack chains and validate findings across multiple evidence sources.

Conclusion

This investigation demonstrated the complete lifecycle of a simulated cyber intrusion by combining offensive security techniques with defensive incident response methodologies.

Beginning with a low-privileged web session, the assessment uncovered weaknesses in authorization, configuration management, credential protection, and network security. Through systematic enumeration, forensic analysis, and evidence correlation, the investigation reconstructed the complete attack path and validated its findings using centralized log analysis.

More importantly, the exercise highlighted that successful attacks rarely depend on a single critical vulnerability. Instead, they emerge from multiple weaknesses that, when combined, enable attackers to move progressively deeper into an environment.

Approaching the investigation from both an attacker's and a defender's perspective provided a broader understanding of how vulnerabilities are exploited, how evidence is preserved, and how security teams can detect, investigate, and prevent similar incidents in production environments.

The recovered encoded evidence successfully validated the reconstructed attack chain, confirming that all investigative objectives had been achieved.