“The weakest link in your security chain might be sitting right on your desk.”
At OP Innovate, our CREST-certified red team is trained to think and act like real adversaries. During a recent Red Team engagement, that mindset transformed a single sticky note, found in plain sight at a client conference, into complete control of the client’s production environment.
Here’s how it happened, step by step, along with lessons every CISO and security practitioner should take to heart.
Step 1: The Sticky Note That Opened the Door
During a routine onsite assessment, our red team observed a MacBook left unattended at a welcome desk. Attached to it was a sticky note containing the login details for the machine. One quick tap on the trackpad, a few keystrokes, and we were staring at the macOS desktop.
When we accessed Google Chrome from the MacBook, we saw that Okta SSO was already active in the session.
Luckily for us, an A4 paper was sitting conveniently next to the laptop, with SSO login details. Since we were accessing Okta from a trusted device, there was no MFA, and we were immediately logged into the Okta web interface, where we could see and launch internal applications like Slack and other business-critical tools with a single click.
This is precisely how attackers operate in the real world: they don’t need a zero-day when human error leaves the door open. A quick glance, a photo, or even shoulder-surfing is all it takes. In this case, the note had likely been written to make sign-in easier for staff managing the event.
By entering the credentials, we were able to:
- Seamlessly access the Okta dashboard without triggering MFA
- Launch internal applications like Slack, and other cloud tools
- Operate as a legitimate user, blending in with normal activity and avoiding detection
It’s a familiar pattern: attackers exploit what’s visible, not just what’s vulnerable. And the most dangerous exposures are often hiding in plain sight.
Step 2: Exploiting SSO for Lateral Movement
The conference system was integrated with the organization’s Okta Single Sign-On (SSO) environment. When we tested the same sticky note credentials on the Okta login portal, they worked.
This single point of entry unlocked multiple connected services, none of which prompted for additional verification.
What we gained:
- Full Slack access: Read/write permissions across all channels, from internal operations to sensitive incident discussions
- Credential exposure: AWS keys and access tokens shared casually in chat history, some still valid
- Operational visibility: Live insight into deployment schedules, configuration changes, and even password reset requests
With a single reused password and no MFA enforcement, we now had the keys to multiple systems. This SSO pivot was the turning point from reconnaissance to exploitation.
It’s the same tactic the Lapsus$ group used in their 2022 breach of Okta: obtain a valid credential, exploit overly trusted SSO connections, and harvest secrets shared in tools like Slack. In their case, as in ours, Slack messages retained AWS keys that enabled attackers to move deeper into the environment.
Lesson: Red team engagements reveal the exact paths real attackers would take—before they get the chance to walk them.
Step 3: AWS Account Compromised
From the moment we accessed Slack, our goal was clear: find secrets that would allow us to escalate privileges and pivot deeper into the environment.
It didn’t take long.
Buried in an old thread within a DevOps channel, we discovered a pair of AWS access keys that had been shared months earlier during a troubleshooting exchange between engineers. The credentials were still active.
We configured the AWS CLI using the recovered keys and were immediately authenticated into the client’s cloud environment. What followed was a cascade of privilege escalation.
The associated IAM role had broad permissions, granting us access to AWS Systems Manager (SSM) Parameter Store, where we uncovered a trove of plaintext secrets, including database credentials, API tokens, and service passwords.
From there, we enumerated S3 buckets and found customer data, infrastructure backups, and configuration files. The breached account had full read/write access across all buckets, allowing us to view, modify, and exfiltrate sensitive information, including client data and internal assets, without any restrictions.
At this stage, we had moved well beyond user-level access. We were operating within core infrastructure, extracting credentials that would allow us to pivot across the environment. In effect, we had quietly taken over the backbone of the company’s cloud operations, with no alarms, no detections, and no resistance.
The initial Slack breach had led to AWS, and AWS had become our springboard for what came next.
Step 4: Lateral Movement Across Cloud Services
With AWS access in hand, we began pivoting through the environment using native tools and exposed secrets. From SSM Parameter Store, we pulled additional credentials that led us into Jenkins, where we found build logs, environment variables, and stored tokens.
Using those, we accessed Bitbucket repositories containing deployment scripts, Docker Hub credentials, and hardcoded SSH keys, many of which were still active.
The SSM Parameters also exposed vCenter credentials, granting us access to ESXi hosts and full control over the client’s on-prem infrastructure.
Each move was enabled by the last. No alerts. No friction. Just silent escalation across systems that were never meant to be this connected.
The Takeaway: A Full Compromise, Rooted in Human Error
This wasn’t a case of zero-days or sophisticated malware. It was a demonstration of how attackers exploit real-world mistakes, chain weak points together, and silently expand access until it’s too late.
Attack Summary
| Phase | Description |
| Physical Security | Sticky note with conference-system credentials |
| SSO Weakness | Same credentials reused across Okta, Slack, and more |
| Cloud Compromise | AWS, S3, SSM, Bitbucket, Jenkins all accessed |
| Infrastructure Control | Production servers, source code, and hypervisors |
Why Leading Organizations Choose OP Innovate for Red Teaming
OP Innovate’s CREST-certified experts simulate real-world attacks to uncover what scanners miss – from overlooked physical exposures and weak SSO configurations to exposed secrets and lateral movement paths hiding in plain sight.
We don’t follow a checklist. We think like adversaries, spotting the sticky note no one noticed, breaching your perimeter, moving laterally through your systems, and testing how far we can go before anyone sounds the alarm.
At the end, you get more than a report. Through our WASP platform, we deliver a clear picture of how we got in, what we accessed, and exactly how to fix it, prioritized by real-world impact.
Want to know how a real attacker would target you? Let us show you.
