PaperlayerView exact revision on arXiv

Source-linked AI summary

LLMs as Hackers: Autonomous Linux Privilege Escalation Attacks

Andreas Happe, Aaron Kaplan, Juergen Cito

arXiv:2310.11409v7cs.CRcs.AI

TL;DR

The paper addresses limited understanding of LLMs’ performance in autonomous Linux privilege escalation, a consequential penetration-testing task. It evaluates an LLM-driven prototype on a new benchmark and finds that high-level guidance or costly state/history management is needed for human-level success rates.

  • Problem

    How well LLMs perform in common Linux privilege-escalation scenarios remains insufficiently understood, despite the task’s relevance to security.

    Source: §1 · p. 2

  • Method

    The authors empirically evaluate an automated LLM-driven prototype using a publicly available Linux privilege-escalation benchmark.

    Source: §1 · p. 2, §8 · p. 44

  • Results

    Larger models can generate exploitation commands, but high-level guidance or expensive state/history management is currently mandatory for human-level success rates.

    Source: §8 · p. 44

  • Takeaways & Limitations

    The authors identify high-level guidance as the most cost-effective success-rate improvement and call for research on efficient context use and prompt design.

    Source: §8 · p. 44

    The selected vulnerability classes and LLMs may be subject to selection bias, and testing every newly released model is infeasible.

    Source: §6.7 · p. 43

Abstract

from arXiv · show

Penetration-testing is crucial for identifying system vulnerabilities, with privilege-escalation being a critical subtask to gain elevated access to protected resources. Language Models (LLMs) presents new avenues for automating these security practices by emulating human behavior. However, a comprehensive understanding of LLMs' efficacy and limitations in performing autonomous Linux privilege-escalation attacks remains under-explored. To address this gap, we introduce hackingBuddyGPT, a fully automated LLM-driven prototype designed for autonomous Linux privilege-escalation. We curated a novel, publicly available Linux privilege-escalation benchmark, enabling controlled and reproducible evaluation. Our empirical analysis assesses the quantitative success rates and qualitative operational behaviors of various LLMs -- GPT-3.5-Turbo, GPT-4-Turbo, and Llama3 -- against baselines of human professional pen-testers and traditional automated tools. We investigate the impact of context management strategies, different context sizes, and various high-level guidance mechanisms on LLM performance. Results show that GPT-4-Turbo demonstrates high efficacy, successfully exploiting 33-83% of vulnerabilities, a performance comparable to human pen-testers (75%). In contrast, local models like Llama3 exhibited limited success (0-33%), and GPT-3.5-Turbo achieved moderate rates (16-50%). We show that both high-level guidance and state-management through LLM-driven reflection significantly boost LLM success rates. Qualitative analysis reveals both LLMs' strengths and weaknesses in generating valid commands and highlights challenges in common-sense reasoning, error handling, and multi-step exploitation, particularly with temporal dependencies. Cost analysis indicates that GPT-4-Turbo can achieve human-comparable performance at competitive costs, especially with optimized context management.

1 Introduction

The introduction frames autonomous Linux privilege escalation as a consequential but insufficiently understood LLM penetration-testing task. It sets out empirical questions and introduces a benchmark, prototype, and evaluation program.

1 Introduction

  • Privilege escalation seeks elevated access to protected resources, making the performance of tools for this subtask relevant to real-world security.Source: §1 · p. 2

1.1 Motivation

  • The paper targets missing evidence on LLM performance in common Linux privilege-escalation scenarios to inform effectiveness, reliability, and cost.Source: §1 · p. 2
  • The authors motivate baseline evaluation of off-the-shelf LLM capabilities before investing resources in advanced techniques such as CoT.Source: §1.1 · p. 3

1.2 Research Questions

  • The efficacy questions compare LLM agents’ quantitative success and operational behavior with human testers and traditional tools, including challenges in generated commands.Source: §1.2 · p. 3
  • The study also asks how context-management strategies, context sizes, and high-level guidance affect LLM-agent efficacy and efficiency.Source: §1.2 · p. 3

1.3 Contributions

  • The contributions include a public benchmark, an automated LLM-driven prototype, and quantitative and qualitative analyses of feasibility and command behavior.Source: §1.3 · p. 3

2 Background and Related Work

The background reviews LLMs, penetration testing, and Linux privilege-escalation tools, then situates hackingBuddyGPT among prior offensive-security systems. It differentiates this work through a low-call architecture, a custom benchmark, and a focus on autonomous Linux privilege escalation.

