jesse12-21/aws-cloud-security-lab
GitHub: jesse12-21/aws-cloud-security-lab
在 AWS 中构建完整的云原生威胁检测实验室,涵盖日志基础设施、自定义检测规则、攻击模拟与事件响应集成,全部通过 Terraform 可复现部署。
Stars: 0 | Forks: 0
# ☁️ AWS 云安全检测实验室
### AWS 中的云原生威胁检测、自定义规则工程与事件响应
[](https://aws.amazon.com/)
[](https://aws.amazon.com/guardduty/)
[](https://www.terraform.io/)
[](https://www.python.org/)
[](LICENSE)
*这是一个实操性的云安全项目,展示了 AWS 中完整的检测生命周期——从账户加固和全面日志记录,到使用 GuardDuty 进行原生威胁检测、使用 EventBridge 进行自定义检测工程、真实的攻击模拟,以及与基于 Python 的 SOC 自动化流水线的集成。*
[账户加固](#part-1---account-hardening--identity-security) · [日志基础设施](#part-2---logging-infrastructure) · [原生威胁检测](#part-3---native-threat-detection) · [自定义检测规则](#part-4---custom-detection-rules-with-eventbridge) · [攻击模拟](#part-5---attack-simulation--detection-validation) · [集成](#part-6---integration--incident-response)
## 📋 项目概述
现代攻击者不是强行闯入——他们是登录进来的。**身份即新的边界**,云环境需要一种与传统本地网络完全不同的检测思维。传统的 IDS 监控的是数据包,而云检测监控的是 API 调用、IAM 事件和配置更改。
本项目在 AWS 内部构建了一个完整的云安全检测实验室,涵盖了检测工程工作流的各个阶段:加固账户、建立全面的日志记录、启用 AWS 原生威胁检测、为 AWS 原生无法捕获的攻击模式编写自定义检测规则、模拟真实的入侵场景,以及将云遥测数据集成到我之前作品集项目中的 [Python Threat Intel Enricher](https://github.com/jesse12-21/threat-intel-enricher) 中。
### 本项目涵盖的内容
| 章节 | 展示的技能 | AWS 服务 |
|---|---|---|
| **账户加固** | IAM 设计、最小权限原则、身份保护 | IAM、Access Analyzer、Config |
| **日志基础设施** | 审计日志架构、基于 SQL 的取证 | CloudTrail、VPC Flow Logs、Athena、S3 |
| **原生威胁检测** | 使用 AWS 原生机器学习检测服务 | GuardDuty、Security Hub |
| **自定义检测规则** | 检测工程、模式匹配 | EventBridge、SNS、Lambda |
| **攻击模拟** | 红队演练、检测验证 | AWS CLI、Systems Manager |
| **集成与 IaC** | SOC 自动化、基础设施即代码 | Terraform、Python |
### 示例运行结果
在 `us-east-1` 区域对 AWS 账户 `534546103786` 端到端运行整个实验室:
| 指标 | 值 |
|---|---|
| AWS 账户 ID | `534546103786`(单账户范围) |
| IAM 加固 | `security-analyst` 用户拥有 3 个分层策略(`SecurityAudit` + `IAMUserChangePassword` + 自定义 `EnforceMFA` 内联策略),控制台访问**已禁用** |
| Access Analyzer 发现 | **1 个活跃发现** — 启用分析器后几分钟内即捕获到公开的 S3 存储桶 |
| CloudTrail | `security-audit-trail`,**多区域**,**已启用日志文件验证**,通过默认的 SSE-S3 传输至 S3(SSE-KMS 被有意推迟 — 参见 Security Hub `CloudTrail.2`) |
| Athena 查询性能 | 7 天活动查询:**2.038 秒,扫描 6.59 MB**(约 $0.00003);MITRE 杀伤链查询:**1.846 秒,8.51 MB** |
| GuardDuty 发现 | 共 **385 个**(11 个严重 / 155 个高危 / 152 个中危 / 67 个低危),涉及 **17 个资源**,外加 **11 个攻击序列** |
| Security Hub CIS 评分 | 基线为 **17%**(42 项控制中通过了 7 项;失败 27 项:1 项严重,1 项高危,7 项中危,18 项低危) |
| 自定义 EventBridge 规则 | 通过 Terraform 部署了 **6 条规则**,在默认事件总线上全部为 `Enabled` 状态 |
| 攻击模拟 | `developer` IAM 用户从 `146.70.58.131` 被攻破;通过一次耗时 1.8 秒的 Athena 查询,从 CloudTrail 中重建了完整的 **11 事件杀伤链** |
| 云 → Python 集成 | Enricher 自动检测 CloudTrail 格式;`185.220.101.45` 评分为 **严重 / 100**,并具有双源印证 |
## 🏗️ 架构
本实验室实现了一个与现代云安全团队运作方式相呼应的检测流水线——多个遥测源同时馈送到原生和自定义检测引擎,并配备自动警报和 SOC 工具集成。
### 检测流程
```
+---------------------------------------------------------------------+
| AWS Cloud Security Detection Lab |
| |
| +----------------------+ +---------------------------+ |
| | Telemetry Sources | | Detection Engines | |
| | | | | |
| | - CloudTrail (API) | -----> | +---------------------+ | |
| | - VPC Flow Logs | -----> | | GuardDuty | | |
| | - DNS Logs | -----> | | (ML-based, AWS) | | |
| | - S3 Access Logs | -----> | +---------------------+ | |
| | - IAM Events | -----> | | |
| +----------------------+ | +---------------------+ | |
| | | Security Hub | | |
| | | (CIS Benchmark) | | |
| | +---------------------+ | |
| | | |
| | +---------------------+ | |
| | | EventBridge | | |
| | | (Custom Rules) | | |
| | +---------------------+ | |
| +-------------+-------------+ |
| | |
| v |
| +---------------------------+ |
| | Alert Destinations | |
| | | |
| | - SNS (email) | |
| | - Threat Intel Enricher | |
| | - Splunk (HEC) | |
| +---------------------------+ |
+---------------------------------------------------------------------+
```
### 实验室组件
| 组件 | 用途 | 成本 |
|---|---|---|
| **CloudTrail**(多区域) | 所有 AWS API 活动日志记录 | 首个跟踪免费 |
| **VPC Flow Logs** | ENI 流量的网络元数据 | 约 $0.50/GB 存储 |
| **GuardDuty** | 基于 ML 的 CloudTrail/DNS/VPC 威胁检测 | 免费 30 天,约 $4/月 |
| **Security Hub** | CIS AWS Foundations 合规性评分 | 约 $0.0010/次检查 |
| **EventBridge** | 自定义检测规则引擎 | 免费额度已足够 |
| **Athena** | 对存储在 S3 上的日志执行 SQL 查询 | $5/TB 扫描量(仅需几分钱) |
| **S3** | 带有版本控制和加密的日志存储 | 几分钱 |
| **Terraform** | 可复现的基础设施即代码 | 免费 |
## 第一部分 - 账户加固与身份安全
在构建检测机制之前,需要先建立一个经过妥善安全加固的基线。每一次云数据泄露都始于身份受损——而身份完全是由配置驱动的。
### Root 账户保护
AWS root 账户拥有无限权限且无法被限制。最佳实践是:启用 MFA,锁好凭证,并且永远不再使用它。
```
# 启用 MFA 后,通过 AWS CLI 进行验证
aws iam get-account-summary \
--query 'SummaryMap.AccountMFAEnabled'
```
### 以最小权限原则创建 IAM 用户
我创建了一个专用的 IAM 用户用于日常操作,仅授予所需的权限:
```
# 在 /security/ 路径下创建用户以便于组织管理
aws iam create-user \
--user-name security-analyst \
--path /security/
# 附加 AWS 托管的只读审计策略
aws iam attach-user-policy \
--user-name security-analyst \
--policy-arn arn:aws:iam::aws:policy/SecurityAudit
# 允许用户轮换自己的密码(不授予其他 IAM 权限)
aws iam attach-user-policy \
--user-name security-analyst \
--policy-arn arn:aws:iam::aws:policy/IAMUserChangePassword
# 通过自定义内联策略强制执行 MFA(当 MFA 不存在时拒绝所有操作)
aws iam put-user-policy \
--user-name security-analyst \
--policy-name EnforceMFA \
--policy-document file://policies/enforce-mfa.json
```
*这是一个实操性的云安全项目,展示了 AWS 中完整的检测生命周期——从账户加固和全面日志记录,到使用 GuardDuty 进行原生威胁检测、使用 EventBridge 进行自定义检测工程、真实的攻击模拟,以及与基于 Python 的 SOC 自动化流水线的集成。*
[账户加固](#part-1---account-hardening--identity-security) · [日志基础设施](#part-2---logging-infrastructure) · [原生威胁检测](#part-3---native-threat-detection) · [自定义检测规则](#part-4---custom-detection-rules-with-eventbridge) · [攻击模拟](#part-5---attack-simulation--detection-validation) · [集成](#part-6---integration--incident-response)
The dedicated
security-analyst IAM user (arn:aws:iam::534546103786:user/security/security-analyst) created on April 24, 2026 with console access disabled — three layered policies attached: SecurityAudit (AWS managed job-function, read-only audit access), IAMUserChangePassword (AWS managed, password self-rotation), and a custom inline EnforceMFA policy. No access keys, no console password — programmatic-only via assumed roles, following AWS least-privilege principles
### 启用 Access Analyzer IAM Access Analyzer 会自动识别在您的账户外部共享的资源——这对于捕获意外公开的 S3 存储桶、配置错误的 KMS 密钥以及有缺陷的 IAM 角色信任策略至关重要。 ``` aws accessanalyzer create-analyzer \ --analyzer-name account-analyzer \ --type ACCOUNT ```
Access Analyzer (
account-analyzer, scoped to the current account zone of trust) caught a real finding within minutes: an S3 bucket (security-lab-tes...) shared with All Principals via bucket policy with Read access level — Finding ID ee0a1da9-3b07-4058-84fa-c5.... This is exactly the kind of accidental public exposure that leads to data breach headlines, surfaced before any data is actually leaked
### 账单警报(财务安全网) 遭到入侵的云账户可能在几小时内就会产生数千美元的费用。账单警报能立即捕捉到这种情况: ``` aws cloudwatch put-metric-alarm \ --alarm-name security-lab-billing-alarm \ --alarm-description "Alert if estimated charges exceed \$5" \ --namespace AWS/Billing \ --metric-name EstimatedCharges \ --dimensions Name=Currency,Value=USD \ --statistic Maximum \ --period 21600 \ --threshold 5 \ --comparison-operator GreaterThanThreshold \ --evaluation-periods 1 \ --alarm-actions $SNS_TOPIC_ARN ``` ## 第二部分 - 日志基础设施 没有全面的日志记录,云安全检测就无从谈起。CloudTrail 捕获每一次 API 调用,VPC Flow Logs 记录网络元数据,而 Athena 使得所有这些都能通过 SQL 进行查询。 ### 启用多区域 CloudTrail 一个单一的多区域跟踪可以捕获来自每个 AWS 区域的 API 活动——这一点非常重要,因为攻击者通常会转移到监控较弱的区域: ``` # 创建带有版本控制 + 加密的 S3 bucket 用于日志 aws s3api create-bucket --bucket my-cloudtrail-logs-$(date +%s) aws s3api put-bucket-versioning --bucket
The
security-audit-trail trail actively logging to cloudtrail-logs-534546103786-d32800b7 with multi-region trail enabled and log file validation enabled — providing cryptographic SHA-256 integrity hashes that prove logs haven't been tampered with after delivery, essential for forensic credibility. Last log delivered at 18:56:27 UTC-06:00 with the most recent file validation completing at 18:51:12
### VPC Flow Logs Flow Logs 捕获 VPC 内每个网络流的 IP 级元数据(源、目的、端口、字节、操作)——相当于云端的 NetFlow: ``` aws ec2 create-flow-logs \ --resource-type VPC \ --resource-ids $VPC_ID \ --traffic-type ALL \ --log-destination-type s3 \ --log-destination arn:aws:s3:::$LOG_BUCKET/vpc-flow-logs/ ``` ### 使用 Athena 查询日志 原始 CloudTrail 日志是存储在 S3 中的 JSON 格式。Athena 允许您使用标准 SQL 对其进行查询——无需数据流水线: ``` -- Create external table over CloudTrail logs in the security_analysis database CREATE EXTERNAL TABLE security_analysis.cloudtrail_logs ( eventTime STRING, eventName STRING, eventSource STRING, awsRegion STRING, sourceIPAddress STRING, userIdentity STRUCT< type: STRING, arn: STRING, userName: STRING >, errorCode STRING, errorMessage STRING, requestParameters STRING ) ROW FORMAT SERDE 'com.amazon.emr.hive.serde.CloudTrailSerde' STORED AS INPUTFORMAT 'com.amazon.emr.cloudtrail.CloudTrailInputFormat' LOCATION 's3://cloudtrail-logs-534546103786-d32800b7/AWSLogs/534546103786/CloudTrail/'; ``` **有用的调查查询:** ``` -- Recent activity across the account (the query shown in the screenshot below) SELECT eventtime, eventname, useridentity.username AS user, sourceipaddress AS source_ip, awsregion AS region FROM security_analysis.cloudtrail_logs WHERE from_iso8601_timestamp(eventtime) > current_timestamp - interval '7' day ORDER BY eventtime DESC LIMIT 50; -- Who logged into the console in the last 24 hours? SELECT eventtime, useridentity.username, sourceipaddress, awsregion FROM security_analysis.cloudtrail_logs WHERE eventname = 'ConsoleLogin' AND from_iso8601_timestamp(eventtime) > current_timestamp - interval '1' day ORDER BY eventtime DESC; -- Failed API calls by user (credential stuffing indicator) SELECT useridentity.arn, errorcode, COUNT(*) as failures FROM security_analysis.cloudtrail_logs WHERE errorcode IS NOT NULL AND from_iso8601_timestamp(eventtime) > current_timestamp - interval '7' day GROUP BY useridentity.arn, errorcode HAVING COUNT(*) > 10 ORDER BY failures DESC; -- API calls from unusual geographies SELECT sourceipaddress, COUNT(*) as calls FROM security_analysis.cloudtrail_logs WHERE from_iso8601_timestamp(eventtime) > current_timestamp - interval '1' day GROUP BY sourceipaddress ORDER BY calls DESC LIMIT 20; ```
Athena running the 7-day activity query against
security_analysis.cloudtrail_logs — completed in 2.038 seconds scanning only 6.59 MB across 50 returned rows (≈$0.00003 at $5/TB pricing). The top results show GetBucketAcl calls originating from cloudtrail.amazonaws.com in us-east-1 — the trail service-principal validating permissions on its own log bucket, exactly what you'd expect to see in a healthy CloudTrail deployment. This is the audit visibility that traditional on-prem environments require expensive SIEM licenses to achieve
## 第三部分 - 原生威胁检测 AWS GuardDuty 利用机器学习和威胁情报分析 CloudTrail、DNS 和 VPC Flow Logs。Security Hub 汇总各种发现,并根据行业基准对合规性进行评分。 ### 启用 GuardDuty ``` aws guardduty create-detector \ --enable \ --finding-publishing-frequency FIFTEEN_MINUTES ``` GuardDuty 会立即开始分析历史日志并监控实时活动,以防范: - **侦察:** 端口扫描、异常 API 模式 - **实例入侵:** 加密货币挖矿、恶意软件 C2、后门活动 - **账户入侵:** 异常 API 调用、异常地理位置、权限提升 - **S3 发现:** 公共访问权限变更、可疑的发现活动 ### 启用带有 CIS Benchmark 的 Security Hub ``` aws securityhub enable-security-hub aws securityhub batch-enable-standards \ --standards-subscription-requests StandardsArn=arn:aws:securityhub:::ruleset/cis-aws-foundations-benchmark/v/1.2.0 ```
GuardDuty summary after enabling sample findings — 385 total findings across 17 resources, broken down by severity (11 critical, 155 high, 152 medium, 67 low) and including 11 attack sequences (the new feature that chains related findings into MITRE-style narratives). Top critical detections include S3 data compromise, Kubernetes cluster compromise, and credential compromise sequences against
IAMUser/john_doe — exactly what GuardDuty is designed to surface from CloudTrail, DNS, and VPC Flow Log telemetry
### 生成示例发现 要在模拟攻击之前查看真实发现的样子,请生成示例: ``` DETECTOR_ID=$(aws guardduty list-detectors --query 'DetectorIds[0]' --output text) aws guardduty create-sample-findings --detector-id $DETECTOR_ID ```
Security Hub running the CIS AWS Foundations Benchmark v1.2.0 against the lab account — initial security score 17% (7 of 42 controls passed, 27 failed, 8 unknown). Failed checks broken down: 1 critical (
Config.1 — AWS Config deliberately left disabled to keep this lab inside the AWS Free Tier; Config bills per configuration item recorded and is the single most expensive service in this stack at scale), 1 high (EC2.2 — VPC default security groups allow traffic), 7 medium (including CloudTrail.2 SSE-KMS encryption and CloudTrail.5 CloudWatch Logs integration — both intentionally deferred), and 18 low. The low score is the point: a fresh account starts non-compliant by default, and CIS gives a prioritized punch-list to harden against — which is exactly the conversation you'd have with a cloud architect on day one of an engagement
## 第四部分 - 使用 EventBridge 的自定义检测规则 GuardDuty 能捕获已知的威胁模式,但针对特定组织的攻击则需要自定义检测。EventBridge 对 CloudTrail 事件的模式匹配是 AWS 的原生检测引擎。 ### 规则 1:Root 账户使用 初始设置完成后,绝不应再使用 root 账户。任何使用行为都应被视为可疑。 ``` { "source": ["aws.signin"], "detail-type": ["AWS Console Sign In via CloudTrail"], "detail": { "userIdentity": { "type": ["Root"] }, "eventName": ["ConsoleLogin"] } } ``` ### 规则 2:安全组在敏感端口上开放 0.0.0.0/0 检测安全组是否在 SSH、RDP 或数据库端口上向互联网开放: ``` { "source": ["aws.ec2"], "detail-type": ["AWS API Call via CloudTrail"], "detail": { "eventName": ["AuthorizeSecurityGroupIngress"], "requestParameters": { "ipPermissions": { "items": { "ipRanges": { "items": { "cidrIp": ["0.0.0.0/0"] } }, "fromPort": [22, 3389, 3306, 5432, 1433] } } } } } ``` ### 规则 3:CloudTrail 被禁用(攻击者清理痕迹) 攻击者的一种经典手法是禁用日志记录以掩盖其踪迹: ``` { "source": ["aws.cloudtrail"], "detail-type": ["AWS API Call via CloudTrail"], "detail": { "eventName": ["StopLogging", "DeleteTrail", "UpdateTrail"] } } ``` ### 规则 4:S3 存储桶被公开 意外(或恶意)公开的存储桶是导致数据泄露的首要原因: ``` { "source": ["aws.s3"], "detail-type": ["AWS API Call via CloudTrail"], "detail": { "eventName": [ "PutBucketAcl", "PutBucketPolicy", "DeleteBucketPolicy", "PutBucketPublicAccessBlock" ] } } ``` ### 规则 5:异常的 API 调用频率(凭证失陷) 失陷的凭证通常被用于快速侦察。检测每个用户发出的过量 API 调用: ``` { "source": ["aws.cloudtrail"], "detail": { "errorCode": ["*"], "userIdentity": { "type": ["IAMUser"] } } } ``` ### 规则 6:IAM 权限提升尝试 将最危险的 IAM API 调用组合到单一规则中——这些是攻击者在凭证失陷后,为了建立持久化或扩大访问权限而采取的行动: ``` { "source": ["aws.iam"], "detail-type": ["AWS API Call via CloudTrail"], "detail": { "eventSource": ["iam.amazonaws.com"], "eventName": [ "CreateUser", "CreateAccessKey", "AttachUserPolicy", "AttachRolePolicy", "PutUserPolicy", "PutRolePolicy", "CreateLoginProfile" ] } } ``` 这一条单一规则就涵盖了 AWS 中绝大多数的 MITRE ATT&CK **T1098 — 账户操纵** 和 **T1136 — 创建账户** 子技术。 ### 使用 Terraform 部署规则 所有规则均以基础设施即代码的形式部署,以确保可复现性: ``` resource "aws_cloudwatch_event_rule" "root_account_usage" { name = "detect-root-account-usage" description = "Alert when root account is used" event_pattern = jsonencode({ source = ["aws.signin"] "detail-type" = ["AWS Console Sign In via CloudTrail"] detail = { userIdentity = { type = ["Root"] } eventName = ["ConsoleLogin"] } }) } resource "aws_cloudwatch_event_target" "root_account_sns" { rule = aws_cloudwatch_event_rule.root_account_usage.name target_id = "SendToSNS" arn = aws_sns_topic.security_alerts.arn } ```
Detail view of
detect-iam-privilege-escalation — one of six custom EventBridge rules deployed via Terraform — showing the rule Enabled on the default event bus with its full event pattern: source aws.iam, detail-type AWS API Call via CloudTrail, and the seven privilege-escalation event names that map to MITRE T1098 and T1136. Rule ARN arn:aws:events:us-east-1:534546103786:rule/detect-iam-privilege-escalation ready to forward matched events to SNS for analyst notification
## 第五部分 - 攻击模拟与检测验证 检测工程的价值,只有在攻击发生时检测机制确实被触发才能体现。本节将端到端地执行一个真实的攻击场景,并验证每一条自定义规则。 ### 场景:IAM 凭证失陷 → 数据窃取 模拟最常见的 AWS 泄露模式:攻击者获取了泄露的 IAM 凭证(例如,来自公开的 GitHub 提交),进行侦察,并试图窃取数据。 ### 攻击步骤 **1. 创建“受害者”IAM 用户:** ``` aws iam create-user --user-name developer aws iam attach-user-policy --user-name developer \ --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess aws iam create-access-key --user-name developer > leaked-creds.json ``` **2. 模拟攻击者行为(从不同的 IP/区域):** ``` # 使用“泄露”的凭证配置 AWS CLI export AWS_ACCESS_KEY_ID=
### 攻击后的 Athena 取证 模拟攻击结束后,通过一条 SQL 查询即可重建完整的攻击时间线,将每个事件映射到 MITRE ATT&CK 阶段——从而将原始 CloudTrail 噪音转化为杀伤链叙事: ``` SELECT eventtime, eventname, sourceipaddress, CASE WHEN eventname IN ('GetCallerIdentity', 'GetAccountSummary') THEN 'Initial Access (T1078)' WHEN eventname IN ('ListUsers', 'ListRoles', 'ListBuckets', 'DescribeInstances') THEN 'Discovery (T1087, T1083)' WHEN eventname IN ('CreateUser', 'AttachUserPolicy') THEN 'Privilege Escalation (T1098)' WHEN eventname = 'CreateAccessKey' THEN 'Persistence (T1098.001)' WHEN eventname IN ('StopLogging', 'DeleteTrail') THEN 'Defense Evasion (T1562.008)' ELSE 'Other' END AS mitre_phase, CASE WHEN errorcode IS NOT NULL THEN 'BLOCKED' ELSE 'SUCCESS' END AS outcome FROM security_analysis.cloudtrail_logs WHERE useridentity.arn LIKE '%developer%' AND from_iso8601_timestamp(eventtime) > current_timestamp - interval '1' hour ORDER BY eventtime ASC; ```
The MITRE ATT&CK kill-chain query against the simulated
developer compromise — the full 11-event attack timeline reconstructed in 1.846 seconds, scanning 8.51 MB. The result reads exactly like an incident report: at 2026-05-04T01:06:52Z the attacker runs GetCallerIdentity → GetAccountSummary (Initial Access T1078) from 146.70.58.131, then within a minute pivots to ListUsers → ListRoles → ListBuckets (Discovery T1087, T1083) — all 11 events SUCCESS because the leaked credentials were valid. This is the "story" view that turns raw logs into actionable threat intelligence
## 第六部分 - 集成与事件响应 最后一节将完成闭环——将云警报集成到我之前作品集项目的 Python [Threat Intel Enricher](https://github.com/jesse12-21/threat-intel-enricher) 中,并编写事件响应操作手册。 ### 扩展 Threat Intel Enricher Enricher 的抽象 `BaseIngester` 类使得添加 CloudTrail 提取器变得非常简单——只需约 50 行新代码即可利用现有的流水线: ``` # 新 ingester:src/enricher/ingesters/cloudtrail.py from pathlib import Path from typing import Iterator from enricher.ingesters.base import BaseIngester from enricher.models import Alert, IOC, IOCType class CloudTrailIngester(BaseIngester): """Ingester for AWS CloudTrail log format. Parses the CloudTrail Records[] JSON array and extracts source IPs and user agents as IOCs for enrichment. """ name = "cloudtrail" def ingest(self, source: Path) -> Iterator[Alert]: with source.open() as f: data = json.load(f) for record in data.get("Records", []): yield self._parse_record(record) def extract_iocs(self, alert: Alert) -> list[IOC]: iocs = [] # External source IPs (skip AWS-internal addresses) if alert.src_ip and not alert.src_ip.endswith(".amazonaws.com"): iocs.append(IOC( value=alert.src_ip, type=IOCType.IP, first_seen=alert.timestamp, source_alert_id=alert.id, )) return iocs ``` 添加后,现有的流水线会自动检测 CloudTrail 格式,并像处理 Suricata 警报一样,通过 AbuseIPDB 和 OTX 对事件进行丰富化: ``` enricher pipeline --source examples/cloudtrail_sample.json --format both --output output/cloud_incident ```
The Threat Intel Enricher auto-detecting CloudTrail format and processing the simulated attack: 8 alerts ingested → 1 unique IOC → 2 enrichment results → 1 actionable finding in 11 seconds. The attacker IP
185.220.101.45 scored CRITICAL / 100 with corroboration from 2 sources (AbuseIPDB and OTX) — the same Tor exit node flagged in the Suricata-fed pipeline, now caught from cloud telemetry. 1 attack campaign identified, Markdown and HTML reports written to output/cloud_incident.{md,html}. Same toolkit, new data source — exactly the portfolio integration story the project promised
### 流式传输至 Splunk CloudTrail 日志也可以通过 HTTP Event Collector (HEC) 直接流式传输到我之前的 [SIEM Analysis 项目](https://github.com/jesse12-21/splunk-siem-analysis) 中的 Splunk 实例: ``` aws events put-targets --rule ship-to-splunk \ --targets "Id=splunk-hec,Arn=arn:aws:lambda:us-east-1:$ACCT:function:SplunkHEC" ``` 这就完成了端到端的闭环:云遥测 → AWS 检测 → SIEM 关联 → Python 丰富化 → 分析师报告。 ### 事件响应操作手册 每项检测机制都需要配备文档化的响应流程。`runbooks/` 文件夹中包含了适用于常见云事件的三个操作手册: | 操作手册 | 场景 | 响应时间 | |---|---|---| | `compromised-iam-credentials.md` | 在公共 GitHub 中检测到泄露的访问密钥 | 立即 | | `public-s3-bucket.md` | 存储桶策略允许公开读写 | 15 分钟 | | `suspicious-ec2-behavior.md` | 实例显示 C2 或加密货币挖矿指标 | 30 分钟 | 每本手册均记录了:初步分诊、遏制步骤、证据保全、根除、恢复以及经验教训模板——遵循 NIST SP 800-61 事件响应生命周期。 ### Terraform 基础设施即代码 整个实验室可以通过单次 `terraform apply` 进行部署,使其便于团队成员或演示环境复用: ``` cd terraform/ terraform init terraform plan terraform apply ``` `terraform/` 文件夹包含了模块化的定义,涵盖: - `cloudtrail.tf` — 带有 S3 和日志文件验证的多区域跟踪 - `guardduty.tf` — 具有发现频率配置的检测器 - `eventbridge.tf` — 全部 6 条自定义检测规则(root 使用、安全组滥用、CloudTrail 篡改、S3 公开暴露、凭证滥用、IAM 权限提升)+ SNS 目标 - `iam.tf` — 位于 `/security/` 路径下并带有强制 MFA 内联策略的 `security-analyst` 用户 - `athena.tf` — `security_analysis` 工作组和 `cloudtrail_logs` 外部表 ## 🔑 关键 AWS 服务参考 | 服务 | 命令示例 | |---|---| | **CloudTrail** | `aws cloudtrail create-trail --is-multi-region-trail` | | **GuardDuty** | `aws guardduty create-detector --enable` | | **Security Hub** | `aws securityhub enable-security-hub` | | **EventBridge** | `aws events put-rule --event-pattern file://pattern.json` | | **Athena** | `aws athena start-query-execution --query-string` | | **Access Analyzer** | `aws accessanalyzer create-analyzer --type ACCOUNT` | | **IAM** | `aws iam create-user --user-name
### 🔗 相关项目
[](https://github.com/jesse12-21/wireshark-threat-detection)
[](https://github.com/jesse12-21/nmap-network-recon)
[](https://github.com/jesse12-21/splunk-siem-analysis)
[](https://github.com/jesse12-21/suricata-ids-rules)
[](https://github.com/jesse12-21/threat-intel-enricher)
*作为网络安全作品集项目构建——欢迎反馈和建议。*
*作为网络安全作品集项目构建——欢迎反馈和建议。*
标签:AMSI绕过, Athena, AWS, Cloudflare, CloudTrail, CSPM, DPI, ECS, EventBridge, GuardDuty, IAM加固, JSONLines, MITRE ATT&CK, Python, Security Hub, Terraform, TinkerPop, 云安全态势管理, 前端应用, 威胁检测, 子域名变形, 安全实验室, 安全工程, 安全规则工程, 攻击模拟, 无后门, 自动化防御, 身份与访问管理, 逆向工具, 零信任, 驱动签名利用