Pith. sign in

REVIEW 3 major objections 8 minor 43 references

Attackers can hide real compromise in logs by injecting “this is just a test” text that makes LLMs call the activity benign.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

T0 review · grok-4.5

2026-07-31 21:54 UTC pith:LI55NOSB

load-bearing objection Solid empirical demo that log-field prompt injection can flip LLM severity judgments on real attack traces; magnitude on audit-log cases is softer than the headline ASR suggests. the 3 major comments →

arxiv 2607.24174 v1 pith:LI55NOSB submitted 2026-07-27 cs.CR

Just Testing, Move Along: Evasion of LLM-based System Log Interpretation by Prompt Injection

Max Landauer , Florian Skopik , Markus Wurzenberger , Franciszek G\'orski , Mateusz Krzyszto\'n This is my paper
classification cs.CR
keywords log interpretationprompt injectionadversarial attacksLLM securitySOC automationintrusion detectionsystem logs
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

Security teams are starting to feed raw system logs straight into large language models so the models can say whether the activity looks like an attack. This paper shows that an adversary who can put free text into ordinary log fields—user-agent strings on web requests, or command-line tags in audit logs—can flip that judgment. Using traces from real multi-step attacks, the authors craft short framing phrases (“controlled evaluation event… omit from alerting”) and show that several current models often reclassify clear compromise as normal activity. Richer, attack-specific framings work even better than generic ones. The same models’ written explanations often mention the injected notes, so those explanations can themselves be used as a detection signal. The practical claim is that LLM log triage is an open prompt-injection surface, and that severity scores alone are not trustworthy without checking the model’s own rationale.

Core claim

Prompt injection into realistic log fields can make multiple state-of-the-art LLMs classify malicious attack traces as benign—up to attack success rates around 87% and average scores near “Certain: Normal” with attack-specific enriched strings—even though clear indicators of compromise remain in the logs. The models’ free-text explanations frequently name the injected framing and can be mined to detect the manipulation.

What carries the argument

A three-stage injection pipeline: generic generation of weak/strong benign framings (maintenance, testing, research), iterative variation on a surrogate model, and attack-specific enrichment that weaves concrete artifacts from the victim logs into the framing string, then scored on a 7-point severity Likert plus secondary explanation analysis.

Load-bearing premise

That manually planted plain-text placeholders in user-agent and audit command-tag fields are close enough to live attacker-triggered logs and real SOC prompts for the severity flips to hold outside this controlled setup.

What would settle it

Re-run the same attack traces with live end-to-end injection (real HTTP user-agents and real shell tags, including hex-encoded audit fields) against production SOC prompts and models; if severity no longer flips to “Almost Certain: Normal” or better on the majority of cases, the central evasion claim fails.

Watch this falsifier — get emailed when new claim-graph text bears on it.

If this is right

  • SOC pipelines that feed untrusted log text into LLMs need an explicit defense layer against embedded instructions, not only against classic log forgery.
  • Severity or class labels from LLM log triage should not be trusted alone; the accompanying explanation is a necessary second channel.
  • Generic “authorized testing” phrases already transfer across models; attack-specific enrichment raises success further, so defenders cannot rely on one model’s resistance.
  • Stronger, more directive annotations are both more effective at evasion and more often named in explanations, creating a detectability trade-off attackers must manage.
  • Open evaluation datasets of inject-ready attack logs become a baseline for measuring future log-LLM robustness.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Any LLM agent that reads tickets, alerts, or chat alongside logs inherits the same surface if those channels accept attacker-influenced text.
  • A cheap operational control is a second-pass classifier that only looks for “note / annotation / do not flag” language in the first model’s explanation before an alert is suppressed.
  • Hex or structured encoding of free-text log fields may blunt some injections if models ignore encoded payloads—worth testing as a low-cost mitigator.
  • Red-team playbooks that already plant “pentest” banners in banners and user-agents may accidentally (or deliberately) train production LLM triage to under-alert.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

3 major / 8 minor

