Security

Cybersecurity takes a big hit in new Trump executive order

BGP, Biz & IT, Encryption, executive orders, Policy, post, quantum computing, Security, Trump, White House / Paul Patrick / June 18, 2025

Cybersecurity practitioners are voicing concerns over a recent executive order issued by the White House that guts requirements for: securing software the government uses, punishing people who compromise sensitive networks, preparing new encryption schemes that will withstand attacks from quantum computers, and other existing controls.

The executive order (EO), issued on June 6, reverses several key cybersecurity orders put in place by President Joe Biden, some as recently as a few days before his term ended in January. A statement that accompanied Donald Trump’s EO said the Biden directives “attempted to sneak problematic and distracting issues into cybersecurity policy” and amounted to “political football.”

Pro-business, anti-regulation

Specific orders Trump dropped or relaxed included ones mandating (1) federal agencies and contractors adopt products with quantum-safe encryption as they become available in the marketplace, (2) a stringent Secure Software Development Framework (SSDF) for software and services used by federal agencies and contractors, (3) the adoption of phishing-resistant regimens such as the WebAuthn standard for logging into networks used by contractors and agencies, (4) the implementation new tools for securing Internet routing through the Border Gateway Protocol, and (5) the encouragement of digital forms of identity.

In many respects, executive orders are at least as much performative displays as they are a vehicle for creating sound policy. Biden’s cybersecurity directives were mostly in this second camp.

The provisions regarding the secure software development framework, for instance, was born out of the devastating consequences of the SolarWinds supply chain attack of 2020. During the event, hackers linked to the Russian government breached the network of a widely used cloud service, SolarWinds. The hackers went on to push a malicious update that distributed a backdoor to more than 18,000 customers, many of whom were contractors and agencies of the federal government.

Cybersecurity takes a big hit in new Trump executive order Read More »

Vandals cut fiber-optic lines, causing outage for Spectrum Internet subscribers

Biz & IT, copper, fiber, Security, spectrum, theft / Rejus Almole / June 17, 2025

Subscribers in Southern California of Spectrum’s Internet service experienced outages over the weekend following what company officials said was an attempted theft of copper lines located in Van Nuys, a suburb located 20 miles from downtown Los Angeles.

The people behind the incident thought they were targeting copper lines, the officials wrote in a statement Sunday. Instead, they cut into fiber optic cables. The cuts caused service disruptions for subscribers in Van Nuys and surrounding areas. Spectrum has since restored service and is offering a $25,000 reward for information leading to the apprehension of the people responsible. Spectrum will also credit affected customers one day of service on their next bill.

An industry-wide problem

“Criminal acts of network vandalism have become an issue affecting the entire telecommunications industry, not just Spectrum, largely due to the increase in the price of precious metals,” the officials wrote in a statement issued Sunday. “These acts of vandalism are not only a crime, but also affect our customers, local businesses and potentially emergency services. Spectrum’s fiber lines do not include any copper.”

Outage information service Downdetector showed that thousands of subscribers in and around Van Nuys reported outages starting a little before noon on Sunday. Within about 12 hours, the complaint levels returned to normal. Spectrum officials told the Los Angeles Times that personnel had to splice thousands of fiber lines to restore service to affected subscribers.

Vandals cut fiber-optic lines, causing outage for Spectrum Internet subscribers Read More »

Coming to Apple OSes: A seamless, secure way to import and export passkeys

Apple, Biz & IT, iOS, iPadOS, macOS, Security, wwdc 2025 / Rejus Almole / June 13, 2025

As the video explains:

This new process is fundamentally different and more secure than traditional credential export methods, which often involve exporting an unencrypted CSV or JSON file, then manually importing it into another app. The transfer process is user initiated, occurs directly between participating credential manager apps and is secured by local authentication like Face ID.

This transfer uses a data schema that was built in collaboration with the members of the FIDO Alliance. It standardizes the data format for passkeys, passwords, verification codes, and more data types.

The system provides a secure mechanism to move the data between apps. No insecure files are created on disk, eliminating the risk of credential leaks from exported files. It’s a modern, secure way to move credentials.

The push to passkeys is fueled by the tremendous costs associated with passwords. Creating and managing a sufficiently long, randomly generated password for each account is a burden on many users, a difficulty that often leads to weak choices and reused passwords. Leaked passwords have also been a chronic problem.

Passkeys, in theory, provide a means of authentication that’s immune to credential phishing, password leaks, and password spraying. Under the latest “FIDO2” specification, it creates a unique public/private encryption keypair during each website or app enrollment. The keys are generated and stored on a user’s phone, computer, YubiKey, or similar device. The public portion of the key is sent to the account service. The private key remains bound to the user device, where it can’t be extracted. During sign-in, the website or app server sends the device that created the key pair a challenge in the form of pseudo-random data. Authentication occurs only when the device signs the challenge using the corresponding private key and sends it back.

