Incident Response Playbook – EC2 Cryptomining [Cheat Sheet]

AWS EC2 Cryptojacking Incident Response playbook cheat sheet blog post

You wake up tomorrow to a GuardDuty notification that there might be EC2 cryptomining activity going on in one of your AWS accounts. What’s your next step?

A) Panic
B) Run through a customized playbook you created after going through Cybr’s course

Hopefully you picked B), but if you haven’t gone through that course yet, here are some tips and steps you can go through, with a cheat sheet at the end:

🟠 [Analysis – Validate]

Regardless of how you detected the incident (GuardDuty, high bill, 3rd party), you should see some sort of information that will reveal a potentially compromised user/access key, instance(s), or other resource.

Using that information, start investigating to:

  • Make sure it’s not a false positive
  • Make sure it’s involving your AWS account (is a 3rd party involved?)
  • Start getting a general idea of what might be happening

🔴 [Containment]

After talking with the user/access key or resource custodian, you can take steps to contain:

  • Deactivate access key(s)
  • Apply deny all policies

There might be other resources you can start containing, though the rest may have to wait after you’ve scoped the incident so that you know what to contain and how.

🟠 [Analysis – Scope]

  • Resource inventory: who/what is involved?
  • What actions were taken and for what timeframe(s)?
  • What resources were created or modified?
  • What indicators are present?
  • Etc…

🔴 [Containment]

With a much better idea of what’s going on, you’ll have a clearer picture of what needs to be contained. Could be:

  • EC2 instances
  • Backdoor users/resources
  • Etc…

Containment steps depend largely on the resources affected. For example, EC2 instances can be contained a few different ways, and there’s more info in the cheat sheet.

🟠 [Analysis – Impact]

Start answering important questions using concrete data you gathered

🔴 [Eradication]

Time to delete those backdoors, malicious resources, etc… This step again depends on the resource, potential impact to production, and so on.

🟢 [Recovery]

Recover legitimate resources (if any), especially if impacting prod or the team

🔵 [Post-Incident Activity]

  • What happened?
  • What can we do better?
  • What could have prevented this?

➡️ This can help you get going, but there’s a lot more I can’t fit in a LinkedIn post. If you want to learn how to do this hands-on with real-world scenarios, check out my course Incident Response with CloudTrail Lake and Athena

In the course, you’ll also get a direct comparison of using Lake and Athena — their pros/cons, how they’re similar and how they’re different, so that you can use the right tool for the job.

AWS Incident Response playbook for EC2 Cryptomining (cryptojacking)

More AWS Security cheat sheets

Related Articles

Responses

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.