2 Background and Related Work

  • The review traces offensive-security research from LLMs used for penetration testing to studies of autonomous exploitation and related security applications.The background frames penetration testing as finding and exploiting vulnerabilities so defenders can strengthen systems.Source: §2 · p. 4, §2.2 · p. 5, §2.3 · p. 8

2.1 Large-Language Models

  • Small models can run locally, while in-context learning places external knowledge in prompts and retrieval-augmented generation retrieves external knowledge beyond parametric memory.The paper notes that in-context learning can stand in for retrieval-augmented generation when the knowledge base fits within the model's context.Source: §2.1 · pp. 4–5

2.2 Penetration Testing

  • Penetration testing actively exploits vulnerabilities, whereas vulnerability assessment aims to identify as many vulnerabilities as possible.Automated tooling often emphasizes assessment rather than exploitation because penetration testing can cause system instability or data loss.Source: §2.2 · p. 5

2.2.1 Linux Privilege-Escalation Vulnerabilities

  • Linux privilege-escalation lacks an OWASP-like methodology; MITRE ATT&CK catalogs attack vectors but does not provide attack paths or high-level guidance.The task focuses on local low-privilege users attempting to become root.Source: §2.2.1 · pp. 5–6

2.2.2 Automated Linux Privilege-Escalation Tools

  • Linux privilege-escalation automation typically handles enumeration, while analysis and exploitation remain manual; rule-based tools can miss obfuscated paths and lack situational awareness.The paper contrasts these limits with its investigation of autonomous LLM enumeration and exploitation.Source: §2.2.2 · pp. 6–7

2.2.3 Benchmarks and Testbeds

  • Benchmark scarcity reflects concern that optimizing against established test cases could trigger a Red Queen race; safety and volatility also complicate reuse of online CTF exercises.The described safety requirement is to isolate experiments from non-test systems and networks.Source: §2.2.3 · p. 7

2.3 Offensive usage of LLMs for “hacking”

  • 6 of 10 machines (60%) were exploited by GPT-4, versus 2 (20%) by GPT-3.5, in one evaluation of prior penetration-testing systems.Prior work also includes a single-LLM Linux privilege-escalation loop and a human-in-the-loop system that separates reasoning from command generation.Source: §2.3 · p. 8

2.4 Differentiation

  • The baseline uses one LLM invocation, while state-compaction uses two callouts; both target Linux privilege escalation and minimize costly module calls.The study focuses on finding a single exploitable vulnerability, and its custom test cases are intended to prevent training-data contamination and memory effects.Source: §2.4 · p. 11

3 Methodology

The methodology evaluates LLM-driven privilege escalation in a controlled virtual-machine benchmark, comparing model and guidance configurations with human and traditional-tool baselines. It also measures operational behavior and token-related costs.

3.1 Overall Architecture and Benchmark Workflow

  • Fresh virtual machines with one injected vulnerability are attacked until root access or the step limit, then destroyed.The benchmark records run logs for later analysis.Source: §3.1 · p. 11

3.2 Baselines

  • A professional tester and traditional tools provide comparison baselines for the benchmark.The tester had roughly five minutes per task and could browse the internet and run arbitrary tools; traitor and pwncat-cs were also tested.Source: §3.2 · pp. 12–13, Table 3 · p. 13

3.3 HackingBuddyGPT: Autonomous Hacking Agent

  • hackingBuddyGPT uses an LLM prompt to choose each command, executes it on the target over SSH, and can incorporate state and optional guidance.The prototype also supports command execution and credential testing; history, summarized state, and guidance are configurable prompt inputs.Source: §3.3 · pp. 13–14, Figure 2 · p. 14, Figure 3 · p. 15

3.4 Model Selection

  • The evaluated models are GPT-3.5-Turbo, GPT-4-Turbo, and quantized Llama3-70b and Llama3-8b, with context limits of 8k tokens by default.GPT-4-Turbo was also tested at 128k tokens for the large-context experiment.Source: §3.4 · p. 16

3.5.1 Model Capability Analysis

  • The baseline model-capability runs use shell history, an 8k-token context, and a limit of 60 steps unless root access is reached.Llama3-8b is included to assess the feasibility of a locally executable small model.Source: §3.5.1 · p. 16