This design ensures that there is no shared secret that ever leaves the user’s device. That means there’s no data to be sniffed in transit, phished, or compromised through other common methods.

As I noted in December, the biggest thing holding back passkeys at the moment is their lack of usability. Apps, OSes, and websites are, in many cases, islands that don’t interoperate with their peers. Besides potentially locking users out of their accounts, the lack of interoperability also makes passkeys too difficult for many people.

Apple’s demo this week provides the strongest indication yet that passkey developers are making meaningful progress in improving usability.

Coming to Apple OSes: A seamless, secure way to import and export passkeys Read More »

Cybercriminals turn to “residential proxy” services to hide malicious traffic

Bulletproof hosting, cybercriminals, proxies, Security, syndication, vpns / Tim Belzer / June 8, 2025

For years, gray market services known as “bulletproof” hosts have been a key tool for cybercriminals looking to anonymously maintain web infrastructure with no questions asked. But as global law enforcement scrambles to crack down on digital threats, they have developed strategies for getting customer information from these hosts and have increasingly targeted the people behind the services with indictments. At the cybercrime-focused conference Sleuthcon in in Arlington, Virginia on Friday, researcher Thibault Seret outlined how this shift has pushed both bulletproof hosting companies and criminal customers toward an alternative approach.

Rather than relying on web hosts to find ways of operating outside law enforcement’s reach, some service providers have turned to offering purpose-built VPNs and other proxy services as a way of rotating and masking customer IP addresses and offering infrastructure that either intentionally doesn’t log traffic or mixes traffic from many sources together. And while the technology isn’t new, Seret and other researchers emphasized to WIRED that the transition to using proxies among cybercrminals over the last couple of years is significant.

“The issue is, you cannot technically distinguish which traffic in a node is bad and which traffic is good,” Seret, a researcher at the threat intelligence firm Team Cymru, told WIRED ahead of his talk. “That’s the magic of a proxy service—you cannot tell who’s who. It’s good in terms of internet freedom, but it’s super, super tough to analyze what’s happening and identify bad activity.”

The core challenge of addressing cybercriminal activity hidden by proxies is that the services may also, even primarily, be facilitating legitimate, benign traffic. Criminals and companies that don’t want to lose them as clients have particularly been leaning on what are known as “residential proxies,” or an array of decentralized nodes that can run on consumer devices—even old Android phones or low end laptops—offering real, rotating IP addresses assigned to homes and offices. Such services offer anonymity and privacy, but can also shield malicious traffic.

Cybercriminals turn to “residential proxy” services to hide malicious traffic Read More »

Millions of low-cost Android devices turn home networks into crime platforms

Android malware, Biz & IT, Security / Mike M. / June 7, 2025

Millions of low-cost devices for media streaming, in-vehicle entertainment, and video projection are infected with malware that turns consumer networks into platforms for distributing malware, concealing nefarious communications, and performing other illicit activities, the FBI has warned.

The malware infecting these devices, known as BadBox, is based on Triada, a malware strain discovered in 2016 by Kaspersky Lab, which called it “one of the most advanced mobile Trojans” the security firm’s analysts had ever encountered. It employed an impressive kit of tools, including rooting exploits that bypassed security protections built into Android and functions for modifying the Android OS’s all-powerful Zygote process. Google eventually updated Android to block the methods Triada used to infect devices.

The threat remains

A year later, Triada returned, only this time, devices came pre-infected before they reached consumers’ hands. In 2019, Google confirmed that the supply-chain attack affected thousands of devices and that the company had once again taken measures to thwart it.

In 2023, security firm Human Security reported on BigBox, a Triada-derived backdoor it found preinstalled on thousands of devices manufactured in China. The malware, which Human Security estimated was installed on 74,000 devices around the world, facilitated a range of illicit activities, including advertising fraud, residential proxy services, the creation of fake Gmail and WhatsApp accounts, and infecting other Internet-connected devices.

Millions of low-cost Android devices turn home networks into crime platforms Read More »

Two certificate authorities booted from the good graces of Chrome

Biz & IT, certificate authorities, chrome browser, Google, Security / Tim Belzer / June 4, 2025

Google says its Chrome browser will stop trusting certificates from two certificate authorities after “patterns of concerning behavior observed over the past year” diminished trust in their reliability.

The two organizations, Taiwan-based Chunghwa Telecom and Budapest-based Netlock, are among the hundreds of certificate authorities trusted by Chrome and most other browsers to provide digital certificates that encrypt traffic and certify the authenticity of sites. With the ability to mint cryptographic credentials that cause address bars to display a padlock, assuring the trustworthiness of a site, these certificate authorities wield significant control over the security of the web.