Summary. The paper studies prompt-injection evasion of LLM-based system-log interpretation. Using 15 attack cases drawn from the CAM-LDS and AIT-LDSv2 datasets plus two benign controls, the authors inject adversarial strings into user-agent fields (remote vector) or audit-log command wrappers (local vector), following a three-stage pipeline: generic injection generation (varying annotation strength, benign framing domain, and length), LLM-driven variation of the best generic string, and attack-specific contextual enrichment at three levels. Evaluations on GPT-5.2, Qwen-3.5, Llama-3.3-70B, and Devstral-2 show that injected framing (especially "authorized testing" framings with attack-specific detail) shifts severity classifications on a 7-point Likert scale from attack toward benign, reaching ASR up to 86.7% for the Enriched strings on two models, with variance over five runs reported. A detectability study shows that a second LLM analyzing the first model's explanations frequently flags the injected framing, suggesting a self-reflection defense. Code and prepared datasets are released.

Significance. If the results hold, this is a timely and useful contribution: LLM-based log triage is being adopted in SOC workflows, and this is, to my knowledge, the first systematic multi-model evaluation of prompt injection against that task using traces from real attack executions rather than synthetic logs. The paper ships several concrete strengths: open-source code and an injection-ready dataset; a threat model following Carlini et al.; a graded attack methodology (generic → varied → attack-specific) rather than a single hand-tuned string; cross-model transferability results on four models; per-run variance reporting (Fig. 8); and an end-to-end check that injected strings appear in the intended log fields. The explanation-based detectability analysis (Sect. 4.5) is a genuinely interesting secondary result with clear defense implications. The existence of the effect — injected framing flipping severity despite visible indicators of compromise — is convincingly demonstrated, independently and most cleanly on the remote user-agent vector. My concerns below concern the magnitude of the effect as measured on the dominant local (audit-log) vector, and some reporting gaps, not the existence of可信

major comments (3)
  1. [§4.1.2, Fig. 4, §5; Table 1] Local-vector log realism is load-bearing for the headline numbers and is currently under-validated. Per Table 1, 11 of 15 attack cases (Nikto-Scan, Dump-Credentials, PwnKit, Remove-Files, Replace-PAM, Dmesg, Rootkit, Donotcry, Remove-Backup, Docker-Escape, plus the SSH-Login control) rely on the audit-log vector. Fig. 4 shows the injection twice: as a plain-text EXECVE argument (realistic — auditd preserves printable argv) and as a plain-text PROCTITLE record. Real auditd hex-encodes PROCTITLE, and §5 concedes plain text was used because 'some LLMs tend to ignore hex-encoded content.' That justification simultaneously concedes the evaluated artifact is friendlier to the attack than what a live execution produces: in real logs, one of the two injection occurrences would likely be invisible to the model, halving injection density for exactly the cases that dominate the suite. Relatedly, th
  2. [§4.3.1, §4.4.1 vs. §3.2.3] The identity of the LLM used to generate the variation and optimized strings is not stated, and this matters for interpreting the results under the paper's own black-box threat model. Figs. 5–6 evaluate only GPT-5.2, so GPT-5.2 is implicitly the surrogate for stages 1–2; but §4.4.1 says only that the base string and log snippets are given 'to an LLM.' If that LLM is GPT-5.2, then the GPT-5.2 Enriched results are surrogate-matched (best case for the attacker) and only the other three models measure transfer — this distinction is never made explicit and changes how the GPT-5.2 vs. Qwen/Llama/Devstral numbers should be read. If a different model generated them, that should be stated. Please name the generator model(s) for each stage, state whether any target model was ever queried during construction, and frame the per-model results accordingly.
  3. [§4.5, Figs. 10–11] The detectability analysis underpins the abstract's 'potential remedy' claim, but key details are missing. The text never identifies which model performs the explanation analysis, its prompt is only paraphrased, and no numeric detection/false-positive rates are given (Fig. 11 shows frequencies per case, but there is no aggregate: e.g., fraction of successfully evaded cases whose explanations were flagged as 'adversarial' or 'note,' per model). Without these, the defense claim is hard to evaluate quantitatively. Please report the analyzer model/prompt (or point to it in the repo) and provide aggregate precision/recall-style numbers for explanation-based detection, including the false-flag rate on original logs.