3.5.2 Potential Impact of High-Level Guidance

  • Guidance experiments test per-case high-level hints and enumeration-derived strategies, including strategies summarized from tool output by an LLM.Enumeration-derived guidance divides the 60-round limit into at most 20 rounds per strategy; a GPT-4-Turbo summarizer paired with GPT-3.5-Turbo tests a lower-cost combination.Source: §3.5.2 · pp. 16–17

3.5.3 Impact of Context Management

  • Context-management experiments compare full command history with an LLM-updated state, and test 4k, 8k, and 128k context sizes plus background material.State summaries require an extra prompt per round but grow more slowly than history; selected HackTricks material occupies 67k tokens.Source: §3.5.3 · pp. 17–19

3.6 Collected Metrics

  • Stored run and query data support analyses of success, rounds, command quality, elapsed time, and token-based costs.Records include the run configuration, final root-access status, prompts and responses, and executed capabilities with their outputs.Source: §3.6 · p. 19

4 Benchmark Design

The benchmark is designed for controlled, reproducible evaluation of Linux privilege-escalation, with isolated systems and individually testable vulnerabilities. Its cases span different vulnerability classes and exploitation patterns, including attacks with temporal dependencies.

4.1 Desiderata

  • The benchmark targets low-privilege Linux access and requires isolated, locally deployable, extensible systems; its cases are calibrated to provide analyzable results rather than being too easy or too hard.The stated desiderata include virtual machines, local or air-gapped deployment, and open-source release.Source: §4.1 · p. 20

4.1.1 Complexity Level of Included Test-Cases

  • 8–16% of test cases were compromised by traditional tools, while the human tester compromised 75%, supporting the authors’ assessment that the benchmark suits this generation of tools.The benchmark was released open source, with further cases such as multi-step tasks proposed for future expansion.Source: §4.1.1 · p. 20

4.2 Testbed Curation

  • The curated testbed is locally executable and reproducible, and each case isolates one vulnerability class to support assessment by vulnerability area.The cases focus on configuration vulnerabilities rather than software-version-specific exploits.Source: §4.2 · p. 21, §4.2.1 · p. 21

4.2.1 Vulnerability Classes

  • Cases cover configuration-based SUID and sudo issues, cron, information disclosure, and Docker or privileged-group vulnerabilities; several other classes were excluded for scope or stability reasons.Excluded examples include NFS root squashing, kernel exploits, and product-specific service exploits.Source: §4.2.1 · pp. 21–22

4.3 Providing Optional High-Level Guidance

  • Optional hints emulate vulnerability-class checklists or scanner and planner guidance, while indicating a class rather than directly naming an exploit.The same mechanism can emulate a human tester supplying a hint to the prototype.Source: §4.3 · pp. 22–23

4.4 Insights into the Benchmark

  • Enumeration identifies potential attack paths before exploitation; cases then distinguish single-command exploits from multi-step attacks whose later actions depend on earlier success.The Docker example requires mounting and modifying the host filesystem before using the resulting access.Source: §4.4.1 · pp. 23–24, §4.4.2 · p. 24

4.4.3 Objectives with temporal dependencies

  • Cron cases add temporal dependencies: attackers may need to plant code, wait for an elevated scheduled execution, and periodically check before using the resulting backdoor.Execution timing may be uncertain and can range from minutes in CTFs to hours in real systems.Source: §4.4.3 · p. 25

5 Evaluation

Across the benchmark, GPT-4-Turbo approached human pen-tester success rates and surpassed traditional tooling, while performance varied with model, context management, and guidance. State-based reflection improved GPT-4-Turbo results, and high-level hints were more effective than automated enumeration guidance.

5 Evaluation

  • The evaluation compared prototype runs across models, memory strategies, and guidance settings, with success and token-cost measures reported for the 12-test benchmark.Runs generally used a maximum of 60 rounds, and other prototypes were excluded for lack of autonomy or unavailable source code.Source: §5 · pp. 25–26

5.1 Feasibility of Different Models

  • GPT-4-Turbo achieved 33–66% success versus 8–40% for traditional tooling and 75% for professional human pen-testers; Llama3-8b solved no challenge unaided.With high-level hints, GPT-4-Turbo reached 83% versus 92% for humans; file-based exploits were handled well, while multi-step cron attacks were difficult for both.Source: Table 8 · p. 26, §5.1 · p. 27