Inherent risk

“Over the past several months and years, we have observed a pattern of compliance failures, unmet improvement commitments, and the absence of tangible, measurable progress in response to publicly disclosed incident reports,” members of the Chrome security team wrote Tuesday. “When these factors are considered in aggregate and considered against the inherent risk each publicly-trusted CA poses to the internet, continued public trust is no longer justified.”

Two certificate authorities booted from the good graces of Chrome Read More »

Meta and Yandex are de-anonymizing Android users’ web browsing identifiers

Biz & IT, browsing histories, Features, Meta Pixel, Metrica, privacy, Security, yandex / Rejus Almole / June 3, 2025

Abuse allows Meta and Yandex to attach persistent identifiers to detailed browsing histories.

Credit: Aurich Lawson | Getty Images

Tracking code that Meta and Russia-based Yandex embed into millions of websites is de-anonymizing visitors by abusing legitimate Internet protocols, causing Chrome and other browsers to surreptitiously send unique identifiers to native apps installed on a device, researchers have discovered. Google says it’s investigating the abuse, which allows Meta and Yandex to convert ephemeral web identifiers into persistent mobile app user identities.

The covert tracking—implemented in the Meta Pixel and Yandex Metrica trackers—allows Meta and Yandex to bypass core security and privacy protections provided by both the Android operating system and browsers that run on it. Android sandboxing, for instance, isolates processes to prevent them from interacting with the OS and any other app installed on the device, cutting off access to sensitive data or privileged system resources. Defenses such as state partitioning and storage partitioning, which are built into all major browsers, store site cookies and other data associated with a website in containers that are unique to every top-level website domain to ensure they’re off-limits for every other site.

A blatant violation

“One of the fundamental security principles that exists in the web, as well as the mobile system, is called sandboxing,” Narseo Vallina-Rodriguez, one of the researchers behind the discovery, said in an interview. “You run everything in a sandbox, and there is no interaction within different elements running on it. What this attack vector allows is to break the sandbox that exists between the mobile context and the web context. The channel that exists allowed the Android system to communicate what happens in the browser with the identity running in the mobile app.”

The bypass—which Yandex began in 2017 and Meta started last September—allows the companies to pass cookies or other identifiers from Firefox and Chromium-based browsers to native Android apps for Facebook, Instagram, and various Yandex apps. The companies can then tie that vast browsing history to the account holder logged into the app.

This abuse has been observed only in Android, and evidence suggests that the Meta Pixel and Yandex Metrica target only Android users. The researchers say it may be technically feasible to target iOS because browsers on that platform allow developers to programmatically establish localhost connections that apps can monitor on local ports.

In contrast to iOS, however, Android imposes fewer controls on local host communications and background executions of mobile apps, the researchers said, while also implementing stricter controls in app store vetting processes to limit such abuses. This overly permissive design allows Meta Pixel and Yandex Metrica to send web requests with web tracking identifiers to specific local ports that are continuously monitored by the Facebook, Instagram, and Yandex apps. These apps can then link pseudonymous web identities with actual user identities, even in private browsing modes, effectively de-anonymizing users’ browsing habits on sites containing these trackers.

Meta Pixel and Yandex Metrica are analytics scripts designed to help advertisers measure the effectiveness of their campaigns. Meta Pixel and Yandex Metrica are estimated to be installed on 5.8 million and 3 million sites, respectively.

Meta and Yandex achieve the bypass by abusing basic functionality built into modern mobile browsers that allows browser-to-native app communications. The functionality lets browsers send web requests to local Android ports to establish various services, including media connections through the RTC protocol, file sharing, and developer debugging.

A conceptual diagram representing the exchange of identifiers between the web trackers running on the browser context and native Facebook, Instagram, and Yandex apps for Android.

While the technical underpinnings differ, both Meta Pixel and Yandex Metrica are performing a “weird protocol misuse” to gain unvetted access that Android provides to localhost ports on the 127.0.0.1 IP address. Browsers access these ports without user notification. Facebook, Instagram, and Yandex native apps silently listen on those ports, copy identifiers in real time, and link them to the user logged into the app.

A representative for Google said the behavior violates the terms of service for its Play marketplace and the privacy expectations of Android users.

“The developers in this report are using capabilities present in many browsers across iOS and Android in unintended ways that blatantly violate our security and privacy principles,” the representative said, referring to the people who write the Meta Pixel and Yandex Metrica JavaScript. “We’ve already implemented changes to mitigate these invasive techniques and have opened our own investigation and are directly in touch with the parties.”

