Security isn't just about tools; it's about the stories they tell. Recently, I completed a thrilling investigation on a suspicious event flagged by Let's Defend's SIEM platform — and today, I’m walking you through exactly how it went down.
Imagine you’re talking to a robot assistant. You say, "Play music," and it does. But what if a stranger whispers secret, harmful commands — like "Open the safe" — and the robot listens? That’s a command injection attack: when attackers trick a system into running their sneaky commands instead of the safe ones it's supposed to obey.
For the tech folks: it usually happens when user inputs aren't properly sanitized, letting attackers slip OS-level commands into web applications.
At 4:12 AM on February 28th, an alert fired off:
Rule: SOC168 - Whoami Command Detected in Request Body
Hostname: WebServer1004
Source IP: 61.177.172.87
Destination: 172.16.17.16
Suspicious Clue? The attacker sent a POST request containing the command whoami — a classic hacker move to figure out who they’ve broken into.
Before rushing into action, it’s smart to pause and understand:
- Why did this rule trigger?
- What is it trying to protect us from?
Looking at the rule name, "Whoami Command Detected," gave an immediate clue: someone’s trying to run system-level commands through our web server!
Using the source IP address, I filtered the logs — and boom! The attacker wasn't just whispering — they were screaming:
?c=whoami?c=ls?c=uname?c=cat /etc/passwd?c=cat /etc/shadow
Here are some examples:
Commands like cat /etc/passwd (which reads user account details) screamed COMMAND INJECTION! They weren't just snooping; they were trying to take over.
Absolutely. These weren’t normal web traffic behaviors; they were classic attacker moves aiming to explore and exploit the server.
Maybe this was just a routine cybersecurity test? To find out, I navigated to the Email Security page and ran a filtered search using keywords like "command" and "whoami."
Interestingly, I did find two emails containing the word "command," but after reviewing them, there was no mention of any planned drills or penetration tests.
✅ Conclusion: This was not a scheduled exercise — it was a real attack.
To understand if this was an insider mistake or an external attack, I checked the traffic flow:
- Source IP Address: 61.177.172.87 → (This is a public IP address, coming from the Internet.)
- Destination IP Address: 172.16.17.16 → (This is a private internal IP, part of our company network.)
🛡️ Reason: Since the source IP is external and the destination IP is internal, it clearly shows an outsider trying to reach inside our network, which is a major security red flag.
Quick Visual:
[Internet] (61.177.172.87) ➡️ [Company Network] (172.16.17.16)
✅ Conclusion: The attack came from the outside world into our internal network — classic case of external threat activity.
Looking closer, I noticed HTTP responses with 200 OK and large data sizes. This suggests that the attack probably succeeded in extracting data from the server.
No time to waste. I quickly navigated to Endpoint Security, filtered for our server's IP, and slammed the "Request Containment" button to isolate the device.
✋ Containment is key to stop the hacker from spreading deeper into the network!
I logged the malicious IP address 61.177.172.87. Recording artifacts is crucial because it strengthens threat intelligence and helps prevent future attacks.
Because the attack was successful, this case demanded escalation to Tier 2 experts. Why?
- To perform deep forensics
- Patch vulnerabilities
- Monitor for any backdoors the attacker might have left.
In my comment field, I summarized my analysis.
Finally, I closed the case as a True Positive — because, without a doubt, this was a real-world attack.
This investigation wasn't just about clicking buttons; it was about thinking like a detective, understanding clues, and taking action fast. Command injection attacks can be deadly if left unchecked — but with the right skills, tools, and mindset, they can be caught and crushed before causing major damage.