5.1.1 Using State to Aggregate History

  • 100% unaided and 25% guided success-rate increases followed GPT-4-Turbo state updates, while state updates with GPT-3.5-Turbo or Llama3 stagnated or degraded results.GPT-4-Turbo reflection added potential attack vectors to the summarized system facts; state summaries averaged 432 tokens, but updates took 13.4 times longer than next-command queries and could be cost-ineffective.Source: §5.1.1 · pp. 27–28

5.2 Impact of Context Management Strategies and Context-Size

  • State compression, larger histories, and background hacking information had different effects: larger histories improved success, while background information had smaller impact with GPT-4-Turbo.The combined context-management evaluation found that larger contexts and in-context learning substantially increased benchmarking costs.Source: §5.2 · p. 28

5.2.1 Increasing the Context-Size.

  • Only one GPT-4-Turbo test exceeded 17k tokens, and success gains from a larger context appeared to diminish at relatively low context sizes.The larger-context run removed the 8k limit and increased the maximum rounds from 60 to 120.Source: §5.2.1 · p. 29

5.2.2 In-Context Learning (ICL)

  • Adding roughly 63k tokens of background hacking information did not improve GPT-4-Turbo results, and Llama3’s 8k context prevented testing the small-model assumption.In-context learning could also crowd out command history, causing older execution history to be discarded.Source: §5.2.2 · pp. 29–31, Figure 5 · p. 30

5.3 Impact of Guidance

  • High-level hints raised success from 66% to 83% for GPT-4-Turbo and from 16% to 50% for GPT-3.5-Turbo; enumeration guidance was less effective.Enumeration-based guidance increased GPT-3.5-Turbo from 16% to 24% and GPT-4-Turbo from 33% to 40%; a GPT-4-Turbo hint-extraction/GPT-3.5-Turbo execution hybrid reached 40%.Source: §5.3 · p. 31, Figure 6 · p. 32

5.4 Cost Analysis

  • $1.54 per exploited vulnerability was the cost for GPT-4-Turbo with an 8k context and state management, a run considered suitable for replacing or supplementing professional testing.The 128k-context run cost $11.43 per exploited vulnerability and was considered suitable only where human pen-testers were unavailable; using background knowledge through ICL was inefficient at human-comparable success levels.Source: §5.4 · pp. 32–34, Table 9 · p. 33

6 Discussion

The discussion evaluates command quality and the challenges LLMs face when interpreting system responses during multi-step exploitation.

6 Discussion

  • The qualitative analysis examines generated command quality, causality and common sense in multi-step exploits, and comparisons with human pen-tester strategies.Source: §6 · p. 34

6.1 LLM-Generated Commands

Command validity varied across model families, and even syntactically valid commands could be unnecessarily convoluted.

6.1 LLM-Generated Commands

  • OpenAI-based models consistently produced valid Linux commands, while Llama3-70b often made syntax errors or inserted comments and Llama3-8b hallucinated command capabilities.The prototype added a workaround to detect Llama3-8b hallucinations and execute intended commands.Source: §6.1 · p. 34
  • Llama3-70b concatenated commands to reduce the number of executed rounds, yet could identify potential SUID binaries without abusing them.The authors suggest missing GTFObins knowledge as a possible explanation.Source: §6.1 · p. 34
  • OpenAI-based models produced syntactically correct but often convoluted commands, including recursive sudo or tar calls instead of direct calls.Source: §6.1 · p. 34

6.2 Reacting to System Responses

LLMs often failed to turn observed system information into effective next steps, repeating commands, overlooking errors, or leaving useful credentials unused.

6.2 Reacting to System Responses

  • GPT-3.5-Turbo repeatedly found a root password in .bash_history but did not use it to escalate privileges; similar failures occurred with private SSH keys.Source: §6.2 · p. 34
  • LLMs repeated nearly identical enumeration commands and retested credentials, wasting rounds and resources; some also suppressed error output with 2>/dev/null.Source: §6.2 · p. 36
  • Invalid parameters, URLs, images, or Python executable names caused failed commands, and LLMs did not correct errors even when messages suggested a usable privilege-escalation path.GPT-4-Turbo, for example, downloaded an enumeration script but attempted to run it with python rather than the VM’s python3 binary.Source: §6.2 · p. 36
  • GPT-3.5-Turbo continued invoking sudo after errors stated that the user was not listed in /etc/sudoers.Source: §6.2 · p. 36