Meta didn’t answer emailed questions for this article, but provided the following statement: “We are in discussions with Google to address a potential miscommunication regarding the application of their policies. Upon becoming aware of the concerns, we decided to pause the feature while we work with Google to resolve the issue.”

Yandex representatives didn’t answer an email seeking comment.

How Meta and Yandex de-anonymize Android users

Meta Pixel developers have abused various protocols to implement the covert listening since the practice began last September. They started by causing apps to send HTTP requests to port 12387. A month later, Meta Pixel stopped sending this data, even though Facebook and Instagram apps continued to monitor the port.

In November, Meta Pixel switched to a new method that invoked WebSocket, a protocol for two-way communications, over port 12387.

That same month, Meta Pixel also deployed a new method that used WebRTC, a real-time peer-to-peer communication protocol commonly used for making audio or video calls in the browser. This method used a complicated process known as SDP munging, a technique for JavaScript code to modify Session Description Protocol data before it’s sent. Still in use today, the SDP munging by Meta Pixel inserts key _fbp cookie content into fields meant for connection information. This causes the browser to send that data as part of a STUN request to the Android local host, where the Facebook or Instagram app can read it and link it to the user.

In May, a beta version of Chrome introduced a mitigation that blocked the type of SDP munging that Meta Pixel used. Within days, Meta Pixel circumvented the mitigation by adding a new method that swapped the STUN requests with the TURN requests.

In a post, the researchers provided a detailed description of the _fbp cookie from a website to the native app and, from there, to the Meta server:

1. The user opens the native Facebook or Instagram app, which eventually is sent to the background and creates a background service to listen for incoming traffic on a TCP port (12387 or 12388) and a UDP port (the first unoccupied port in 12580–12585). Users must be logged-in with their credentials on the apps.

2. The user opens their browser and visits a website integrating the Meta Pixel.

3. At this stage, some websites wait for users’ consent before embedding Meta Pixel. In our measurements of the top 100K website homepages, we found websites that require consent to be a minority (more than 75% of affected sites does not require user consent)…

4. The Meta Pixel script is loaded and the _fbp cookie is sent to the native Instagram or Facebook app via WebRTC (STUN) SDP Munging.

5. The Meta Pixel script also sends the _fbp value in a request to https://www.facebook.com/tr along with other parameters such as page URL (dl), website and browser metadata, and the event type (ev) (e.g., PageView, AddToCart, Donate, Purchase).

