WEBRR: A Forensic System for Replaying and Investigating Web-Based Attacks in The Modern Web

WEBRR: A Forensic System for Replaying and Investigating Web-Based Attacks in The Modern Web

Speakers: Joey Allen, Zheng Yang, Roberto Perdisci, Wenke Lee

Conference: USENIX Security '24

YouTube: https://www.youtube.com/watch?v=BseE1guIorM

Overview

In an era of escalating data breaches, understanding the precise vector and impact of an attack is paramount for effective incident response and future prevention. Traditional forensic approaches, often centered on whole-system auditing and system-call-based causality graphs, fall short when confronted with the unique semantics and dynamic nature of web-based attacks. These attacks, frequently leveraging intricate JavaScript interactions, DOM manipulations, and social engineering, demand a more granular, web-aware forensic capability. The WEBRR system, presented by Joey Allen and his co-authors at USENIX Security '24, addresses this critical gap by introducing a novel forensic record and replay system specifically designed for modern web applications.

WEBRR’s core innovation lies in its ability to deterministically replay web-based attacks exactly as they occurred in the victim's browser, providing invaluable dynamic and visual analysis capabilities. By instrumenting the browser's rendering engine rather than relying solely on JavaScript-level hooks, WEBRR overcomes the significant challenge of executional divergence, a phenomenon where the timing of asynchronous web operations can lead to different execution paths during replay compared to the original recording. This allows forensic investigators to not only reconstruct the attack lineage from logs but also visually observe the malicious payload delivery, user interaction, and subsequent impact, offering unprecedented insight into complex web compromises.

This talk is crucial for security professionals, incident responders, and forensic analysts grappling with the complexities of modern web security. It highlights the limitations of existing forensic tools in the web domain and presents a robust, OS-agnostic solution that ensures high-fidelity attack reconstruction. By enabling a visual and dynamic understanding of web attacks, WEBRR significantly enhances the ability to analyze sophisticated threats that often rely on a blend of technical exploitation and deceptive user interfaces, ultimately strengthening an organization's defensive posture.

Background

▶ Watch: Introduction and motivation for WebRR (0:00)

The landscape of cybersecurity forensics has long been dominated by techniques focused on understanding system-level activities. Existing whole-system auditing solutions, such as Arnold, Rain, and RAG, meticulously collect information about processes, system calls, and file accesses to construct causality graphs. These graphs are powerful for reconstructing attack lineages in a post-mortem fashion, revealing how adversaries gained access and what resources they impacted. However, these systems operate at the wrong level of abstraction for web-based attacks. Investigating a malicious iframe injection or a complex JavaScript exploit solely through system calls provides an incomplete and often unintelligible picture. The semantics of a web attack—involving DOM manipulation, network requests, and intricate script interactions—are fundamentally different from those of a traditional operating system compromise.

Recognizing this semantic mismatch, prior research has attempted to adapt causality graph concepts to the web context. Systems like JSGraph and NEOS reimagine causality graphs using web-based primitives such as iframes, DOM events, and script executions. While these efforts represent a step forward, they primarily support static analysis. They can show the relationships between web components and events, but they fail to capture the dynamic, time-sensitive, and visual aspects of a web attack. For instance, a static graph cannot convey how a malicious element was rendered, what visual cues were presented to the user, or how asynchronous JavaScript execution impacted the attack flow. This limitation is particularly problematic for attacks that incorporate a social engineering component, where the visual presentation and user interaction are critical to the exploit's success. Without seeing exactly what the user saw, understanding the full impact and mechanism of such attacks remains challenging.

The need for dynamic and visual analysis has driven interest in record and replay (R&R) systems. These systems aim to capture the execution of an application and replay it deterministically. However, existing R&R solutions also face significant hurdles in the web domain:

