❌

Visualização normal

Antes de ontemStream principal
  • ✇Cybersecurity News
  • APT29 Uses Watering Holes and Plerdy Tracker to Deploy Mobile Exploits Do Son
    Sekoia uncovered an APT29 watering hole campaign mobile exploits operation using Plerdy analytics and watering holes to compromise unpatched phones. Related Posts: Suspected MuddyWater SimpleHelp Campaign Targets Israeli Organizations With Tax Lures mSecure Security Notification Prompts Password Resets Threat Actors Hijack Enterprise AI Models in Costly LLMJacking Cloud Attacks The post APT29 Uses Watering Holes and Plerdy Tracker to Deploy Mobile Exploits appeared first on Daily CyberSecurit
     
  • ✇Security Affairs
  • Russian APT29 Targets Mobile Users with Watering Hole Attacks Pierluigi Paganini
    Russia-linked group APT29 targeted iOS and Android users through hijacked websites and a compromised analytics service. Sekoia says a large-scale watering hole campaign is going after iOS and Android users, and it links the campaign to APT29 (aka SVR group, Cozy Bear, Nobelium, BlueBravo, Midnight Blizzard, and The Dukes), the Russian group tied to the SVR foreign intelligence service. A watering hole is a site that attackers poison so visitors infect themselves. Sekoia found the campaig
     

Russian APT29 Targets Mobile Users with Watering Hole Attacks

5 de Novembro de 2026, 07:00

Russia-linked group APT29 targeted iOS and Android users through hijacked websites and a compromised analytics service.

Sekoia says a large-scale watering hole campaign is going after iOS and Android users, and it links the campaign to APT29 (aka SVR group, Cozy Bear, Nobelium, BlueBravo, Midnight Blizzard, and The Dukes), the Russian group tied to the SVR foreign intelligence service. A watering hole is a site that attackers poison so visitors infect themselves.

Sekoia found the campaign in mid-October 2026. It involved hacked or cloned high-profile websites in the US, Ukraine, the Czech Republic and Bulgaria. There’s also a supply-chain attack on a Ukrainian web analytics service, Plerdy, loaded by thousands of websites, most of them Ukrainian.

The attackers used three different methods to reach victims, but all led to the same malicious payload. They injected JavaScript into hacked websites, created fake websites that copied legitimate ones and secretly added malicious code, and compromised the Plerdy analytics service to infect websites using its script.

APT29 Watering Hole

Sekoia first spotted the campaign on the website of a Ukrainian gas production company. Other compromised sites included a major US chemical industry association, a European far-right political party and a Bulgarian website linked to the military. In the Bulgarian case, attackers modified an existing JavaScript library without changing the website’s visible pages. Researchers found no clear pattern in the targeted organizations, although they believe some websites may have been selected to reach specific individuals.

Sekoia also identified two fake websites designed to impersonate legitimate services. One copied America250, the US initiative marking the country’s 250th anniversary, while another reproduced the website of Raffles London at The OWO, a luxury hotel close to the UK Ministry of Defence and Downing Street.

“The second website, theowo[.]club, now offline, acted as a reverse proxy for the website of Raffles London at The OWO, a prestigious luxury hotel housed in the historic Old War Office building.” reads the report published by Sekoia. “The hotel’s location is particularly noteworthy because of its proximity to some of the United Kingdom’s most sensitive government institutions, including the Ministry of Defence and 10 Downing Street, the official residence and office of the British Prime Minister.”

The hotel connection is particularly interesting because Ukrainian President Volodymyr Zelensky reportedly stayed there during a visit to London on October 14. Sekoia believes the fake website may have been used to target diplomatic delegations through spear-phishing, but stresses that this remains an unconfirmed possibility.

Between August 27 and September 3, 2026, the attackers compromised the Plerdy tracker at a.plerdy[.]com. For a week, visitors loaded both Plerdy’s script and the attackers’ profiling script. Several affected sites relate to the military and military recruitment, including army, special forces and military equipment websites.