6. The Facebook or Instagram apps receive the _fbp cookie from the Meta JavaScripts running on the browser and transmits it to the GraphQL endpoint (https://graph[.]facebook[.]com/graphql) along with other persistent user identifiers, linking users’ fbp ID (web visit) with their Facebook or Instagram account.

Detailed flow of the way the Meta Pixel leaks the _fbp cookie from Android browsers to it’s Facebook and Instagram apps.

The first known instance of Yandex Metrica linking websites visited in Android browsers to app identities was in May 2017, when the tracker started sending HTTP requests to local ports 29009 and 30102. In May 2018, Yandex Metrica also began sending the data through HTTPS to ports 29010 and 30103. Both methods remained in place as of publication time.

An overview of Yandex identifier sharing

A timeline of web history tracking by Meta and Yandex

Some browsers for Android have blocked the abusive JavaScript in trackers. DuckDuckGo, for instance, was already blocking domains and IP addresses associated with the trackers, preventing the browser from sending any identifiers to Meta. The browser also blocked most of the domains associated with Yandex Metrica. After the researchers notified DuckDuckGo of the incomplete blacklist, developers added the missing addresses.

The Brave browser, meanwhile, also blocked the sharing of identifiers due to its extensive blocklists and existing mitigation to block requests to the localhost without explicit user consent. Vivaldi, another Chromium-based browser, forwards the identifiers to local Android ports when the default privacy setting is in place. Changing the setting to block trackers appears to thwart browsing history leakage, the researchers said.

Tracking blocker settings in Vivaldi for Android.

There’s got to be a better way

The various remedies DuckDuckGo, Brave, Vivaldi, and Chrome have put in place are working as intended, but the researchers caution they could become ineffective at any time.

“Any browser doing blocklisting will likely enter into a constant arms race, and it’s just a partial solution,” Vallina Rodriguez said of the current mitigations. “Creating effective blocklists is hard, and browser makers will need to constantly monitor the use of this type of capability to detect other hostnames potentially abusing localhost channels and then updating their blocklists accordingly.”

He continued:

While this solution works once you know the hostnames doing that, it’s not the right way of mitigating this issue, as trackers may find ways of accessing this capability (e.g., through more ephemeral hostnames). A long-term solution should go through the design and development of privacy and security controls for localhost channels, so that users can be aware of this type of communication and potentially enforce some control or limit this use (e.g., a permission or some similar user notifications).

Chrome and most other Chromium-based browsers executed the JavaScript as Meta and Yandex intended. Firefox did as well, although for reasons that aren’t clear, the browser was not able to successfully perform the SDP munging specified in later versions of the code. After blocking the STUN variant of SDP munging in the early May beta release, a production version of Chrome released two weeks ago began blocking both the STUN and TURN variants. Other Chromium-based browsers are likely to implement it in the coming weeks. Firefox didn’t respond to an email asking if it has plans to block the behavior in that browser.

The researchers warn that the current fixes are so specific to the code in the Meta and Yandex trackers that it would be easy to bypass them with a simple update.

“They know that if someone else comes in and tries a different port number, they may bypass this protection,” said Gunes Acar, the researcher behind the initial discovery, referring to the Chrome developer team at Google. “But our understanding is they want to send this message that they will not tolerate this form of abuse.”

Fellow researcher Vallina-Rodriguez said the more comprehensive way to prevent the abuse is for Android to overhaul the way it handles access to local ports.

“The fundamental issue is that the access to the local host sockets is completely uncontrolled on Android,” he explained. “There’s no way for users to prevent this kind of communication on their devices. Because of the dynamic nature of JavaScript code and the difficulty to keep blocklists up to date, the right way of blocking this persistently is by limiting this type of access at the mobile platform and browser level, including stricter platform policies to limit abuse.”

Got consent?

The researchers who made this discovery are:

Aniketh Girish, PhD student at IMDEA Networks
Gunes Acar, assistant professor in Radboud University’s Digital Security Group & iHub
Narseo Vallina-Rodriguez, associate professor at IMDEA Networks
Nipuna Weerasekara, PhD student at IMDEA Networks
Tim Vlummens, PhD student at COSIC, KU Leuven

Acar said he first noticed Meta Pixel accessing local ports while visiting his own university’s website.

There’s no indication that Meta or Yandex has disclosed the tracking to either websites hosting the trackers or end users who visit those sites. Developer forums show that many websites using Meta Pixel were caught off guard when the scripts began connecting to local ports.

“Since 5th September, our internal JS error tracking has been flagging failed fetch requests to localhost: 12387,” one developer wrote. “No changes have been made on our side, and the existing Facebook tracking pixel we use loads via Google Tag Manager.”

“Is there some way I can disable this?” another developer encountering the unexplained local port access asked.

It’s unclear whether browser-to-native-app tracking violates any privacy laws in various countries. Both Meta and companies hosting its Meta Pixel, however, have faced a raft of lawsuits in recent years alleging that the data collected violates privacy statutes. A research paper from 2023 found that Meta pixel, then called the Facebook Pixel, “tracks a wide range of user activities on websites with alarming detail, especially on websites classified as sensitive categories under GDPR,” the abbreviation for the European Union’s General Data Protection Regulation.

So far, Google has provided no indication that it plans to redesign the way Android handles local port access. For now, the most comprehensive protection against Meta Pixel and Yandex Metrica tracking is to refrain from installing the Facebook, Instagram, or Yandex apps on Android devices.

Dan Goodin is Senior Security Editor at Ars Technica, where he oversees coverage of malware, computer espionage, botnets, hardware hacking, encryption, and passwords. In his spare time, he enjoys gardening, cooking, and following the independent music scene. Dan is based in San Francisco. Follow him at here on Mastodon and here on Bluesky. Contact him on Signal at DanArs.82.

Meta and Yandex are de-anonymizing Android users’ web browsing identifiers Read More »

Ransomware kingpin “Stern” apparently IDed by German law enforcement

Biz & IT, conti, ransomware, Security, Stern, syndicated, TrickBot / Tim Belzer / May 31, 2025

unlikely to be extradited

BSA names Vitaly Nikolaevich Kovalev is “Stern,” the leader of Trickbot.

Credit: Tim Robberts/Getty Images

For years, members of the Russian cybercrime cartel Trickbot unleashed a relentless hacking spree on the world. The group attacked thousands of victims, including businesses, schools, and hospitals. “Fuck clinics in the usa this week,” one member wrote in internal Trickbot messages in 2020 about a list of 428 hospitals to target. Orchestrated by an enigmatic leader using the online moniker “Stern,” the group of around 100 cybercriminals stole hundreds of millions of dollars over the course of roughly six years.

Despite a wave of law enforcement disruptions and a damaging leak of more than 60,000 internal chat messages from Trickbot and the closely associated counterpart group Conti, the identity of Stern has remained a mystery. Last week, though, Germany’s federal police agency, the Bundeskriminalamt or BKA, and local prosecutors alleged that Stern’s real-world name is Vitaly Nikolaevich Kovalev, a 36-year-old, 5-foot-11-inch Russian man who cops believe is in his home country and thus shielded from potential extradition.

A recently issued Interpol red notice says that Kovalev is wanted by Germany for allegedly being the “ringleader” of a “criminal organisation.”

“Stern’s naming is a significant event that bridges gaps in our understanding of Trickbot—one of the most notorious transnational cybercriminal groups to ever exist,” says Alexander Leslie, a threat intelligence analyst at the security firm Recorded Future. “As Trickbot’s ‘big boss’ and one of the most noteworthy figures in the Russian cybercriminal underground, Stern remained an elusive character, and his real name was taboo for years.”

Stern has notably seemed to be absent from multiple rounds of Western sanctions and indictments in recent years calling out alleged Trickbot and Conti members. Leslie and other researchers have long speculated to WIRED that global law enforcement may have strategically withheld Stern’s alleged identity as part of ongoing investigations. Kovalev is suspected of being the “founder” of Trickbot and allegedly used the Stern moniker, the BKA said in an online announcement.

“It has long been assumed, based on numerous indications, that ‘Stern’ is in fact Kovalev,” a BKA spokesperson says in written responses to questions from WIRED. They add that “the investigating authorities involved in Operation Endgame were only able to identify the actor Stern as Kovalev during their investigation this year,” referring to a multi-year international effort to identify and disrupt cybercriminal infrastructure, known as Operation Endgame.

The BKA spokesperson also notes in written statements to WIRED that information obtained through a 2023 investigation into the Qakbot malware as well as analysis of the leaked Trickbot and Conti chats from 2022 were “helpful” in making the attribution. They added, too, that the “assessment is also shared by international partners.”

The German announcement is the first time that officials from any government have publicly alleged an identity for a suspect behind the Stern moniker. As part of Operation Endgame, BKA’s Stern attribution inherently comes in the context of a multinational law enforcement collaboration. But unlike in other Trickbot- and Conti-related attributions, other countries have not publicly concurred with BKA’s Stern identification thus far. Europol, the US Department of Justice, the US Treasury, and the UK’s Foreign, Commonwealth & Development Office did not immediately respond to WIRED’s requests for comment.

Several cybersecurity researchers who have tracked Trickbot extensively tell WIRED they were unaware of the announcement. An anonymous account on the social media platform X recently claimed that Kovalev used the Stern handle and published alleged details about him. WIRED messaged multiple accounts that supposedly belong to Kovalev, according to the X account and a database of hacked and leaked records compiled by District 4 Labs but received no response.

Meanwhile, Kovalev’s name and face may already be surprisingly familiar to those who have been following recent Trickbot revelations. This is because Kovalev was jointly sanctioned by the United States and United Kingdom in early 2023 for his alleged involvement as a senior member in Trickbot. He was also charged in the US at the time with hacking linked to bank fraud allegedly committed in 2010. The US added him to its most-wanted list. In all of this activity, though, the US and UK linked Kovalev to the online handles “ben” and “Bentley.” The 2023 sanctions did not mention a connection to the Stern handle. And, in fact, Kovalev’s 2023 indictment was mainly noteworthy because his use of “Bentley” as a handle was determined to be “historic” and distinct from that of another key Trickbot member who also went by “Bentley.”

The Trickbot ransomware group first emerged around 2016, after its members moved from the Dyre malware that was disrupted by Russian authorities. Over the course of its lifespan, the Trickbot group—which used its namesake malware, alongside other ransomware variants such as Ryuk, IcedID, and Diavol—increasingly overlapped in operations and personnel with the Conti gang. In early 2022, Conti published a statement backing Russia’s full-scale invasion of Ukraine, and a cybersecurity researcher who had infiltrated the groups leaked more than 60,000 messages from Trickbot and Conti members, revealing a huge trove of information about their day-to-day operations and structure.

Stern acted like a “CEO” of the Trickbot and Conti groups and ran them like a legitimate company, leaked chat messages analyzed by WIRED and security researchers show.

“Trickbot set the mold for the modern ‘as-a-service’ cybercriminal business model that was adopted by countless groups that followed,” Recorded Future’s Leslie says. “While there were certainly organized groups that preceded Trickbot, Stern oversaw a period of Russian cybercrime that was characterized by a high level of professionalization. This trend continues today, is reproduced worldwide, and is visible in most active groups on the dark web.”

Stern’s eminence within Russian cybercrime has been widely documented. The cryptocurrency-tracing firm Chainalysis does not publicly name cybercriminal actors and declined to comment on BKA’s identification, but the company emphasized that the Stern persona alone is one of the all-time most profitable ransomware actors it tracks.

“The investigation revealed that Stern generated significant revenues from illegal activities, in particular in connection with ransomware,” the BKA spokesperson tells WIRED.

Stern “surrounds himself with very technical people, many of which he claims to have sometimes decades of experience, and he’s willing to delegate substantial tasks to these experienced people whom he trusts,” says Keith Jarvis, a senior security researcher at cybersecurity firm Sophos’ Counter Threat Unit. “I think he’s always probably lived in that organizational role.”

Increasing evidence in recent years has indicated that Stern has at least some loose connections to Russia’s intelligence apparatus, including its main security agency, the Federal Security Service (FSB). The Stern handle mentioned setting up an office for “government topics” in July 2020, while researchers have seen other members of the Trickbot group say that Stern is likely the “link between us and the ranks/head of department type at FSB.”

Stern’s consistent presence was a significant contributor to Trickbot and Conti’s effectiveness—as was the entity’s ability to maintain strong operational security and remain hidden.

As Sophos’ Jarvis put it, “I have no thoughts on the attribution, as I’ve never heard a compelling story about Stern’s identity from anyone prior to this announcement.”

This story originally appeared on wired.com.

Wired.com is your essential daily guide to what’s next, delivering the most original and complete take you’ll find anywhere on innovation’s impact on technology, science, business and culture.

Ransomware kingpin “Stern” apparently IDed by German law enforcement Read More »

Spy-catcher saw “stupid” tech errors others made. FBI says he then made his own.

DIA, Security, SOCKS, spying / Tim Belzer / May 31, 2025

2) EMAIL ADDRESS FAIL: The FBI quickly gained access to the “anonymous” email account used to send the message. They found that, on the day that this account was set up, it received a message from a second email account—possibly as a test—which turned out to be one of Laatsch’s and contained his name as part of the email address.