1. System-level Record and Replay: Similar to whole-system auditing, these systems (e.g., Arnold, Rain, RAG) record all processes on a Linux-based OS. Their primary limitation is their strong dependency on the underlying operating system. Their approach is not easily portable to other platforms like Windows or Android, which are common targets for web-based attacks.
2. JavaScript-based Record and Replay: These systems attempt to instrument JavaScript code as it's loaded into the browser, either via a web proxy or inline. While more web-aware, they suffer from a fundamental security flaw: the instrumentation operates at the same privilege level as the malicious web application. A sophisticated adversary, aware of such instrumentation, could easily detect and disable it, preventing the attack from being replayed. This undermines the tamper-proof requirement crucial for forensic investigations.
3. In-browser Record and Replay: This approach, which WEBRR adopts, embeds R&R logic directly within the browser. Systems like Web Capsule have explored this. The major advantages are OS agnosticism (as browsers already support multiple OSes) and the potential for tamper-proof recording hooks that are inaccessible to JavaScript. However, a critical challenge that has plagued these systems is executional divergence. This occurs when the replay environment fails to precisely reproduce the timing and order of asynchronous JavaScript executions, leading to a different outcome than the original recording. This divergence renders the replay inaccurate and unreliable for forensic purposes.

To be considered a truly forensic-grade record and replay system, WEBRR had to meet several stringent requirements: it must be deterministic (replaying exactly what the user saw), portable (working across different operating systems), always-on (continuously monitoring without significant overhead), and tamper-proof (resilient against adversary attempts to disable recording). Addressing executional divergence was the linchpin to achieving determinism in the complex, asynchronous world of the modern web.

Key Findings

▶ Watch: Limitations of current record and replay systems (2:50)

The central discovery and contribution of WEBRR lies in its successful mitigation of executional divergence in in-browser record and replay systems, a challenge that has historically hampered the reliability of web forensics. Prior in-browser R&R systems treated the browser's rendering process as a black box, lacking granular control over how JavaScript execution was scheduled. This led to non-deterministic replays, especially with asynchronous web APIs.

WEBRR's key findings and contributions can be summarized as:

1. Identification of Executional Divergence as a Core Problem: The researchers pinpointed that the varying idle times of the browser's render thread, particularly when interacting with asynchronous APIs like requestIdleCallback (as opposed to setTimeout), cause JavaScript execution sequences to diverge across different runs. This divergence leads to replay failures, where malicious payloads might not be delivered or the attack path is not accurately reconstructed.
2. Novel Approach: Instrumenting the Rendering Engine: Instead of merely instrumenting the JavaScript engine or relying on proxy-based methods, WEBRR directly instruments the browser's rendering engine (specifically Chrome's Blink engine). This allows WEBRR to gain fine-grained control over the scheduling of JavaScript execution, capturing the precise order of events that contribute to the web application's behavior.
3. Introduction of JavaScript Execution Unit Partitioning: To ensure deterministic replay, WEBRR breaks down the web application's execution into a sequence of discrete JavaScript execution units (JEUs). These units are categorized as script units (initial script execution), callback units (execution of asynchronous callbacks like timers or network responses), and event units (execution triggered by user interactions or other browser events). By recording and enforcing the precise order of these JEUs, WEBRR can guarantee a faithful replay.
4. Development of a Replay Scheduler: Building upon the instrumented rendering engine, WEBRR implements a custom replay scheduler. This scheduler overrides the browser's native JavaScript scheduling mechanism during replay, forcing the execution of JEUs in the exact sequence recorded. This deterministic scheduling is crucial for reproducing the exact state and behavior of the web application.
5. Successful Replay of Web-Based Attacks: Through rigorous evaluation, WEBRR demonstrated its ability to successfully replay all tested web-based attacks across diverse operating systems including Linux, Android, and Windows. Crucially, these replays exhibited no divergence, meaning the JavaScript execution sequences and API call orders perfectly matched the original recordings.
6. Low Runtime and Storage Overhead: Despite its sophisticated instrumentation, WEBRR maintains practical overheads. It incurs only a 3.44% increase in page load overhead during recording, making it suitable for always-on deployment. The storage overhead is also manageable, estimated at 2.2 terabytes per year for a single user's 8-hour workday, which is reasonable for dedicated forensic capture.

These findings collectively demonstrate that WEBRR provides a viable, robust, and high-fidelity solution for dynamic and visual forensic analysis of web-based attacks, overcoming long-standing challenges in the field.

Technical Deep Dive

▶ Watch: Key requirements for forensic record and replay (4:15)