“Between 27 August and 3 September 2026, the intrusion set compromised the Ukrainian Plerdy analytics tracker hosted under the domain a.plerdy[.]com, which is loaded by thousands of websites, the large majority of them Ukrainian.” reads the report. “It remains unclear whether the attackers intended to target visitors to specific websites or sought to compromise as many unpatched mobile devices as possible, indiscriminately exfiltrating data before selectively identifying and exploiting information of interest.”

Sekoia can’t say whether the aim was specific visitors or as many unpatched phones as possible, with the sorting done later. It also considers that the attackers may have used Plerdy after failing to inject code directly into Ukrainian high-value sites that relied on it. The Plerdy payload pointed to a load-balancing domain that sent traffic across several delivery servers.

The profiling script, which the attackers call UltimateFingerprinter, is attached to a minified AngularJS library that makes up 98 percent of a 2.3 MB file. Sekoia thinks that bulk might stop analysis by large language models, or make the script look legitimate. The script runs 61 collectors that build 394 fields, then sends them to a server that decides whether to answer with exploit code.

Strangely, almost none of that data matters. Only implausible screen sizes, like 99999, or a device reporting zero touch points block delivery. Sekoia doesn’t know why the attackers collect so much and sees no sign the data was used later.

Sekoia pulled three exploit chains from the delivery server. Class A hits iOS 16.7 and steals cookies. Class B hits iOS 18.5 and takes full device data. Class C hits Android Chrome versions 139 to 145, minus 143 for reasons Sekoia can’t explain, and steals Chrome cookies and Wi-Fi passwords.

“During the investigation, we tested different browser profiles against the fingerprinting endpoint at static[.]flux-telemetry[.]com in order to retrieve the exploits served to visitors.” states the report. “This allowed us to retrieve three complete exploit chains (afternamed A, B and C), along with their final payloads, targeting both Android and iOS. Here is a summary of what we found:”

Class B is DarkSword, which Sekoia describes as a suspected iOS exploit kit from a commercial surveillance vendor, uploaded to VirusTotal in September 2026. It takes text messages and iMessages, Mail indexes, voicemail, WhatsApp and Telegram databases, Keychain passwords and tokens, account credentials and Wi-Fi keys. It also takes contacts, call history, calendar, notes, Safari history and cookies, location caches, Health data, photos and iCloud Drive.

The Android payload, which Sekoia calls AndroSnitch, collects Chrome cookies, saved logins and history, plus Wi-Fi settings. It stops on one phone model, the Samsung Galaxy S25 Ultra. It resembles a 2024 payload that Google TAG documented, called AndroSnatch, but the sample is too small to prove lineage. The iOS cookie chains set a marker cookie meant to block reinfection for a day, but a coding mistake makes it expire in a minute.

All stolen data goes to ad.starx-net[.]com:8881/telemetry/v12. None of the chains persist on the device. All of them rely on known flaws, and none uses a zero-day.

For attribution, Sekoia has several threads. A CERT said a compromised site’s backend files held traces matching a private report on a 2025 APT29 watering hole campaign, and Google TAG said the framework resembles an APT29 campaign against Mongolian government websites in 2024. Victims also skew to Europe and the US with a focus on Ukraine, infrastructure sits across multiple hosters, and a hacked Czech far-right site fits APT29’s record of targeting European political parties. It rates the link moderate to high confidence, and it’s coordinating with the CERTs of affected countries.

The campaign shows how exploit kits move down the market. Sekoia says state-backed groups keep reusing frameworks from commercial surveillance vendors such as DarkSword, and that packaged exploit chains lower the cost and skill needed for advanced mobile attacks. It expects such reuse to become more frequent.

The good news is that Sekoia’s attackers don’t have fresh tricks. Every flaw was fixed by its vendor before the campaign began, and none works against fully updated devices.

“None of them contain zero-days or work against fully updated devices. Each flaw was resolved by the respective vendor before this campaign began. This operation targets unpatched devices using n-days; a user running an up-to-date operating system is safe from these attacks.” concludes the report.

