Today’s Topics:

• 9,308 Live AWS Keys Expose a Persistent Cloud Identity Problem
• How a Trusted Update Channel Turned Android Car Head Units Into Proxy Nodes
• How can Netizen help?

---

9,308 Live AWS Keys Expose a Persistent Cloud Identity Problem

Publicly exposed cloud credentials are often treated as a code hygiene problem: a developer commits a key, a scanner finds it, the key gets removed from the repository, and the incident appears closed. New research from Truffle Security shows why that model is dangerously incomplete. After re-verifying 10,616 complete AWS key pairs on August 10, 2026, researchers found that 9,308 still authenticated. The credentials had surfaced publicly between August 2022 and August 2026 across Git history, datasets, container images, package registries, CI logs, and other sources. Some had remained usable for years after entering public data sources.

The scale becomes more significant once permissions are considered. Truffle Security’s scanners had accumulated 431,875 verified AWS secret findings and deduplicated them into 64,024 unique access keys associated with 50,654 AWS accounts. Of those unique keys, 10,625 were root access keys, 48,744 belonged to IAM users, and 4,655 could not be classified at verification time. Root access keys represented 16.6 percent of the verified population. An AWS root principal is fundamentally different from an ordinary IAM identity: it begins with unrestricted account-level authority and cannot be constrained through the same IAM permission model used for ordinary users and roles. AWS itself recommends against creating root-user access keys.

Truffle Security then identified 817 still-active keys linked to businesses. Of those, 526 were root keys and 242 belonged to IAM users carrying the AWS-managed AdministratorAccess policy. Those two groups did not overlap, producing 768 active corporate credentials capable of granting full control over an AWS account. The research also identified 130 live root keys belonging to AWS Organizations management accounts. A compromised management account can present an especially serious risk since that account sits above member accounts in an organization and is used to administer organization-level functions.

This changes how exposed secrets need to be classified by incident-response teams. A leaked AWS access key is not simply confidential information that escaped a repository. It is an authentication artifact that can represent an active identity. Its impact is determined by the principal behind it, the policies attached to that principal, group memberships, resource policies, trust relationships, permissions boundaries, service control policies, and any roles the identity can assume. A key that appears narrowly scoped at first inspection may still lead to a more privileged role through an sts:AssumeRole path.

That distinction is especially relevant in AWS environments that make heavy use of role chaining and cross-account trust. An IAM user may possess relatively limited permissions directly yet retain permission to assume a deployment role, operations role, or administrator role. Trust policies on those roles determine which principals can assume them, and the resulting session receives the permissions assigned to the role. TruffleHog’s AWS Analyze research describes this problem by mapping the identity associated with a discovered credential, its attached policies, and potential role paths, including another trust-policy hop beyond a directly assumable role.

The persistence of the leaked credentials may be the most concerning part of the research. For 2,903 keys where researchers could use iam:ListAccessKeys to retrieve creation information, the median still-active key had been created 1,831 days earlier, or slightly more than five years. Half of those credentials were more than five years old. The oldest was 17.4 years old. Only 25, representing 0.9 percent of that set, had been created during the previous 30 days. This was not primarily a snapshot of freshly leaked development credentials. It was evidence of long-lived authentication material surviving years after exposure.

Rotation data painted a similar picture. Of the same 2,903 enumerable credentials, just 398 had a newer access key associated with the user. Truffle Security calculated that 86 percent showed no evidence of being rotated, superseded, or cleaned up. A credential can disappear from active development workflows yet remain usable against the AWS API indefinitely if the corresponding access key remains active. Removing the plaintext string from a source file does nothing to invalidate the credential itself.

Git makes that failure mode particularly persistent. Deleting a secret in a later commit does not erase it from earlier commits. Container layers can preserve files or build artifacts that are no longer visible in the final filesystem. CI output can expose environment variables or command arguments. Public datasets can copy source repositories at scale. Once copied into downstream archives, mirrors, datasets, model-training corpora, or container registries, the original organization loses practical control of every copy. Truffle Security found that 43 percent of its AWS key population appeared in more than one source.

Hugging Face was the largest single source identified in the research. Truffle Security reported 8,482 unique live AWS keys across 3,394 public datasets, with root keys accounting for 17.9 percent of the Hugging Face population. Many of those datasets were described as snapshots of public code prepared for training. In a separate scan covering 7.6 petabytes of public Hugging Face training data, researchers found 3,343 live AWS keys, and more than 900 could enumerate S3 buckets containing at least 51.7 terabytes of private data. The result shows how AI datasets can become a secondary persistence mechanism for secrets that originally leaked somewhere else.

