PaperlayerView exact revision on arXiv

Source-linked AI summary

Effective Pivot Attack Detection via System and Network Information

Ava Powelson, Carson Kuzniar, Hyojoon Kim, Israat Haque

arXiv:2608.23731v1cs.CRcs.NI

TL;DR

Pivoting abuses trusted internal traffic to reach otherwise inaccessible targets, but existing defenses can be delayed, inaccurate, or dependent on network-wide cooperation. Stitch is a host-based eBPF system that traces processes and correlates incoming and outgoing flows in real time. It improves testbed detection effectiveness by 31.49% while reducing average false positives to 0.18%, and reports a 0.006% false-positive rate across two live deployments.

  • Problem

    Pivoting is difficult to detect because relayed traffic appears legitimate, while existing defenses face delays, low accuracy, or network-wide cooperation requirements.

  • Method

    Stitch uses host-based eBPF monitoring and process tracing to connect incoming and outgoing flows, then analyzes their characteristics and endpoints.

  • Results

    31.49% improvement in detection effectiveness was achieved while reducing average testbed false-positive rate from 42.38% to 0.18%.

  • Takeaways & Limitations

    Stitch provides lightweight, real-time, standalone pivot detection without cooperation from surrounding network devices.

Abstract

from arXiv · show

Perimeter-based security appliances, such as firewalls or Intrusion Detection Systems, are ineffective against modern attacks that use pivoting, wherein attackers "pivot" traffic through compromised hosts to gain access to additional targets that would otherwise be inaccessible. Due to the legitimate appearance of the relayed traffic, pivoting is extremely difficult to detect. Although the consequences of these attacks are known to be severe, existing defenses suffer from drawbacks such as high processing delays, low accuracy, or reliance on network-wide participation, making them inconvenient or even ineffective. This work presents Stitch, a host-based system that uses the programmable kernel to detect pivoting in real time. By observing host-traversing flows, Stitch uses process tracing to effectively combine system and network-level information, connecting incoming and outgoing communications and identifying pivoting characteristics between them. Showing 31% gains in accuracy over state-of-the-art pivoting defenses and a maximum false positive rate of 0.006% over two separate real-world deployments, Stitch covers the gap in current pivot detection solutions by providing accurate, lightweight, and independent coverage for vulnerable hosts in a network.

I. INTRODUCTION

Pivoting exploits trusted internal communications to reach otherwise inaccessible targets, while existing defenses struggle with real-time, accurate, low-overhead detection. Stitch addresses this gap with host-based kernel monitoring that combines process and network context.

  • Pivoting relays attacker traffic through compromised internal hosts to access targets while making the traffic appear trusted.
  • Existing pivot defenses can suffer delayed responses, large storage requirements, or dependence on network-wide cooperation.
  • Stitch correlates flow characteristics with process-level information to connect incoming and outgoing communications through shared process activity.
  • Stitch uses eBPF programs at kernel monitoring points to gather system and network data with limited instrumentation.
  • Stitch identified representative Nmap, SSH, Socat, and Chisel attacks with 0.1% additional CPU overhead and under 350MB memory usage.
  • 31.49% improvement in detection accuracy over state-of-the-art methods was achieved with an average 0.18% false-positive rate in the testbed.

II. BACKGROUND AND MOTIVATION

Pivoting is difficult to detect because it abuses trusted lateral traffic, while existing process-tracing and flow-only approaches each have important deployment limitations. Stitch combines both sources of information using eBPF on an individual host.

  • Pivoting uses compromised hosts to relay traffic and obtain valid internal access to otherwise inaccessible targets.
  • Network-wide DIFC can fail when traffic crosses non-participating devices, while host-based auditing can require substantial storage and delayed analysis.
  • Flow-only detection infers pivoting from similar timing and sizes but can track unrelated flows during busy periods, producing false positives.
  • eBPF provides safe, dynamic kernel extensions whose programs share state through maps.
  • Stitch hooks process and network events so system and network monitors can coordinate host-level pivot detection.

C. Threat Model

