analyzing-cloud-storage-access-patterns
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
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/PutObjectare data events, off by default. Confirm withaws cloudtrail get-event-selectors --trail-name Xshowing aDataResourcesentry forAWS::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 hitsGetObjectfrom their IP; access via VPC gateway endpoint shows an internalvpce-source; CloudFront/OAC fronting masks the real client IP. - Volume framed as "normal": slow-drip exfil under your
>100 GetObject/hrthreshold, orListBucketrecon 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
GetObjectfrom 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 byuserIdentity.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
- Install dependencies:
pip install boto3 requests - Query CloudTrail for S3 Data Events using AWS CLI or boto3.
- Build access baselines: hourly request volume, per-user object counts, source IP history.
- Detect anomalies:
- After-hours access (outside 8am-6pm local time)
- Bulk downloads: >100 GetObject calls from single principal in 1 hour
- New source IPs not seen in the prior 30 days
- ListBucket enumeration spikes (reconnaissance indicator)
- 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 查看 →
评论
登录即可评论;带「已验证安装」的,是发布者名下有本店的安装或持有记录。
…