Daily Cybersecurity News – August 23, 2026

What happened

A supply-chain attack is abusing a legitimate DoFun device-update app called TWCore on Android-based car head units to deliver malware that turns the devices into proxy botnet nodes or ad-fraud tools.

Kaspersky linked the activity to the MoYu group, previously tied to the BadBox botnet. The app pulls instructions via an MQTT server at cardoor[.]cn and drops a silent APK named JarService. That component decrypts a second-stage loader, reaches a C2 server, and fetches an encrypted payload that reports device details (model, resolution, Wi-Fi SSID, MAC) and accepts commands for HTTP requests, WebView JS execution, code loading, clipboard ops, deeplinks, and host checks.

Researchers call this the first documented infection chain built specifically for car head units. The malware avoids vehicle control systems and focuses on fraud and residential-proxy use.

Who is affected

Owners and fleets using generic Android-based head units from DoFun (Shenzhen Driving Control Technology Co., Ltd.), a Chinese provider of automotive software, cloud services, and hardware that serves as the infotainment and settings hub.

Any internet-connected unit running the legitimate TWCore updater is potentially exposed. Scale is not publicly quantified but covers aftermarket and OEM-style Android head units in consumer and commercial vehicles.

Why it matters

Compromised head units become always-on residential proxies or ad-fraud engines sitting inside cars, giving attackers durable network access that is hard to attribute and often trusted by downstream services.

The supply-chain vector via a signed system updater means infection can occur without user interaction or sideloading. Operators lose visibility into vehicle connectivity and risk secondary abuse of the car’s network identity.

How it could have been prevented

Inventory Android head units and confirm the vendor and update channel. Prefer units that allow disabling or tightly controlling third-party update apps and MQTT endpoints.

Block or monitor traffic to known bad domains such as cardoor[.]cn at the network edge. Keep head-unit firmware current from the OEM, segment vehicle networks from sensitive corporate or home resources, and treat car connectivity as untrusted until verified.

If compromise is suspected, factory-reset the unit from a clean image and change associated accounts.

What happened

Security firms this week detailed three active banking-trojan families that continue to evolve: Manic (Android), Grandoreiro (Windows), and ToxicPanda 2.0.

ThreatFabric describes Manic as an Android banking trojan plus spyware used mainly against Ukraine (banks, government, messaging) but also Russian, European, crypto, fintech, and military messaging targets. It arrives via malicious sites and droppers, supports keylogging, phishing overlays, remote control, notification theft, location tracking, file harvesting, and an offline mesh relay over Wi-Fi Direct or Bluetooth when C2 is unreachable.

Acronis reports Grandoreiro, a long-running Brazilian Windows banking trojan, remains active with heavy recent focus on Mexico while still hitting Latin America, Europe, and North America. Fresh samples abuse the legitimate Duplicate Files Finder app via DLL sideloading and include extensive anti-analysis (sandbox/VM checks).

ToxicPanda has expanded to version 2.0 with broader capabilities for credential theft and fraud.

Who is affected

Android users in Ukraine and secondary targets in Russia, Europe, and global crypto/fintech/military messaging; Windows users in Mexico, wider Latin America, Europe, and North America; and victims of the expanded ToxicPanda 2.0 campaigns.

Anyone banking, trading crypto, or using government/messaging apps on mobile or desktop in the targeted regions faces elevated risk from these phishing and overlay-driven operations.

Why it matters

These trojans combine credential phishing, remote device control, and data theft to empty accounts and enable fraud at scale. Manic’s offline mesh relay lets stolen data move even without direct internet to C2, complicating detection and isolation.

Grandoreiro’s decade-long persistence and DLL-sideloading abuse show how mature banking malware survives takedowns by blending with legitimate software. Builders and operators must assume continuous targeting of financial and messaging apps.

How it could have been prevented

On Android: sideload only from trusted sources, keep Google Play Protect on, review accessibility and overlay permissions, and avoid links from unsolicited messages. Use bank apps with strong biometric and transaction-signing controls.

On Windows: block DLL sideloading where possible, restrict execution of unexpected loaders, keep EDR/AV current, and apply application allow-listing for sensitive environments. Educate users on phishing lures that drop banking malware.

Monitor for unusual accessibility service use, overlay windows, and outbound connections from financial apps; isolate suspected devices promptly.

What happened

Windows named pipes enable fast local interprocess communication, yet weak access controls commonly let untrusted processes connect to privileged services and abuse exposed functionality.

ThreatLocker explains that developers often treat same-machine pipes as inherently trusted. In reality any process that knows the pipe name and holds sufficient rights can connect. A privileged service (for example running as LocalSystem) that exposes powerful operations through a pipe effectively offers a local API to those capabilities. Connection alone does not prove the client is the expected binary, the user is authorized, or the data is safe.

The risk is highest when a high-privilege server talks to a lower-privilege desktop client without proper identity checks, command authorization, or input validation.

Who is affected

Windows applications and services that use named pipes for IPC, especially privileged services communicating with user-mode clients, desktop apps, tray processes, or background agents.

Any Windows workstation or server running third-party software, scripts, or potentially compromised accounts is in scope; the issue is architectural rather than a single CVE.

Why it matters

A poorly protected named pipe can become a local privilege-escalation or lateral-movement path. Attackers or malware already on the box can issue commands to a LocalSystem service, modify protected resources, or abuse the service’s privileges without needing a remote exploit.

Builders who assume “local equals trusted” create attack surface that endpoint security and standard ACLs may not fully close. Operators inherit the risk whenever such software is deployed.

How it could have been prevented

Treat every named pipe as an exposed local interface. Verify the connecting client’s identity (process, user, integrity level), authorize only required commands, validate all input strictly, and run the pipe server with the least privileges necessary.

Apply narrow ACLs on the pipe so only intended principals can open it. Prefer impersonation and explicit checks over blanket trust. ThreatLocker and similar tools can enforce endpoint verification and command allow-listing for pipe traffic.

Review existing privileged services for pipe-based APIs and harden or redesign them before deployment.