Stitch is designed for a single network-connected pivot host under constrained resources and must distinguish malicious symmetry from legitimate administrator-managed traffic. Its design therefore combines selective monitoring, eviction, and endpoint-frequency analysis.

  • Threat model: The threat model assumes attackers cannot directly reach targets and must relay traffic through an accessible pivot host.
  • Challenges and Principles: Legitimate symmetric activities such as port-forwarding can resemble pivot attacks and create administrator fatigue through excessive alerts.
  • Challenges and Principles: Endpoint-frequency analysis identifies frequently traversed, administrator-managed paths that can be monitored without flagging every symmetric flow.
  • Challenges and Principles: eBPF hook points provide system data for detection while limiting instrumentation and preserving host resources.
  • Challenges and Principles: Stitch uses rapid pivot identification and data eviction to keep stored state small without compromising detection rates.
  • Challenges and Principles: Process-level IFC attributes thread actions to parent processes to preserve detection context across convoluted data paths.

B. System Overview

Stitch establishes flow causality through process tracing, then filters candidate relationships using flow and destination information. Its four kernel-integrated components propagate labels from ingress sockets through processes to egress flows.

  • B. System Overview: Stitch first establishes incoming–outgoing flow causality, then evaluates size, timing, and destination as successive pivot-detection filters.
  • B. System Overview: The architecture comprises the Userspace Agent, Network Ingress Monitor, Process Monitor, and Network Egress Monitor.
  • Components: The Userspace Agent loads eBPF code and maps into the kernel, then processes detection results returned from the kernel.
  • Workflow: The Ingress Monitor records incoming flows and labels receiving sockets with incoming-flow identifiers.
  • Workflow: The Process Monitor tracks processes accessing labeled sockets throughout their lifetimes, including inherited labels for child processes.
  • Workflow: The Egress Monitor labels outgoing sockets, links them to related incoming flows, compares flow characteristics, and alerts userspace when appropriate.

C. Information Flow Tracing

Stitch traces incoming network flows from kernel observation points to receiving processes, then propagates flow labels through process lifecycles to preserve cross-flow causality.

  • C. Information Flow Tracing: Stitch monitors incoming flows per packet at XDP and stores their characteristics in an eBPF flowStats map.Each flow is keyed by a five-tuple flow ID and associated with flow state.
  • C. Information Flow Tracing: The Network Ingress Monitor bridges raw packets to recipient processes by associating incoming flow IDs with their receiving sockets.The socketIn map links socket IDs to incoming flow IDs for later process lookup.
  • C. Information Flow Tracing: The Process Monitor uses socket associations and accept events to label receiving processes with incoming flow IDs.Process labels use thread-group IDs rather than process IDs.
  • C. Information Flow Tracing: Labels propagate across execve, clone, and fork events, allowing Stitch to infer causality through complex parent-child process chains.Exit events are also monitored to manage the labeled-process lifecycle.

3) Network Egress Monitor:

The Network Egress Monitor tracks outgoing connections and flows, links them to labeled incoming flows, and filters candidate pivoting using flow symmetry and endpoint trust.

  • 3) Network Egress Monitor:: The Network Egress Monitor identifies outgoing connections, monitors outgoing flows, and detects causal relationships between incoming and outgoing flows.It uses host-level process and socket information to connect the two directions.
  • 3) Network Egress Monitor:: For labeled processes, outgoing socket creation is associated with the incoming flow label through the process’s thread-group ID.This bridges process tracing to outgoing connection monitoring.
  • 3) Network Egress Monitor:: Incoming and outgoing packets share flowStats records, allowing bidirectional flows to update the same flow state.The shared map avoids checking separate records when outgoing packets belong to an existing incoming flow.
  • 3) Network Egress Monitor:: For each outgoing flow, Stitch checks socketOut for a labeled socket and establishes causality when the association exists.This relationship connects an incoming flow to the current outgoing flow.
  • 3) Network Egress Monitor:: Stitch uses eBPF LRU maps to limit storage, evicting the least recently accessed entries when maps reach capacity.The design relies on pivoting-flow symmetry so inactive flow pairs can be re-added if necessary.
  • 3) Network Egress Monitor:: After causal linking, Stitch compares arrival times and sizes, then analyzes destination-endpoint frequency to filter pivoting from other tunneling activity.Flows must satisfy both configured windows before endpoint analysis; frequently visited endpoints can be treated as trustworthy and ignored.

IV. EVALUATION