The core technical challenge addressed by WEBRR is executional divergence, a phenomenon where the timing of asynchronous operations in a web browser leads to non-deterministic JavaScript execution paths across different runs. The speakers illustrated this with an example involving a malicious hook.js script on a compromised political website. This script uses requestIdleCallback to establish a heartbeat with a backend server and getPayload to deploy a malicious payload upon receiving a response.

The crucial distinction lies between requestIdleCallback and more traditional timers like setTimeout. setTimeout executes a callback after a specified delay, irrespective of the browser's render thread state. In contrast, requestIdleCallback only executes when the render thread goes idle. The duration and frequency of these idle periods are highly variable, influenced by factors such as system load, user interaction, and browser rendering tasks. This variability means that in one recording, the script might execute four heartbeats before getPayload is called, while in another, only two heartbeats might occur, leading to different sequences of API calls and potentially altering the attack outcome. Prior R&R systems failed because they might resend a heartbeat response instead of the actual payload response due to this timing mismatch.

WEBRR's solution to executional divergence is deeply rooted in instrumenting the browser's internal architecture, specifically targeting the rendering engine rather than just the JavaScript engine. The Chrome browser's render process comprises two major components: the rendering engine (Blink), responsible for network requests, DOM management, web API implementations, and crucially, scheduling JavaScript execution; and the JavaScript engine (V8), which executes the JavaScript code. Prior work treated this entire render process as a black box, giving them no control over scheduling.

WEBRR's approach involves instrumenting the Blink engine to record more fine-grained information about how JavaScript is scheduled. During replay, it then builds a custom replay scheduler on top of Chrome's existing task scheduler to enforce the exact same ordering of JavaScript execution. This is achieved through JavaScript Execution Unit Partitioning.

A JavaScript Execution Unit (JEU) is defined as a discrete block of JavaScript execution. WEBRR identifies three types of JEUs:

1. Script Unit: The initial execution of a <script> block.
2. Callback Unit: The execution of a callback function registered via web APIs (e.g., setTimeout, requestIdleCallback, fetch response handlers).
3. Event Unit: The execution of an event handler triggered by user input (e.g., click, keypress) or other browser events.

Returning to the heartbeat example, when the malicious hook.js is executed, WEBRR records a sequence of JEUs:

• A script unit for the initial execution of hook.js.
• A callback unit for the first heartbeat.
• Another callback unit for the second heartbeat.
• A callback unit for the getPayload function.
• Potentially more callback units for subsequent heartbeats.

Each time a callback or script executes, WEBRR records this as a JEU, capturing all necessary context.

The replay strategy during forensics consists of three main goals:

1. Replay JavaScript execution units in the same order.
2. Ensure the DOM state is consistent at each step, so any JavaScript queries to the DOM yield identical results as in the recording.
3. Replay all sources of non-determinism correctly.

The replay scheduler is the core component enabling this strategy. It consists of:

• Replay Operation Queue: This queue is populated at the start of a replay with all the recorded JEUs. Each operation object in the queue contains the necessary information (e.g., script content, callback ID, event details, arguments) to deterministically replay that specific execution unit.
• Replay Dispatcher: This is a custom task that WEBRR schedules using Chrome's native task scheduler. When it's the replay dispatcher's turn to execute on the render thread, it pops the next replay operation off the queue and executes that unit synchronously. Once the unit completes, control is released back to Chrome's task scheduler. This incremental execution strategy allows the web page to "build" visually during the replay, mirroring the user's original experience, rather than just appearing fully rendered at the end. This visual progression is vital for understanding social engineering aspects of an attack.

Beyond JavaScript execution, WEBRR also addresses other sources of non-determinism. It achieves this by introducing shims (interception layers) at critical points within the browser's architecture:

• Blink Platform Shims: These shims are placed to record all network requests, ensuring that during replay, network responses are served deterministically from the recorded data rather than initiating new, potentially variable, network interactions.
• Blink V8 Layer Shims: These shims are responsible for recording calls to non-deterministic web APIs, such as localStorage queries (which might depend on prior state) or Math.random() calls (which produce different values on each execution). By capturing the return values of these APIs during recording, WEBRR ensures they are consistently returned during replay.

By deeply embedding its recording and scheduling logic within the rendering engine and carefully shimming non-deterministic APIs, WEBRR constructs a comprehensive and tamper-proof system capable of deterministic web attack replay.

Demo / Proof of Concept

