A cloud security assessment that started with an innocent image upload function became a dangerous entry point.
Three days. That’s how long it took our Swarm to gain full control of a major insurance provider’s web servers, AWS environment, and client databases, all starting from three ordinary image upload forms on a client login portal.
What began as a scoped proof of concept turned into a clear case for why a cloud security assessment has to look past the obvious attack surface, and why traditional testing just isn’t enough.
Three upload forms. One way in. Hours to a reverse shell. Days to full compromise. The gap between what looked secure and what actually was: wide open.
The setup and the discovery
This insurance provider came to us wanting a proof of concept. Budget constraints pushed the start of the engagement back by a few months, and once it got the green light, the ask was simple: test the client login portal. That single request would prove more important than anyone expected.
Our Swarm doesn’t just test. We attack from every angle at once. Inside the portal, we found three separate image upload areas: one for IDs, one for supporting documents, one for profile pictures. To most people, these look like standard features.
To the Swarm, each one was a potential file upload vulnerability waiting to be proven, and a scoped test of one login page had just become an assessment of everything behind it.
The breach
This is where the engagement moved fast. Within hours of finding the upload forms, we had:
- Confirmed the server ran PHP
- Deployed a custom proof-of-concept payload
- Executed system commands
- Established a reverse shell connection
- Gained full control of the AWS environment
- Accessed all eight domains and their databases
We weren’t done. By day three, we’d found an SQL injection attack path in the search function, letting us pull sensitive data at will. The gap between what the client believed about their security and what a real cloud security assessment actually found was stark.
Full AWS control meant we could read, alter, or delete any customer data stored on their infrastructure. Access to all eight domains meant every connected system, not just the login portal, was in reach.
That’s the business risk behind the technical finding: one overlooked input field gave an attacker control of the servers, the cloud infrastructure, and every database sitting behind the portal.
The turning point
The moment we confirmed these vulnerabilities, we skipped the usual playbook. Instead of writing up findings for a report the client would read weeks later, we pulled key Swarm members and the client’s team into a live session and built a remediation plan together, in real time.
That’s exactly what a cloud security assessment should surface when it goes deep enough: not just what’s broken, but what to do about it before the meeting ends.
This kind of gap survives most scans because upload validation usually checks file extension and size, not what’s actually inside the file. A scanner sees a JPEG. It doesn’t see the payload riding inside it.
The lesson
Following this engagement, discussions began about expanding CovertSwarm’s work to the client’s sister companies. That expansion tells its own story: point-in-time testing, however thorough, can’t keep pace with a live adversary.
Your organisation might carry the same risk right now. Attackers will find it eventually. The only real question is who finds it first, you or them.
Perceived security and actual security aren’t the same thing, and the gap between them costs money and reputation. A single cloud security assessment doesn’t need months to prove that annual testing isn’t enough. Constant, targeted attack, delivered on subscription, closes the gap before someone else finds it.
What would three days of pressure find in your own upload forms?
One overlooked input field is all it took here. Don’t wait for a real attacker to test yours. Contact CovertSwarm and put your cloud infrastructure under constant, targeted attack before someone else finds the gap first.