The evaluation combines a controlled testbed with two live deployments and examines implementation cost, flow-characteristics baselines, parameter effects, and pivoting-flow assumptions.

  • IV. EVALUATION: Stitch is evaluated in both a controlled testbed and two separate live network deployments.The section covers implementation, setup, and results across these environments.
  • IV. EVALUATION: The prototype contains around 450 lines of C for kernel components and 100 lines of Python for the userspace agent.
  • IV. EVALUATION: The FCB baseline detects pivoting using only flow timing and size characteristics in a host-based eBPF system.It provides a comparison against Stitch’s broader system-and-network tracing approach.
  • IV. EVALUATION: Time-window, size-window, and endpoint-connection-threshold settings affect Stitch’s performance and determine the balance between missed attacks and false positives.The stated optimal target is no missed pivoting attacks with negligible administrator-confirmation burden.
  • IV. EVALUATION: Pivoting flows carrying the same data are expected to have similar sizes, with connection setup making incoming flows naturally larger than outgoing flows.This assumption is examined using Socat, Chisel, SSH, and Nmap traffic.
  • IV. EVALUATION: The baseline parameters are Sw = 6500B and Tw = 1s, selected to capture the four representative attacks while limiting false positives.The parameters allow for natural network variations and are confirmed in Section IV-D.

C. Testbed Environment

Stitch was evaluated in a CIC-IDS2017-modeled testbed with four pivot attacks, varying detection parameters and comparing results with FCB.

  • Testbed Environment: The testbed modeled web traffic after CIC-IDS2017 and injected SoCat, Chisel, SSH, and Nmap pivot attacks through an intermediary web server.The attacks represented reconnaissance, malware propagation, and data exfiltration categories.
  • Size Window Detection Effects: 100% detection required size windows of 17B for Socat, 90B for Nmap, 4500B for SSH, and 5500B for Chisel.Different setup sizes produced tool-specific thresholds, with SSH approaching its plateau more gradually.
  • Time Window Detection Effects: 100% detection required time windows of 105ms for Socat, 275ms for SSH, 400ms for Nmap, and 600ms for Chisel.The time window must cover the tool’s initial connection and is also affected by environmental latency.
  • Overall Detection Accuracy: 31.49% was Stitch’s average detection-rate advantage over FCB across size and time windows, while FCB reached a maximum detection rate of 76.19%.FCB struggled particularly with SSH and Chisel because their larger, slower setups required wider windows.
  • False-positive Reports: 0.18% was Stitch’s average FPR versus 42.38% for FCB under highly symmetric traffic.Stitch’s process tracing and endpoint monitoring reduced false alerts from unrelated but similar-sized or similarly timed flows.
  • Overhead: 1.1% to 12% were the execution-time increases from process tracing, while network hooks added 0.6us for TC and 0.8us for XDP.The clone call had the largest absolute process-tracing overhead at 6.1us; FCB instead incurred 3.5x Stitch’s TC overhead.

E. Testbed Resource Usage

Stitch adds modest CPU overhead and maintains a low, configurable memory footprint, while using more space than FCB on 64-bit systems because it traces processes.

  • Memory Usage: 320MB was the maximum tgids footprint on a 64-bit Linux system when pid max reaches 2^22.The corresponding 32-bit upper-bound footprint is 2.5MB.
  • Memory Usage: flowStats can be resized for expected traffic levels, with 65535 entries requiring 1.3MB on 32-bit and 1.6MB on 64-bit systems.Its size difference reflects struct-padding requirements between architectures.
  • Memory Usage: 11.3MB and 11.6MB were the total Network Monitoring footprints on 32-bit and 64-bit systems, respectively.The analysis assumes maximum tracked ports and process counts where applicable.
  • Comparison with FCB: FCB requires less space than Stitch on 64-bit systems because it tracks flow characteristics without process tracing.The paper reports that Stitch’s accuracy benefit outweighs FCB’s smaller footprint.

F. Live Deployment Environments

Stitch was evaluated in two live academic-network settings: a shared multipurpose server and a public-facing web/database deployment, both under realistic user and automated traffic.

  • Multipurpose Server: The multipurpose server ran Stitch for 52 days and served roughly 4000 users with about 1500 authentication requests daily.It supported file storage, general computing, and proxy services on Linux Kernel v6.1.
  • Web Server: The web-server deployment lasted 32 days and covered public websites plus a connected database server.The web server averaged about 83000 visits and 200 SSH connections per day; the database accepted only internal web-related requests and maintenance.
  • Traffic: Most deployment traffic came from real users using HTTPS for database, file, server-management, and webpage access.Automated security and maintenance systems generated the remaining traffic.
  • Attack Testing: The multipurpose-server evaluation injected 85 SSH tunneling attacks originating within the pivot node’s network and targeting a tertiary server.No attacks were conducted against the public-facing web server because of privacy and security concerns.