“This watering hole campaign, which we assess with moderate to high confidence to be linked to APT29, combines multiple web delivery vectors with n-day mobile exploit chains targeting Android and iOS devices. Across the directly compromised websites, no single sectoral targeting pattern emerges from our analysis. While the victimology shows a focus on Ukraine and the United States, the inclusion of unrelated entities such as an Australian medical clinic complicates a broad strategic interpretation. However, we assess that these websites may have been selected to profile and infect specific individuals of interest based on targeting intelligence to which we do not have visibility. The operators adapted by deploying Adversary-in-the-Middle-ish to intercept visitors associated with diplomatic or high-profile events.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, APT29)

  • ✇Security Affairs
  • U.S. CISA adds Apple flaw to its Known Exploited Vulnerabilities catalog Pierluigi Paganini
    U.S. Cybersecurity and Infrastructure Security Agency (CISA) adds Apple flaw to its Known Exploited Vulnerabilities catalog. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added an Apple flaw, tracked as CVE-2024-27834 (CVSS score of 5.5), to its Known Exploited Vulnerabilities (KEV) catalog. “This type of vulnerability is a frequent attack vector for malicious cyber actors and poses significant risks to the federal enterprise.” reads the advisory by CISA. CVE-2024-27
     

U.S. CISA adds Apple flaw to its Known Exploited Vulnerabilities catalog

5 de Novembro de 2026, 05:55

U.S. Cybersecurity and Infrastructure Security Agency (CISA) adds Apple flaw to its Known Exploited Vulnerabilities catalog.

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added an Apple flaw, tracked as CVE-2024-27834 (CVSS score of 5.5), to its Known Exploited Vulnerabilities (KEV) catalog.

“This type of vulnerability is a frequent attack vector for malicious cyber actors and poses significant risks to the federal enterprise.” reads the advisory by CISA.

CVE-2024-27834 is a security vulnerability affecting Apple’s operating systems and Safari. It could allow an attacker who already has arbitrary read and write capabilities on a device to bypass Pointer Authentication (PAC), a hardware-based security mechanism designed to protect memory addresses and prevent certain types of memory-corruption attacks.

Pointer Authentication is a security feature implemented in Apple processors. It adds cryptographic signatures to pointers, helping ensure that memory addresses have not been maliciously modified.

An attacker who gains the ability to read and write arbitrary memory could potentially exploit CVE-2024-27834 to circumvent these protections. This could weaken an important security barrier and make further exploitation of the device easier.

What is the impact?

  • Bypassing Pointer Authentication protections.
  • Weakening defenses against memory-corruption attacks.
  • Potentially facilitating further exploitation when combined with other vulnerabilities.

Apple addressed the vulnerability through improved security checks in:

  • Safari 17.5
  • iOS 16.7.8 and iOS 17.5
  • iPadOS 16.7.8 and iPadOS 17.5
  • macOS Sonoma 14.5
  • tvOS 17.5
  • watchOS 10.5

Cybersecurity firm Sekoia reports on attacks attributed with moderate to high confidence to Russia-linked cyberespionage group APT29. Attackers used compromised websites, fake websites and a supply-chain compromise of Plerdy SEO Tracker to deliver malicious JavaScript. The zero-click exploit chain targeted Safari and Chrome vulnerabilities to bypass security protections and deploy information-stealing malware capable of collecting browser cookies and device data.

“Achieving arbitrary read/write access within the renderer is no longer sufficient for full exploitation on modern Apple silicon. This architecture relies on Pointer Authentication Codes (PAC) to cryptographically sign control-flow pointers. Because of this, even if an attacker can manipulate memory, they cannot simply overwrite a function pointer to hijack the execution flow, triggering an improperly signed pointer will crash the process rather than execute the payload.” Sekoia writes. “To overcome this mitigation and forge the valid pointers required for arbitrary code execution, the exploit chain incorporates a PAC bypass utilizing CVE-2024-27834.”

According to Binding Operational Directive (BOD) 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities, FCEB agencies have to address the identified vulnerabilities by the due date to protect their networks against attacks exploiting the flaws in the catalog.

