An attacker who has quietly moved through your AWS environment for three weeks without triggering a single alert has not been lucky. They have been operating in an environment where logging was switched on but nobody was actually watching what it recorded, which amounts to the same thing as having no visibility at all when it matters most.
CloudTrail turned on is not the same as CloudTrail monitored
AWS CloudTrail logs almost everything that happens across an account, which sounds reassuring until you consider the sheer volume it produces and how few organisations have someone actively reviewing it, or proper alerting configured to flag the events that actually matter. A default CloudTrail setup will happily record an attacker enumerating IAM permissions, accessing S3 buckets they have never touched before, or creating a new access key on a dormant account — and every one of those events can sit unread in a log bucket indefinitely if nobody has built the alerting to surface it.
This is exactly the blind spot that AWS pen testing is designed to surface, because it tests not only whether an attacker can get in, but whether your team would actually notice while it was happening. A tester who successfully moves through an environment for days without triggering a single response is handing you a finding worth far more than a list of missing patches — it tells you your detection capability has a hole in it precisely where you need it most.
GuardDuty and alerting need active configuration, not defaults
AWS GuardDuty can flag genuinely suspicious behaviour, but only if it is properly tuned, actively monitored, and connected to a process that ensures someone actually responds to what it flags. We regularly find GuardDuty enabled with the default settings, generating alerts that route to an inbox nobody checks regularly, or a Slack channel muted months ago after one too many false positives. The tool did exactly its job; the process built around it simply was not there to receive the output.
William Fieldhouse has tested this exact scenario enough times to have a clear diagnosis.
“During one engagement we spent nine days inside a client’s AWS environment, moving between services and gradually escalating privileges, and not one alert reached a human being who could act on it. The logging was all there afterwards when we reviewed it together. Nobody had built the bridge between the data being collected and a person actually looking at it in real time.”
— William Fieldhouse, Director of Aardwolf Security Ltd
Nine days is a long time for an attacker to operate freely, and it is precisely the kind of finding that a vulnerability scan would never surface, because nothing about the logging configuration itself was technically wrong. The gap was entirely in the process around it — the missing bridge between data collection and human response, which no automated tool can test on your behalf.
Test whether you would actually notice, not just whether you log
Logging without monitoring is a false sense of security dressed up as due diligence, and it is worth finding out now, deliberately, rather than during a real incident. Aardwolf Security’s cloud assessments specifically test detection and response as part of every engagement, not just initial access. If you want an honest answer about how long an attacker could operate undetected in your AWS environment, get in touch and ask for a penetration testing quote.