3) EMAIL ACCOUNT FAIL: This second email account, when the FBI examined it, had been set up using Laatsch’s full name, date of birth, and phone number.

4) IP ADDRESS FAIL: Both the first and second email account had been logged into from the same IP address, suggesting they were controlled by the same person. And the IP address that was used for them both resolved to… Laatsch’s residence.

The leaker did suggest moving the conversation to an encrypted messaging platform, but the damage was already done.

The FBI immediately began a sting operation, posing as the “friendly country,” asking Laatsch to copy some juicy data and provide it in a “dead drop” at a park in northern Virginia. Laatsch allegedly then went in to work at DIA, using his deep knowledge of DIA computerized tracking systems to avoid detection by… copying secret documents into notebooks by hand, then ripping out the sheets of paper and stuffing them in his socks.

This appears to have worked well enough—except for the fact that internal DIA “video monitoring” was watching him do it, with FBI agents noting even the ways Laatsch tried to “hide his notebook” when co-workers walked by. Whether Laatsch was aware of this video monitoring system is unclear.

On May 1, 2025, Laatsch allegedly wrote up his notes, stored them on a thumb drive, and dropped them as requested at an Alexandria park. The drive was later retrieved by the FBI. On May 8, Laatsch told his contact that he wasn’t seeking money but “citizenship for your country” because he didn’t “expect things here to improve in the long term, even in the event there is a change in the future.”