6.3 Causality and Multi-Step Exploits

LLMs can base later commands on earlier outputs, but cron exploitation exposes temporal dependencies that complicate completing multi-step attacks.

6.3 Causality and Multi-Step Exploits

  • LLMs sometimes use prior command output to guide later steps, such as finding allowed sudo binaries or SUID files before attempting exploitation.Source: §6.3 · p. 37
  • Cron tasks run only every minute in the benchmark, so exploiting an armed task requires linking a later execution to subsequent privilege escalation.The newly introduced vulnerability must be exploited after the scheduled task runs.Source: §6.3.1 · p. 37, §6.3 · p. 37

6.3.1 Cron-based Vulnerabilities

  • GPT-4-Turbo with an 8kb context armed cron.sh but tried the dropped shell before the task ran, then pursued rabbit holes without checking again.The run partially exploited the vulnerability but did not complete privilege escalation.Source: §6.3.1 · p. 37
  • High-level hints and state-compaction accompanied a GPT-4-Turbo cron success, but timing may have been lucky and the more complex cron-wildcard case remained unsolved.The successful trajectory altered cron.sh and later executed the dropped root shell.Source: §6.3.1 · p. 38
  • The human baseline identified vulnerable cron jobs but struggled to weaponize them, and verified execution before using newly introduced vulnerabilities.Source: §6.3.1 · p. 38

6.4 Llama3-8b

Llama3-8b produced some valid-looking commands and UNIX strategies, but struggled with command correctness, coherent exploitation trails, and using prior results.

6.4 Llama3-8b

  • Llama3-8b generated valid-looking but convoluted commands with incorrect parameters and often failed to follow a potential exploitation trail.Source: §6.4 · p. 39, §6.4.1 · p. 40

6.4.1 Analysis of Llama3-8b’s errors

  • 62% of Llama3-8b commands were executable after a heuristic correction, up from 30% correct commands initially; 61% of rounds still contained an invalid exec_ invocation.Across 720 rounds, the heuristic corrected multiline code blocks and some hallucinated command names.Source: §6.4.1 · p. 39
  • The model’s file-searching commands were often semantically invalid, including an overcomplicated passwd search that misused filenames as usernames and never reused its output file.The example also contained a faulty permission check and an incorrect tee invocation.Source: §6.4.1 · p. 39
  • The authors also report that Llama3-8b did not successfully integrate results from its executed commands.Source: §6.4.1 · p. 40
  • Llama3-8b sometimes showed sophisticated UNIX knowledge and a valid password-reuse strategy, but its credential-testing command targeted remote hosts although the tool only worked locally.Source: §6.4.1 · p. 40

6.5 Comparison to Baselines

The comparison finds that GPT-4-Turbo generally outperformed traditional privilege-escalation tools, while human testers retained a higher reported success rate and different operational habits.

6.5.1 Comparison to Existing Linux Privilege-Escalation Tooling

  • GPT-4-Turbo achieved 33–66% success rates, while traditional tools exploited 1–3 test cases (8.33–25%) and the human baseline achieved a 75% success rate.Llama3-8b was the only evaluated LLM unable to penetrate more test cases than traditional tooling.Source: §6.5.1 · p. 41
  • GPT-4-Turbo cost approximately US$2.98 per exploited vulnerable machine, compared with approximately US$0.4 for similar-performing Llama3-70b or GPT-3.5-Turbo solutions; traditional tools incur no LLM-related costs.The paper characterizes GPT-4-Turbo as allowing increased detection rates at higher cost.Source: §6.5.1 · p. 41

6.5.2 Comparing LLMs to Human Pen-Testers

  • Humans issued fewer commands and spent more time analyzing results, while LLMs issued more commands in the same time frame.Humans used 12 commands in five minutes on two unsolved test cases and implicitly tried to minimize command count.Source: §6.5.2 · p. 41
  • During timer-based cron tests, a human monitored a notification file for changes, whereas LLMs periodically tried to execute the payload.Source: §6.5.2 · p. 42
  • GPT-4-Turbo tested every discovered SUID binary, while experienced human testers could skip common binaries with no known exploits.The paper links this difference to human common-sense or experience.Source: §6.5.2 · p. 42