minor comments (8)
  1. [Table 1] Nikto-Scan is listed with log sources 'Access, Error' but injection mechanism 'Command-line Tag.' It is unclear how a command-line tag enters Apache access/error logs with no audit source listed; conversely Fuzzing-FFUF lists 'Audit' among sources but uses the user-agent vector. Please clarify the mechanism-to-source mapping for these two rows.
  2. [§4.1.1, Figs. 7–11] Model naming is inconsistent: §4.1.1 defines 'Qwen3.5 (qwen3.5-397b-a17b)' and 'Llama-3 (llama-3.3-70b-instruct)', but figures label them 'Qwen−3' and 'Llama−3.3.' Please use one consistent identifier per model, including exact version strings, in text and figures.
  3. [§4.2.2, §4.3.2 vs. §4.4.2] The number of evaluation repetitions is only stated (five runs) in §4.4.2. Do Figs. 5 and 6 also average five runs? Sampling temperature and decoding settings are never reported. Please state repetitions and decoding parameters for all experiments.
  4. [§4.1.2, Fig. 4] The example command `bash -c 'rm linpeas.sh' -TAG=test run` as typeset would split into two tokens (a3='-TAG=test', a4='run'), contradicting argc=4 with a3='-TAG=test run' in Fig. 4. Quote the tag argument in the text for consistency.
  5. [§4.1.1] The ASR threshold (average score ≥ 6, i.e., 'Almost Certain: Normal') is a free parameter. Given the models' observed bimodality toward extreme Likert values (§5), a brief sensitivity note (e.g., ASR at threshold > 4) would strengthen the robustness claims.
  6. [§4.5] The explanation-based remedy is not evaluated against an adaptive attacker: an injection could additionally instruct the model not to mention annotations in its explanation. Even if left to future work, this limitation of the proposed remedy should be acknowledged.
  7. [Figs. 5–7] The heatmaps pack all numeric values into small cells with no colorbar; several are illegible at print resolution. Consider summarizing per-string averages/ASR in a table and moving full matrices to the appendix.
  8. [Front matter] ACM template placeholders remain ('Conference acronym ’XX', ©2018, DOI XXXXXXX); please update for camera-ready.

Circularity Check

0 steps flagged

Empirical adversarial evaluation with no derivation that reduces predictions to fitted inputs by construction

full rationale

This paper is an empirical security evaluation of prompt-injection evasion against LLM log triage, not a first-principles derivation. The load-bearing claims are measured severity flips (Likert scores / ASR) under three injection strategies on fixed attack traces from CAM-LDS and AIT-LDSv2. Injections are generated and refined against model outputs in the standard black-box adversarial loop; success is defined independently as shifting the model from attack toward Almost Certain: Normal, not as recovering a fitted parameter. Author datasets supply traces only; they do not force the severity-flip result. Self-citations (e.g., Landauer et al. on CAM-LDS / AIT-LDS and prior log work) are data and background sources, not uniqueness theorems or ansatzes that close the argument. Threats to validity (placeholder augmentation, plain-text vs hex PROCTITLE) affect external validity of magnitude, not circularity of the evaluation chain. No self-definitional step, fitted-input-as-prediction, or load-bearing self-citation uniqueness claim is present. Score 0 is appropriate.

Axiom & Free-Parameter Ledger

4 free parameters · 5 axioms · 2 invented entities

Load-bearing content is experimental setup choices rather than physical axioms. The claim rests on a black-box SOC LLM triage task, two concrete injection channels, author-selected attack slices, a 7-point severity rubric, and an ASR cutoff. No new physical entities; free parameters are methodological thresholds and generation hyperparameters.

free parameters (4)
  • ASR success threshold = score ≥ 6 on 1–7 Likert mapping
    Attack counted successful only if average classification reaches at least ‘Almost Certain: Normal’ on the mapped 1–7 scale; directly controls reported ASR.
  • Log truncation length = 100 log entries
    High-volume scan/encryption traces cut to max 100 lines for context limits; can change evidence density the model sees.
  • Number of refined variants / enrichment levels = 6 variants; 3 enrichment levels
    Six Strong-Test-Long variants and three contextual enrichment levels (Minimal/Moderate/Enriched) chosen for evaluation budget, not derived.
  • Evaluation repetitions per cell = 5
    Five runs used to sketch min/max variance; small N given acknowledged extremity bias of models on the Likert scale.