▶ Watch: Understanding executional divergence: a core challenge (4:40)

While the talk did not feature a live, interactive demo of WEBRR, the speakers presented a thorough evaluation that serves as a robust proof of concept for the system's capabilities. The evaluation aimed to answer three key questions:

1. Can WEBRR successfully replay web-based attacks?
2. Can WEBRR replay highly dynamic benign web applications?
3. What is the runtime and storage overhead of WEBRR?

To define a successful replay, the researchers established stringent criteria:

• The attack must be recorded successfully.
• The sequence of JavaScript Execution Units (JEUs) during replay must closely match the recorded sequence.
• A fine-grained API level check must confirm that all APIs called during the recording are executed in the exact same order during the replay.

For the first question, WEBRR was evaluated against a variety of web-based attacks across different operating systems, including Linux, Android, and Windows. The results were highly positive: WEBRR was successful in all cases, demonstrating its ability to accurately record and replay complex malicious web interactions. Crucially, in these attack scenarios, there was no divergence observed during the replay, indicating perfect fidelity in reproducing the attack's execution flow. This confirms WEBRR's effectiveness in its primary goal of forensic attack reconstruction.

Next, to assess its robustness with complex, everyday web applications, WEBRR was tested on several benign, highly dynamic websites. The system successfully recorded all of them, and the execution order of the JEUs was consistently correct. However, a minor discrepancy was noted in the edit distance between API sequences. Upon investigation, it was found that while the API sequences were correct, the return values for document.nodeType queries were sometimes incorrect during replay. This issue was attributed to WEBRR's use of a custom HTML parser during replay, which had an incorrect event type implementation for this specific scenario. The researchers emphasized that despite these incorrect return values, the replay did not crash or fail, and they believe this is an "additional engineering effort" that could be fixed. This highlights the complexity of achieving perfect fidelity in all aspects of web execution but also demonstrates the system's resilience.

Finally, the evaluation addressed the practical concerns of runtime and storage overhead, which are critical for any forensic system intended for "always-on" deployment.

• Runtime Overhead: WEBRR introduced a modest 3.44% increase in page load overhead. This low impact is significant, as it suggests that the system could be deployed in real-world scenarios without severely degrading user experience or system performance.
• Storage Overhead: The estimated storage requirement for WEBRR is approximately 2.2 terabytes (TB) for a single year of recording for a user working an 8-hour workday. While substantial, this figure is manageable for dedicated forensic infrastructure, especially given the richness of the data captured.

The evaluation also touched upon some limitations. WEBRR currently only supports the most popular methods for registering callbacks. More "rare" callback registration methods might not be scheduled correctly, potentially leading to replay inaccuracies. Additionally, while WEBRR was able to replay some drive-by download attacks, its effectiveness is case-by-case. The primary security limitation is that if an adversary manages to compromise the rendering process itself (e.g., through a browser exploit) and gains full control over Blink, they could potentially disable WEBRR's recording hooks, circumventing the tamper-proof design. However, this represents a higher bar for attackers than merely manipulating JavaScript.

Overall, the evaluation provides strong evidence that WEBRR is a highly effective and practical system for replaying web-based attacks, demonstrating high fidelity and manageable overheads, even with its identified minor limitations.

Defensive Implications

▶ Watch: WebRR's approach to handling executional divergence (6:35)

WEBRR presents significant advancements for cybersecurity defenders, particularly those involved in incident response, forensic analysis, and threat intelligence. Its capabilities directly address critical gaps in understanding and mitigating web-based attacks:

1. Enhanced Forensic Analysis: For forensic analysts, WEBRR provides an unprecedented ability to conduct dynamic and visual analysis of web-based attacks. Instead of relying on fragmented logs or static causality graphs, analysts can now precisely replay an attack, seeing exactly what the victim saw at the time of compromise. This is invaluable for understanding the social engineering components of attacks, such as deceptive login pages, malicious pop-ups, or subtle UI manipulations that lead to user interaction. It allows defenders to observe the full attack chain, from initial compromise to payload delivery and subsequent actions, in its original context.

