UMass Amherst researchers showed expired Visa contactless cards can make real purchases by exploiting an unsigned expiry field in Visa’s EMV kernel. Researchers at the University of Massachusetts Amherst demonstrated at USENIX Security 2026 in Baltimore that expired Visa contactless credit cards can complete real purchases, including transactions at live retail and grocery merchants, by exploiting a gap in how the payment protocol handles expiration dates. The paper is titled “Zombie Cards Back Online: Reviving Expired Credit Cards for Contactless Payments,” and the name is accurate. Raja Hasnain Anwar, Gerard DeCunha, and Muhammad Taqi Raza built the attack around a structural weakness in EMV, the contactless payment protocol used by Visa, Mastercard, American Express, and Discover. “A central source of fragility is that the EMV contactless protocol is a selectively authenticated transaction flow. Many data objects are exchanged in plaintext between the card and terminal [2], and only a subset is later bound to cryptographic verification via Offline Data Authentication (ODA) and issuer-verified cryptograms.” reads the paper. “In consequence, an adversary who obtains a man-in-the-middle position on the NFC channel can tamper with decision-critical fields that are consumed by the terminal but are not end-to-end integrity protected. Prior NFC attacks [10–12, 44], including relay-based manin-the-middle techniques, exploit this gap by manipulating transaction-relevant objects in transit while leaving cryptographic checks intact.” The attack exploits a specific design decision in Visa’s Kernel 3, the software layer that implements the EMV protocol for Visa transactions. A Visa contactless transaction presents the expiration date twice: once in a field the payment terminal reads (tag 5F24, the Application Expiration Date) and once in a field the issuing bank reads (tag 57, Track 2 Equivalent Data). These two representations should be tied together by a cryptographic signature, but in Visa’s implementation they aren’t. The relay attack changes only the expiry date that the payment terminal sees, replacing it with a future date while leaving the data sent to the bank unchanged. The card’s digital signature remains valid because it does not cover the expiry date. As a result, the bank receives a transaction that appears legitimate and passes its normal security checks. In simple terms, an attacker can change the expiry date between the card and the terminal without breaking the card’s cryptographic protection. The relay itself is two NFC-capable Android phones running custom software over Wi-Fi: one emulates a card, one emulates a terminal. Each communication round trip added roughly 20 milliseconds for relay alone and about 50 milliseconds with the date modification, keeping the per-transaction average around 415 milliseconds, within Visa’s 500-millisecond command limit. None of the test hardware used EMV’s optional Relay Resistance Protocol, which would have detected the added latency by bounding permissible response times. Mastercard, American Express, and Discover all blocked the attack. Mastercard’s terminal checks consistency between the two expiry representations during record parsing and treats a mismatch as a card data error. American Express binds the expiration date into the data covered by offline authentication, so a modified value produces a hash mismatch. Discover’s kernel wraps the modified transaction objects into the verified transaction hash, and those also failed. Visa’s Kernel 3 does none of these things. The outcome also depended on the issuing bank. The researchers tested three banks with expired and replaced physical Visa cards and found three distinct policies, not a clean pass or fail split. Bank A accepted the modified transactions at $1.00, $100.00, and $500.00 in the lab, and completed purchases of $2.79 at a retail merchant and $3.19 at a grocery merchant on campus. Bank A also accepted transactions from both the expired original card and its replacement against the same account simultaneously, a separate finding that Anwar described as alarming. Bank B detected the modification but still accepted some transactions. A third bank tested on Discover’s kernel detected the edit and declined; however, it also showed the simultaneous-card problem without any modification at all. There is another finding that makes the issue more serious. Researchers changed the Consumer Device Cardholder Verification Method flag at five US banks, and the transactions worked at most of them. This flag controls how the terminal verifies the cardholder, and attackers can change it because the payment data can be modified while it travels between the card and the terminal. There is also another problem with Kernel 3. It sends the issuer a Terminal Verification Results value filled with zeros. This means the bank cannot tell whether the terminal checked the card’s expiry date or whether that check failed. The bank must therefore approve the transaction without seeing what the terminal actually detected. “Across all tests, the dominant factors that determine attack success or failure are: (i) the EMV kernel in use and whether expiry data fields are cryptographically bound to authenticated protocol outputs; (ii) issuer-side lifecycle enforcement, especially whether authorization is tied only to the active account and PAN or also to the specific card instrument and expiration date; and (iii) whether terminal-side validation results are visible to the issuer via TVR. In contrast, transaction amount1 , merchant category, and POS terminal brand did not independently determine the transaction outcome.” continues the paper. The researchers disclosed the findings to Visa in May 2025 and followed up in December 2025. The paper records that Visa acknowledged the report, said it passed initial triage, and indicated it was undergoing reproduction by Visa’s red team. No CVE has been assigned. Neither Visa nor any of the notified banks confirmed any mitigation as of the paper’s acceptance. The Register asked Visa for comment and received no response. The countermeasures the paper proposes sit at the kernel, terminal, and issuer layers: bind the expiry date cryptographically to an issuer-verifiable signature, require terminals to compare both expiry representations and make mismatches visible to the issuer, and have issuers authorize against the PAN-and-expiry combination rather than the PAN alone. For cardholders, the researchers recommend destroying the chip and magnetic stripe of expired cards rather than discarding them intact. Given that the attack requires only the expired physical card or sustained NFC proximity to it, that guidance is now slightly less hypothetical than it was before this paper. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, Visa)
A previously unknown malware family dubbed SynkLoader is being distributed in Microsoft Teams phishing campaigns to steal credentials via a fake lock screen. The attacker impersonates the target company's IT help desk, a tactic Microsoft highlighted earlier this year as increasingly common in multi-stage attacks. Expel’s security researcher Marcus Hutchins explains that the attacks direct the victim to install a fake “PowerShell Cleaner” executable (.MSI) hosted in Microsoft Azure, making the download appear trustworthy. Analysis of the malware showed "compile dates and file timestamps indicating it was first compiled and distributed around July 28, 2026." The installer extracts a PowerShell script named cleaner.ps1 and a ZIP archive containing the Python framework, a malicious Python script, precompiled Python libraries, and several fake Microsoft runtime DLLs.
More than 9,300 Amazon Web Services (AWS) access keys publicly exposed between August 2022 and August 2026 are still active and valid. Truffle Security has been tracking this exposure for the past four years and says that 817 of the exposed keys were linked to companies, 526 of them being AWS root keys. According to the researchers, 242 of the keys are associated with Identity and Access Management (IAM) users with the AdministratorAccess policy. This role has full permissions to create, modify, delete, and view virtually all AWS services and resources within an account. They note that each key of the 768 live keys in the two sets “full control of a company's AWS account.” The company found 431,875 AWS secrets across code repositories, Git history, datasets, Docker images, registries, and CI logs and extracted 64,024 unique AWS keys that corresponded to 50,654 AWS accounts after removing duplicates.
Using the same email, phone number, payment method, and other identifiers makes it easier for data brokers and attackers to profile your activity. Anonyome Labs explains how separate digital personas can reduce correlation and limit the impact of breaches, spam, and identity theft.
Microsoft has patched a maximum-severity vulnerability in the Entra ID identity and access management (IAM) platform that has been exploited in attacks.
Toronto's Hospital for Sick Children (SickKids) says a cybersecurity incident exposed the personal information of some current and former employees and job applicants, stemming from a flaw in third-party software. Clinical systems and patient records were not affected. (264)
CERT Polska confirmed active exploitation of CVE-2026-73570, a critical unauthenticated RCE in Zimbra Collaboration Suite patched on July 20. CERT Polska, Poland’s national computer emergency response team, confirmed this week that threat actors are actively exploiting a critical vulnerability in Zimbra Collaboration Suite tracked as CVE-2026-73570. The flaw allows unauthenticated remote code execution and was patched less than a month ago. “The CERT Polska team informs about an actively exploited OS Command Injection vulnerability in Zimbra Collaboration Suite.” reads the advisory published by CERT Polska. “The vulnerability, identified as CVE-2026-73570 , allows an unauthenticated attacker to execute arbitrary shell commands with the privileges of the zimbra user . The vulnerability affects instances that have the SNMP trap service enabled via the snmp_notify parameter and the swatchdog service running (enabled by default).” The vulnerability affects systems with SNMP trap notifications enabled and the swatchdog service running, which is enabled by default. The technical root cause is a sanitization failure in the SNMP monitoring component. Zimbra released version 10.1.20 on 20 July 2026 to address the issue. The fix came 28 days before active exploitation was confirmed, which is not a wide window, but apparently wide enough. The attack surface only exists when the optional zimbra-snmp package is installed and SNMP notifications are active, but swatchdog, the service that processes those notifications, is running by default on most installations. Below are recommendations by CERT Polska: “Due to the ongoing campaign exploiting this vulnerability, we recommend: verifying Zimbra logs /var/log/zimbra.log for the following entries: Service status change: <szkodliwy ładunek> changed from stopped to running Service status change: <szkodliwy ładunek> changed from running to stopped verification of files created by user zimbra in the last 30 days in the following directories: /opt/zimbra/jetty/webapps/ /opt/zimbra/jetty_base/webapps/ /tmp/ If you discover any signs of potential exploitation of this vulnerability, please contact our team immediately.” The exposure numbers aren’t reassuring. Shadowserver currently tracks over 12,100 Zimbra servers reachable from the Internet, split roughly between Europe (4,382) and Asia (4,492). That figure doesn’t distinguish between patched and unpatched instances, or between production servers and honeypots, so the real attack surface is smaller, but nobody knows by how much. CERT Polska published indicators of compromise alongside the advisory and gave administrators specific places to look. The team recommends checking /var/log/zimbra.log for service status change entries where the payload transitions from stopped to running and back, which is the signature of a malicious command being executed as a service. Admins should also check whether any files were created in /opt/zimbra/jetty/webapps/, /opt/zimbra/jetty_base/webapps/, or /tmp/ by the zimbra user in the last 30 days. Web shells dropped into those directories would give persistent access after the initial command injection. CVE-2026-73570 isn’t yet in CISA’s Known Exploited Vulnerabilities catalog, which currently lists 18 Zimbra Collaboration Suite entries, four of them added this year. The absence doesn’t mean the threat is lower; it means the catalog hasn’t caught up yet. Zimbra solutions have been targeted by nation-state actors for years. Russian espionage group Winter Vivern exploited a reflected XSS flaw in February 2023 to steal emails from NATO-aligned organizations through Zimbra webmail portals. In October 2024, US and UK agencies warned that APT29, linked to Russia’s Foreign Intelligence Service, was targeting vulnerable Zimbra servers via a credential-stealing flaw. Most recently, in March 2026, Seqrite Labs researchers documented APT28, tied to Russian military intelligence, exploiting a stored XSS vulnerability against Ukrainian government Zimbra deployments. Organizations in sectors targeted by Russian or Chinese state-backed groups should treat unpatched Zimbra servers as a high priority. CVE-2026-73570 is especially risky because attackers can exploit it without authentication, the vulnerable service is enabled by default, and many Zimbra servers are exposed online. These conditions make the flaw an attractive target for rapid exploitation. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, Zimbra Collaboration Suite)
While monitoring Android threats in June 2026, we discovered a new piece of Android malware. What struck us as unusual was that it installed like an ordinary user app yet made no attempt to disguise itself as legitimate software: it had no user interface at all. This led us to suspect the app might be reaching users’ devices without their knowledge. Further investigation confirmed that hypothesis and allowed us to reconstruct the entire infection chain. Key findings: We identified new Android malware: a multi-stage downloader whose ultimate purpose is ad fraud and creation of a proxy botnet. The malware spread through the built-in updaters of Android-based automotive head unit firmware. This is the first documented case of malware found on a car head unit with an infection chain specific to that type of device. We attribute this activity, with high confidence, to the MoYu Group, an actor linked to the BADBOX botnet. Kaspersky solutions detect the threats described below under the following detection names: HEUR:Trojan-Dropper.AndroidOS.Agent.vu HEUR:Trojan-Downloader.AndroidOS.Agent.ov HEUR:Trojan-Proxy.AndroidOS.Zhima.* HEUR:Trojan.AndroidOS.Vo1d.* Head unit firmware overview A head unit is a system that combines multimedia functions with partial control over certain vehicle functions. Head units may come as part of a car’s factory equipment or as an aftermarket upgrade. The main attack vectors for these systems are compromise via physical access and vulnerabilities in the head unit’s OS or components, both of which we’ve covered previously. In some cases, head units run on Android, primarily because it’s convenient for manufacturers: Android’s source code already accounts for use cases within automotive head units. Android also allows manufacturers to add their own system applications during the build process, which they can use for a range of purposes: customizing the UI, adding system components tailored to the vendor’s needs, and more. Most apps developed for Android devices can also run on an Android-based head unit, and that is true for malware as well. That said, it’s hard to imagine certain categories of smartphone-targeted malware being used to attack a head unit. Banking Trojans are a good example: since mobile banking is used almost exclusively on smartphones, infecting a head unit with a banking Trojan would be a waste of the attacker’s resources. It’s worth noting that head units often include SIM card slots and can connect to the internet, enabling features like navigation and software updates. Since a head unit typically holds nothing of value to an attacker, one of the more likely attack scenarios using “classic” Android malware is infecting the device to recruit it into a botnet – similar to attacks on IoT devices. During our research, we found exactly that kind of malware. The design of firmware for DoFun head units enabled attackers to distribute malware. We notified the vendor about the distribution scheme, and they subsequently reported fixing the security issues. Below is the entire infection chain: Head unit infection scheme Let’s look at exactly how these head units became infected. The TWCore app TWCore is a legitimate system application responsible for collecting analytics data and updating the head unit software. Let’s take a closer look at how the update function works. The process is fairly simple. An MQTT message broker hosted on the subdomain cardoor[.]cn sends a message containing information about the APK files that need to be downloaded and installed on the head unit. Notably, the object describing this message includes an installNotExists field, a Boolean flag that can be set to true or false. This flag allows TWCore to install apps that weren’t originally present on the device. TWCore only checks whether an app is already installed on the device when installNotExists = false The APK file is downloaded to <TWCore external cache dir>/push/apk/ for installation. The path TWCore uses to download APK files Our telemetry revealed previously unknown malware at these file paths. On top of that, our data indicates that in every observed case, the malware was installed by an app with the package name com.tw.core, which matches the TWCore package name. Next, we’ll break down the malware installed by TWCore: the JarService dropper. Stage 1: the JarService dropper As mentioned earlier, JarService is a small dropper app with no UI of any kind. It decrypts data stored as encrypted blocks within the Trojan’s code. Each block is XOR-encrypted with a single-byte key that shifts linearly from block to block. The decrypted data contains serialized information about the payload version and entry point, along with the malware’s own code for further loading. Decrypting and deserializing information about the stage 2 payload In the version of JarService we analyzed, the entry point for the next-stage payload was the wa method of the com.c.j.qbh class. Stage 2: the loader This stage’s payload is a malicious loader. Its code contains encrypted strings that are later used as class names to execute the stage 3 payload using the reflection mechanism. The loader sends implant information to one of the attackers’ servers via a POST request. Example of a request to the C2 server: { "userId": "REDACTED", "dexVersion": "1.7", "dexType": 1, "channelId": "2039", "packageName": "com.tw.jar1", "appVersion": 12, "appName": "JarService" }In response to the POST request, the C2 server returns a link for downloading the stage 3 payload. An example of a C2 response is shown below. { "code": 200, "data": { "dexUrl": "hxxp://144.217.243[.]201/vr34der34/dex3.68.png", "dexVersion": 3.680, "status": 0 } }The Trojan uses the link in the dexUrl field of the data object to download serialized data for loading the next stage. This data begins with a single-byte integer, a key used to decrypt the strings in the loader’s code. Immediately following this number is a four-byte floating-point value used to XOR-decrypt the stage 3 payload, which itself is located after these keys. Decrypting the stage 3 payload In the decrypted payload, the entry point is the init method of the com.ast.sdk.BillingMain class, shown in the screenshot below. Entry point of the stage 3 payload While analyzing this stage, we noticed that the download link for the next-stage payload includes a version number. We decided to try other version numbers to retrieve different payload versions, and ultimately obtained seven distinct variants, which we list under “Indicators of Compromise” at the end of this report. The earliest version, numbered 3.57, uses a different decoding algorithm than the one described above. This may indicate that an earlier version of the infection chain used a different loader between JarService and the stage 3 payload. Stage 3: clicker / reverse proxy loader In this stage, the malware sends a POST request to /cpc/api/task every 90 minutes by default, containing information about the infected device (display resolution, device model, the SSID of the connected Wi-Fi network, MAC address, and so on) along with the Trojan’s configuration version. If the configuration is outdated, the C2 server returns an updated configuration containing new C2 addresses and new paths for sending HTTP requests. An example of a response is shown below. Note that at the time of our research, the most up-to-date configuration version was 3.82. { "code": 100, "data": { "configVersion": 3.820, "hosts": ["hxxp://t2.kshahnd[.]sbs", "hxxp://t2.mdsjhd[.]sbs", "hxxp://t2.nmnsny[.]sbs", "hxxps://t2.nmnsny[.]sbs"], "interval": 5500000, "reportApi": "/cpc/api/report", "tagName": "config", "taskApi": "/cpc/api/task", "updates": ["hxxp://a2.kshahnd[.]sbs", "hxxp://a2.mdsjhd[.]sbs", "hxxp://a2.nmnsny[.]sbs", "hxxps://a2.nmnsny[.]sbs"], "vn": 1.010 } }If the configuration version doesn’t need updating, the C2 server instead returns integer command identifiers, which the attackers refer to as productId. The Trojan maps each identifier to command information, which it stores as a serialized JSON object using the SharedPreferences API. Each identifier also has its own version, expressed as a UNIX timestamp. If the C2 response includes an unknown productId or one whose version is outdated, the malware sends a GET request to the attackers’ server at /cpc/api/xml to retrieve the command contents for all such identifiers. The C2 server responds with command information for each unknown identifier. An example of a response is shown below. { "code": 200, "data": [{ "productId": 979, "script": "{\n \"loadType\": 1,\n \"reload\": true,\n \"method\": \"start\",\n \"url2\": \"hxxp://144.217.243[.]201/vr34der34/sh65.io\",\n \"md52\": \"de77c3303e93c9450424759f1741441c\",\n \"name\": \"zhima\",\n \"className\": \"com.miyc.transfer.Client\",\n \"thread\": true,\n \"tagName\": \"loadlib2\",\n \"params\": [\n {\n \"type\": \"Context\"\n },\n {\n \"type\": \"String\",\n \"value\": \"107.151.248[.]132\"\n },\n {\n \"type\": \"String\",\n \"value\": \"1002\"\n },\n {\n \"type\": \"int\",\n \"value\": 1337\n },\n {\n \"type\": \"int\",\n \"value\": 7777\n },\n {\n \"type\": \"int\",\n \"value\": 8888\n },\n {\n \"type\": \"int\",\n \"value\": 15000\n }\n ],\n \"url\": \"hxxp://144.217.243[.]201/vr34der34/sh65.io\",\n \"md5\": \"de77c3303e93c9450424759f1741441c\"\n}", "version": 1778650942 }, { "productId": 1019, "script": "{\n \"loadType\": 1,\n \"reload\": true,\n \"method\": \"start\",\n \"url2\": \"hxxp://144.217.243[.]201/vr34der34/sh65.io\",\n \"md52\": \"de77c3303e93c9450424759f1741441c\",\n \"name\": \"zhima\",\n \"className\": \"com.miyc.transfer.Client\",\n \"thread\": true,\n \"tagName\": \"loadlib2\",\n \"params\": [\n {\n \"type\": \"Context\"\n },\n {\n \"type\": \"String\",\n \"value\": \"128.14.210[.]58\"\n },\n {\n \"type\": \"String\",\n \"value\": \"1002\"\n },\n {\n \"type\": \"int\",\n \"value\": 9999\n },\n {\n \"type\": \"int\",\n \"value\": 7777\n },\n {\n \"type\": \"int\",\n \"value\": 8888\n },\n {\n \"type\": \"int\",\n \"value\": 15000\n }\n ],\n \"url\": \"hxxp://144.217.243[.]201/vr34der34/sh65.io\",\n \"md5\": \"de77c3303e93c9450424759f1741441c\"\n}", "version": 1766001509 }, { "productId": 3505, "script": "{\n\"tagName\":\"http\",\n\"url\":\"hxxps://api.kookjar[.]com/sayhi?channel=daihai&uuid={get_uuid_10}\"\n}", "version": 1776656317 }], "msg": "" }The command information includes a tagName field, which is the command name. The code maps each name to the corresponding class responsible for executing it. List of executable commands At the time of our research, the attackers had implemented nine commands. The table below lists command names, brief descriptions, and arguments. The functionality of these commands suggests that the malware can be used to display ads, commit ad fraud (serving as a clicker), and download additional malicious code. Command name Description Arguments return Return a value from SharedPreferences. key: the key whose value should be returned copy Set the contents of the clipboard. text: the key whose value from SharedPreferences is returned as the clipboard contents url: a link for downloading gzip-compressed data (optional); this data is then concatenated with the value of the text key, with (5 spaces) used as a separator http Make a POST/GET HTTP request to a specified resource and, if instructed, save the response in SharedPreferences under a specified key. url: the resource address method: the HTTP method name (optional) startLabel: a marker for the start of the data to save from the resource (optional) endLabel: a marker for the end of the data to save from the resource (optional) valueLabel: the key under which to save the value (optional) header: a dictionary of headers for the HTTP request (optional) content: the content of the POST request (optional) web Open a link in the WebView and execute arbitrary JavaScript code within it. url: the link to open in the WebView js: base64-encoded JavaScript code to execute in the WebView; used when the url parameter is empty or absent corejs: JavaScript code to execute when the resource loads in the WebView (optional) param: a string dictionary of parameters for launching the WebView client: if this key is present, WebViewClient is used to handle redirects manually time: task timeout loadlib Not fully implemented at the time of publishing this report. – loadlib2 Download and execute arbitrary code. url: the address to download the payload from name: the name of the module being downloaded md5: the MD5 hash of the payload clear: a comma-separated list of payload names to delete (optional) params: an array of parameters to launch the payload with className: the class name of the payload entry point method: the name of the virtual method at the payload entry point cmethod: the name of the static method used to instantiate the entry-point class (optional) thread: a flag; the payload runs in a separate thread if this flag is not set reload: a flag that, when set, restarts already loaded modules loadlib3 Not fully implemented at the time of publishing this report. – deeplink Open a resource in the browser. url: a link to the resource traceroute Check resource availability via an ICMP ping. host: comma-separated list of resources to check However, attackers use only a relatively small subset of these commands in real-world attacks. As shown in the example C2 response above, at the time of publishing this report the attackers were using the loadlib2 and http commands. The payload downloaded via the loadlib2 command is a reverse proxy module named “zhima”, which researchers from the Nokia Deepfield Emergency Response Team independently discovered in TV set-top boxes around the same time as we did and also described in their report. This confirms that the attackers’ ultimate goal is building a proxy botnet. While investigating this stage of the attack chain, we noticed that the zhima download link also included a version number. As with the previous stage, we tried other possible version numbers and found eight variants of the zhima module, the earliest of which was version 57. The complete list of identified zhima modules is provided under “Indicators of Compromise” below. Attribution While analyzing the complete infection chain, we noticed that the stage 2 loader created a thread with the meaningful name mosdk-host-loader. We decided to investigate what mosdk referred to in that name. This led us to a malicious app installed on various TV set-top boxes with the package name com.abc.nexus (3AD4BF5A86D26FFBF09CAE42AF330A98). It consists of several components (including a dropper similar to JarService), each used by the attackers to covertly monetize the device’s computing power. Each malicious component in the app corresponds to its own service, and the service containing the launch code for the JarService-like dropper is named AdmoyuService. In light of this and the name of the malicious thread found in the payload code, we concluded that moyu in the service name referred to MoYu Group, one of the actors linked to the BADBOX malware platform, which had been described by researchers at HUMAN. This assessment is further supported by extensive overlap between the malware’s network infrastructure and that of MoYu Group, which was independently identified by researchers from the Nokia Deepfield Emergency Response Team around the same time as our own research. Based on these similar naming patterns and prominent infrastructure overlap between the activity of MoYu Group and the attacks described in this report, we attribute it to the same actor with high confidence. While investigating the malware downloaded by TWCore, we noticed that the domain admin.uipoxy[.]com resolved to the IP address 128.14.210[.]58, one of the C2 servers for the zhima reverse proxy module. It appears that the URL hxxp://admin.uipoxy[.]com/proxy/u/login hosts the zhima admin panel. Interestingly, this panel allows anyone to register as long as they have a valid invite code. The malware operator registration page During registration, users are prompted to review the terms of use and privacy policy. Both documents are hosted on links under the pxyedge[.]com domain, which belongs to PXYEDGE, a vendor specializing in the sale of residential proxies. On the registration page hosted at admin.uipoxy[.]com, we also found the string copyright © 2020 proxyforu[.]com all rights reserved, which linked to hxxps://proxyforu[.]com, the website of ProxyForU, another vendor of residential proxy services. We found several similarities in the authentication APIs across all of these sites: The sign-in page was hosted on an admin.* subdomain. The sign-in page was located at /proxy/u/login. The signup page was located at /proxy/register?channelKey=<invitation code>. Based on this, we believe these services are connected to MoYu Group. Conclusion Despite efforts by cybersecurity professionals and law enforcement to shut down the BADBOX botnet, individual actors linked to it continue their malicious activity, infecting devices worldwide. Delivery methods for this kind of malware vary widely, from downloads via pre-installed backdoors to infected builds of IPTV apps. The case examined here demonstrates an even more sophisticated delivery method: distribution through the legitimate update functionality of a system application. Attackers are also actively expanding into new platforms. This malware is the first known malicious app targeting head units, which means these platforms now require protection against malware as well. Indicators of compromise Stage 1: JarService ba27951b4ee1c341f4415d033369ecd3 d63bacd6d6709dd68a10ef9d374c7835 6c2e34b30da42085240ede53ab6107d4 8b5e513144a6138a966ea59e68bf9da2 e119845877089d6f4b0a70dc7388f316 Stage 2: loader e9f3a0dab6949ce2cddab9e0aa80ae1a Stage 3: loader/clicker 0fbaa7092204f4b1494e0b840b014774 1dcf031c40ce456b6a36a00b0acf3d11 44b6b213a6a3f299eaf88e078de95ecb 67dc78e544ebce16b85dc7c195dfbc58 9642ae619b3165d23c6349002d1abe24 b067d5b0dbecbd6498bcdfba45dba77e f0e3f7eba2cde91e2dedb921bab47422 zhima module 412e9243f2981bbea3894254d105b3b8 71ab5517f71866279d0d87d37f2ae320 89ef78f716a75964539f2db6520be362 a4223ce4288a230d1e6c3ff2c7639045 bd4d81cd27125ad3d9a114922d468499 c6bfb1643ac7474ed8a7b4f96a187fdb de77c3303e93c9450424759f1741441c f8cf8c23ff597700d471fb7767df8bac Domains and IP addresses xmsae[.]sbs ishano456[.]sbs xshaon123[.]sbs kshahnd[.]sbs mdsjhd[.]sbs nmnsny[.]sbs kookjar[.]com ty54fgd435[.]my ue886578433[.]online ty4523[.]space 144.217.243[.]201 107.151.248[.]132 128.14.210[.]58 Addresses used to download JarService hxxp://ovcloudcontrol.cdn.cardoor[.]cn/upgrade/2026-06-08/bd80bd3c3d0e4bf6b5b4a825650d01f5.apk hxxp://ovcloudcontrol.cdn.cardoor[.]cn/upgrade/2025-06-10/fe71af9ecf174de48d2b2ccc2c15fb04.apk hxxp://ovcloudcontrol.cdn.cardoor[.]cn/upgrade/2024-11-07/fa831c3c23824b99871163387bcda7ad.apk Hashes of TWCore (the legitimate software used to distribute JarService) 2a64c3efc11bf224aa54f24e876446c9 7a4d3ba2dacccfdda55859a5dfee2671 ea24487996eb70c1780922fb3063bcc5
Cl0p claims over 40 organizations fell victim to attacks exploiting a PTC Windchill and FlexPLM vulnerability. Cl0p is using a familiar strategy again: exploit one flaw in enterprise software to attack many companies, then publish the victims’ names if they refuse to pay. The group claims it has targeted more than 40 organizations through a vulnerability in PTC’s Windchill and FlexPLM platforms, which manufacturers and engineering companies use to manage product and design data. CVE-2026-12569 (CVSS score of 9.3) is a critical remote code execution (RCE) vulnerability in PTC Windchill PDMlink and PTC FlexPLM. An attacker can exploit this vulnerability through the deserialization of untrusted data. The flaw impacts all CPS versions and Windchill and FlexPLM releases prior to 11.0 M030. In June, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added the flaw to its Known Exploited Vulnerabilities (KEV) catalog. German police reportedly warned organizations directly that attacks were coming, which tells you the exploitation window here wasn’t exactly subtle to security researchers watching it unfold. Cl0p group’s tooling for this campaign goes well beyond a basic web shell. Security firm ReliaQuest found the group deployed a custom implant built for full data theft on its own, no additional tools required to actually pull data out once inside. A class loader like that turns a single web shell into an open-ended backdoor, useful for lateral movement, ransomware deployment, or just quietly sitting there for months. “ReliaQuest identified the web shell as a fully equipped extortion platform: it maps sensitive vault data, decrypts every credential in the Windchill keystore, and includes a custom Java class loader that lets Clop execute any additional code inside the application process, extending the shell into an unlimited backdoor for follow-on activity such as lateral movement, ransomware, or persistence.” reads the report published by ReliaQuest. “The web shell gives attackers a direct path to credential theft and large-scale data exfiltration, with no additional tooling required. Unlike generic command shells, this implant decrypts credentials, delivers malware, and maps stored files for exfiltration.” Cl0p’s naming strategy followed its usual slow build. The group initially posted partial company names on its leak site, then switched to full names starting August 12, and the victim count has climbed steadily since. For each organization, the listing includes what type of data got stolen and roughly how much, ranging anywhere from a single gigabyte up to multiple terabytes depending on the target. The stolen data includes databases, project files, backups, engineering documents, blueprints, diagrams and corporate files, as well as images. The victim list reads like a cross-section of major manufacturing and industrial names: Shell, Philips, Fiserv, Zebra Technologies, Ingersoll Rand, Toast, Mindray, and Largan Precision, the company that supplies camera lenses for Apple’s devices. Researchers noticed that GE was on the list briefly before quietly disappearing from Cl0p’s site, a move that usually signals either a ransom payment or at least resumed negotiations behind closed doors. Shell, Philips, Fiserv, and GE have all publicly acknowledged awareness of the claims and said they’re investigating, though none has confirmed a significant breach so far. None of this is a new pattern for Cl0p specifically; it’s the same mass-exploitation-then-extortion model the group has run repeatedly against Oracle E-Business Suite, MOVEit, Cleo, and GoAnywhere over the past few years. What’s different this time is the target: enterprise PLM software sits deep inside manufacturing supply chains, holding the exact kind of engineering data that competitors and nation-states alike would pay real money to see. If your organization runs Windchill or FlexPLM and hasn’t checked for this specific CVE yet, that’s the item to move to the top of today’s list. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, Cl0p )
Microsoft on Thursday warned of a maximum-severity security flaw in Entra ID that it said has been exploited in the wild, but noted that no customer action is required. The vulnerability, tracked as CVE-2026-69836 (CVSS score: 10.0), is a case of remote code execution impacting the tech giant's cloud-based identity and access management service. It was previously called Azure Active Directory
Confirm this action.
Leaving now will discard your changes.