Laatsch was arrested yesterday, May 29.

Spy-catcher saw “stupid” tech errors others made. FBI says he then made his own. Read More »

Thousands of Asus routers are being hit with stealthy, persistent backdoors

asus routers, backdoors, Biz & IT, hacking, Security / Paul Patrick / May 29, 2025

GreyNoise said it detected the campaign in mid-March and held off reporting on it until after the company notified unnamed government agencies. That detail further suggests that the threat actor may have some connection to a nation-state.

The company researchers went on to say that the activity they observed was part of a larger campaign reported last week by fellow security company Sekoia. Researchers at Sekoia said that Internet scanning by network intelligence firm Censys suggested as many as 9,500 Asus routers may have been compromised by ViciousTrap, the name used to track the unknown threat actor.

The attackers are backdooring the devices by exploiting multiple vulnerabilities. One is CVE-2023-39780, a command-injection flaw that allows for the execution of system commands, which Asus patched in a recent firmware update, GreyNoise said. The remaining vulnerabilities have also been patched but, for unknown reasons, have not received CVE tracking designations.

The only way for router users to determine whether their devices are infected is by checking the SSH settings in the configuration panel. Infected routers will show that the device can be logged in to by SSH over port 53282 using a digital certificate with a truncated key of: ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAo41nBoVFfj4HlVMGV+YPsxMDrMlbdDZ…