1. Deeper Understanding of Attack Mechanics: Incident responders can leverage WEBRR to gain a much deeper understanding of how specific web APIs were abused, what JavaScript code was executed, and how DOM manipulations occurred. This granular insight helps in identifying specific vulnerabilities exploited, understanding the adversary's techniques, and accurately assessing the scope and impact of a breach. For instance, if an attack involved a complex chain of asynchronous events, WEBRR's deterministic replay can untangle this complexity and reveal the exact timing and order that led to the exploit.

1. Improved Threat Intelligence and Prevention: By enabling high-fidelity replay, WEBRR facilitates the creation of richer threat intelligence. Defenders can meticulously analyze new attack vectors and develop more targeted detection and prevention mechanisms. Understanding the exact visual and interactive elements of an attack can inform better user training, more robust web application security testing, and the development of advanced browser security features.

1. Validation of Security Controls: WEBRR can be used to validate the effectiveness of existing security controls. By replaying known attack scenarios within a monitored environment, organizations can verify if their WAFs, IDS/IPS, or endpoint detection and response (EDR) solutions would have successfully detected or prevented the attack.

However, defenders should also be aware of WEBRR's current limitations:

• Callback Registration Support: While WEBRR supports popular callback registration methods, it may not handle "more rare" methods deterministically. This means that highly novel or obfuscated attacks using obscure web APIs for scheduling might still lead to replay divergence. Defenders should be aware that 100% fidelity might not be guaranteed for all possible web attack permutations.
• Rendering Process Compromise: The tamper-proof nature of WEBRR relies on its hooks being inaccessible from JavaScript. However, if an adversary achieves a full compromise of the rendering process itself (e.g., via a browser zero-day exploit that gives them control over Blink), they could potentially disable WEBRR's recording mechanisms. This represents a higher-privilege attack, but it highlights that no system is entirely invulnerable. For drive-by download attacks, replay success can be on a case-by-case basis, implying that some forms of direct browser exploitation might bypass WEBRR's current instrumentation.

In summary, WEBRR empowers defenders with critical visibility into the intricacies of web-based attacks, transforming the static analysis of logs into a dynamic, visual, and highly accurate forensic experience. While not a silver bullet, it represents a substantial leap forward in web forensics, enabling more informed incident response and proactive security measures.

Key Takeaways

• Web-centric Forensics are Essential: Traditional system-level auditing falls short for web-based attacks, which require dynamic and visual analysis of browser interactions, DOM manipulations, and asynchronous JavaScript execution.
• Executional Divergence is a Major Challenge: The non-deterministic nature of asynchronous web APIs (like requestIdleCallback) due to variable render thread idle times causes existing in-browser record and replay systems to fail in faithfully reproducing attack scenarios.
• WEBRR's Novel Approach Solves Divergence: By instrumenting the browser's rendering engine (Blink) and implementing a custom replay scheduler, WEBRR gains fine-grained control over JavaScript execution, ensuring deterministic replay.
• JavaScript Execution Unit Partitioning is Key: WEBRR breaks down web application execution into discrete script, callback, and event units, recording their precise order and context to guarantee high-fidelity replay.
• High Fidelity with Low Overhead: WEBRR successfully replays all evaluated web-based attacks with no divergence, across multiple OSes, while incurring only a 3.44% page load overhead and manageable storage requirements (2.2 TB/year per user).
• Empowers Defenders with Visual and Dynamic Analysis: The system provides forensic analysts and incident responders with the ability to visually observe attacks exactly as they occurred, crucial for understanding social engineering and complex exploit chains.

About the Speaker(s)

The research presented on WEBRR was a collaborative effort by Joey Allen, Zheng Yang, Roberto Perdisci, and Wenke Lee.

Joey Allen was the primary presenter of the WEBRR talk at USENIX Security '24. As the lead speaker, he articulated the motivation, technical intricacies, and evaluation results of the WEBRR system. His presentation highlighted the critical need for advanced forensic tools capable of handling the unique challenges posed by modern web-based attacks.

Zheng Yang, Roberto Perdisci, and Wenke Lee are co-authors of the WEBRR research. Given the academic context of USENIX Security, they are likely researchers or professors with expertise in cybersecurity, systems, and network security, contributing significantly to the theoretical foundation, architectural design, and experimental validation of the WEBRR forensic system. Their collective work underscores a deep commitment to advancing the state of the art in understanding and defending against sophisticated digital threats.