Experts also recommend that private organizations review the Catalog and address the vulnerabilities in their infrastructure.

CISA orders federal agencies to fix the flaw by November 18, 2026.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, CISA)

  • ✇Cybersecurity Blog | SentinelOne
  • How SentinelOne Blocked APT29's CaptiveCrunch Campaign SentinelOne
    Once the corporate network stopped being defensible, the control had to move to the device, as SentinelOne® has long argued.That move carried one assumption with it. Wherever the laptop sits, name resolution tells it the truth and the agent can reach its own cloud. Almost nothing in the stack checks either half.In July 2026, Microsoft disclosed a campaign that breaks both and named it CaptiveCrunch. A captive portal is the sign-in page a public Wi-Fi network pushes in front of you before it lets
     

How SentinelOne Blocked APT29's CaptiveCrunch Campaign

16 de Outubro de 2026, 15:01

Once the corporate network stopped being defensible, the control had to move to the device, as SentinelOne® has long argued.

That move carried one assumption with it. Wherever the laptop sits, name resolution tells it the truth and the agent can reach its own cloud. Almost nothing in the stack checks either half.

In July 2026, Microsoft disclosed a campaign that breaks both and named it CaptiveCrunch. A captive portal is the sign-in page a public Wi-Fi network pushes in front of you before it lets you online. Hotels, airports, conference centres, the splash screen you click through without reading. That is where this campaign starts.

CaptiveCrunch is the work of APT29, the cyber-espionage arm of Russia's Foreign Intelligence Service. Microsoft tracks the group as Midnight Blizzard, and elsewhere it is Cozy Bear. Outside the industry it is best known for the SolarWinds compromise.

We saw the same operation from the endpoint, across multiple environments we protect in three regions. We also found the adversary answering from inside the victims' own networks, which no public account of the campaign describes.

The Adversary Was on the Victim's Own Network Segment

Public accounts of CaptiveCrunch describe compromised captive-portal infrastructure, but our telemetry shows something narrower. The DnsPoison indicator recorded LLMNR responses on UDP/5355 carrying the adversary's address on roughly a third of affected hosts.

The queries carried randomised canary hostnames. LLMNR is link-local multicast that does not traverse routers. Anything answering those queries had to be sitting on the victim's own broadcast domain.

A Responder-style spoofer was sitting on the shared network, and no DNS server anywhere in the chain was compromised.

The techniques in play:

  • T1557.001 (LLMNR/NBT-NS Poisoning and SMB Relay)

  • T1557 (Adversary-in-the-Middle)

  • T1659 (Content Injection), for the fake updates served in response to connectivity checks

  • T1584.008 (Compromise Infrastructure: Network Devices), per public accounts, for the captive portal gateways

From the same layer-two segment as the laptop, the spoofer raced the legitimate resolver and won often enough to matter. Across affected hosts, clean and poisoned answers for the same domain interleaved seconds apart.

Success rates ranged from 5.6% to 84% depending on the network. The spoofer replayed the genuine CNAME chain and rewrote only the terminal A record.

Then Windows delivered the lure itself. To check whether a network needs a sign-in page, Windows fetches a known file over plain HTTP. If the reply is not what it expects, it assumes a captive portal and opens the default browser for sign-in. All of that is documented behaviour.

An adversary who rewrites the reply on-path gets the operating system to open the browser at their page. The lure needed no email and no link, but everything after that still needed a person at the keyboard.

The payload was a browser updater matched to the victim's own browser. Microsoft documented ClickFix-style lures for this campaign. In those, the victim is walked through running a command. We saw no such lure on our endpoints, where downloading the file and launching it was manual every time.

Nothing you own sits in the path on someone else's LAN, so the control has to live on the host.

Disable LLMNR. It is the best host control and also the bluntest. It takes away the protocol the adversary is answering on, which no detection rule can do. LLMNR's fallback is rarely load-bearing in a managed estate.

Why the Usual Controls Were Not In the Path

The attack runs on someone else's network, so your network controls are not involved. Your DNS filtering is not involved either, because the spoofer forges answers on the wire before trusted resolvers respond.

The browser renders the lure because Windows told it to. The chain has no email, link, attachment, or scripting host in it.

There is also almost no behaviour to detect, because everything dangerous about this payload happens after a process is created. Before that, nearly every step belongs to the operating system or the network. That is not the kind of behaviour a detection engine is built to catch.

The payload is CornFlake, a Go remote access trojan. CornFlake in turn deploys ChocoShell, a PowerShell infostealer that runs entirely in memory. Microsoft's analysis of the same payload itemises what each of them does.

CornFlake, on the host:

  • Surveillance: A raw-input keylogger, clipboard monitoring, on-demand screenshots, microphone and webcam capture, and USB monitoring.

  • Persistence: Service registration, Run keys, and scheduled tasks, with a watchdog to restore whatever a defender removes.

ChocoShell, deployed by CornFlake and resident only in memory:

  • Cookie theft: Live cookie extraction from browser process memory and a defeat for Chrome's App-Bound Encryption.

  • Token theft: Microsoft 365 and Entra ID tokens lifted from the Token Broker cache.

  • Evasion: It disables AMSI through .NET reflection and runs a timing-based check for sandboxes and virtual machines before collecting anything.

  • Escalation: It chains three UAC bypasses in fallback order through the SilentCleanup task, wsreset.exe, and sdclt.exe.

Until it runs, the file sits inert in Downloads.

Deciding Locally, On the File, Before it Runs

The adversary controlled the network the laptop sat on and had cut the agent's path to its cloud. That left the file, judged on the agent with nothing else in the loop.

The agent convicted every copy that landed, each before it could execute. That is one hundred percent of delivered payloads in one hundred percent of affected environments. We verified both figures twice against the telemetry. One endpoint ran an agent nearly a year out of date and reached the same verdict as current ones.

Then we tested for the things that would mean we were wrong. Every check came back empty:

  • No process creations from the Downloads folder on any affected host

  • No adversary-attributable persistence

  • No lateral movement

  • No post-incident C2 contact

  • No payload hashes remaining

What It Looked Like in the Console

The investigating analyst recorded his screen while walking the Storylines on the endpoint where the payload came closest to running.

Because the Storylines are scattered across the campaign, he worked in two views. One was the management console, and the other was the Threat Operations Center, which clusters the same events more legibly.

Storyline 1: Delivery, With the Poisoning Visible On One Screen

It opens with Windows launching Edge with the connectivity-check URL as its argument.

apt29-blog_1.jpg

Scroll into the DNS events on that same Storyline and the race is sitting there in plain view. One request for a domain resolves to a legitimate address. Scroll down, same domain, and it resolves to the adversary's address.

The same name was answered both ways, minutes apart, on one machine. Only injection racing a real resolver produces that pattern. Later comes the download, a browser updater with a (5) suffix on its filename.

The suffix means the browser had already written four earlier copies to the same folder. Our analyst took that to mean someone kept going back for it and tried to run the last one.

Deep Visibility does not record mouse clicks. Manual launching is an inference from the filename and the process chain, and we are flagging it as one.

Storyline 2: A Token Request While the Login Domain Was Poisoned

A different Storyline shows connections out to the adversary's address. Follow the URL events and the timing lines up with the delivery window.

The request is a POST to the OAuth token endpoint. Open the DNS events on that same Storyline, and the Microsoft login domain is already resolving to the adversary's address.

apt29-blog_6.jpgapt29-blog_7.jpgapt29-blog_8.jpgapt29-blog_9.jpg

We can confirm token requests were issued while the poisoning was active, to a login domain resolving to the adversary. We cannot confirm what happened to them. Endpoint telemetry records the intended destination of a request, not the outcome of the TLS handshake. That handshake content is not something we have or can obtain.

Across the campaign there were 49 such requests. On one endpoint they began roughly 24 hours before any payload arrived, on another ten minutes before. Roughly half of the affected endpoints saw poisoning and no payload at all. That is a reasonable sign the malware was never the sole objective.

Storyline 3: The Verdict

It starts with the launch attempt, from the same browser process that had carried the operation from the start.

Static AI caught the download attempts, and the agent quarantined the file. On the launch attempt, the console records the payload blocked before launch and quarantined in under 100 milliseconds. It names the engine and the detection type on that event.

apt29-blog_11.jpg

Earlier in the same sequence, Static AI convicted a .crdownload, the partial file a browser writes mid-download. That file was not named .exe, was not complete, and carried a partial hash rather than the payload's finished one.

apt29-blog_12.jpg

Static AI read its structure and reached a verdict while the file was still arriving. It needed no signature, finished artifact, or lookup. The later (5) suffix shows the downloads kept coming. Nothing that landed ever ran.

Hunting for the Pattern, and the Identity Question the Endpoint Cannot Answer

Every behavioural signal missed at least one confirmed victim. Only two signals fired on every affected endpoint: the adversary's address and the poisoned DNS answer. Both depend on one address the operator can rotate at will.

Run these steps as a scheduled threat hunt rather than as a detection rule. Most of the work is correlation that costs something to run.

Primary Hunt: One Address Answering for Unrelated Domain Owners

Count distinct registrable domains (eTLD+1) spanning unrelated vendor ecosystems that resolve to the same public address. In our test against roughly ten thousand IPs and domains from affected environments, two surfaced, and both were the adversary.

  1. Take DNS resolution events across the hunt window, keeping the queried name and the answered address.

  2. Drop answers in private and carrier-grade ranges.

  3. Reduce each queried name to its registrable domain using the Public Suffix List.

  4. Group by answered address and count distinct registrable domains.

  5. Map each registrable domain to its owning organisation and count distinct owners per address.

Step five separates a CDN from the adversary. An address answering for many domains owned by one organisation is a CDN. An address answering for many unrelated owners is not anything legitimate.

Counting raw answers instead fires on 389 of 9,375 addresses at a threshold of five. Azure Front Door and Cisco Umbrella top that list, and this hunt must never alert on that traffic.

Azure Front Door answers for azure.com, office.com, live.com, and microsoft.com. The adversary's address answered for Adobe, Apple, Akamai, AnyDesk, BeyondTrust, Brother, Microsoft, and roughly 128 others.

This hunt surfaced nearly a third of the endpoints we confirmed. No alert had flagged any of them. It runs across whole accounts, so it reaches machines beyond the ones you have already been handed.

Supporting inputs, weaker alone and useful in combination:

  • An LLMNR response carrying a non-RFC1918 address. Expect travel noise, since some hotel and carrier networks hand out addressing outside RFC1918 that is odd but harmless.

  • wpad.[your domain] resolving to a non-RFC1918 address.

  • The connectivity-check URL in a browser command line, followed within sixty seconds by an executable or .crdownload in Downloads.

  • Failed _ldap._tcp SRV lookups for your own domain controllers in the same window, placing the machine outside your own network.

If your staff roam, review the identity side for any suspected exposure window. Look for sign-ins from unfamiliar infrastructure, anomalous token issuance, and unexpected device registrations. Check there for what happened to the token requests.

Why the File Verdict Held

The agent convicted every copy of the file, on current and year-old agents alike. It did so while the adversary answered DNS for our own cloud endpoints in two regions. The network was the adversary's, down to the answer the agent received when it tried to reach its own console.

Static AI ships inside the SentinelOne agent. It reads a file's structure and reaches a verdict on the endpoint, without a signature update or a cloud round-trip. The Singularity™ Platform is built that way on purpose, because an agent cut off from its cloud needs a verdict.

APT29 showed here that it can cut an agent off from its cloud. Test what renders a verdict on your endpoints when the network is hostile and your console is unreachable. If it requires a lookup, that is your gap.

Third Party Disclaimer:

All third-party product names, logos, and brands mentioned in this publication are the property of their respective owners and are for identification purposes only. Use of these names, logos, and brands does not imply affiliation, endorsement, sponsorship, or association with the third-party.

❌
❌