Privilege analysis exposed another problem. Truffle Security attempted to enumerate managed and group policy names for 7,590 active IAM-user credentials. Of the 1,157 users that permitted the necessary queries, 976 had AdministratorAccess either directly or through a group, and another 144 had IAMFullAccess. The researchers caution that this subset is biased toward identities able to read IAM metadata, so the percentages should not be extrapolated across all leaked keys. The raw counts remain significant: hundreds of publicly exposed identities had administrative AWS permissions at the time they were tested.

The AWSCompromisedKeyQuarantine findings show that detection by the cloud provider does not automatically produce remediation. Truffle Security identified 929 active IAM users carrying an AWS compromised-key quarantine policy. Of those, 112 still carried an older version that AWS stopped applying in 2023, indicating that some had been identified as exposed at least three years earlier. The credentials still authenticated when researchers checked them. Quarantining a credential can reduce immediate impact, but leaving the identity active preserves technical debt and leaves defenders dependent on the scope of the quarantine controls.

Attackers do not need access to the AWS Management Console to exploit such credentials. An access-key ID and secret access key can be used through the AWS CLI, SDKs, or direct API requests. An attacker can begin with sts:GetCallerIdentity to identify the principal and account, then enumerate whatever services and metadata the principal is allowed to access. Depending on effective permissions, possible follow-on activity could include discovering S3 buckets, reading or modifying objects, creating or altering IAM identities, changing Lambda functions, modifying compute resources, accessing secrets, querying databases, deploying workloads for cryptocurrency mining, or establishing new persistence. The actual actions available depend on the identity’s effective authorization path.

Administrative credentials create a particularly difficult containment scenario since a knowledgeable attacker can use the legitimate AWS control plane rather than exploit software. New IAM users, roles, access keys, policies, trust relationships, Lambda functions, EC2 instances, security-group rules, access mechanisms, or cross-account relationships can serve as persistence mechanisms. Revoking the originally exposed key may stop one authentication path without removing changes already made through it. An exposed administrator credential needs to be treated as a possible cloud-account compromise, not merely a secret-rotation ticket.

CloudTrail becomes central to that investigation. Responders need to identify API activity associated with the compromised principal and establish a timeline covering the period from the earliest plausible exposure through revocation. High-risk events include IAM mutations, role assumptions, new access keys, policy changes, logging changes, unusual service creation, security-group modifications, access to sensitive S3 objects, Secrets Manager or Systems Manager Parameter Store activity, and actions originating from unfamiliar addresses or regions. Role sessions created from the compromised identity deserve separate review since temporary credentials issued before containment may remain valid until their session expires.

The study also found weak financial guardrails across many accessible accounts. Researchers were able to inspect budget information for 2,754 credentials, yet just 262 of those accounts had a budget alert. The median configured threshold was eight dollars. Among accounts where July 2026 cost data could be read, 50 had spent more than $1,000 during the month and nine had exceeded $10,000. The readable accounts collectively recorded $420,631 in July spending. Billing alerts are not a security control by themselves, but unusual increases in compute consumption can provide another signal for cryptomining or other unauthorized workload activity.

The deeper defensive lesson is that long-term access keys should be an exception. AWS recommends federated access and temporary credentials for human users, IAM roles and temporary credentials for workloads, regular removal of unused identities and credentials, least-privilege permissions, IAM Access Analyzer, and restrictive conditions where long-term keys cannot be eliminated. Workloads running in AWS can receive temporary role credentials directly, and external workloads have options such as IAM Roles Anywhere or identity federation rather than permanently embedded IAM-user keys.

Root access keys deserve immediate scrutiny. AWS explicitly recommends that organizations not create them, given the root user’s account-wide authority. Existing root keys should be inventoried and removed where they are not required. IAM-user access keys need similar lifecycle controls: ownership, purpose, creation date, last-use information, effective permissions, rotation history, and exposure status should all be visible to security teams. A credential with no known owner or workload is itself a security finding.

Secret scanning also needs to extend past the active branch of a source repository. Git history, forks, archived repositories, public container registries, build artifacts, CI logs, collaboration systems, model repositories, notebooks, package registries, and data-science platforms all create potential exposure paths. Discovery needs to be paired with verification. A five-year-old string that no longer authenticates is historical evidence; a five-year-old string that still authenticates is an active identity incident.