To remove the backdoor, infected users should remove the key and the port setting.

People can also determine if they’ve been targeted if system logs indicate that they have been accessed through the IP addresses 101.99.91[.]151, 101.99.94[.]173, 79.141.163[.]179, or 111.90.146[.]237. Users of any router brand should always ensure their devices receive security updates in a timely manner.

Thousands of Asus routers are being hit with stealthy, persistent backdoors Read More »

Feds charge 16 Russians allegedly tied to botnets used in cyberattacks and spying

Biz & IT, botnet, russian hacking, Security, syndication / Tim Belzer / May 24, 2025

The hacker ecosystem in Russia, more than perhaps anywhere else in the world, has long blurred the lines between cybercrime, state-sponsored cyberwarfare, and espionage. Now an indictment of a group of Russian nationals and the takedown of their sprawling botnet offers the clearest example in years of how a single malware operation allegedly enabled hacking operations as varied as ransomware, wartime cyberattacks in Ukraine, and spying against foreign governments.

The US Department of Justice today announced criminal charges today against 16 individuals law enforcement authorities have linked to a malware operation known as DanaBot, which according to a complaint infected at least 300,000 machines around the world. The DOJ’s announcement of the charges describes the group as “Russia-based,” and names two of the suspects, Aleksandr Stepanov and Artem Aleksandrovich Kalinkin, as living in Novosibirsk, Russia. Five other suspects are named in the indictment, while another nine are identified only by their pseudonyms. In addition to those charges, the Justice Department says the Defense Criminal Investigative Service (DCIS)—a criminal investigation arm of the Department of Defense—carried out seizures of DanaBot infrastructure around the world, including in the US.

Aside from alleging how DanaBot was used in for-profit criminal hacking, the indictment also makes a rarer claim—it describes how a second variant of the malware it says was used in espionage against military, government, and NGO targets. “Pervasive malware like DanaBot harms hundreds of thousands of victims around the world, including sensitive military, diplomatic, and government entities, and causes many millions of dollars in losses,” US attorney Bill Essayli wrote in a statement.

Since 2018, DanaBot—described in the criminal complaint as “incredibly invasive malware”—has infected millions of computers around the world, initially as a banking trojan designed to steal directly from those PCs’ owners with modular features designed for credit card and cryptocurrency theft. Because its creators allegedly sold it in an “affiliate” model that made it available to other hacker groups for $3,000 to $4,000 a month, however, it was soon used as a tool to install different forms of malware in a broad array of operations, including ransomware. Its targets, too, quickly spread from initial victims in Ukraine, Poland, Italy, Germany, Austria, and Australia to US and Canadian financial institutions, according to an analysis of the operation by cybersecurity firm Crowdstrike.

Feds charge 16 Russians allegedly tied to botnets used in cyberattacks and spying Read More »

Researchers cause GitLab AI developer assistant to turn safe code malicious

AI, Artificial Intelligence, Biz & IT, chatbots, large language models, Security / Rejus Almole / May 24, 2025

Marketers promote AI-assisted developer tools as workhorses that are essential for today’s software engineer. Developer platform GitLab, for instance, claims its Duo chatbot can “instantly generate a to-do list” that eliminates the burden of “wading through weeks of commits.” What these companies don’t say is that these tools are, by temperament if not default, easily tricked by malicious actors into performing hostile actions against their users.

Researchers from security firm Legit on Thursday demonstrated an attack that induced Duo into inserting malicious code into a script it had been instructed to write. The attack could also leak private code and confidential issue data, such as zero-day vulnerability details. All that’s required is for the user to instruct the chatbot to interact with a merge request or similar content from an outside source.

AI assistants’ double-edged blade

The mechanism for triggering the attacks is, of course, prompt injections. Among the most common forms of chatbot exploits, prompt injections are embedded into content a chatbot is asked to work with, such as an email to be answered, a calendar to consult, or a webpage to summarize. Large language model-based assistants are so eager to follow instructions that they’ll take orders from just about anywhere, including sources that can be controlled by malicious actors.

The attacks targeting Duo came from various resources that are commonly used by developers. Examples include merge requests, commits, bug descriptions and comments, and source code. The researchers demonstrated how instructions embedded inside these sources can lead Duo astray.

“This vulnerability highlights the double-edged nature of AI assistants like GitLab Duo: when deeply integrated into development workflows, they inherit not just context—but risk,” Legit researcher Omer Mayraz wrote. “By embedding hidden instructions in seemingly harmless project content, we were able to manipulate Duo’s behavior, exfiltrate private source code, and demonstrate how AI responses can be leveraged for unintended and harmful outcomes.”

Researchers cause GitLab AI developer assistant to turn safe code malicious Read More »