The best and most effective way to bypass all of GuardDuty is to just add your own attacker IP address to the list of trusted IP addresses in the target account. It is a simple process and GuardDuty doesn't trigger anything to do with the enumeration or modification of GuardDuty settings, so it will likely fly under the radar, even in more modern, advanced environments. If we look at the Lists tab of GuardDuty in the AWS web console, we will see something similar to the following screenshot:

In this screenshot, we can see that there is a section for Trusted IP lists and Threat lists. Respectively, they are basically a way to whitelist and blacklist IP addresses, telling GuardDuty to either ignore findings from these IP addresses (whitelist) or to trigger on everything from these IP addresses (blacklist).

As an attacker, this is amazing. We can whitelist our own IP address without triggering any alerts in the process, then go nuts in the environment without worrying about GuardDuty from that point on.

There is a problem that you may encounter when trying to add yourself as a trusted IP and that is that there is a maximum of one trusted IP list per-region allowed by GuardDuty. This means that if our target is already utilizing the trusted IP list, we'll have to modify our attack slightly. The first thing to do will be to determine whether they are, in fact, using the trusted IP list or not. Note that GuardDuty monitors on a per-region basis, so it may be necessary to repeat these steps for each GuardDuty detector in each available region. We can do this by running the following AWS command-line interface (CLI) command:

   aws guardduty list-detectors 

This should return the ID of the GuardDuty detector in the current region. In our example, that turns out to be e2b19kks31n78f00931ma8b081642901. If no detector IDs are returned, then that means GuardDuty is not enabled in the current region, which is good news if you are trying to bypass it! Then we will check this detector to see if there is already a trusted IP list associated with it, using the following command:

   aws guardduty list-ip-sets --detector-id e2b19kks31n78f00931ma8b081642901 

If there is already a trusted IP set in place, its ID will be returned, and if not, an empty list will be returned. The first scenario we will look at will assume that they are not using a trusted IP list already. This is the best-case scenario for us.

To start off this attack, we will need to create a text file locally on our computer that contains the IP address that we want to whitelist. We'll be naming this the ip-whitelist.txt file. Then, because GuardDuty requires the file containing the IP whitelist to be hosted in S3, we will upload this file to an S3 bucket within our own attack account and expose the file publicly. The reason for this is so that we are always in control of the whitelist that is being used and we could even modify it as needed during an engagement. For this example, we'll say that we are using the bucket-for-gd-whitelist S3 bucket. First, we'll upload our file to the bucket with this command:

   aws s3 cp ./ip-whitelist.txt s3://bucket-for-gd-whitelist

Next, we will want to make sure that our file is publicly readable, so that GuardDuty can read it as needed when it is set as the whitelist. We can do this with the following command:

aws s3api put-object-acl --acl public-read --bucket bucket-for-gd-whitelist --key ip-whitelist.txt 

Bear in mind that the settings on the bucket itself or your account may prevent public objects, so if you receive an access denied message when running this command or it does not seem to be working, ensure that the bucket or account public access settings are correctly configured to allow public objects.

Now our file should be publicly accessible at this URL (for this example only): https://s3.amazonaws.com/bucket-for-gd-whitelist/ip-whitelist.txt.

Next, we will create the new trusted IP list for the GuardDuty detector we identified earlier with the following command:

   aws guardduty create-ip-set --detector-id e2b19kks31n78f00931ma8b081642901 --format TXT --location https://s3.amazonaws.com/bucket-for-gd-whitelist/ip-whitelist.txt --name Whitelist --activate

If this was successful, you should receive a response that includes the ID of the newly-created trusted IP set. Now, that's it. Your IP is in an active trusted IP list for GuardDuty in the current region, meaning that GuardDuty will not generate findings for it (from the GuardDuty Lists page).

As you may have guessed, there's a Pacu module to automate this process. From Pacu, we can use the guardduty__whitelist_ip module to do this across every region. We can use the following command to do so:

   run guardduty__whitelist_ip --path https://s3.amazonaws.com/bucket-for-gd-whitelist/ip-whitelist.txt

When that is complete, Pacu will have whitelisted your IP address in GuardDuty across every AWS region.

Now we are going to look at a scenario where the target AWS account already has a GuardDuty trusted IP list setup. We can't just add another list, because there is a maximum of one trusted IP list per GuardDuty detector. There are a couple different ways we could handle this. After we run the ListIPSets command and see that there is, in fact, a trusted IP list set up, we could just go ahead and delete the existing IP set, then implement one that whitelists our own IP. If you are using Pacu, and Pacu detects an existing trusted IP set, it will prompt you to delete it and create your own or skip that detector. The only problem with this is that deleting an existing trusted IP whitelist may have unintended consequences in the environment, which means we might draw more attention to ourselves than necessary when trying to stay stealthy.

Another option we have is to update the current trusted IP list to include our own IP, as well as all the IPs that were there originally. To do this, let's take the IP set ID that we collected from the ListIPSets API call and run the GetIPSet command:

   aws guardduty get-ip-set --detector-id e2b19kks31n78f00931ma8b081642901 --ip-set-id 37w2992c2274llq7u4121o8af11j4971 

If we run that command on the trusted IP list we just created earlier in this section, the output will look like the following:

{
    "Format": "TXT",
    "Location": "https://s3.amazonaws.com/bucket-for-gd-whitelist/ip-whitelist.txt",
    "Name": "Whitelist",
    "Status": "ACTIVE"
}

We'll consider this trusted IP list as one we haven't seen before (even though we set it up ourselves). What we will want to do is to visit the URL and download the current list, then we will modify the list to include our own attacker IP address. Once that is done, we will go through the same process as earlier, where we upload this file to our own personal S3 bucket and make the file publicly readable.

Once that is done, we will then use the UpdateIPSet API instead of the CreateIPSet API like we did earlier. We can update the existing trusted IP list with our new one with the following command:

   aws guardduty update-ip-set --detector-id e2b19kks31n78f00931ma8b081642901 --ip-set-id 37w2992c2274llq7u4121o8af11j4971 --location https://s3.amazonaws.com/our-own-bucket-for-gd-whitelist/our-own-ip-whitelist.txt --activate

Now, we will have updated the trusted IP list with our own IP address without removing any IPs that were already whitelisted, thus not creating any ruckus in the environment that might get us noted.

As a responsible (and smart) attacker, there is one more step we must follow. That step is at the very end of the AWS engagement/penetration test/attack, where we restore the original whitelist, so that the configuration doesn't look strange when viewing it, and our IP is no longer stored in a list they have access to. To do this, we should save the URL that was originally associated with the trusted IP list until the end of the engagement, and then use the UpdateIPSet API again to restore it back to that URL. By doing this, our IP is whitelisted with GuardDuty for the duration of the engagement, then we leave the environment when are done without any major modifications to the resources in it.

One more important note is that if the account you are attacking has GuardDuty controlled by another external master account, you will not be able to modify the trusted IP list settings. Only the master account can do that when managing the GuardDuty cross-account. When a master account uploads a trusted IP list, this list is then applied to all GuardDuty members that belong to that master, which is amazing for an attacker who has compromised a GuardDuty master account.