Once a valid AWS credential is discovered in a public source, defenders should assume that unauthorized parties could already possess it. Disabling or deleting the key closes the known authentication path, but response still requires reviewing effective permissions, role-assumption paths, CloudTrail activity, persistence mechanisms, resource changes, newly created credentials, and potentially accessed data. Administrative and root credentials warrant account-level investigation. Keys connected to an AWS Organizations management account warrant examination of member accounts as well.

The most consequential figure in Truffle Security’s research is not 431,875 secret findings or 64,024 unique keys. It is 9,308. Those credentials were publicly exposed, complete enough to test, and still accepted by AWS on August 10, 2026. The incident illustrates a gap between finding a secret and terminating the identity represented by that secret. In cloud infrastructure, that gap can remain exploitable for years.

---

How a Trusted Update Channel Turned Android Car Head Units Into Proxy Nodes

The software update mechanism inside a connected vehicle is supposed to establish trust: vendor-controlled infrastructure identifies new software, a system component retrieves it, and the device installs it with privileges ordinary applications do not receive. Kaspersky researchers have now documented an infection chain in which that trust path was used to deliver malware to Android-based automotive head units. The campaign targeted DoFun devices and ultimately converted compromised systems into nodes for advertising fraud and residential proxy activity. Kaspersky describes it as the first documented malware infection chain built around automotive head units as the target platform.

The distinction between this campaign and a conventional malicious Android application is significant. Researchers did not observe users searching for a questionable APK, following a phishing link, or intentionally enabling installation from an unknown source. The first malicious component was installed through TWCore, a legitimate system application already present on affected DoFun head units. TWCore performs analytics and software-update functions, placing it inside the device’s trusted software-distribution path.

Kaspersky discovered the activity in June 2026 after encountering an Android application with no user interface. The absence of any attempt to impersonate a normal application led researchers to examine how it was reaching devices. Telemetry showed that the malicious application was being installed by a package named com.tw.core, matching TWCore. Investigation of the updater then revealed an architectural feature capable of placing applications on devices even when those applications were not already installed.

TWCore receives update instructions through an MQTT message broker hosted under cardoor[.]cn. The update message contains information identifying APK files for download and installation. One field, installNotExists, controls whether TWCore can install an application absent from the device. When set to the appropriate state, the updater can retrieve a new APK and place it into TWCore’s external cache under its update path before installation. That functionality is legitimate in an update system that needs to deploy new components, yet it also means trust in the upstream update instruction can translate directly into code installation on the endpoint.

Kaspersky’s telemetry showed malware appearing in those download locations, with TWCore performing the installation. The first malicious stage was named JarService. JarService has no visible interface and acts primarily as a dropper. Its code contains multiple encrypted blocks that are decoded at runtime using a single-byte XOR scheme in which the key changes between blocks. The resulting serialized data contains information about the next-stage payload, including versioning and an execution entry point. In the sample analyzed by Kaspersky, execution moved into the wa method in the com.c.j.qbh class.

The second stage functions as a loader. It contains encrypted strings representing class names and relies on Java reflection to invoke the next component dynamically. The loader reports information about the implant to attacker infrastructure through an HTTP POST request, including fields such as the package name, application version, channel identifier, and DEX version. The command-and-control server responds with a URL identifying the next payload.

That payload is transmitted in an encoded format rather than as an immediately recognizable Android application. Kaspersky found that the serialized data begins with key material used to decode strings and the next DEX stage. Once decrypted, execution enters the init method of com.ast.sdk.BillingMain. Researchers manipulated version numbers found in the download path and recovered seven variants of this stage, indicating that the infrastructure supported versioned payload delivery rather than a single static malware sample.

The third stage turns the infection into a remotely managed platform. By default, the malware contacts its command infrastructure roughly every 90 minutes through a task API. The request includes information such as the device model, screen resolution, connected Wi-Fi SSID, MAC address, and malware configuration version. The server can respond with an updated configuration containing replacement command servers, update infrastructure, request paths, and polling information. This structure lets operators change backend infrastructure without redeploying the entire infection chain.

Commands are represented by identifiers the operators call productId values. The malware stores command definitions in Android SharedPreferences as serialized JSON and tracks versions using Unix timestamps. When the server references a new or updated command identifier, the implant retrieves the corresponding instruction data from another API endpoint. That arrangement gives the operators a modular tasking mechanism in which capabilities can be updated independently of the base malware.

