A GuardDuty alert for an outgoing SSH bruteforce attack means your EC2 instance is compromised and attacking others. Here’s my no-nonsense, in-the-trenches guide to containing the threat, finding the root cause, and ensuring it never happens again.

So, GuardDuty Says You’re the Bad Guy Now: A Senior Engineer’s Guide to Outgoing SSH Attacks

It was 3 AM. The on-call phone, sitting ominously on my nightstand, lit up with a high-severity PagerDuty alert. I was expecting the usual ‘CPU utilization high on prod-db-01’ or a disk space warning. Instead, I saw a GuardDuty finding that made my stomach drop: UnauthorizedAccess:EC2/SSHBruteForce. My first thought wasn’t, “How did they get in?” It was, “Oh no… we’re the ones doing the attacking.” There’s no feeling quite like realizing one of your own servers has gone rogue and is now part of a botnet, hammering some poor soul’s infrastructure. This isn’t just an alert; it’s a declaration that your perimeter has been breached, and you’re now part of the problem.

First Off, Why is This Happening?

Let’s get one thing straight: the server didn’t just wake up and decide to become a digital menace. It was compromised. An attacker gained access and is now using your trusted AWS resources—and your billing account—to launch attacks against other targets. They do this because attacks coming from a legitimate AWS IP are more likely to bypass simple firewalls.

The root cause is almost always one of these classics:

• Weak Credentials: A user account on the machine (like ‘ubuntu’ or ‘ec2-user’) had a password instead of a key, and it was guessable.
• Leaked Keys: A developer accidentally committed an .pem key to a public GitHub repository. It happens more than you think.
• Unpatched Vulnerability: The instance was running an old, vulnerable version of an application (think Log4j, old WordPress, etc.) that allowed for remote code execution.
• Overly Permissive Security Groups: You left SSH port 22 open to the entire internet (0.0.0.0/0). This is like putting a “We’re Open!” sign on your front door for attackers.

The attacker’s script is simple: break in, install a tool like ‘masscan’ or a custom script, and start hammering other IPs on port 22. Now, let’s fix it.

The Triage Plan: From Quick Fix to Permanent Solution

When you’re under pressure, it’s tempting to just terminate the instance and hope for the best. Don’t. You’ll destroy the evidence and won’t learn how they got in, meaning it will happen again. Here’s my tiered approach.

Step 1: The Quick Fix – “Stop the Bleeding”

Your immediate goal is to stop the attack without destroying the crime scene. We need to isolate the machine.

1. Isolate Network Access: Go to the instance’s Security Group. Do NOT remove the rule that lets you SSH in. Instead, create a new Security Group. For its inbound rules, allow port 22 ONLY from your IP address or your company’s bastion host. For its outbound rules, delete all of them. This effectively cuts the instance off from the internet, stopping the bruteforce attack instantly, but still allows you to get in for forensics.
2. Snapshot the Volume: Before you even log in, go to the EC2 console, find the EBS volume attached to the instance, and take a snapshot. This is your forensic backup. If you mess something up, you still have the evidence.

Pro Tip: Once a machine is compromised, you cannot trust any binary on it. ps, netstat, ls… all of them could have been replaced by the attacker to hide their tracks. That’s why we take a snapshot first, so we can mount it on a trusted “forensics” instance later and analyze it safely.

Step 2: The Permanent Fix – “Treat it Like a Crime Scene”

With the instance contained, it’s time to figure out what happened and clean up properly. And by “clean up,” I mean terminate it.

1. Perform a Quick Investigation (on the live box): Now that it’s isolated, SSH in. You’re looking for the obvious clues. Check the command history for suspicious activity:

   cat ~/.bash_history

   Look at running processes and network connections. The attacker might be gone, but their scripts could still be running.

   # Look for unusual processes or high CPU usage
   ps aux
   
   # Look for established connections on port 22 to external IPs
   # (This won't show anything now that you've blocked outbound traffic, but it's good practice)
   netstat -tulpn

2. Find the Root Cause: Review your logs. /var/log/auth.log or /var/log/secure will show you the history of SSH logins. Did they get in with a password? Was it a user you don’t recognize? Correlate this with your CloudTrail logs to see if any API keys on the instance were used.
3. Terminate and Rebuild: You found the vulnerability. Great. Now, terminate the instance. Do not try to “clean” it. You’ll never be 100% sure you removed the rootkit or backdoor. Use your Infrastructure as Code (Terraform, CloudFormation) to rebuild a fresh, clean instance from a known-good AMI. This time, fix the vulnerability you found—whether that’s closing port 22 to the world, enforcing key-only auth, or patching the application.

Step 3: The ‘Nuclear’ Option – “Rotate Everything”

Sometimes, the compromised instance had more power than it should have. If the EC2 instance was using an IAM Role with broad permissions (like *:*, I’m looking at you), you have to assume the worst.

WARNING: This is the “I’m not sleeping tonight unless I do this” option. If the instance, say dev-legacy-jenkins-01, had an IAM role that could access your production S3 buckets or your RDS master password from Secrets Manager, you have to assume those secrets are now compromised.

In this case, the plan is simple but painful:

• Rotate the IAM access keys for the Role that was attached to the instance.
• Rotate any database credentials, API keys, or other secrets that the instance had access to.
• Audit CloudTrail for any suspicious API calls made by that instance’s IAM Role around the time of the compromise.

It’s a huge pain, but it’s a lot less painful than explaining a full-blown data breach to your CISO.

Summary of Actions

Here’s a quick-glance table for your next incident response meeting.

Getting a GuardDuty alert like this is jarring, but it’s also a valuable—if stressful—learning experience. It’s a real-world test of your security posture and your incident response plan. Follow these steps, stay calm, and turn this crisis into a stronger, more secure architecture.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions