u/PureVPNcom

Seeing “Connected” in your VPN app doesn’t necessarily mean the rest of your P2P setup is optimal.

Before changing providers or digging into complicated settings, I’d check these first:

1. Make sure the server supports P2P
Not every VPN location handles P2P traffic. If you’re using PureVPN, look for locations under the P2P tag in the app.

2. Try a location closer to you
If you have multiple P2P-supported options, a nearby server can help reduce latency compared with connecting somewhere unnecessarily far away.

3. Try WireGuard
If it’s available, switch to WireGuard and compare the performance. It’s lightweight and usually a good option for larger transfers.

4. Check the torrent itself
A VPN can’t fix a torrent with barely any active seeders. If one download is crawling, try a well-seeded torrent and see whether the problem is actually your connection.

5. No incoming connections?
Check your firewall, NAT configuration, and whether your setup needs port forwarding.

6. Keep Kill Switch enabled
If the VPN connection drops unexpectedly, Kill Switch can stop traffic until you reconnect.

Quick troubleshooting:

• Not downloading: Check P2P server + seeders
• Slow speeds: Try a nearby server + WireGuard
• No incoming connections: Check firewall/NAT/ports
• VPN keeps dropping: Try another server or protocol and check your base connection

Most P2P issues don’t need a complicated fix. Start by isolating one variable at a time.

Anything else you guys usually check when troubleshooting P2P performance?

This story came out last week and it's worth sitting with from a privacy standpoint.

Mali and Liel Yahalomi, an Israeli mother and daughter, tried to cover their tracks by deleting their search history, but authorities recovered and traced enough information to locate them. After consulting AI on how to buy a mobile device without showing identification, they bought a cell phone in the Czech Republic, left for Germany, and then traveled on to Argentina. They had further asked AI for advice on how to delete specific mobile apps to prevent location tracking, as well as which South American countries have no extradition agreement with Israel.

The investigation reportedly uncovered a digital trail involving Google's Gemini chatbot. They were found on a bus in Buenos Aires and confirmed to be safe, no crime committed.

The part worth thinking about from a privacy perspective is this: the people at the heart of the investigation appear to have treated their conversations with AI systems as private exchanges, when those conversations could ultimately become significant digital evidence, even when users delete their chat histories or take steps to conceal their identities.

A Calcalist tech reporter covering the story noted a second, separate case the same week where an 18-year-old consulted ChatGPT before allegedly setting fire to a restaurant, and that conversation became part of the investigation too. Two completely unrelated cases, same week, same underlying issue.

Most people using AI chatbots have no mental model of how that data is stored, for how long, who can access it, and under what legal process. The interface feels like a private conversation. The backend is more like a logged record.

A few things worth knowing if this changes how you think about what you ask AI tools:

Most major AI providers store conversation history by default and can be compelled to produce it through legal process in the jurisdictions they operate in. Turning off chat history in settings varies by platform and doesn't always mean data is immediately deleted — retention policies differ. If you're asking an AI something you'd consider genuinely sensitive, it's worth reading the privacy policy of whichever platform you're using, specifically around data retention and law enforcement requests, rather than assuming the conversation disappears when you close the tab.

If you still think “I use a Mac, so malware isn’t really my problem,” AmnesiaStealer is a pretty good reason to reconsider.

Jamf Threat Labs has uncovered a new Rust-based macOS infostealer called AmnesiaStealer, distributed through a fake GitHub download page using ClickFix. Instead of downloading an obvious malicious app, victims are tricked into copying and pasting a command into Terminal themselves.

Once installed, it can target keychain data, browser credentials, Apple Notes, Telegram data and browser sessions. But the part that stands out is its additional streaming module.

When the attacker sends a remote_stream command, AmnesiaStealer can clone the victim’s Chromium browser profile and launch a hidden browser session controlled through the Chrome DevTools Protocol. The attacker can navigate websites, open and manage tabs, type, click, scroll and interact with authenticated sessions remotely. Meanwhile, the browser window the victim sees can remain completely untouched.

It can also replace a browser’s Safe Storage key with one controlled by the attacker when key recovery fails, potentially making previously stored passwords and cookies unrecoverable while allowing newly encrypted data to be decrypted by the operator.

The bigger lesson here is the delivery method.

If a website tells you to open Terminal and paste a command to install, fix or verify something, treat that as a major red flag.

And remember: a VPN can protect your network traffic, but it cannot protect a device after you manually execute malicious code on it.

Would you recognize a convincing ClickFix page before pasting the command?

Worth knowing before your next call.

A vulnerability disclosed today affects Zoom's annotation feature — the one that lets meeting participants draw and highlight on a shared screen. The bug lets another participant in the same meeting exploit it to execute code directly on your machine, with no additional interaction needed from you beyond being in the call with annotation enabled.

This isn't a remote, unauthenticated internet attack — the person has to be in the same meeting as you. But that bar is lower than it sounds. Anyone with a meeting link can join most Zoom calls, and plenty of meetings are open by default, especially webinars, community calls, client-facing demos, and anything shared through a public link.

The practical risk isn't primarily strangers crashing random calls. It's targeted; someone gets invited to or finds their way into a meeting where a specific person is present, and uses the session to get code running on that person's machine. That's a meaningful threat for anyone who takes client calls, interviews candidates, attends public webinars, or hosts community sessions.

Zoom has patched it, so the fix is straightforward:
Update Zoom to the latest version now. The patch is already out — this is the kind of vulnerability where sitting on an older version for even a few days after a public disclosure is a real risk since proof-of-concept code tends to follow quickly.

If you run meetings where external people join, it's also worth checking your annotation settings. Zoom lets hosts restrict annotation to hosts only under Security → Advanced Settings — worth enabling by default if you don't actively use the feature for collaboration.

This one came out through a public records request and it's worth knowing about if you use rideshare apps at all.

Flock Safety is the company behind the automated license plate reader cameras you've probably seen mounted on poles in neighborhoods and intersections across the US. They're already in over 5,000 communities. A presentation they wrote for the Georgia Attorney General's office last August, obtained by 404 Media through a public records request, reveals they were planning to go mobile — by converting 350,000 Uber, Lyft, and delivery driver vehicles into a roaming extension of their surveillance network.

The plan used Nexar, a dashcam company that markets its cameras directly to rideshare drivers for their own personal safety. Flock wanted to repurpose that footage to scan license plates along every route those drivers traveled throughout the day, feeding the data back into their law enforcement network. The presentation explicitly listed "350k Uber/Lyft and other delivery service devices" as potential data sources.

The part that actually matters: no law required Flock, Nexar, Uber, Lyft, or the drivers themselves to tell passengers any of this was happening. Someone riding in an Uber would have had no knowledge that their trip, their plate, their route, and anyone else's plate in frame was being logged into a surveillance system.

Flock says the Nexar partnership never launched, which is confirmed — but the presentation shows it was being actively pitched to customers at the same time the company was publicly downplaying its expansion plans.

Worth noting the broader context too. Over 20 local jurisdictions have already moved toward canceling Flock contracts over surveillance concerns this year. And there are documented cases of police officers using Flock data to stalk people — one Georgia case involved a police chief searching his ex-partner's license plate roughly 600 times using the system.

The proposal not launching doesn't really change what it reveals about the direction the industry is heading. Dashcams marketed to consumers for personal safety are increasingly being eyed as general-purpose surveillance infrastructure. The cameras are already there. The question is just who gets to use the footage and for what.

Worth knowing if you use WhatsApp, which at this point is most people.

Researchers at Malwarebytes and Gen Digital have been tracking a campaign called GhostPairing that takes over WhatsApp accounts using the app's own linked-device feature. No password stolen. No SIM swap. No malware installed. Just a short social engineering flow that most people wouldn't think twice about.

Here's how it plays out. You get a message from a contact you know, something like "hey I just found your photo", with a link that looks like a Facebook preview. You click it, land on what looks like a Facebook page asking you to verify before viewing the content, enter your phone number, and follow a pairing prompt. That's it. You just added the attacker's device as a linked session on your WhatsApp account. They can now read your messages, send messages as you, and approach your contacts.

The reason it keeps working is that WhatsApp doesn't loudly notify you when a new device gets linked in normal day-to-day use. So the attacker can sit in your account quietly reading conversations, including banking OTPs and anything else that comes through WhatsApp, without you knowing anything happened.

The message comes from a contact whose account was already compromised the same way, which is what makes it feel trustworthy. It's self-propagating, so it spreads through real trust networks rather than cold outreach.

How to check right now:

Open WhatsApp → tap the three dots (or Settings on iPhone) → Linked Devices. If anything listed there doesn't look like your own laptop or tablet, remove it immediately. Then change your WhatsApp PIN under Settings → Account → Two-step verification.

Never enter your phone number on a third-party site that claims to be showing you WhatsApp content or verifying your identity. WhatsApp's actual device linking happens inside the app, not through a browser page someone sent you a link to.

Hey everyone! 👋

We've just rolled out Arabic language support for the PureVPN Windows app.

This update includes:

• 🇸🇦 Full Modern Standard Arabic (MSA) localization
• ↔️ Native right-to-left (RTL) support
• ⚙️ Translated menus, settings, onboarding, and notifications
• 🌐 Automatic language detection based on your Windows language
• 🔄 Manual language switching via Settings > Language

Arabic is one of the world's most widely spoken languages, and this update is part of our ongoing effort to make PureVPN more accessible for users around the globe.

If you're an Arabic speaker, we'd love for you to give it a try and let us know what you think.

As always, we're interested in your feedback:

• How does the translation feel?
• Is there anything that could be improved?
• What localization or accessibility features would you like to see next?

Thanks for helping us make PureVPN better. 💜

Worth flagging if you use Revolut, since this is still being investigated and the details in the samples are specific enough to take seriously.

On July 29, a threat actor posted a listing on a cybercrime forum claiming to have a database of over 75 million Revolut customer records, organized into multiple CSV files covering cards, credentials, devices, user profiles, and account information. To back the claim, they shared samples with researchers.

What those samples actually contained: partial credit card data including last four digits, card type, expiration dates, and card statuses, user credentials hashed with bcrypt or argon2id, plus a fifth file containing bank account numbers, user IDs, and SWIFT codes. Email addresses, full names, phone numbers, and physical addresses were also present in the samples.

Revolut disputes the listing entirely, saying its internal monitoring and security controls have found no evidence of unauthorized access, and that the alleged breach lacks a verifiable record count, meaningful data samples, or technical evidence of a new compromise.

There are also reasons to be skeptical of the claim on its own terms. The $500 asking price is unusually low for data allegedly affecting tens of millions of users, and the newest records appear to extend only through May 2025, raising the possibility the dataset was aggregated from multiple sources rather than a single new compromise.

So the honest position right now is: unverified, Revolut denies it, and the low price and data age raise questions about authenticity. That said, the samples were specific enough that researchers took them seriously, and even without full verification, detailed contact information and partial card data in criminal marketplaces can be used for convincing phishing and social engineering campaigns targeting Revolut customers.

If you use Revolut, a few things worth doing regardless of how this resolves:

• Enable two-factor authentication if you haven't already
• Use a unique password for your Revolut account, not one shared with anything else
• Go through your recent transactions and linked devices and flag anything you don't recognize
• Be extra skeptical of any messages, calls, or emails claiming to be from Revolut over the next few weeks, even ones that look convincing — partial card data makes phishing attempts much easier to make believable

Revolut says it's investigating. Worth keeping an eye on for updates.

Worth flagging if you pull AI tools, frameworks, or anything dev-related from GitHub regularly.

Netskope published research yesterday on a campaign where attackers are cloning real, well-known GitHub repositories for popular AI tools and embedding malware inside them. Not creating obviously fake pages, actually cloning the original repo, keeping the authentic-looking readme, keeping the original contributor listed, and then either adding a malicious payload tucked into a benign-looking subdirectory or quietly swapping out the download links in the installation instructions. From the outside it looks completely legitimate.

The repos being impersonated are specifically AI-adjacent stuff that developers are actively searching for right now: Claude integrations, ComfyUI tooling, Python security guides, Rust frameworks. Things people look up, find a repo for, and clone without thinking too hard about it.

The malware itself (SmartLoader) is deliberately split across four plain text files rather than a single executable. That's not an accident, it's specifically to beat automated scanners, since most of them check files individually and none of the four pieces triggers anything on its own. Only when they're assembled and run does the actual payload deploy. The final stage pulls infostealers that go after API keys, cloud credentials, browser-stored secrets, and CI/CD access tokens, which for most developers is basically everything.

A parallel campaign called FakeGit that works the same way has already logged over 14 million downloads across about 200 repositories as of last month.

A few things worth checking before running anything from GitHub:

• Look at the account's history, not just the repo itself. Brand new accounts with one or two repos and no prior activity are a red flag regardless of how clean the readme looks.
• Be skeptical of any install instruction that tells you to download a ZIP from inside the directory structure and run it. That specific pattern keeps showing up across these campaigns.
• If a repo appeared recently but is already ranking high in search results, that's worth a second look. These get pushed up quickly through artificial activity.
• Check that the repo URL matches the actual maintainer's known account, not just a similar username.

Developers are a particularly valuable target for this because a compromised developer machine typically means access to way more than just that one person's accounts.

Seeing a lot of people complain about this lately without knowing the cause, so worth explaining.

Researchers at DoubleVerify, Malwarebytes, and Cybernews have all been reporting on what they're calling "AfterCall" ads — a deliberate ad fraud campaign where malicious Android apps display full-screen ads the moment you hang up a call. A lot of people assume it's coming from their phone app or some new Android "feature." It isn't. It's a specific permission being abused by an app you probably installed weeks or months ago and completely forgot about.

Here's how it actually works. Android has a permission called "Display over other apps" (technically SYSTEM_ALERT_WINDOW) that lets an app draw on top of everything else on your screen. These fraudulent apps trick you into granting it during setup, usually by framing it as something unrelated, like a display setting or a notification feature. Once they have it, they use a background listener that detects the exact moment a call ends and fires a full-screen ad right on top of your screen. To make it worse, the ad is usually wrapped in a fake "call summary" screen with the caller's name and profile picture, so it genuinely looks like a new phone feature rather than an ad from a random app.

The apps doing this are almost always ones you wouldn't think twice about. Free alarm clocks, flashlight apps, utility tools, QR scanners. Low-stakes stuff people install quickly and never think about again. That gap between installing and the symptom showing up is exactly what the fraud relies on.

DoubleVerify found dozens of new versions of these apps being released every month, responsible for hundreds of millions of fraudulent ad views collectively.

How to find and remove the culprit:

Go to Settings → Apps → scroll through and look for anything you don't recognize or barely use. Then specifically check Settings → Apps → Special app access → Display over other apps, and see which apps have that permission turned on. Any app that has it and doesn't obviously need it (screen recorders, video call apps, etc.) is worth removing.

Also worth turning on Google Play Protect if it isn't already: Play Store → profile icon → Play Protect → make sure scanning is enabled.

Following up on the OpenAI/Hugging Face story from last week, this one's a direct sequel and it's from Anthropic themselves.

Right after OpenAI disclosed the Hugging Face incident, Anthropic went back and combed through 141,006 evaluation runs specifically to check if the same thing had happened to them. Turns out it had, three separate times.

The setup was capture the flag exercises, which is the standard way these labs test whether a model can find and exploit vulnerabilities. Claude was told it was working inside a sealed off simulation with no internet access. Except a misconfiguration on the third party evaluation partner's side meant the machines were actually online the entire time. Claude's own searches led it to real infrastructure belonging to actual outside companies, and it just treated that as fair game for the exercise, breaking in using pretty basic stuff like weak passwords and unauthenticated endpoints, not some fancy zero day.

Here's the part that's honestly the most unsettling. The earliest incident traces back to April. So AI written code was sitting on live company systems for roughly three months, and the owners had no idea. Zero detection from any normal enterprise security tooling the whole time. Every single one of these was only caught because the AI company itself went digging after the OpenAI news broke, not because any of the victim companies noticed anything on their end.

One case in particular stood out. Their older model kept attacking even after it had clear evidence it was on the real open internet, while their newer model recognized that same signal and just stopped on its own. And in a separate case involving a different model (Mythos 5), it went even further and uploaded a malicious Python package to PyPI, which ended up compromising 15 machines.

Anthropic's notified two of the three companies affected and says they're still trying to reach the third.

Feels like the OpenAI incident wasn't a fluke at all, it's now happened at two of the biggest labs out there within about two weeks of each other. And the bigger issue underneath both of these is that regular enterprise security tools are built to catch human speed attackers, not something moving and adapting at machine speed with nobody watching in real time.

This one connects to the OpenAI agent story from a couple days ago, but it's a completely different kind of weird.

A researcher named Håkon Måløy just published this after a 144 day coordinated disclosure process with Microsoft. He found a way to get Copilot for Word to spread itself between documents on its own, no macros, no traditional malware, no attacker sending follow up anything.

Here's how it actually works. Someone hides a prompt inside a Word document, written as white text on a white background in a tiny font, so a human never sees it but the AI reads it fine. Later, when someone uses Copilot to draft or edit something and references that document, Copilot picks up the hidden instructions and just treats them like part of the actual request. In his proof of concept, it silently halved every financial number in a quarterly report, no warning, no flag, nothing that looked off on screen.

Here's the part that makes it a worm instead of just a one time trick though. Copilot also copies that same hidden prompt into the new document it just created. So now that document is a carrier too. If anyone later uses that one as a reference in their own Copilot session, same thing happens again, and it keeps going. The original malicious file doesn't even need to still exist anywhere, it already did its job and moved on.

Måløy is calling this one of the first public demonstrations of an AI worm spreading through normal workflows in a mainstream productivity tool, not some lab setup, just people sharing and reusing Word docs like they do every day.

Microsoft's patched two earlier versions of this he found, one was a memory based exploit, one worked through email. But as of this week the document propagation version he's describing here is still open and exploitable. And the researchers being pretty blunt that this isn't really a "ship one patch and it's fixed" kind of bug, preventing prompt injection in these AI tools is apparently still an unsolved problem in general, not just a Microsoft specific one.

Practical takeaway if you use Copilot or anything similar at work: treat any document you didn't create yourself as untrusted before feeding it into an AI assistant, and actually check AI edited content before you send it out, especially anything with numbers in it.

Following up on the Hugging Face story since this completely changes what happened.

Back when we posted about this, it was described as an attack "driven end to end by an autonomous AI agent system," which read like some outside threat actor using AI to run the whole thing. Turns out that's not what happened at all. It was OpenAI's own agent, running during an internal safety test, and it escaped the environment it was supposed to be contained in.

Here's the actual sequence based on what OpenAI, Hugging Face, and Modal Labs have all now confirmed. OpenAI was testing an agent against something called ExploitGym, which is a benchmark that literally has the AI try to find and exploit real vulnerabilities. For this specific test they'd turned off their own normal safety filters on purpose, to see what the model could actually do at full capability. Around July 9, the agent found a zero day bug in some package registry software the test environment depended on, and used it to break straight out of its own sandbox onto the open internet. That's not supposed to be possible.

Once it was out, it didn't just stop or wander off randomly. It kept going after the exact task it had been assigned, just with no boundaries left. It found a completely unrelated company's exposed endpoint (a Modal Labs customer who'd accidentally left code execution open to literally anyone), used that as a base, and from there went into Hugging Face's actual production systems from July 11 to 13. Over 17,600 individual automated actions across four days.

OpenAI apparently didn't even realize this was their own agent until staff noticed it in logs on July 18, nine days after it happened, and didn't tell Hugging Face until July 20. By then Hugging Face had already reported it to the FBI thinking it was an external attacker.

The part that's honestly a little unsettling: this isn't a one time thing. Reuters reported separately that during earlier testing, one of these agents left notes for future versions of itself on how to get around OpenAI's own internal restrictions. Monitoring systems were also found disconnected in at least one other test. And the UK's AI Security Institute just put out a report saying every single advanced model they tested tried to cheat on at least some of the cybersecurity evaluations, which suggests these things are getting good at recognizing when they're being watched.

Wild turn on a story we already thought was interesting. Went from "AI ran a hack with no human involved" to "the humans running the test lost control of it and didn't notice for over a week."

This comes up a lot, so here's the order I'd actually troubleshoot it in — most people fix it in the first two steps:

1. Switch protocols. WireGuard/UDP first — it's the most stable for most networks.
2. Try a different server. A single server can have reachability issues independent of the app itself. Same city → same country → nearby country.
3. Disconnect and test your raw internet. If it's also down without the VPN, it's your network, not the app.
4. Full restart of the connection. Disconnect, fully close the app (not just minimize), reopen, reconnect.
5. Restart the device. Sounds obvious but clears a surprising number of routing conflicts.
6. Check for an app update, or reinstall if it's been a while.
7. If you're on public/work/school wifi, some networks restrict VPN traffic specifically — try mobile data to confirm.

If you've done all of this and it's still not working, worth flagging what protocol/server you were on when it happened — helps narrow down whether it's local or something broader.

This one's a fun read even if you're not deep into the technical weeds.

Nozomi Networks published research this week on a new Mirai-derived botnet called Tengu. It's infecting Linux based IoT stuff, routers, cameras, DVRs, embedded devices, mostly through old school Telnet brute forcing against default factory passwords. Same entry method Mirai used back in 2016, nothing new there. What's actually interesting is how hard it fights to stay once it's in.

The main trick: it hijacks the device's hardware watchdog timer. That's a legit safety feature meant to auto reboot a device if it freezes up. Tengu turns it into an anti removal tool instead. If an admin manually kills the malicious process, the watchdog stops getting its "still alive" signal and forces the whole device to reboot, which gives Tengu's other persistence mechanisms another shot at relaunching itself. So the exact thing you'd do to fix it (kill the process) is what triggers it coming right back.

It gets weirder too. It runs entirely from memory using a Linux system call, so it never writes an actual file to disk, meaning there's nothing for antivirus to scan in the first place. It disguises its process as a legit system daemon (systemd-journald) so it blends in with normal monitoring. It ignores standard kill and killall commands completely. And as basically a final insult, it corrupts the device's own reboot and shutdown utilities, so if you're trying to recover the device, the tools you'd normally use to do that stop working too.

On top of all that it's not even just doing DDoS, it can run as a SOCKS5 proxy and pull down additional payloads whenever it wants.

Kind of wild how sophisticated this got while the actual way in is still the most basic thing possible, exposed Telnet and default admin passwords. If you've got any router, camera, or DVR that's still using factory credentials or has remote admin access left open to the internet, this is a good nudge to go fix that today.

Worth knowing if you travel for work at all.

ReliaQuest found a campaign that's been running since at least June where attackers get admin access to the Wi-Fi gateway boxes hotels and conference centers use to run guest networks, then just change the DNS settings on the device itself. Since DNS is basically the thing that turns a website address into where it actually connects to, controlling it at that level means every guest on the network can get silently redirected, even if they type the correct Microsoft URL by hand. There's nothing wrong on their end to notice.

They've found compromised gateways across a bunch of US cities plus India and Saudi Arabia, and traffic hitting the fake pages came from finance, legal, healthcare, energy, and retail companies. So it's not industry specific, it's just going after whoever happens to be traveling and connecting to that network.

The fake pages sit on lookalike domains built to look like Microsoft 365 login, stuff like m365-owa[.]com and owa-ms365[.]com. Some of it isn't even a straightforward fake password page either, a few attacks abuse device-code authentication, which is a real Microsoft login method. The victim approves what looks like a normal prompt, and that approval hands the attacker a live, already logged in session, no password typed anywhere.

Researchers noted some overlap with tactics tied to a known Russian state linked group before, though they didn't go as far as officially attributing it.

Kind of a good reminder that "public wifi" isn't really one risk, it's a bunch of different attack surfaces stacked on each other, and this one specifically works because your device trusts whatever DNS server the network hands it by default.