iOS and Android Attacks: How the Campaign Worked
Learn how a suspected Russian intelligence campaign used compromised-looking websites to target iPhones and Android devices—and what users and teams should do.
How a Website Visit Became an iPhone or Android Attack
A mobile attack doesn't always start with a shady app or an email attachment. In a campaign described by security researchers, simply visiting a targeted website could expose an iPhone or Android device to malicious code. The sites looked legitimate, but attackers used lookalike domains and reverse proxies to inject JavaScript into what visitors received.
Sekoia assessed - with moderate to high confidence - that the activity was linked to Russia's Foreign Intelligence Service. They said the attackers went after sites that referenced the war in Ukraine, plus a website tied to the 250th anniversary of American independence and a London hotel. The campaign used exploits for flaws that had already been patched, and the payloads were tailored to the visitor's mobile platform.
That distinction matters. The report doesn't prove that every visitor was infected, or that every attempted data theft succeeded. What it does make clear is how a believable website can become part of an intrusion operation - so device updates, website monitoring, and incident response have to work together.
What happened in the iOS and Android attacks?
The reported campaign started when visitors landed on websites modified to serve malicious JavaScript. That script checked the device and then determined what to deliver next. After that, the attackers used platform-specific payloads for iPhones or Android devices.
Sekoia reported that the targets may have included potentially hundreds of sites. Some connected to Russia's war against Ukraine. Others were tied to plausible opportunities to reach people with diplomatic or political interests. One impersonated domain, america250[.]holiday, acted as a reverse proxy for america250.org, a non-partisan organization marking the 250th anniversary of American independence. Another, theowo[.]club, proxied the website of Raffles of London OWO, a luxury hotel near sensitive UK government institutions.
Sekoia suggested the American anniversary site could have been chosen because its public profile made it useful as an invitation-themed pretext for spear-phishing. The hotel's location - and a reported connection to a visit by Ukrainian President Volodymyr Zelenskyy - also provides context for the targeting. Still, that doesn't prove who was targeted or that a specific guest's phone was compromised.
Sekoia assessed that the operation may have been carried out by Russia's Foreign Intelligence Service, with moderate to high confidence. That's an intelligence assessment, not a publicly established fact about the operator's identity. Attribution often relies on infrastructure, technical patterns, and operational context, so it shouldn't be treated as certain - especially when the researchers themselves qualify their conclusions.
Why "previously patched" is important
The exploits in the reported activity relied on flaws that were already patched. That matters because it makes the campaign different from one built around a newly discovered, unpatched vulnerability - often called a zero-day. It also changes the practical question for users: was the device running software with the relevant fixes installed at the time the person visited the site?
The source report doesn't list the specific vulnerability identifiers, affected operating system versions, or the full exploit chain. It would be misleading to assume those details or to claim that all current iPhones and Android devices remain vulnerable. The more defensible takeaway is narrower: the attackers tried known exploits, and timely updates can block that path.
How did the malicious websites deliver the attack?
This campaign used a common web technique in a way that's harder to spot. A reverse proxy pulls content from one website and serves it through another domain. Legitimate organizations use proxying for real reasons, but attackers can use it to make a lookalike site show most of a real site's content while inserting their own code into the response.
In the example described, america250[.]holiday proxied america250.org. That meant visitors could see content resembling the genuine anniversary site, while the traffic was altered to include malicious JavaScript. The report describes a similar setup involving theowo[.]club and the hotel's website. In short, the trust problem is simple: a page can look authentic even when it's not coming from the genuine domain.
The injected script also profiled the device before delivering a platform-specific payload. That sequencing helps an attacker avoid sending the same exploit to every visitor. It also means that just visiting the page doesn't guarantee the payload ran. The outcome can vary depending on the device model, operating system version, browser, and whether the relevant vulnerability is present.
Why a proxy can be harder to spot than a fake page
A crude imitation tends to break things - layout glitches, outdated text, spelling mistakes. A reverse proxy can reproduce the real site's current pages, so a quick visual check is less useful. And while a padlock or "secure" indicator shows encryption, it doesn't prove the domain is official. It only indicates the connection to the domain shown in the address bar is encrypted.
For defenders, the key question is what content the site owner published versus what the visitor actually received. If a server is compromised, if an injected script is in play, or if a malicious intermediary sits in the middle, the response can change after publication. That's why website owners need to monitor domains, DNS changes, third-party scripts, and the code delivered to browsers - not just what they think is sitting on their own servers.
For users, the practical habit is to check the domain itself when anything sensitive is happening. If the address looks like a trusted organization's domain but isn't quite right, that deserves extra caution - especially if the message asks you to RSVP, sign in, or download something. This doesn't mean every lookalike domain is malicious. It just means the address bar is a more reliable signal than a familiar logo.
What data could the attackers access?
Sekoia reported that the final payloads attempted to steal browser cookies. In some cases, the attackers also tried to collect Wi-Fi passwords and other broader data from the mobile device. The word attempted is important here: the report describes what the payloads were designed to do, not proof that every targeted visitor lost data.
Browser cookies can keep you signed in or preserve a session. If an attacker steals a valid session cookie and it still works, they may be able to access an account without immediately needing the account password. The risk depends on the service's protections, how the session is managed, and whether the session has expired or been revoked. Multi-factor authentication helps, but it doesn't automatically defeat an active session that's already been taken.
Wi-Fi credentials and device data create different kinds of risk. A Wi-Fi password could help someone access a network, depending on the network setup and other controls. Device data might reveal things that help an attacker understand contacts, activity, or stored material. The source report doesn't provide a full list of collected fields, so it's not possible to say exactly what any specific phone had taken from it.
Exposure is not the same as compromise
Browser-based attacks usually have multiple stages: a visitor reaches the site, the script profiles the device, an exploit is attempted, malicious code runs, and data is accessed or transmitted. A report can show that some of those stages occurred as part of a campaign without proving that every stage happened for every visitor.
That's why you shouldn't assume your phone was hacked just because you visited a domain mentioned in reporting. On the flip side, not noticing obvious symptoms doesn't prove your device is clean. Mobile spyware may not cause a dramatic crash, pop-up, or sudden battery drain - and most users won't have enough local evidence to diagnose a sophisticated intrusion on their own.
If sensitive accounts or diplomatic work were involved, treat this like an incident. Preserve relevant details, contact the organization's security team, and use a trusted device for account recovery. Changing passwords from a phone that might be compromised can help, but it shouldn't be the only response if session tokens or device data might have been exposed.
What should iPhone and Android users do now?
The simplest defense is to keep your operating system and browser up to date. This campaign reportedly relied on flaws that had already been patched, so skipping updates can leave you exposed to attacks that newer software would block. Turn on automatic updates when it fits your device-management setup, and check from time to time that updates are actually installing - not just that the setting is enabled.
If you visited one of the lookalike domains named in the report, what you should do depends on your situation. For most people with a fully updated phone, there may be no evidence of compromise and no reason to assume the worst. If you were on an older device, received an invitation or sign-in request from the site, or you handle sensitive work, report the visit to your security or IT team and follow their incident process.
A practical response checklist
- Update the phone and browser. Install available security updates through the device's normal settings. If a device no longer receives security updates, don't use it for sensitive accounts.
- Don't go back to the suspicious page. Close it and contact the organization using a known app, saved contact, or a separately verified address. Don't rely on how the page looks.
- Review account sessions. If you accessed accounts after visiting the suspicious domain, sign out other sessions where the service supports it. Change credentials using a trusted device if you think your account may be exposed.
- Use multi-factor authentication. Choose phishing-resistant options when available. MFA lowers the risk from stolen passwords, but it may not invalidate a session cookie that was already taken.
- Escalate high-risk cases. People working in government, diplomacy, journalism, or other sensitive roles should notify their security team quickly. A managed investigation is usually more useful than installing an unverified "cleaner" app.
Also, don't rely on antivirus scans as a definitive answer. Mobile security tools can help with some threats, but they can't guarantee that a sophisticated exploit didn't run or that stolen session data has been revoked. A factory reset may remove some persistence mechanisms, but it can also destroy evidence and still leave exposed accounts or credentials behind. If the risk is significant, take those steps with guidance from a qualified security team.
What should organizations learn from the campaign?
The sites in this report were useful to attackers because they offered credible context. A recognizable public event can support a believable invitation, and a prominent hotel can be relevant to people traveling for government or diplomatic business. The lesson isn't that organizations should avoid public events or high-profile websites. The lesson is that a brand, venue, or campaign can be borrowed by a lookalike domain.
Organizations with public-facing websites should build domain monitoring into their security process. Lookalike registrations aren't always preventable, but early detection can give communications and security teams time to assess risk and warn the audiences likely to be targeted. Monitor newly registered domains that resemble official names, and pay attention to unexpected DNS or certificate changes. Then decide up front who escalates when something looks wrong.
Website operators also need to check what users actually receive in their browsers. Review third-party scripts, limit unnecessary code, monitor for integrity changes, and investigate unexpected changes in traffic. A content management system can look normal while a compromised plugin, hosting account, or upstream service alters what the browser gets. Testing from an external network can catch problems that reviewing only the source repository misses.
Prepare for the human part of the attack
Even good technical controls won't help if staff are left to improvise when someone receives a suspicious invitation. Set up a simple reporting route and tell employees what to include: the domain, approximate time, device type, whether they entered credentials, and any files or prompts they interacted with. That gives security teams evidence without turning ordinary users into forensic investigators.
For organizations managing phones, enforce supported operating system versions and make update compliance visible. Separate administrative access from everyday browsing where possible, and ensure account owners can revoke sessions quickly. If a visitor-facing campaign ties to a public event, coordinate security and communications teams so impersonation reports can be verified and shared accurately.
There's always a trade-off between coverage and friction. Blocking every unfamiliar site can disrupt real work; allowing everything without monitoring pushes the burden onto users to spot subtle imitations. A workable approach usually looks like: keep devices updated, set sensible browsing controls, monitor domains, and have a response path that can start quickly when targeting seems credible.
Conclusion
This campaign shows why mobile security isn't only about avoiding suspicious apps. A familiar-looking website can be used to profile a phone and attempt an exploit, especially when the device has missed security updates. Researchers described attempts to steal cookies and, in some cases, Wi-Fi passwords and device data, but they didn't establish that every visitor was compromised.
Keep devices updated, verify domains when interactions are sensitive, and report credible exposure through the right security channel. For organizations, monitor lookalike domains and the code users actually receive. These steps don't stop every targeted attack, but they cut down on avoidable exposure and make it easier to contain a suspected incident.