Assessing the Risk: Sub-Domain Takeover via EC2 IP Takeover
Learn how EC2 IP takeover can lead to subdomain takeover vulnerabilities, and whether this emerging technique poses a real threat to your cloud infrastructure.
Security teams often categorize clickjacking as a "known but tolerated" vulnerability. It's frequently downplayed during security assessments and dismissed with a simple note to "consider implementing frame protections." This dangerous complacency overlooks how modern attackers have evolved this technique from simple button tricks to sophisticated attack chains capable of devastating consequences.
Multi-step clickjacking transforms this "low-priority" vulnerability into a precision weapon. Rather than using crude one-click attacks, malicious actors now craft elaborate interactive experiences that guide users through seemingly legitimate workflows while secretly orchestrating actions on your protected domains. These attacks are particularly insidious because they target already authenticated users, completely bypassing your carefully designed authentication controls.
The most alarming aspect? These attacks do not require advanced technical skills to execute. With basic web development knowledge, attackers can create convincing overlays that perfectly mimic your application's interface, making detection nearly impossible for even the most security-conscious users.
Clickjacking is a deceptive manipulation of user interfaces where malicious actors trick users into clicking something other than what they believe. This technique involves placing an invisible, interactive element from a target website over seemingly harmless content on an attacker-controlled site. Users who think they are interacting with the visible content trigger actions on the hidden element.
At its core, clickjacking exploits a fundamental trust relationship between users and their web interfaces. The attack typically works like this:
The danger lies in its subtlety—users remain completely unaware that they have been manipulated, as the visible experience appears normal while malicious actions occur invisibly. Traditional clickjacking may trick users into actions like changing account settings, making purchases, enabling camera or microphone access, or even downloading malware.
Most basic clickjacking attacks target a single malicious click, causing many security professionals to underestimate their impact. However, as we will explore next, modern attackers have advanced this technique into something considerably more sophisticated and dangerous.
Multi-step clickjacking extends the deceptive principles of basic clickjacking into a more sophisticated and dangerous attack chain. While traditional clickjacking aims to trick users into performing a single unintended action, multi-step variants orchestrate coordinated interactions across multiple pages or states.
In these advanced attacks, malicious actors craft an intricate sequence of invisible frames and overlays that guide users through what appears to be a typical workflow. As users navigate through what they perceive as legitimate interfaces, they trigger a predetermined sequence of actions on target websites. The attacker carefully choreographs each step, positioning invisible elements to capture clicks across multiple stages of interaction.
Multi-step clickjacking is particularly effective because it can bypass protections designed for single-click attacks. By chaining together a series of seemingly innocuous actions, attackers can accomplish complex tasks that would be impossible with simple clickjacking, like navigating through confirmation dialogs, completing form submissions, or performing actions that require multiple sequential inputs. The victim remains unaware as they're guided through an invisible journey that leverages their authenticated sessions to perform unauthorized actions.
The key challenge in multi-step clickjacking attacks is determining when a user has completed one action so you can transition them to the next step. Traditional clickjacking relies on overlaying invisible elements, but this raises a question: how does the attacker know when the user has clicked?
The Timing Problem
When an attacker places an invisible iframe (with pointer-events: none) under a visible but non-interactive button, the user sees the decoy button, and when clicked, the interaction passes through to the hidden iframe. However, the attacker's page receives no event notification that the click occurred. This makes sequencing multiple steps difficult because there's no reliable way to know when to advance to the next stage of the attack.
The Solution: Mouse Hover Detection
Software Secured’sMy research uncovered a more reliable technique that solves this timing problem. The attacker positions a transparent div over the target button in the iframe. This div has pointer-events: auto (so it can detect hover events). When the user's mouse hovers over this div (which is positioned over the button they intend to click), it triggers an event handler. The event handler starts a timer (typically a few seconds), and after this delay, the attack automatically advances to the next step.
Why This Works
This technique is highly effective due to human behavior patterns. Users rarely hover their mouse over a button without intending to click it. Their brief hesitation before clicking allows the hover detection to function. Users are mentally committed to the action when they position their cursor over a button. By using hover detection with a short delay instead of attempting to detect the actual click, attackers can reliably sequence a chain of interactions across multiple pages or states, making complex multi-step attacks possible.
Implementation Example
This technique transforms clickjacking from a relatively simple one-time trick into a sophisticated attack chain capable of guiding users through complex sequences of actions while maintaining the illusion of normal interaction. The hover-based timing approach creates a predictable way to sequence multiple malicious actions using the user's own behavioral patterns, all while keeping them completely unaware that they're being manipulated across multiple steps.
For this example, let's consider a vulnerable website called example.com. During security testing, a self-XSS vulnerability was discovered that required multiple precise clicks to exploit. This discovery sparked the investigation into multi-step clickjacking as an attack vector.
The Vulnerability Setup
The security team had implemented X-Frame-Options on most pages, including their login page, but they overlooked one critical internal page that could only be accessed when a user is logged in. When attempting to iframe this unprotected page, since it requires authentication, the browser automatically redirects to the login page. Importantly, the browser checks the X-Frame-Options header of the initial URL being framed (the internal page), not the page it ultimately redirects to (the login page).
This creates a critical security loophole:
3. Despite the login page having X-Frame-Options, it is now displayed in the iframe because the browser only checked the framing policy of the initially requested page.
Combined with the discovered self-XSS that required multiple user interactions, this created the perfect scenario for a multi-step clickjacking attack.
The Attack Chain
Here's how an attacker exploits this situation through multi-step clickjacking:
This attack demonstrates why multi-step clickjacking is particularly dangerous - it provides a method to exploit vulnerabilities that would otherwise require direct user manipulation. The combination of inconsistent frame protections and a self-XSS vulnerability created a serious security risk that could lead to complete account takeover.
To effectively protect your application against multi-step clickjacking attacks, implement these comprehensive defensive measures:
Frame Protection Headers
The most critical defense against clickjacking is implementing proper HTTP headers consistently across your entire application. Set the X-Frame-Options header to DENY or SAMEORIGIN on every page of your application to prevent unauthorized framing. The DENY option blocks all framing attempts regardless of origin, while SAMEORIGIN allows framing only from pages on the same domain. For more granular control, consider using the Content-Security-Policy header with the frame-ancestors directive, which offers more flexibility in specifying which domains can frame your content. A strict implementation would use Content-Security-Policy: frame-ancestors 'none'; to block all framing attempts.
Defense-in-Depth Strategies
A comprehensive defense requires multiple layers of protection. Start by implementing automated header validation through CI/CD checks that verify security headers across all routes before deployment. Add client-side frame-busting JavaScript as a secondary defense layer with code such as if (window !== window.top) { window.top.location = window.location; } to force breakout from frames. Configure cookies with SameSite=Strict attributes to prevent cross-site request forgery and limit the effectiveness of clickjacking attacks. Include specific clickjacking scenarios in your regular application security testing program to identify potential vulnerabilities before they can be exploited.
Developer Education
The human element remains crucial in maintaining strong defenses. Provide security training to ensure all development teams thoroughly understand clickjacking risks and mitigation strategies. Create standardized security templates and configurations that developers can easily apply to new application components, ensuring consistent protection across your digital ecosystem. Whenever possible, implement framework-level security controls that apply protections by default, reducing the risk of human error or oversight. Remember that security awareness among your development team can prevent the small mistakes that often lead to significant vulnerabilities.
YRemember that your application's security against clickjacking is only as strong as its weakest endpoint. One unprotected page can compromise your entire security posture, so thorough and consistent implementation of these protective measures is essential.
Multi-step clickjacking represents a significant evolution in web-based attacks, transforming what many security teams dismiss as a minor issue into a sophisticated threat vector with severe consequences. As demonstrated in our examples, these attacks can bypass standard protections and leverage authenticated sessions to perform complex actions without user awareness.
The danger lies in the perfect storm of technical oversight (inconsistent frame protections), user manipulation (convincing interactive experiences), and the ability to chain multiple vulnerabilities together. Even a single unprotected endpoint can serve as the entry point for a devastating attack chain.
Security professionals must reassess their approach to clickjacking vulnerabilities. Rather than treating frame protection as an optional security enhancement, they should implement comprehensive X-Frame-Options or Content-Security-Policy headers across their entire application. Remember that your security is only as strong as your weakest endpoint.
As attackers continue to refine these techniques, organizations that maintain a "known but tolerated" stance toward clickjacking vulnerabilities are leaving themselves exposed to sophisticated attacks that can bypass authentication controls and compromise user accounts. Don't wait until after a breach to take this threat seriously—audit your applications now and close these dangerous security gaps.
https://github.com/Hacking-Notes/ClickMe
https://owasp.org/www-community/attacks/Clickjacking
https://portswigger.net/web-security/clickjacking
Security
Can be easily manipulated without detection if not properly secured.
Digitally signed and can be validated on the server. Manipulation can be detected.
Size
Limited to 4KB.
Can contain much more data, up to 8KB.
Dependency
Often used for session data on the server-side. The server needs to store the session map.
Contains all the necessary information in the token. Doesn’t need to store data on the server.
Storage Location
Browser cookie jar.
Local storage or client-side cookie.
Discover the top 10 penetration testing companies with side-by-side comparisons of their strengths, testing methods, platforms, and ideal use cases to help you choose the best vendor for your security needs.
Providing the quality of the biggest names in security without the price tag and complications.
Manual penetration testing
Full time Canadian hackers
Remediation support