‹ 首页

analyzing-cloud-storage-access-patterns

@xalgord · 收录于 昨天 · 上游提交 昨天

Detect abnormal access patterns in AWS S3, GCS, and Azure Blob Storage by analyzing CloudTrail Data Events, GCS audit logs, and Azure Storage Analytics. Identifies after-hours bulk downloads, access from new IP addresses, unusual API calls (GetObject spikes), and potential data exfiltration using statistical baselines and time-series anomaly detection.

适合你,如果负责云存储安全,需要自动发现可疑访问模式。

/ 通过 npx 安装 校验哈希
npx oh-my-skill add xalgord/xalgorix/analyzing-cloud-storage-access-patterns
/ 通过 bash 安装
curl -fsSL https://oh-my-skill.com/install.sh | bash -s -- xalgord/xalgorix/analyzing-cloud-storage-access-patterns
/ 已经装过?验证本机副本,不用重装
npx oh-my-skill verify xalgord/xalgorix/analyzing-cloud-storage-access-patterns
安装目标可用 --agent / --scope 或 --to 明确指定;省略时只会在唯一已存在的 agent 目录上自动选择,零命中或多命中会停止并提示。content_hash 缺失或不一致均拒装。
807GitHub stars
~746上下文体积 · 单文件
索引托管

怎么用

技能原文 SKILL.md作者撰写 · MIT · eeaf26b

Analyzing Cloud Storage Access Patterns

When to Use
  • When investigating security incidents that require analyzing cloud storage access patterns
  • When building detection rules or threat hunting queries for this domain
  • When SOC analysts need structured procedures for this analysis type
  • When validating security monitoring coverage for related attack techniques
Detection Gaps & Validation
  • The events may not exist at all: S3 GetObject/PutObject are data events, off by default. Confirm with aws cloudtrail get-event-selectors --trail-name X showing a DataResources entry for AWS::S3::Object. GCS object reads need Data Access audit logs (DATA_READ) explicitly enabled per-service; Azure needs Storage Analytics / diagnostic settings on the storage account.
  • Exfil paths that dodge per-IP baselines: presigned URLs log the signer's identity/IP, not the downloader; CopyObject / S3 replication to an attacker-owned bucket never hits GetObject from their IP; access via VPC gateway endpoint shows an internal vpce- source; CloudFront/OAC fronting masks the real client IP.
  • Volume framed as "normal": slow-drip exfil under your >100 GetObject/hr threshold, or ListBucket recon spread across days, evades count-based rules. Watch bytes-out and distinct-key fan-out, not just call counts.
  • Baseline poisoning: an attacker active during the 30-day learning window becomes part of "normal." Seed baselines from a known-clean period.
  • Validate the rule fires: replay a known-bad pattern (e.g., 150 GetObject from a new IP in <1h against a canary key) and confirm a finding is generated; tune FPs by excluding backup/replication service principals and known batch jobs by userIdentity.arn.
Prerequisites
  • Familiarity with cloud security concepts and tools
  • Access to a test or lab environment for safe execution
  • Python 3.8+ with required dependencies installed
  • Appropriate authorization for any testing activities
Instructions
  1. Install dependencies: pip install boto3 requests
  2. Query CloudTrail for S3 Data Events using AWS CLI or boto3.
  3. Build access baselines: hourly request volume, per-user object counts, source IP history.
  4. Detect anomalies:
  5. After-hours access (outside 8am-6pm local time)
  6. Bulk downloads: >100 GetObject calls from single principal in 1 hour
  7. New source IPs not seen in the prior 30 days
  8. ListBucket enumeration spikes (reconnaissance indicator)
  9. Generate prioritized findings report.
python scripts/agent.py --bucket my-sensitive-data --hours-back 24 --output s3_access_report.json
Examples
CloudTrail S3 Data Event
{"eventName": "GetObject", "requestParameters": {"bucketName": "sensitive-data", "key": "financials/q4.xlsx"},
 "sourceIPAddress": "203.0.113.50", "userIdentity": {"arn": "arn:aws:iam::123456789012:user/analyst"}}
按 MIT 许可原样转载,未经改动 · 在 GitHub 查看 →

评论

登录即可评论;带「已验证安装」的,是发布者名下有本店的安装或持有记录。