Skip to content

Commit

Permalink
Merge pull request nccgroup#119 from bleemb/limit-logging
Browse files Browse the repository at this point in the history
Modify GuardDuty Configurations
  • Loading branch information
Frichetten authored Jan 30, 2022
2 parents 320debe + baff626 commit b828344
Showing 1 changed file with 96 additions and 0 deletions.
96 changes: 96 additions & 0 deletions content/aws/avoiding-detection/modify-guardduty-config.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,96 @@
---
author: Ben Leembruggen
title: Modify GuardDuty Configuration
description: Modify existing GuardDuty configurations in the target account to hinder alerting and remediation capabilities.
---

When an account has been successfully compromised, an attacker can modify threat detection services like GuardDuty to reduce the likelihood of their actions triggering an alert. Modifying, as opposed to outright deleting, key attributes of GuardDuty may be less likely to raise alerts, and result in a similar degradation of effectiveness. The actions available to an attacker will largely depend on the compromised permissions available to the attacker, the GuardDuty architecture and the presence of higher level controls like [Service Control Policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html).

## GuardDuty
Where GuardDuty uses a delegated admin or invite model, features like detector configurations and IP Trust lists are centrally managed, and so they can only be modified in the GuardDuty administrator account. Where this is not the case, these features can be modified in the account that GuardDuty is running in.

---
### Misconfiguring the Detector
An attacker could modify an existing GuardDuty detector in the account, to remove log sources or lessen its effectiveness.

Configuration changes may include a combination of:

- Disabling the detector altogether.
- Removing Kubernetes and s3 as data sources, which removes all [S3 Protection](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-s3.html) and [Kubernetes alerts](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-kubernetes.html).
- Increasing the event update frequency to 6 hours, as opposed to as low as 15 minutes.


#### Required Permissions to execute
- guardduty:ListDetectors
- guardduty:UpdateDetector

Example CLI commands
```
# Disabling the detector
aws guardduty update-detector \
--detector-id 12abc34d567e8fa901bc2d34eexample \
--no-enable
# Removing s3 as a log source
aws guardduty update-detector \
--detector-id 12abc34d567e8fa901bc2d34eexample \
--data-sources S3Logs={Enable=false}
# Increase finding update time to 6 hours
aws guardduty update-detector \
--detector-id 12abc34d567e8fa901bc2d34eexample \
--finding-publishing-frequency SIX_HOURS
```
---
### Modifying Trusted IP Lists
An attacker could create or update GuardDuty's [Trusted IP list](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_upload-lists.html), including their own IP on the list. Any IPs in a trusted IP list will not have any Cloudtrail or VPC flow log alerts raised against them.

*DNS findings are exempt from the Trusted IP list.*

#### Required Permissions to execute
- guardduty:ListDetectors
- guardduty:ListIPSet
- iam:PutRolePolicy
- guardduty:CreateIPSet (To create new list)
- guardduty:UpdateIPSet (To update an existing list)

*Depending on the level of stealth required, the file can be uploaded to an s3 bucket in the target account, or an account controlled by the attacker.*


Example CLI commands
```
aws guardduty update-ip-set \
--detector-id 12abc34d567e8fa901bc2d34eexample \
--ip-set-id 24adjigdk34290840348exampleiplist \
--location https://malicious-bucket.s3-us-east-1.amazonaws.com/customiplist.csv \
--activate
```

---
### Modify Cloudwatch events rule
GuardDuty populates its findings to Cloudwatch Events on a 5 minute cadence. Modifying the Event pattern or Targets for an event may reduce GuardDuty's ability to alert and trigger auto-remediation of findings, especially where the remediation is triggered in a member account as GuardDuty administrator protections do not extend to the Cloudwatch events in the member account.

!!! Note
In a delegated or invitational admin GuardDuty architecture, cloudwatch events will still be created in the admin account.

#### Required Permissions to execute
- event:ListRules
- event:ListTargetsByRule
- event:PutRule
- event:RemoveTargets

Example CLI commands
```
# Disable GuardDuty Cloudwatch Event
aws events put-rule --name guardduty-event \
--event-pattern "{\"source\":[\"aws.guardduty\"]}" \
--state DISABLED
# Modify Event Pattern
aws events put-rule --name guardduty-event \
--event-pattern '{"source": ["aws.somethingthatdoesntexist"]}'
# Remove Event Targets
aws events remove-targets --name guardduty-event \
--ids "GuardDutyTarget"
```

0 comments on commit b828344

Please sign in to comment.