TaoLi-NYU/llmagent4incidense-response-aaai26summer
GitHub: TaoLi-NYU/llmagent4incidense-response-aaai26summer
基于轻量级 LLM 的端到端网络事件响应代理方案,通过微调和思维链推理实现安全事件的自动感知、状态推断与处置策略生成。
Stars: 0 | Forks: 0
# 上下文自主网络事件响应:一种端到端大型语言模型 Agent 方法
本代码库包含与论文《上下文自主网络事件响应:一种端到端大型语言模型 Agent 方法》相关的产物,该论文已被 AAAI 2026 夏季系列研讨会接收。我们提出利用大型语言模型(LLM)的预训练安全知识和上下文学习,为事件响应规划创建一个端到端的 agentic 解决方案。具体而言,我们的 agent 将感知、推理、规划和行动这四项功能集成到一个轻量级 LLM(14b 模型)中。通过 fine-tuning 和 chain-of-thought 推理,我们的 LLM agent 能够处理系统日志并推断底层网络状态(感知),更新其对攻击模型的推测(推理),模拟不同响应策略下的后果(规划),并生成有效的响应(行动)。
## 环境要求
- Python 3.8+
- `torch`
- `transformers`
- `peft`
- `bitsandbytes`
- `accelerate`
## 安装说明
克隆本代码库并以可编辑模式安装:
```
git clone https://github.com/TaoLi-NYU/llmagent4incidense-response-aaai26summer.git
cd llmagent4incidense-response-aaai26summer
pip install -e .
```
要安装或升级所需的依赖项:
```
pip install -e . --upgrade
```
## 开发
安装开发依赖项:
```
pip install -r requirements_dev.txt
```
运行代码检查和测试:
```
flake8 .
mypy .
pytest
```
## 产物
- 我们实验中使用的 incident-response fine-tuning 数据集可在
[Hugging Face](https://huggingface.co/datasets/kimhammar/CSLE-IncidentResponse-V1/tree/main) 上获取。
- 我们 fine-tune 后的模型的 LoRA adapter 权重可在
[Hugging Face](https://huggingface.co/GYR1-determine/llmagent4incident-response) 上获取。
## 在我们的动作生成数据集上 Fine-tuning DeepSeek-R1-Distill-Qwen-14B
命令:
```
python examples/fine_tune_action_generation.py
```
预期输出:
```
Fetching 4 files: 100% 4/4 [01:16<00:00, 19.04s/it]
Loading checkpoint shards: 100% 4/4 [00:33<00:00, 8.25s/it]
generation_config.json: 100% 181/181 [00:00<00:00, 2.02MB/s]
README.md: 100% 33.0/33.0 [00:00<00:00, 363kB/s]
action_examples.json: 100% 694M/694M [00:05<00:00, 136MB/s]
Generating train split: 1 examples [00:09, 9.84s/example]
Trainable parameters: 50331648
...
Step: 299, Epoch: 0.1086, Progress: 10.86%, Avg_loss=0.9460, LR=0.00084720, Grad_norm=0.3544, minutes: 315.9855
prediction:
I note that the attacker is actively communicating with our internal and external resources, so I choose to immediately isolate the affected hosts and block all traffic to and from the attacker IPs to stop further spread and data exfiltration.
{
"Action": "Isolate WikiServer, GitServer, and DevWorkstation; block all traffic to and from 185.140.53.11, 185.140.53.12, and 185.140.53.13 at firewalls and proxies.",
"Explanation": "Immediate isolation and blocking halt attacker communication and lateral movement."
}
label:
I note that the attacker IPs are actively communicating with internal systems and facilitating lateral movement, so to immediately stop further spread and communication, I choose to block their IPs at the perimeter and isolate the most affected hosts to contain the attack.
{
"Action": "Block all traffic to attacker IPs 185.140.53.11, 185.140.53.12, and 185.140.53.13 at perimeter firewalls and immediately isolate WikiServer (203.0.113.120) and DevWorkstation (10.66.22.41) from the network.",
"Explanation": "Cutting external and internal communication halts spread and C2, achieving immediate containment."
}<|end▁of▁sentence|>
```
## 在我们的状态预测数据集上 Fine-tuning DeepSeek-R1-Distill-Qwen-14B
为了对模型进行状态预测的 fine-tuning,请使用 `examples/fine_tune_action_generation.py` 并将其 `load_dataset` 调用替换为:
```
load_dataset("kimhammar/CSLE-IncidentResponse-V1", data_files="states_examples.json")
```
预期输出:
```
Fetching 4 files: 100% 4/4 [01:15<00:00, 18.91s/it]
Loading checkpoint shards: 100% 4/4 [00:34<00:00, 8.63s/it]
generation_config.json: 100% 181/181 [00:00<00:00, 1.36MB/s]
README.md: 100% 33.0/33.0 [00:00<00:00, 242kB/s]
states_examples.json: 100% 1.30G/1.30G [00:04<00:00, 280MB/s]
Generating train split: 1 examples [00:15, 15.77s/ examples]
Trainable parameters: 50331648
Step: 1, Epoch: 0.0006, Progress: 0.06%, Avg_loss=1.7383, LR=0.00095000, Grad_norm=1.3308, minutes: 1.2491
...
Step: 249, Epoch: 0.1594, Progress: 15.93%, Avg_loss=0.4396, LR=0.00079926, Grad_norm=0.1929, minutes: 98.7646
prediction:
I see that reviewing logs and performing forensic triage provides sufficient knowledge to understand the attack timeline and scope, so I update knowledge sufficiency to true.
{
"are_forensics_preserved": true,
"is_attack_contained": true,
"is_eradicated": false,
"is_hardened": false,
"is_knowledge_sufficient": true,
"is_recovered": false
}
label:
By reviewing and analyzing the collected logs and evidence, I gain detailed understanding of the attack timeline and scope. Therefore, knowledge is now sufficient, with forensic evidence preserved and containment maintained.
{
"are_forensics_preserved": true,
"is_attack_contained": true,
"is_eradicated": false,
"is_hardened": false,
"is_knowledge_sufficient": true,
"is_recovered": false
}<|end▁of▁sentence|>
...
```
## 在我们的 incident 数据集上 Fine-tuning DeepSeek-R1-Distill-Qwen-14B
为了对模型进行 incident 识别的 fine-tuning,请使用 `examples/fine_tune_action_generation.py` 并将其 `load_dataset` 调用替换为:
```
load_dataset("kimhammar/CSLE-IncidentResponse-V1", data_files="incident_examples.json")
```
预期输出:
```
Fetching 4 files: 100% 4/4 [01:13<00:00, 18.34s/it]
Loading checkpoint shards: 100% 4/4 [00:33<00:00, 8.30s/it]
generation_config.json: 100% 181/181 [00:00<00:00, 1.41MB/s]
README.md: 100% 33.0/33.0 [00:00<00:00, 250kB/s]
incident_examples.json: 100% 190M/190M [00:01<00:00, 135MB/s]
Generating train split: 1 examples [00:02, 2.51s/example]
Trainable parameters: 50331648
Step: 1, Epoch: 0.0016, Progress: 0.16%, Avg_loss=1.1644, LR=0.00095000, Grad_norm=0.4378, minutes: 1.0350
...
Step: 199, Epoch: 0.3184, Progress: 31.84%, Avg_loss=0.6381, LR=0.00064904, Grad_norm=0.1456, minutes: 158.3210
prediction:
I note that in the logs there is no recorded activity or events; the logs are entirely blank, which means there is no evidence of suspicious or malicious behavior to analyze. Given that the system description outlines a peer-to-peer network with a decentralized mesh topology and multiple nodes each performing distinct roles such as bootstrap_node, relay_node, edge_node, validator_node, storage_node, and dht_node, I would expect to see logs indicating routine network traffic, peer discovery, data exchange, or consensus operations if there were any anomalies. The absence of any log entries suggests that the network is operating without issues or alerts. Additionally, the security monitoring system, which is a distributed Snort IDS covering all nodes with logs sent to 172.16.100.5, would normally capture and record any suspicious activities, such as intrusion attempts, known malicious IP connections, or protocol violations. Since no such entries appear in the logs, I infer that no security events or intrusions have been detected. The firewall rules include default allow_p2p_protocols and rate_limit_new_connections, which align with normal p2p network behavior, and the external_restrictions block known malicious IPs and limit new connections, further reducing the chance of successful attacks. Therefore, the combination of an empty log, a secure network design, and active security monitoring strongly supports the conclusion that the system is operating normally and that there is no incident or cyberattack occurring.
{
"Entities": {},
"Incident": "No",
"Incident description": "No incident can be inferred from the logs because they contain no substantial information.",
"MITRE ATT&CK Tactics": [],
"MITRE ATT&CK Techniques": []
}
label:
I note that in the logs provided, there is no information or recorded events indicating any abnormal activity, alerts, or warnings that might suggest a cyberattack or incident. Since the logs are completely blank, no suspicious connections, errors, or intrusion detection system (IDS) alerts such as those from Snort are present. I also observe from the system description that the IDS is deployed in a distributed manner covering all nodes, with centralized logging at 172.16.100.5. This comprehensive coverage makes it unlikely that any incidents would go undetected or unlogged if they occurred in the network. Additionally, the network is configured in a secured decentralized mesh topology with clear firewall rules including blocking known malicious IPs and rate-limiting new connections, which further reduces the attack surface and likelihood of successful intrusion. The system’s default policy allows peer-to-peer protocols, which explains normal traffic patterns without triggering alerts. Therefore, considering the absence of any logged suspicious activity, the robust IDS deployment, security firewall policies, and the controlled peer-to-peer environment, I conclude that the current blank logs and system state do not indicate a cyberattack incident but reflect normal operation.
{
"Entities": {},
"Incident": "No",
"Incident description": "No incident can be inferred from the logs because they contain no substantial information.",
"MITRE ATT&CK Tactics": [],
"MITRE ATT&CK Techniques": []
}<|end▁of▁sentence|>
...
```
## 响应生成
命令:
```
python examples/response_generation.py
```
预期输出(示例):
```
Loading weights: 100% 579/579 [00:09<00:00, 58.45it/s]
adapter_model.safetensors: 100% 201M/201M [00:14<00:00, 14.2MB/s]
tokenizer_config.json: 100% 3.07k/3.07k [00:00<00:00, 10.3MB/s]
tokenizer.json: 100% 7.03M/7.03M [00:00<00:00, 136MB/s]
README.md: 100% 33.0/33.0 [00:00<00:00, 199kB/s]
examples_16_june.json: 100% 536M/536M [00:08<00:00, 60.4MB/s]
Generating train split: 1 examples [00:09, 9.15s/ examples]
[transformers] Setting `pad_token_id` to `eos_token_id`:151643 for open-end generation.
I understand that simply containing and preserving evidence is not enough; the adversary must be fully removed. Since malicious payloads and backdoors could persist, I choose to perform malware eradication by reimaging affected hosts, applying patches, and removing unauthorized persistence mechanisms.
{
"Action": "Reimage or malware-scan and clean affected hosts, apply latest patches, and remove any unauthorized persistence mechanisms.",
"Explanation": "Reimaging and malware removal eradicate malware and close exploited vulnerabilities, ensuring the environment is clean."
}
```
## 作者与维护者
Yiran Gao gaoyiran525@gmail.com
Kim Hammar
Tao Li li.tao@cityu.edu.hk
## 版权与许可
[许可协议](LICENSE.md)
知识共享
版权所有 (c) 2026 Yiran Gao, Kim Hammar, Tao Li。
## 环境要求
- Python 3.8+
- `torch`
- `transformers`
- `peft`
- `bitsandbytes`
- `accelerate`
## 安装说明
克隆本代码库并以可编辑模式安装:
```
git clone https://github.com/TaoLi-NYU/llmagent4incidense-response-aaai26summer.git
cd llmagent4incidense-response-aaai26summer
pip install -e .
```
要安装或升级所需的依赖项:
```
pip install -e . --upgrade
```
## 开发
安装开发依赖项:
```
pip install -r requirements_dev.txt
```
运行代码检查和测试:
```
flake8 .
mypy .
pytest
```
## 产物
- 我们实验中使用的 incident-response fine-tuning 数据集可在
[Hugging Face](https://huggingface.co/datasets/kimhammar/CSLE-IncidentResponse-V1/tree/main) 上获取。
- 我们 fine-tune 后的模型的 LoRA adapter 权重可在
[Hugging Face](https://huggingface.co/GYR1-determine/llmagent4incident-response) 上获取。
## 在我们的动作生成数据集上 Fine-tuning DeepSeek-R1-Distill-Qwen-14B
命令:
```
python examples/fine_tune_action_generation.py
```
预期输出:
```
Fetching 4 files: 100% 4/4 [01:16<00:00, 19.04s/it]
Loading checkpoint shards: 100% 4/4 [00:33<00:00, 8.25s/it]
generation_config.json: 100% 181/181 [00:00<00:00, 2.02MB/s]
README.md: 100% 33.0/33.0 [00:00<00:00, 363kB/s]
action_examples.json: 100% 694M/694M [00:05<00:00, 136MB/s]
Generating train split: 1 examples [00:09, 9.84s/example]
Trainable parameters: 50331648
...
Step: 299, Epoch: 0.1086, Progress: 10.86%, Avg_loss=0.9460, LR=0.00084720, Grad_norm=0.3544, minutes: 315.9855
prediction:
I note that the attacker is actively communicating with our internal and external resources, so I choose to immediately isolate the affected hosts and block all traffic to and from the attacker IPs to stop further spread and data exfiltration.
{
"Action": "Isolate WikiServer, GitServer, and DevWorkstation; block all traffic to and from 185.140.53.11, 185.140.53.12, and 185.140.53.13 at firewalls and proxies.",
"Explanation": "Immediate isolation and blocking halt attacker communication and lateral movement."
}
label:
I note that the attacker IPs are actively communicating with internal systems and facilitating lateral movement, so to immediately stop further spread and communication, I choose to block their IPs at the perimeter and isolate the most affected hosts to contain the attack.
{
"Action": "Block all traffic to attacker IPs 185.140.53.11, 185.140.53.12, and 185.140.53.13 at perimeter firewalls and immediately isolate WikiServer (203.0.113.120) and DevWorkstation (10.66.22.41) from the network.",
"Explanation": "Cutting external and internal communication halts spread and C2, achieving immediate containment."
}<|end▁of▁sentence|>
```
## 在我们的状态预测数据集上 Fine-tuning DeepSeek-R1-Distill-Qwen-14B
为了对模型进行状态预测的 fine-tuning,请使用 `examples/fine_tune_action_generation.py` 并将其 `load_dataset` 调用替换为:
```
load_dataset("kimhammar/CSLE-IncidentResponse-V1", data_files="states_examples.json")
```
预期输出:
```
Fetching 4 files: 100% 4/4 [01:15<00:00, 18.91s/it]
Loading checkpoint shards: 100% 4/4 [00:34<00:00, 8.63s/it]
generation_config.json: 100% 181/181 [00:00<00:00, 1.36MB/s]
README.md: 100% 33.0/33.0 [00:00<00:00, 242kB/s]
states_examples.json: 100% 1.30G/1.30G [00:04<00:00, 280MB/s]
Generating train split: 1 examples [00:15, 15.77s/ examples]
Trainable parameters: 50331648
Step: 1, Epoch: 0.0006, Progress: 0.06%, Avg_loss=1.7383, LR=0.00095000, Grad_norm=1.3308, minutes: 1.2491
...
Step: 249, Epoch: 0.1594, Progress: 15.93%, Avg_loss=0.4396, LR=0.00079926, Grad_norm=0.1929, minutes: 98.7646
prediction:
I see that reviewing logs and performing forensic triage provides sufficient knowledge to understand the attack timeline and scope, so I update knowledge sufficiency to true.
{
"are_forensics_preserved": true,
"is_attack_contained": true,
"is_eradicated": false,
"is_hardened": false,
"is_knowledge_sufficient": true,
"is_recovered": false
}
label:
By reviewing and analyzing the collected logs and evidence, I gain detailed understanding of the attack timeline and scope. Therefore, knowledge is now sufficient, with forensic evidence preserved and containment maintained.
{
"are_forensics_preserved": true,
"is_attack_contained": true,
"is_eradicated": false,
"is_hardened": false,
"is_knowledge_sufficient": true,
"is_recovered": false
}<|end▁of▁sentence|>
...
```
## 在我们的 incident 数据集上 Fine-tuning DeepSeek-R1-Distill-Qwen-14B
为了对模型进行 incident 识别的 fine-tuning,请使用 `examples/fine_tune_action_generation.py` 并将其 `load_dataset` 调用替换为:
```
load_dataset("kimhammar/CSLE-IncidentResponse-V1", data_files="incident_examples.json")
```
预期输出:
```
Fetching 4 files: 100% 4/4 [01:13<00:00, 18.34s/it]
Loading checkpoint shards: 100% 4/4 [00:33<00:00, 8.30s/it]
generation_config.json: 100% 181/181 [00:00<00:00, 1.41MB/s]
README.md: 100% 33.0/33.0 [00:00<00:00, 250kB/s]
incident_examples.json: 100% 190M/190M [00:01<00:00, 135MB/s]
Generating train split: 1 examples [00:02, 2.51s/example]
Trainable parameters: 50331648
Step: 1, Epoch: 0.0016, Progress: 0.16%, Avg_loss=1.1644, LR=0.00095000, Grad_norm=0.4378, minutes: 1.0350
...
Step: 199, Epoch: 0.3184, Progress: 31.84%, Avg_loss=0.6381, LR=0.00064904, Grad_norm=0.1456, minutes: 158.3210
prediction:
I note that in the logs there is no recorded activity or events; the logs are entirely blank, which means there is no evidence of suspicious or malicious behavior to analyze. Given that the system description outlines a peer-to-peer network with a decentralized mesh topology and multiple nodes each performing distinct roles such as bootstrap_node, relay_node, edge_node, validator_node, storage_node, and dht_node, I would expect to see logs indicating routine network traffic, peer discovery, data exchange, or consensus operations if there were any anomalies. The absence of any log entries suggests that the network is operating without issues or alerts. Additionally, the security monitoring system, which is a distributed Snort IDS covering all nodes with logs sent to 172.16.100.5, would normally capture and record any suspicious activities, such as intrusion attempts, known malicious IP connections, or protocol violations. Since no such entries appear in the logs, I infer that no security events or intrusions have been detected. The firewall rules include default allow_p2p_protocols and rate_limit_new_connections, which align with normal p2p network behavior, and the external_restrictions block known malicious IPs and limit new connections, further reducing the chance of successful attacks. Therefore, the combination of an empty log, a secure network design, and active security monitoring strongly supports the conclusion that the system is operating normally and that there is no incident or cyberattack occurring.
{
"Entities": {},
"Incident": "No",
"Incident description": "No incident can be inferred from the logs because they contain no substantial information.",
"MITRE ATT&CK Tactics": [],
"MITRE ATT&CK Techniques": []
}
label:
I note that in the logs provided, there is no information or recorded events indicating any abnormal activity, alerts, or warnings that might suggest a cyberattack or incident. Since the logs are completely blank, no suspicious connections, errors, or intrusion detection system (IDS) alerts such as those from Snort are present. I also observe from the system description that the IDS is deployed in a distributed manner covering all nodes, with centralized logging at 172.16.100.5. This comprehensive coverage makes it unlikely that any incidents would go undetected or unlogged if they occurred in the network. Additionally, the network is configured in a secured decentralized mesh topology with clear firewall rules including blocking known malicious IPs and rate-limiting new connections, which further reduces the attack surface and likelihood of successful intrusion. The system’s default policy allows peer-to-peer protocols, which explains normal traffic patterns without triggering alerts. Therefore, considering the absence of any logged suspicious activity, the robust IDS deployment, security firewall policies, and the controlled peer-to-peer environment, I conclude that the current blank logs and system state do not indicate a cyberattack incident but reflect normal operation.
{
"Entities": {},
"Incident": "No",
"Incident description": "No incident can be inferred from the logs because they contain no substantial information.",
"MITRE ATT&CK Tactics": [],
"MITRE ATT&CK Techniques": []
}<|end▁of▁sentence|>
...
```
## 响应生成
命令:
```
python examples/response_generation.py
```
预期输出(示例):
```
Loading weights: 100% 579/579 [00:09<00:00, 58.45it/s]
adapter_model.safetensors: 100% 201M/201M [00:14<00:00, 14.2MB/s]
tokenizer_config.json: 100% 3.07k/3.07k [00:00<00:00, 10.3MB/s]
tokenizer.json: 100% 7.03M/7.03M [00:00<00:00, 136MB/s]
README.md: 100% 33.0/33.0 [00:00<00:00, 199kB/s]
examples_16_june.json: 100% 536M/536M [00:08<00:00, 60.4MB/s]
Generating train split: 1 examples [00:09, 9.15s/ examples]
[transformers] Setting `pad_token_id` to `eos_token_id`:151643 for open-end generation.
I understand that simply containing and preserving evidence is not enough; the adversary must be fully removed. Since malicious payloads and backdoors could persist, I choose to perform malware eradication by reimaging affected hosts, applying patches, and removing unauthorized persistence mechanisms.
{
"Action": "Reimage or malware-scan and clean affected hosts, apply latest patches, and remove any unauthorized persistence mechanisms.",
"Explanation": "Reimaging and malware removal eradicate malware and close exploited vulnerabilities, ensuring the environment is clean."
}
```
## 作者与维护者
Yiran Gao gaoyiran525@gmail.com
Kim Hammar 标签:DLL 劫持, 人工智能, 凭据扫描, 大语言模型, 库, 应急响应, 微调, 用户模式Hook绕过, 系统调用监控, 网络安全, 逆向工具, 隐私保护