AWS GuardDuty | Demo-Compromised IAM Credentials | Workflow with manual remediation |

[@rajiv7]

this was so perfect!!!

[@saahilkambale]

should we put our all environment IP addresses in the list? if someone trying to access our s3 bucket from another IP address that we do not define in our list, so it is a malicious attach?

[@Cloud4DevOps]

malicious attack is consider when you are getting hit from malicious IP list which is generating millions of request suddenly and what kind of request they are accessing. Multiple factors are there to consider malicious attack and not just the IP

[@bhakta_rg]

@@Cloud4DevOps You assumed that you know the IP address and therefore you put it in the GD threatlist. In most cases you will not have the IP address of the hacker .....

[@sam7on]

Hi, could you please refer to where I can find Lambda function to automate the inactivation of the account?

[@Cloud4DevOps]

You might need to search for that in awslabs github

[@sam7on]

Thanks

[@sam7on]

@@Cloud4DevOps I can not find the github page, can you share a link? Regards

[@mohdshahnawaz7609]

When we manually remediate a finding, does it automatically disappear from GuardDuty findings tab or we have to suppress it each time?

[@bhakta_rg]

Very high level and vague, my friend. where is the implementation part with Lambda? How are we supposed to know the hacker machine IP address? if the IP is not in the Guardduty threatlist, how will Lambda get triggered to deactivate the credentials?

[@minmanple]

and what inside the ipthreatlist.txt?