mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-12 07:40:49 -08:00
Merge pull request #220 from HackTricks-wiki/update_Skimming_Credentials_with_Azure_s_Front_Door_WAF_20251009_182735
Skimming Credentials with Azure's Front Door WAF
This commit is contained in:
File diff suppressed because one or more lines are too long
@@ -1,5 +1,7 @@
|
||||
# AWS - Lambda Async Self-Loop Persistence via Destinations + Recursion Allow
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Abuse Lambda asynchronous destinations together with the Recursion configuration to make a function continually re-invoke itself with no external scheduler (no EventBridge, cron, etc.). By default, Lambda terminates recursive loops, but setting the recursion config to Allow re-enables them. Destinations deliver on the service side for async invokes, so a single seed invoke creates a stealthy, code-free heartbeat/backdoor channel. Optionally throttle with reserved concurrency to keep noise low.
|
||||
|
||||
Notes
|
||||
@@ -99,3 +101,4 @@ aws iam delete-role-policy --role-name "$ROLE_NAME" --policy-name allow-invoke-s
|
||||
|
||||
## Impact
|
||||
- Single async invoke causes Lambda to continually re-invoke itself with no external scheduler, enabling stealthy persistence/heartbeat. Reserved concurrency can limit noise to a single warm execution.
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -50,7 +50,7 @@ def generate_password():
|
||||
return password
|
||||
```
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -248,3 +248,4 @@ aws secretsmanager get-resource-policy --region "$R2" --secret-id "$NAME"
|
||||
# Configure attacker credentials and read
|
||||
aws secretsmanager get-secret-value --region "$R2" --secret-id "$NAME" --query SecretString --output text
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -119,3 +119,4 @@ aws ec2 delete-instance-connect-endpoint \
|
||||
> Notes
|
||||
> - The injected SSH key is only valid for ~60 seconds; send the key right before opening the tunnel/SSH.
|
||||
> - `OS_USER` must match the AMI (e.g., `ubuntu` for Ubuntu, `ec2-user` for Amazon Linux 2).
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -55,3 +55,4 @@ curl --interface $HIJACK_IP -sS http://$PROTECTED_HOST -o /tmp/poc.out && head -
|
||||
## Impact
|
||||
- Bypass IP allowlists and impersonate trusted hosts within the VPC by moving secondary private IPs between ENIs in the same subnet/AZ.
|
||||
- Reach internal services that gate access by specific source IPs, enabling lateral movement and data access.
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -94,7 +94,7 @@ aws ecr batch-delete-image --repository-name your-ecr-repo-name --image-ids imag
|
||||
aws ecr-public batch-delete-image --repository-name your-ecr-repo-name --image-ids imageTag=latest imageTag=v1.0.0
|
||||
```
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -218,3 +218,4 @@ aws ecr put-registry-scanning-configuration --region $REGION --scan-type BASIC -
|
||||
aws ecr put-account-setting --region $REGION --name BASIC_SCAN_TYPE_VERSION --value AWS_NATIVE
|
||||
```
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -60,7 +60,7 @@ aws ecs submit-attachment-state-changes ...
|
||||
|
||||
The EC2 instance will probably also have the permission `ecr:GetAuthorizationToken` allowing it to **download images** (you could search for sensitive info in them).
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -139,3 +139,4 @@ aws ecs delete-service --cluster ht-ecs-ebs --service ht-ebs-svc --force
|
||||
aws ecs deregister-task-definition ht-ebs-read
|
||||
```
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,5 +1,7 @@
|
||||
# AWS Lambda – EFS Mount Injection via UpdateFunctionConfiguration (Data Theft)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Abuse `lambda:UpdateFunctionConfiguration` to attach an existing EFS Access Point to a Lambda, then deploy trivial code that lists/reads files from the mounted path to exfiltrate shared secrets/config that the function previously couldn’t access.
|
||||
|
||||
## Requirements
|
||||
@@ -75,3 +77,4 @@ An attacker with the listed permissions can mount arbitrary in-VPC EFS Access Po
|
||||
```
|
||||
aws lambda update-function-configuration --function-name $TARGET_FN --file-system-configs [] --region $REGION || true
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,5 +1,7 @@
|
||||
# AWS - Lambda Function URL Public Exposure (AuthType NONE + Public Invoke Policy)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Turn a private Lambda Function URL into a public unauthenticated endpoint by switching the Function URL AuthType to NONE and attaching a resource-based policy that grants lambda:InvokeFunctionUrl to everyone. This enables anonymous invocation of internal functions and can expose sensitive backend operations.
|
||||
|
||||
## Abusing it
|
||||
@@ -46,3 +48,4 @@ https://e3d4wrnzem45bhdq2mfm3qgde40rjjfc.lambda-url.us-east-1.on.aws/
|
||||
aws lambda remove-permission --function-name $TARGET_FN --statement-id ht-public-url || true
|
||||
aws lambda update-function-url-config --function-name $TARGET_FN --auth-type AWS_IAM || true
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,5 +1,7 @@
|
||||
# AWS Lambda – Runtime Pinning/Rollback Abuse via PutRuntimeManagementConfig
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Abuse `lambda:PutRuntimeManagementConfig` to pin a function to a specific runtime version (Manual) or freeze updates (FunctionUpdate). This preserves compatibility with malicious layers/wrappers and can keep the function on an outdated, vulnerable runtime to aid exploitation and long-term persistence.
|
||||
|
||||
Requirements: `lambda:InvokeFunction`, `logs:FilterLogEvents`, `lambda:PutRuntimeManagementConfig`, `lambda:GetRuntimeManagementConfig`.
|
||||
@@ -11,3 +13,4 @@ Example (us-east-1):
|
||||
|
||||
Optionally pin to a specific runtime version by extracting the Runtime Version ARN from INIT_START logs and using `--update-runtime-on Manual --runtime-version-arn <arn>`.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,5 +1,7 @@
|
||||
# AWS Lambda – VPC Egress Bypass by Detaching VpcConfig
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Force a Lambda function out of a restricted VPC by updating its configuration with an empty VpcConfig (SubnetIds=[], SecurityGroupIds=[]). The function will then run in the Lambda-managed networking plane, regaining outbound internet access and bypassing egress controls enforced by private VPC subnets without NAT.
|
||||
|
||||
## Abusing it
|
||||
@@ -61,3 +63,4 @@ Force a Lambda function out of a restricted VPC by updating its configuration wi
|
||||
### Cleanup
|
||||
- If you created any temporary code/handler changes, restore them.
|
||||
- Optionally restore the original VpcConfig saved in /tmp/orig-vpc.json as shown above.
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -88,7 +88,7 @@ aws secretsmanager update-secret-version-stage \
|
||||
--remove-from-version-id <previous-version-id>
|
||||
```
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -141,3 +141,4 @@ aws secretsmanager batch-get-secret-value --secret-id-list <id1> <id2> <id3>
|
||||
Impact
|
||||
- Rapid “smash-and-grab” of many secrets with fewer API calls, potentially bypassing alerting tuned to spikes of GetSecretValue.
|
||||
- CloudTrail logs still include one GetSecretValue event per secret retrieved by the batch.
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## Description
|
||||
|
||||
Abuse an SQS queue resource policy to allow an attacker-controlled SNS topic to publish messages into a victim SQS queue. In the same account, an SQS subscription to an SNS topic auto-confirms; in cross-account, you must read the SubscriptionConfirmation token from the queue and call ConfirmSubscription. This enables unsolicited message injection that downstream consumers may implicitly trust.
|
||||
Abuse an SQS queue resource policy to allow an attacker-controlled SNS topic to publish messages into a victim SQS queue. In the same account, an SQS subscription to an SNS topic auto-confirms; in cross-account, you must read the SubscriptionConfirmation token from the queue and call ConfirmSubscription. This enables unsolid message injection that downstream consumers may implicitly trust.
|
||||
|
||||
### Requirements
|
||||
- Ability to modify the target SQS queue resource policy: `sqs:SetQueueAttributes` on the victim queue.
|
||||
@@ -51,6 +51,6 @@ aws sqs receive-message --queue-url "$Q_URL" --region $REGION --max-number-of-me
|
||||
- Subscriptions won’t auto-confirm. Grant yourself temporary `sqs:ReceiveMessage` on the victim queue to read the `SubscriptionConfirmation` message and then call `sns confirm-subscription` with its `Token`.
|
||||
|
||||
### Impact
|
||||
**Potential Impact**: Continuous unsolicited message injection into a trusted SQS queue via SNS, potentially triggering unintended processing, data pollution, or workflow abuse.
|
||||
**Potential Impact**: Continuous unsolid message injection into a trusted SQS queue via SNS, potentially triggering unintended processing, data pollution, or workflow abuse.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -286,7 +286,7 @@ Assuming we find `aws_access_key_id` and `aws_secret_access_key`, we can use the
|
||||
|
||||
- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -328,3 +328,4 @@ aws ec2 modify-instance-metadata-options --instance-id <INSTANCE_ID> \
|
||||
```
|
||||
|
||||
Potential Impact: Theft of instance profile credentials via SSRF leading to privilege escalation and lateral movement with the EC2 role permissions.
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -105,7 +105,7 @@ aws ecr set-repository-policy \
|
||||
--policy-text file://my-policy.json
|
||||
```
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -281,3 +281,4 @@ aws ecr put-account-setting --name REGISTRY_POLICY_SCOPE --value V2 --region $RE
|
||||
|
||||
</details>
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -343,7 +343,7 @@ aws ecs update-service-primary-task-set --cluster existing-cluster --service exi
|
||||
|
||||
- [https://ruse.tech/blogs/ecs-attack-methods](https://ruse.tech/blogs/ecs-attack-methods)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -579,3 +579,4 @@ Commands (us-east-1):
|
||||
|
||||
|
||||
**Potential Impact:** Attacker-controlled EC2 nodes receive victim tasks, enabling OS-level access to containers and theft of task IAM role credentials.
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -289,7 +289,7 @@ Some lambdas are going to be **receiving sensitive info from the users in parame
|
||||
- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
|
||||
- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -357,3 +357,4 @@ Cleanup:
|
||||
```bash
|
||||
aws lambda delete-function-code-signing-config --function-name $TARGET_FN --region $REGION || true
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Az - File Shares
|
||||
# Az - Front Door
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -10,9 +10,78 @@ To bypass this rule automated tools can be used that **brute-force IP addresses*
|
||||
|
||||
This is mentioned in the [Microsoft documentation](https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-configure-ip-restriction).
|
||||
|
||||
## Credential Skimming via WAF Custom Rules + Log Analytics
|
||||
|
||||
Abuse Azure Front Door (AFD) WAF Custom Rules in combination with Log Analytics to capture cleartext credentials (or other secrets) traversing the WAF. This is not a CVE; it’s misuse of legitimate features by anyone who can modify the WAF policy and read its logs.
|
||||
|
||||
Key behavior enabling this:
|
||||
- AFD WAF Custom Rules can match on request elements including headers and POST parameters.
|
||||
- When a Custom Rule uses the action Log traffic only, evaluation continues and traffic proceeds (no short-circuit), keeping the flow normal/stealthy.
|
||||
- AFD writes verbose diagnostics to Log Analytics under Category FrontDoorWebApplicationFirewallLog. Matched payload details are included in details_matches_s along with the rule name in ruleName_s.
|
||||
|
||||
### End-to-end workflow
|
||||
|
||||
1. Identify target POST parameters
|
||||
- Inspect the login form and note parameter names (e.g., username, password).
|
||||
|
||||
2. Enable diagnostics to Log Analytics
|
||||
- In your Front Door profile > Monitoring > Diagnostic settings, send logs to a Log Analytics workspace.
|
||||
- At minimum, enable the category: FrontDoorWebApplicationFirewallLog.
|
||||
|
||||
3. Create a malicious Custom Rule
|
||||
- Front Door WAF Policy > Custom rules > New rule:
|
||||
- Name: innocuous name, e.g., PasswordCapture
|
||||
- Priority: low number (e.g., 5) so it evaluates early
|
||||
- Match: POST arguments username and password with Operator = Any (match any value)
|
||||
- Action: Log traffic only
|
||||
|
||||
4. Generate events
|
||||
|
||||
```bash
|
||||
curl -i -X POST https://example.com/login \
|
||||
-H "Content-Type: application/x-www-form-urlencoded" \
|
||||
--data "username=alice&password=S3cret!"
|
||||
```
|
||||
|
||||
5. Extract credentials from Log Analytics (KQL)
|
||||
|
||||
```kusto
|
||||
AzureDiagnostics
|
||||
| where Category == "FrontDoorWebApplicationFirewallLog"
|
||||
| where ruleName_s == "PasswordCapture"
|
||||
| project TimeGenerated, ruleName_s, details_matches_s
|
||||
| order by TimeGenerated desc
|
||||
```
|
||||
|
||||
Useful parsing (optional):
|
||||
|
||||
```kusto
|
||||
AzureDiagnostics
|
||||
| where Category == "FrontDoorWebApplicationFirewallLog" and ruleName_s == "PasswordCapture"
|
||||
| extend m = parse_json(details_matches_s)
|
||||
| mv-expand match = m.matches
|
||||
| project TimeGenerated, ruleName_s, match.matchVariableName, match.matchVariableValue
|
||||
| order by TimeGenerated desc
|
||||
```
|
||||
|
||||
The matched values appear in details_matches_s and include the cleartext values that matched your rule.
|
||||
|
||||
### Why Front Door WAF and not Application Gateway WAF?
|
||||
- Application Gateway WAF custom-rule logs don’t include the offending POST/header values the same way; AFD WAF diagnostics include matched content in details, enabling credential capture.
|
||||
|
||||
### Stealth and variants
|
||||
- Set Action to Log traffic only to avoid breaking requests and to keep other rules evaluating normally.
|
||||
- Use a low numeric Priority so your logging rule evaluates before any later Block/Allow rules.
|
||||
- You can target any sensitive names/locations, not only POST params (e.g., headers like Authorization or API tokens in body fields).
|
||||
|
||||
### Prerequisites
|
||||
- An existing Azure Front Door instance.
|
||||
- Permissions to edit the AFD WAF policy and read the associated Log Analytics workspace.
|
||||
|
||||
## References
|
||||
|
||||
- [https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass](https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass)
|
||||
- [Skimming Credentials with Azure's Front Door WAF](https://trustedsec.com/blog/skimming-credentials-with-azures-front-door-waf)
|
||||
- [Azure WAF on Front Door monitoring and logging](https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-monitor)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user