iOS exploit kits reach iPhones through hidden website frames.

An iOS exploit kit uses browser vulnerabilities to attack an iPhone when it visits a page. On compromised websites, an injected hidden frame sends the browser to an external router or exploit loader while the site's visible content stays on screen.

compromised website
  -> hidden frame loads an external page
  -> router checks the device and iOS version
  -> dispatcher fetches and runs selected modules
  -> browser enters the exploit chain

Hidden frames load code outside the visible page

Coruna sits behind a one-pixel frame marked aria-hidden. That frame opens another external frame, whose page imports the dispatcher.

Another router creates frames with zero width and height, positions them off-screen and disables pointer events. It reads the iPhone, iPad or iPod OS version from the user agent and loads separate frame routes. A browser-storage lock suppresses retries after a child frame signals that its entry code ran.

Version checks select the loader route

The remote-module loader extracts the iPhone OS version from navigator.userAgent. It fetches JavaScript files as text, saves each response in window.modules under its filename and evaluates an entry module. A retrying variant uses cache: 'no-store' and waits for the downloads to finish before running the entry.

Coruna uses an obfuscated obChTK dispatcher with hash-keyed modules and salted resource filenames. Alongside it, a recurring beacon reads the visitor's public IP address and an OS/version description, then posts them with a campaign value and the executing frame's hostname to an IP-sync endpoint.

What we see across infected sites

Month	New sites
September	0
October so far	2

Of the 1 site captured since 25 September, 0 ran WordPress.

Of the 0 sites recaptured at least 25 days after their first match, 0 still served iOS exploit-kit code (0%).

Finding and removing the hidden frames

Preserve the page source, rendered DOM and frame request chain. Check for:

• one-pixel or zero-size frames loading unfamiliar external pages
• aria-hidden, off-screen positioning and disabled pointer events on those frames
• user-agent checks for iPhone OS versions before remote scripts load
• JavaScript fetched as text, stored in window.modules and passed to eval
• an obChTK dispatcher, hash-named modules or recurring IP-sync requests
• parent/child messages and browser-storage keys that suppress repeat loads

Remove the injected frames and their loaders, then restore changed page templates and site files from trusted sources. Review CMS, hosting and deployment access, rotate affected credentials and clear caches. Test the original path with an iPhone user agent and inspect the frame requests again.