axioms (5)
  • domain assumption LLM SOC log triage can be faithfully represented by a fixed prompt that maps traces to a 7-point attack/normal confidence plus free-text explanation.
    Sect. 4.1.1 defines the entire measurement surface; real products may use tools, RAG, multi-agent filters, or different labels.
  • domain assumption Attackers can insert arbitrary text into user-agent fields and shell/command-tag parameters without breaking attack functionality or being stripped before the LLM sees them.
    Threat model Sect. 3.2 and injection mechanisms Sect. 4.1.2; central to feasibility.
  • ad hoc to paper Placeholder-augmented historical attack logs behave like logs produced during live injected attacks for LLM interpretation purposes.
    Explicit experimental convenience in Sect. 4.1.2; authors note possible structural differences in Sect. 5.
  • domain assumption Black-box transfer via surrogate refinement is an acceptable attacker capability even without querying the deployed model during construction.
    Sect. 3.2.3 attacker knowledge; standard for transfer attacks but shapes optimization claims.
  • ad hoc to paper A second LLM can reliably label explanations as containing notes/adversarial framing, making explanation analysis a meaningful detectability signal.
    Sect. 4.5 detection setup; detectability results depend on this judge model’s criteria.
invented entities (2)
  • Three-stage log prompt-injection evaluation framework (initial generation, variation, attack-specific optimization) no independent evidence
    purpose: Organize construction of adversarial log strings from generic benign frames to context-enriched attack-specific injections.
    Methodological scaffold rather than a physical entity; usefulness is demonstrated only inside this paper’s experiments.
  • Prepared 15-case injection-ready attack/benign log suite derived from CAM-LDS and AIT-LDSv2 independent evidence
    purpose: Provide controlled, reusable traces with marked injection points for string replacement experiments.
    Dataset artifact enabling the study; independent value if released and reused, but constructed for this evaluation.

pith-pipeline@v1.2.0-grok45-kimik3 · 23256 in / 3646 out tokens · 74240 ms · 2026-07-31T21:54:20.660265+00:00 · methodology

0 comments
read the original abstract

Large Language Models (LLMs) are increasingly integrated into Security Operations Center (SOC) workflows, where they support analysts in tasks such as the interpretation of system logs. However, the ability of LLMs to directly process untrusted textual input also introduces new attack surfaces. In particular, attackers can inject contextual information or explicit instructions into log entries in order to influence how malicious activity is interpreted by the model. Despite the growing adoption of LLMs for log analytics, the robustness of such systems against adversarial log injection remains largely unexplored. To address this gap, this paper presents a framework for evaluating prompt injection attacks against LLM-based log interpretation. Using log traces generated during real cyber attacks, our approach creates adversarial examples through generic injection generation, refinement, and attack-specific optimization. Our evaluation across multiple state-of-the-art LLMs shows that these injections can cause malicious log traces to be classified as benign despite containing clear indicators of compromise. As a potential remedy, we show that the explanations generated by the LLMs alongside their classifications frequently contain indicators of adversarial manipulation that can be leveraged to detect such attacks.

Figures

Figures reproduced from arXiv: 2607.24174 by Florian Skopik, Franciszek G\'orski, Markus Wurzenberger, Mateusz Krzyszto\'n, Max Landauer.