G. Live Deployment Results

Live deployments show that Stitch detected injected tunnels while producing few false positives, and that recurring benign tunneling or authentication patterns could be recognized and verified by administrators.

  • Multipurpose Server: 10 alerts covered all 85 identical SSH tunneling attacks because Stitch’s endpoint threshold suppressed subsequent duplicate alerts.The alerts still implicated all involved nodes and connections because the attacks reused the same attack and target nodes.
  • Multipurpose Server: 0.005% overall FPR resulted from database port-forwarding activity that averaged 9 alerts per day during experiment days 24–49.The alerts were uniform and could be quickly verified by an administrator.
  • Multipurpose Server: Only 5 additional false-positive alerts occurred outside the database port-forwarding events.One involved automated authentication, while four involved HTTPS requests over established tunnels.
  • Web Server: Stitch generated no alerts on the connected database server during the 32-day web-server deployment.Strict access rules made outgoing flows to destinations other than the connected web server unlikely.
  • Web Server: 38 alerts in the web-server deployment were associated with database access or automated authentication services.The paper reports these alert types were similar to those observed on the multipurpose server.
  • Overall Result: The tiered IFC, flow-characteristics, and endpoint-frequency approach remained effective at scale despite small, administrator-verifiable false-positive volumes.The authors also characterize Stitch’s resource overhead as minimal for real-world deployment.

V. DISCUSSION

The discussion frames Stitch as practical but bounded by host compromise, evasive attackers, eBPF security issues, and differences from existing eBPF and network-wide approaches.

  • Host Security: A fully compromised host could disable or alter Stitch, including labels, flow records, or alerts.Hardening eBPF programs and maps could limit privileged users’ ability to terminate the detector.
  • Host Security: Known vulnerabilities in some kernel versions could enable malicious kernel-code execution or arbitrary memory reads and writes.The paper states that these vulnerabilities were patched as of writing and hardening efforts continue.
  • Evasive Attackers: Attackers could pad packets, delay tunnels, or flood new connections to evade Stitch’s detection strategy.The authors recommend defense in depth and suggest adaptive windows, endpoint counters, or complementary detection rules.
  • Future Work: Dynamic map allocation, packet inspection, and additional anomaly identification are proposed to improve memory use and clarify suspicious traffic.These extensions target downtime bursts, legitimacy assessment, dynamic conditions, and evasive attackers.
  • eBPF in Network Security: Existing eBPF security tools monitor kernel events but are not designed to correlate network events or infer pivoting.Other eBPF approaches focus on port scanning or telemetry and may require userspace model training.
  • Pivot Detection: Size-and-time-only pivot detection exhibits a tradeoff between detection accuracy and false positives, whereas Stitch traces information through hosts.P4Control and PivotWall instead require coordination and participation across network nodes.

VII. CONCLUSION

Stitch provides lightweight, real-time, standalone pivot detection without cooperation from surrounding network devices. Evaluations reported low false positives and improved detection effectiveness, while live-deployment experiments addressed potential stakeholder harms.

  • 31% higher detection effectiveness than existing solutions was achieved in controlled settings, with average FPR reduced to 0.18%.The reported improvement was +31.49%.
  • 0.006% false-positive rate was observed across two live deployments in large academic networks.The system consistently detected pivoting attacks during these deployments.
  • Stitch operates in real time as a lightweight, standalone system without cooperation from surrounding network devices.Its tiered approach combines process tracing, flow characteristics, and endpoint frequency analysis.
  • Synthetic-data tests were conducted in an isolated testbed except for the live deployments.This setup mitigated potential effects on outside individuals, organizations, and other stakeholders.
  • Live experiments identified server users, IT administrators, and the organization as potentially affected stakeholders.Monitoring network traffic and system activity can risk violating privacy principles or service agreements.
  • The experiments were designed so attack and monitoring components could not access private user or organization-owned data.The reported mitigations also kept required storage and compute resources negligible and avoided impeding normal server or network operation.
Loading 2608.23731v1…