Fake AWS & Apple ID Pages Push iOS Spyware

How the attack worked

Researchers at Censys identified an unknown operator running more than 100 web properties, most of which are fake AWS sign-in pages. Victims are funneled to one of two entry points: an AWS-console impersonation subdomain or an Apple ID sign-in decoy page. When a victim reaches either page, a malicious iframe loads JavaScript that fires an exploit chain. Successful exploitation deploys GHOSTBLADE modules that dump keychain, iCloud, and Wi-Fi credentials and exfiltrate files from the device.

The operator's infrastructure included multiple admin and panel logins, referenced internally with names like DarkSword Admin, Decode Dashboard, and C2 Control Panel, along with exposed tooling found in an open directory. A Telegram contact link was also found on the C2 Control Panel, suggesting a direct channel for the operator.

Why it succeeded

This campaign works because it targets two of the most routine actions people take online: signing into a cloud console and signing into an Apple ID. Both AWS and Apple ID logins are trusted, frequently used prompts, so a lookalike page in the right context does not necessarily stand out. The attack chain also does not always require credential entry, since simply reaching the page can be enough to trigger the exploit against iOS. That combination of familiar pretext and a low bar for compromise makes the approach effective against a broad range of users, including IT, DevOps, engineering, and executives.

What to watch for

• Login prompts for AWS or Apple ID that appear on unusual domains or subdomains rather than the official ones
• A sign-in page reached through a random link, search result, or unfamiliar site rather than a bookmarked URL or official app flow
• Unexpected page behavior, such as hidden iframe or script activity, that seems inconsistent with a normal sign-in page
• Sign-in pages hosted alongside unrelated admin or panel infrastructure

How to build resistance

Treat cloud login pages as high-risk touchpoints. Employees should only sign in through bookmarked or known-good URLs rather than links received in messages or found through search. Any unexpected AWS or Apple ID sign-in prompt should be treated as suspicious until verified through an official channel.

Because a website visit alone can be enough to start an iOS compromise in this campaign, keeping iOS devices fully updated and avoiding unknown or unofficial sites on work devices is important. Given that stolen data can include password stores and cloud account credentials, organizations should encourage use of managed devices where possible and promote quick reporting of any unusual or unexpected sign-in prompts so security teams can investigate before credentials or device data are exposed.

How does this attack start?

It begins when a victim reaches an operator-controlled domain, either an AWS-console impersonation subdomain or an Apple ID sign-in decoy, which loads a malicious iframe that fires JavaScript to trigger the exploit chain.

What data can attackers steal with this campaign?

Once the exploit succeeds, the implant delivers modules that dump keychain, iCloud, and Wi-Fi credentials and can exfiltrate files from the device.

Do I need to enter credentials for the attack to work?

Not necessarily. Researchers note that simply reaching one of the lookalike pages can be enough to trigger an iOS exploit chain, in addition to credential entry on the fake sign-in forms.

How can I tell a fake AWS or Apple ID sign-in page from a real one?

Watch for sign-in prompts hosted on unusual domains or subdomains not used by AWS or Apple, prompts that appear after clicking an unfamiliar link rather than through official settings or console flows, and pages that behave oddly or are hosted alongside unrelated admin panels.