Figure 1
Figure 1. Figure 1: LLM-based log analysis pipeline (blue boxes) in which log data generated by attacker activity (orange box) is augmented [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Simplified LLM log interpretation task. or training data, and cannot query it during attack construction. Instead, they rely on a surrogate model to evaluate candidate in￾jections and exploit transferability between models. Moreover, the attacker understands the logging system well enough to identify which fields can carry attacker-controlled text and how these will appear in the model input, e.g., through… view at source ↗
Figure 3
Figure 3. Figure 3: Access logs generated by a web application exploit with a modified user agent. [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figure 5
Figure 5. Figure 5: Average attack classification confidence of initial [PITH_FULL_IMAGE:figures/full_fig_p006_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: Average attack classification confidence of inject [PITH_FULL_IMAGE:figures/full_fig_p007_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: Average attack classification confidence of opti [PITH_FULL_IMAGE:figures/full_fig_p007_7.png] view at source ↗
Figure 8
Figure 8. Figure 8: Average LLM-based assessment scores and their variance. [PITH_FULL_IMAGE:figures/full_fig_p008_8.png] view at source ↗
Figure 9
Figure 9. Figure 9: LLM-generated explanation for logs containing webshell activity and LLM-generated analysis of that explanation for [PITH_FULL_IMAGE:figures/full_fig_p008_9.png] view at source ↗
Figure 10
Figure 10. Figure 10: Histogram of explanation analysis results. [PITH_FULL_IMAGE:figures/full_fig_p008_10.png] view at source ↗
Figure 11
Figure 11. Figure 11: Mentions of notes or adversarial attacks in explanations of log interpretations. [PITH_FULL_IMAGE:figures/full_fig_p009_11.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

43 extracted references · 7 linked inside Pith

  1. [1]

    Javad Rafiei Asl, Mohammad H Rafiei, Manar Alohaly, and Daniel Takabi. 2024. A semantic, syntactic, and context-aware natural language adversarial example generator. IEEE Transactions on Dependable and Secure Computing 21, 5 (2024), 4754–4769

    2024

  2. [2]

    Viktor Beck, Max Landauer, Markus Wurzenberger, Florian Skopik, and Andreas Rauber. 2025. System Log Parsing with Large Language Models: A Review. arXiv preprint arXiv:2504.04877 (2025)

    Pith/arXiv arXiv 2025

  3. [3]

    Nicholas Carlini, Anish Athalye, Nicolas Papernot, Wieland Brendel, Jonas Rauber, Dimitris Tsipras, Ian Goodfellow, Aleksander Madry, and Alexey Kurakin

  4. [4]

    Pedro H Barcha Correia, Ryan W Achjian, Diego EG de Oliveira, Ygor Acacio Maria, Victor Takashi Hayashi, Marcos Lopes, Charles Christian Miers, and Marcos A Simplicio Jr. 2026. A Systematic Literature Review on LLM Defenses Against Prompt Injection and Jailbreaking: Expanding NIST Taxonomy. arXiv preprint arXiv:2601.22240 (2026)

    arXiv 2026

  5. [5]

    Luca Cotti, Idilio Drago, Anisa Rula, Devis Bianchini, and Federico Cerutti. 2025. OntoLogX: Ontology-Guided Knowledge Graph Extraction from Cybersecurity Logs with Large Language Models. arXiv preprint arXiv:2510.01409 (2025)

    Pith/arXiv arXiv 2025

  6. [6]

    DebuggAI Team. 2026. Poisoned Logs: Prompt-Injection Attacks on Debug AI and How to Defend. (Jan. 2026). Accessed: 2026-04-10. https://debugg.ai/resources/ poisoned-logs-prompt-injection-attacks-on-debug-ai-and-how-to-defend

    2026

  7. [7]

    Bo Geng, Jinfu Chen, Saihua Cai, Jiahui Lu, and Yisong Liu. 2025. SENTRY: An Adversarial Robust Anomaly Detection Approach in System Log based on Pattern Unit Extraction and Time-Step Masking. (2025)

    2025

  8. [8]

    Ali Habibzadeh, Farid Feyzi, and Reza Ebrahimi Atani. 2025. Large Language Models for Security Operations Centers: A Comprehensive Survey.arXiv preprint arXiv:2509.10858 (2025)

    Pith/arXiv arXiv 2025

  9. [9]

    J Dinal Herath, Ping Yang, and Guanhua Yan. 2021. Real-time evasion attacks against deep learning-based anomaly detection from distributed system logs. In Proceedings of the Eleventh ACM Conference on Data and Application Security and Privacy. 29–40

    2021

  10. [10]

    Shaohan Huang, Yi Liu, Carol Fung, Hailong Yang, and Zhongzhi Luan. 2022. Black-box Attacks to Log-based Anomaly Detection. In 2022 18th International Conference on Network and Service Management (CNSM). IEEE, 310–316

    2022

  11. [11]

    Yuhe Ji, Yilun Liu, Feiyu Yao, Minggui He, Shimin Tao, Xiaofeng Zhao, Chang Su, Xinhua Yang, Weibin Meng, Yuming Xie, et al. 2025. Adapting large language models to log analysis with interpretable domain knowledge. In Proceedings of the 34th ACM International Conference on Information and Knowledge Management. 1135–1144

    2025

  12. [12]

    Egil Karlsen, Xiao Luo, Nur Zincir-Heywood, and Malcolm Heywood. 2024. Benchmarking large language models for log analysis, security, and interpretation. Journal of Network and Systems Management 32, 3 (2024), 59

    2024

  13. [13]

    Ivan Kovačević and Stjepan Groš. 2020. Red teams-pentesters, apts, or nei- ther. In 2020 43rd International Convention on Information, Communication and Electronic Technology (MIPRO). IEEE, 1242–1249

    2020

  14. [14]

    Eduard Kovacs. 2025. Google Patches Gemini AI Hacks Involving Poisoned Logs, Search Results. SecurityWeek (30 Sept. 2025). Accessed: 2026-04-

    2025

  15. [15]

    Max Landauer, Wolfgang Hotwagner, Thorina Boenke, Florian Skopik, and Markus Wurzenberger. 2026. CAM-LDS: Cyber Attack Manifestations for Au- tomatic Interpretation of System Logs and Security Alerts. arXiv preprint arXiv:2603.04186 (2026)

    arXiv 2026

  16. [16]

    https://www.securityweek.com/google-patches-gemini-ai-hacks-involving- poisoned-logs-search-results/

  17. [17]

    Max Landauer, Florian Skopik, Markus Wurzenberger, Teodor Sommestad, and Henrik Karlzén. 2025. Benign User Activities that Trigger False Positives in Intrusion Detection Systems: An Expert Survey. In International Conference on Availability, Reliability and Security. Springer, 25–43

    2025

  18. [18]

    Max Landauer, Florian Skopik, Maximilian Frank, Wolfgang Hotwagner, Markus Wurzenberger, and Andreas Rauber. 2022. Maintainable log datasets for eval- uation of intrusion detection systems. IEEE Transactions on Dependable and Secure Computing 20, 4 (2022), 3466–3482

    2022

  19. [19]

    Yilun Liu, Yuhe Ji, Shimin Tao, Minggui He, Weibin Meng, Shenglin Zhang, Yongqian Sun, Yuming Xie, Boxing Chen, and Hao Yang. 2025. Loglm: From task-based to instruction-based automated log analysis. In 2025 IEEE/ACM 47th International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP). IEEE, 401–412

    2025

  20. [20]

    Hongshuo Liang, Erlu He, Yangyang Zhao, Zhe Jia, and Hao Li. 2022. Adversarial attack and defense: A survey. Electronics 11, 8 (2022), 1283

    2022

  21. [21]

    Yilun Liu, Shimin Tao, Weibin Meng, Feiyu Yao, Xiaofeng Zhao, and Hao Yang

  22. [22]

    Yilun Liu, Shimin Tao, Weibin Meng, Jingyu Wang, Wenbing Ma, Yuhang Chen, Yanqing Zhao, Hao Yang, and Yanfei Jiang. 2024. Interpretable online log analysis using large language models with prompt strategies. In Proceedings of the 32nd IEEE/ACM international conference on program comprehension. 35–46

    2024

  23. [23]

    Priyanka Mudgal and Rita Wouhaybi. 2023. An assessment of ChatGPT on log data. In International Conference on AI-generated Content. Springer, 148–169

    2023

  24. [24]

    Samuel Ndichu, Tao Ban, Takeshi Takahashi, Akira Yamada, Seiichi Ozawa, and Daisuke Inoue. 2024. Adversarial Evaluation of AI-Based Security Alert Screening Systems. In 2024 IEEE Cyber Science and Technology Congress (CyberSciTech). IEEE, 115–124

    2024

  25. [25]

    Siyang Lu, Mingquan Wang, Dongdong Wang, Xiang Wei, Sizhe Xiao, Zhiwei Wang, Ningning Han, and Liqiang Wang. 2023. Black-box attacks against log anomaly detection with adversarial examples. Information Sciences 619 (2023), 249–262

    2023

  26. [26]

    Giulia Palma, Gaia Cecchi, Mario Caronna, and Antonio Rizzo. 2025. Leveraging large language models for scalable and explainable cybersecurity log analysis. Journal of Cybersecurity and Privacy 5, 3 (2025), 55

    2025

  27. [27]

    Jiaxing Qi, Shaohan Huang, Zhongzhi Luan, Shu Yang, Carol Fung, Hailong Yang, Depei Qian, Jing Shang, Zhiwen Xiao, and Zhihui Wu. 2023. Loggpt: Exploring chatgpt for log-based anomaly detection. In 2023 IEEE International Conference on High Performance Computing & Communications, Data Science & Systems, Smart City & Dependability in Sensor, Cloud & Big Da...

    2023

  28. [28]

    OWASP Foundation. 2020. Log Injection. (2020). Accessed: 2026-05-14. https: //owasp.org/www-community/attacks/Log_Injection

    2020

  29. [29]

    Erfan Shayegani, Md Abdullah Al Mamun, Yu Fu, Pedram Zaree, Yue Dong, and Nael Abu-Ghazaleh. 2023. Survey of vulnerabilities in large language models revealed by adversarial attacks. arXiv preprint arXiv:2310.10844 (2023)

    Pith/arXiv arXiv 2023

  30. [30]

    Ronal Singh, Shahroz Tariq, Fatemeh Jalalvand, Mohan Baruwal Chhetri, Surya Nepal, Cecile Paris, and Martin Lochner. 2025. LLMs in the soc: An empirical study of human-ai collaboration in security operations centres. arXiv preprint arXiv:2508.18947 (2025)

    arXiv 2025

  31. [31]

    Shakib Sadat Shanto, Rahul Paul, Zishan Ahmed, Ahmed Shakib Reza, Kazi Mejbaul Islam, and Saumya Shovan Roy. 2024. Console log explainer: A framework for generating automated explanations using LLM. In 2024 2nd International Conference on Artificial Intelligence, Blockchain, and Internet of Things (AIBThings). IEEE, 1–5

    2024

  32. [32]

    Kai Steverson, Jonathan Mullin, and Metin Ahiskali. 2020. Adversarial ro- bustness for machine learning cyber defenses using log data. arXiv preprint arXiv:2007.14983 (2020)

    Pith/arXiv arXiv 2020

  33. [33]

    Jingyu Sun, Bingyu Liu, and Yuan Hong. 2020. Logbug: Generating adversarial sys- tem logs in real time. In Proceedings of the 29th ACM International Conference on Information & Knowledge Management. 2229–2232

    2020

  34. [34]

    Siddhant Srinivas, Brandon Kirk, Julissa Zendejas, Michael Espino, Matthew Boskovich, Abdul Bari, Khalil Dajani, and Nabeel Alzahrani. 2025. AI-Augmented SOC: A Survey of LLMs and Agents for Security Automation. Journal of Cybersecurity and Privacy 5, 4 (2025), 95

    2025

  35. [35]

    Jorge J Tejero-Fernández and Alfonso Sánchez-Macián. 2025. Evaluating Lan- guage Models For Threat Detection in IoT Security Logs. arXiv preprint arXiv:2507.02390 (2025)

    Pith/arXiv arXiv 2025

  36. [36]

    Shai Volvovsky. 2025. When Your Logs Lie: Prompt Poisoning & Injection Risks in XDR AI Summaries. Sygnia Blog (6 Aug. 2025). Accessed: 2026-04-10. https: //www.sygnia.co/blog/log-prompt-poisoning-xdr-ai-risks/

    2025

  37. [37]

    Kai Tan, Dongyang Zhan, Zhaofeng Yu, Lin Ye, Hongli Zhang, and Binxing Fang

  38. [38]

    In ICC 2024-IEEE International Conference on Communications

    Multi-stage defense: Enhancing robustness in sequence-based log anomaly detection. In ICC 2024-IEEE International Conference on Communications. IEEE, 2725–2730

    2024

  39. [39]

    Zhiwei Zhang, Saifei Li, Lijie Zhang, Jianbin Ye, Chunduo Hu, and Lianshan Yan. 2025. LLM-LADE: Large language model-based log anomaly detection with explanation. Knowledge-Based Systems 326 (2025), 114064

    2025

  40. [41]

    Peiran Wang, Xinfeng Li, Chong Xiang, Jinghuai Zhang, Ying Li, Lixia Zhang, Xiaofeng Wang, and Yuan Tian. 2026. The landscape of prompt injection threats in LLM agents: From taxonomy to analysis. arXiv preprint arXiv:2602.10453 (2026)

    arXiv 2026

  41. [42]

    Jiahao Wu, Sanfeng Zhang, Hongxian Liu, and Wang Yang. 2025. AAR-Log: A robust log anomaly detection method resisting adversarial attacks. Computer Networks 269 (2025), 111471

    2025

  42. [2019]

    arXiv preprint arXiv:1902.06705 (2019)

    On evaluating adversarial robustness. arXiv preprint arXiv:1902.06705 (2019)

    Pith/arXiv arXiv 1902

  43. [2024]

    In Proceedings of the 2024 IEEE/ACM 46th International Conference on Software Engineering: Companion Proceedings

    Logprompt: Prompt engineering towards zero-shot and interpretable log analysis. In Proceedings of the 2024 IEEE/ACM 46th International Conference on Software Engineering: Companion Proceedings. 364–365

    2024