Kaspersky documented a broader command set than the operators were actively using at publication time. The malware can retrieve stored values, manipulate clipboard contents, issue HTTP GET or POST requests, load URLs into an Android WebView, execute supplied JavaScript in that WebView, open browser resources, test host reachability through ICMP, and download and execute arbitrary code modules. Two loader commands were still incomplete in the analyzed version. At the time of publication, researchers observed attackers making practical use mainly of the HTTP capability and the arbitrary module-loading function named loadlib2.

The primary module delivered through loadlib2 was a reverse-proxy component called zhima. Rather than using the head unit primarily for data theft, the module turns the device’s network connection into infrastructure that other traffic can traverse. That transforms an infected automotive endpoint into a residential-style proxy node. Nokia researchers independently encountered the same proxy component in television set-top boxes, helping confirm its role. Kaspersky recovered eight versions of the zhima module during its analysis.

Residential proxy capacity has commercial and criminal value. Traffic exiting through ordinary consumer connections can appear less suspicious than traffic from hosting providers or known proxy infrastructure. Such nodes can be rented or otherwise monetized for web scraping, advertising manipulation, account abuse, fraud, and attempts to obscure the original source of network activity. A connected car head unit offers many of the same traits that make inexpensive Android TV boxes useful for this purpose: persistent connectivity, limited security monitoring, long operational lifetimes, and a network location that appears to belong to a normal consumer.

Kaspersky also found infrastructure linking the proxy component to services associated with the sale of residential proxy access. One command server used by zhima was linked to admin.uipoxy[.]com, where researchers located what appeared to be an administration portal. Registration-related documents on that infrastructure referenced domains connected with residential proxy businesses. Kaspersky used those relationships, naming artifacts inside related malware, and infrastructure overlaps as part of its attribution assessment.

The researchers attribute the operation with high confidence to MoYu Group, an actor associated with the BADBOX malware ecosystem. During analysis, they found a thread named mosdk-host-loader and traced related components to malware previously installed on Android television devices. One related service was named AdmoyuService. Kaspersky combined those naming links with substantial network-infrastructure overlap observed by both its own researchers and Nokia’s team to reach the MoYu attribution.

BADBOX has historically centered on low-cost Android devices that arrive compromised or gain malicious components through software distribution channels. Infected televisions, set-top boxes, and related embedded Android hardware can be repurposed for proxy services, ad fraud, and other monetization schemes. The DoFun case extends that model into automotive hardware and shows that attackers are willing to treat vehicle infotainment systems as another class of always-connected Android endpoint.

That finding needs to be interpreted accurately. There is no evidence in the published research that the malware manipulated steering, braking, acceleration, engine control, or another safety-critical driving function. BleepingComputer reports that Kaspersky found no interference with driving or critical vehicle-control systems. The observed objective was monetization through advertising activity and proxy-node deployment. Claims that this campaign allowed attackers to remotely drive vehicles would go beyond the available evidence.

The absence of demonstrated vehicle-control impact does not make the incident minor. Modern automotive head units occupy an unusual security position. They may have cellular connectivity, Wi-Fi, Bluetooth, GPS, microphones, local storage, USB connectivity, access to user accounts, and interfaces with other vehicle components. Their software lifecycle may span many years. Security monitoring on these devices is often far less mature than monitoring on corporate laptops or mobile phones. A compromise may remain unnoticed for long periods if the malware avoids disrupting normal infotainment behavior.

The supply-chain aspect creates a separate concern. Traditional endpoint guidance assumes that users or applications must cross a visible security boundary to install malicious software. In this case, the relevant trust decision existed upstream. A legitimate system updater received instructions and installed the first malicious stage. From the endpoint’s perspective, the activity originated through a component already authorized to perform software installation. Security controls centered only on blocking sideloaded applications would miss the central failure mode.

The public research does not establish exactly how the attackers gained the ability to make TWCore deliver the malicious package. BleepingComputer contacted Kaspersky and DoFun seeking more information on the initial compromise vector, and the reporting available at publication did not identify whether attackers compromised update infrastructure, credentials, backend services, an administrative interface, or another part of the distribution system. That gap matters. The evidence establishes abuse of the legitimate delivery mechanism; it does not establish the precise upstream intrusion technique.

For manufacturers, the case argues for treating embedded update infrastructure as part of the product’s security boundary. Update authorization, package signing, server authentication, administrative access, build integrity, backend credential protection, update logging, and rollback controls all matter. A system component capable of installing arbitrary new applications based on remote instructions creates a high-trust execution path. Compromise of that path can bypass many controls intended to distinguish trusted software from untrusted software.