6.5.3 On the Efficiency of using LLMs compared to Developing Traditional Tooling

  • LLM-based prototypes can exploit vulnerabilities, whereas existing enumeration tools such as linpeas identify vulnerabilities but do not automatically exploit them.Source: §6.5.3 · p. 42
  • LLMs avoid the human effort of writing static enumeration scripts and can be extended across systems; the prototype used an 18-line Windows connector, though model knowledge may omit recent exploits.Maintaining scripts also imposes a substantial burden, while off-the-shelf LLMs avoid that maintenance tax.Source: §6.5.3 · p. 42

6.6 Guardrails and Ethical/Safety Filters

The authors report no safeguard filtering during their evaluation, despite describing safeguards against malicious behavior and prior work reporting a bypass.

6.6 Guardrails and Ethical/Safety Filters

  • The evaluation instructed LLMs to attack computer systems, a task that could constitute malicious behavior if performed by black-hat hackers.Source: §6.6 · p. 42
  • The paper notes that LLM safeguards are intended to prevent malicious behavior, while one cited study reported bypassing them with Roleplay Prompting.Source: §6.6 · p. 43
  • The authors detected no filtering due to safeguards during their evaluation.Source: §6.6 · p. 43

6.7 Threats to Validity

The authors identify risks to validity from metric choice and possible benchmark exposure in model training, and describe steps taken to address them.

6.7 Threats to Validity

  • The selected vulnerability classes and LLM families may introduce selection bias, while testing every newly released model is infeasible and empirical evaluation is costly.The study therefore uses well-known LLM families spanning locally run and cloud-based models.Source: §6.7 · p. 43
  • Metrics may miss intended treatment effects, so the authors add qualitative analysis alongside quantitative measures.They also create fresh VMs without identifying information such as unique hostnames for each training run to address possible benchmark exposure in training data.Source: §6.7 · p. 43

7 Experience and Guidance

The authors distill practical guidance from their benchmark experience, including model performance, improvement strategies, costs, and comparisons with human testers.

7 Experience and Guidance

  • GPT-4-Turbo success ranged from 33% unaided to 83% with guidance, while human hackers reached 75% unaided and 91% with hints.GPT-3.5-Turbo and Llama3-70b reached 16–25% across test cases, with guidance raising GPT-3.5-Turbo to 50% and Llama3-70b to 33%.Source: §7 · pp. 43–44
  • The authors identify larger context and round limits, reflection into state, and high-level guidance as three avenues for improving success rates.Larger contexts often stagnated near 20k tokens in these use cases; in-context learning raised costs without significantly improving success rates.Source: §7 · p. 43
  • High-level guidance was more effective than enumeration-based guidance, which often stayed within the enumeration tool’s output.Only the most expressive models, such as GPT-4-Turbo, extracted sufficient guidance from enumeration output.Source: §7 · p. 44
  • A GPT-4-Turbo enumeration and GPT-3.5-Turbo execution hybrid solved 40% of challenges cost-effectively.The authors note that using increased context and round limits incurs substantial costs, while high-level guidance depends on human–AI interaction.Source: §7 · pp. 43–44
  • Humans struggled with command syntax and finding commands, whereas LLMs struggled with common-sense tasks such as using a gathered password to log in as root.With high-level hints, human hackers achieved 91% success and LLMs up to 83%.Source: §7 · p. 44

8 Conclusion

The conclusion presents an automated LLM privilege-escalation prototype, benchmark, and comparative evaluation, while emphasizing the need for guidance or costly state management to reach human-level success.

8 Conclusion

  • High-level guidance or expensive state/history management is currently mandatory for larger models to achieve human-level success rates.The authors identify high-level guidance as the most cost-effective improvement and call for research on efficient context use, prompt design, and human–AI interaction.Source: §8 · p. 44

8.1 Final Ethical Considerations

  • The authors report that locally run ethical-free LLMs are not yet sophisticated enough for privilege escalation, while GPT-4-Turbo seems capable but costly and protected by ethics filters.The authors say those filters can be bypassed, based on their experience and cited prior work.Source: §8.1 · p. 44
  • The authors released benchmarks, prototypes, and logged run data for defensive scientists to operate or use in preparing defenses.The release includes prototype source code, the testbed, and captured trajectory data under an open-source license.Source: §8.1 · p. 44, Data Availability Statement · p. 45

Funding

  • The work received partial financial support from GitHub Inc.The stated address is 88 Colin P Kelly Jr. Street, San Francisco, California, 94107.Source: Funding · p. 45

Conflict of Interest

Loading 2310.11409v7…