Cryptographic package verification can reduce part of this risk if devices accept code signed only by authorized release identities and those signing identities are isolated from ordinary update administration. Signing alone does not resolve every distribution attack. If the same compromised environment can generate or authorize signed releases, attackers can still move through the trusted path. Release approval, signing-key custody, reproducible build practices, audit trails, and separation between build, signing, and distribution roles all become relevant controls.

Automotive defenders also need telemetry capable of detecting abnormal behavior after installation. A head unit making recurring connections to unfamiliar infrastructure, periodically submitting hardware and network information, loading dynamic DEX content, executing unexpected code through reflection, or acting as a network proxy creates behavioral indicators that can be detected independently of the original APK hash. Static hashes remain useful for known samples, but the versioned and modular structure documented by Kaspersky means defenders should expect payloads and infrastructure to change.

Network controls may provide another detection point. The malware reports to tasking infrastructure on a periodic schedule and receives modular commands from remote servers. The reverse-proxy component also needs external connectivity to provide its service. Manufacturers with fleet telemetry can look for anomalous destinations, unexpected long-lived outbound connections, unusual proxy-like traffic patterns, or network behavior inconsistent with navigation, media, telemetry, or legitimate update services. Such visibility is much harder to obtain when aftermarket devices operate without centralized vendor monitoring.

Kaspersky notified DoFun about the malicious distribution mechanism, and the company reported that it had resolved the security issues. Public reporting does not provide enough detail to independently assess the scope of that remediation or determine how many devices received malicious components before the fix. Kaspersky published hashes, domains, addresses, and other indicators from the infection chain that can aid investigation of affected devices and related infrastructure.

The broader significance of the campaign lies in the endpoint class it introduces into an established criminal model. Attackers did not need an infotainment system to contain high-value files. They needed a remotely reachable Android device, an internet connection, and a trusted mechanism capable of delivering code. Once those conditions existed, a car head unit could be monetized much like a compromised set-top box or other embedded device.

That changes the security question for connected automotive systems. Risk does not begin and end with whether an attacker can influence the operation of the vehicle. A head unit can still become unauthorized network infrastructure, participate in fraud, expose local network information, execute attacker-supplied modules, or serve as a durable foothold on hardware that owners rarely inspect for malware. The DoFun campaign demonstrates that the software supply chain for vehicle-adjacent computing systems now deserves the same scrutiny applied to other internet-connected embedded platforms.

---

How Can Netizen Help?

Founded in 2013, Netizen is an award-winning technology firm that develops and leverages cutting-edge solutions to create a more secure, integrated, and automated digital environment for government, defense, and commercial clients worldwide. Our innovative solutions transform complex cybersecurity and technology challenges into strategic advantages by delivering mission-critical capabilities that safeguard and optimize clients’ digital infrastructure. One example of this is our popular “CISO-as-a-Service” offering that enables organizations of any size to access executive level cybersecurity expertise at a fraction of the cost of hiring internally. 

Netizen also operates a state-of-the-art 24x7x365 Security Operations Center (SOC) that delivers comprehensive cybersecurity monitoring solutions for defense, government, and commercial clients. Our service portfolio includes cybersecurity assessments and advisory, hosted SIEM and EDR/XDR solutions, software assurance, penetration testing, cybersecurity engineering, and compliance audit support. We specialize in serving organizations that operate within some of the world’s most highly sensitive and tightly regulated environments where unwavering security, strict compliance, technical excellence, and operational maturity are non-negotiable requirements. Our proven track record in these domains positions us as the premier trusted partner for organizations where technology reliability and security cannot be compromised.

Netizen holds ISO 27001, ISO 9001, ISO 20000-1, and CMMI Level III SVC registrations demonstrating the maturity of our operations. We are a proud Service-Disabled Veteran-Owned Small Business (SDVOSB) certified by U.S. Small Business Administration (SBA) that has been named multiple times to the Inc. 5000 and Vet 100 lists of the most successful and fastest-growing private companies in the nation. Netizen has also been named a national “Best Workplace” by Inc. Magazine, a multiple awardee of the U.S. Department of Labor HIRE Vets Platinum Medallion for veteran hiring and retention, the Lehigh Valley Business of the Year and Veteran-Owned Business of the Year, and the recipient of dozens of other awards and accolades for innovation, community support, working environment, and growth.

Looking for expert guidance to secure, automate, and streamline your IT infrastructure and operations? Start the conversation today.

---