DomainTools Investigations | Exposure of TLS Private Key for Myclaw 360 in Qihoo 360 “Security Claw” AI Platform

Executive Summary

DTI analyzed the confirmed exposure of a Transport Layer Security (TLS) private key associated with the wildcard certificate *.myclaw[.]360[.]cn, which appears tied to the Security Claw (安全龙虾) artificial-intelligence assistant platform developed by Qihoo 360. Earlier public discussion of the issue relied primarily on screenshots and reposted commentary claiming that the certificate and private key were embedded in the platform’s installer package. The material provided for this investigation includes the full X.509 certificate and corresponding private key. Cryptographic validation confirms that the supplied private key matches the public key contained in the certificate, establishing that the exposed credential is authentic and operational rather than a placeholder or decoy.

The certificate is issued by WoTrus CA Limited under the issuing chain WoTrus RSA DV SSL CA 2. It is a wildcard certificate covering both *.myclaw[.]360[.]cn and myclaw[.]360[.]cn and was originally issued with a validity period spanning 12 March 2026 through 12 April 2027. Because wildcard certificates authenticate any host within the domain namespace, possession of the corresponding private key would allow an attacker to impersonate services across the entire Security Claw infrastructure if the certificate remained trusted and unrevoked.

Subsequent certificate-transparency analysis conducted during this investigation indicates that the certificate has since been rotated and replaced as part of an apparent incident-response action. CT log entries show that on 16 March 2026, a new wildcard certificate for *.myclaw[.]360[.]cn was issued with a new RSA key pair and shortened validity period, replacing the originally exposed certificate. The rapid issuance of the replacement certificate and the change in key material strongly suggest that Qihoo 360 detected the credential exposure and executed emergency key rotation to invalidate the compromised trust material.

Infrastructure analysis further confirms that the parent domain ecosystem (360[.]cn) is registered to Beijing Qihoo Technology Co., Ltd. (北京奇虎科技有限公司) and uses internally controlled DNS and mail infrastructure. This strongly supports attribution of the myclaw[.]360[.]cn namespace to Qihoo 360’s operational domain environment. The exposure therefore represents a confirmed cryptographic trust-material leak, with potential consequences including server impersonation, TLS interception, credential theft, and malicious update delivery within the Security Claw ecosystem. Although the certificate appears to have been rotated following discovery of the issue, the operational impact ultimately depends on whether the compromised key was actively deployed in production services and whether any adversary obtained the key prior to remediation.

Background: Qihoo 360 and the Security Claw Platform

Qihoo 360 is widely recognized as one of China’s largest cybersecurity and internet-technology companies, operating across both consumer and enterprise security markets. Since its founding in the early 2000s, the company has developed a broad portfolio of security and software products that include antivirus platforms, endpoint protection suites, web browsers, vulnerability-scanning tools, and large-scale threat-intelligence services. Through these products, Qihoo 360 has established an extensive user base spanning hundreds of millions of individual users as well as corporate and government customers. Much of the company’s security ecosystem is built around large telemetry pipelines that collect threat data from deployed endpoints and feed it into centralized analytics systems used to detect malware, exploit campaigns, and network intrusions.

In recent years the company has increasingly invested in artificial-intelligence technologies as part of its broader cybersecurity strategy. Like many large security vendors, Qihoo 360 has begun integrating machine-learning models and generative AI capabilities into its defensive tools, both to automate analysis tasks and to provide interactive interfaces for users and analysts. This effort has produced a range of AI-enabled assistants and intelligent agents designed to augment traditional security workflows. These systems typically allow users to query threat data, analyze malware samples, or receive automated recommendations through natural-language interfaces powered by backend AI models.

However, they have started pulling back on this, as they have begun learning about the pitfalls.

The Security Claw (安全龙虾) platform appears to be one of the products emerging from this initiative. Based on publicly available information and artifacts analyzed during this investigation, Security Claw functions as a locally installed client application that interacts with remote services operated by Qihoo 360. Rather than performing all processing locally, the client appears to act as a front-end interface that communicates with cloud-hosted AI infrastructure. These backend services operate within the myclaw.360.cn domain namespace, which appears to serve as the central network environment for the platform’s API endpoints and inference services.

Reports associated with the platform indicate that the client software connects to at least one backend endpoint located at https://myclaw[.]360[.]cn:19798, a service running on a non-standard port rather than the default HTTPS port 443. The use of such ports is common in internal service architectures where applications communicate directly with API gateways or service nodes without passing through standard web-server front ends. The presence of this endpoint suggests that the client communicates with a specialized service interface rather than a conventional public website.

Architecturally, this design reflects a hybrid deployment model commonly used by modern AI assistant platforms. In this model, a lightweight local application acts as a wrapper that manages user interactions, authentication, and system integration while delegating computationally intensive tasks such as natural-language processing, model inference, and large-scale data retrieval to cloud infrastructure. The client collects user prompts and contextual information from the local system and forwards these requests to backend services where AI models perform the actual analysis or generate responses.

Systems built on this architecture typically consist of multiple interconnected backend components. These may include authentication services responsible for validating client identities, API gateways that route requests to the appropriate services, telemetry collectors that gather usage and performance data from deployed clients, and inference endpoints hosting the machine-learning models used to generate responses. Additional components often include update services responsible for delivering model updates or configuration files to the client software. All of these elements operate together to create the user-facing experience of an AI assistant while relying on centralized cloud infrastructure to perform the majority of processing tasks.

Technical Findings

Certificate Structure

Analysis of the certificate associated with the Security Claw infrastructure indicates that it is a standard X.509 server authentication certificate issued for the wildcard domain namespace *.myclaw[.]360[.]cn. The certificate’s Common Name (CN) is configured as *.myclaw[.]360[.]cn, enabling it to authenticate any host operating under that subdomain space. In addition to the wildcard identifier, the certificate’s Subject Alternative Name (SAN) extension explicitly includes both *.myclaw.360[.]cn and the root host myclaw[.]360[.]cn. This configuration allows the certificate to be used by both the base domain and any subordinate services, a design pattern typically employed in microservice architectures where multiple backend services operate under a single domain namespace.

The certificate was issued by WoTrus RSA DV SSL CA 2, a certificate authority chain operated by WoTrus CA Limited, a Chinese certificate authority widely used within domestic cloud infrastructure and enterprise platforms. The certificate’s validity window begins on 12 March 2026 and extends through 12 April 2027, reflecting a relatively long operational lifespan typical of domain-validated certificates used in application backends. Cryptographically, the certificate employs an RSA 2048-bit public key, a widely adopted key size for TLS server authentication that provides an established balance between security strength and compatibility across client platforms.

The certificate is uniquely identified by the serial number 98dfeafdc4c32371f0ab490c8a3c7819, which serves as the certificate authority’s internal identifier for the issued credential. Its cryptographic fingerprint, calculated using the SHA-256 hashing algorithm, is 5a0a0df9695395223a1d342d2ccf82f449b342a281ed056dfa7880965bcbe3ca. This fingerprint provides a reliable mechanism for identifying the certificate across transparency logs, passive TLS telemetry, and network monitoring systems.

Functionally, the certificate is a domain-validated TLS certificate intended solely for server authentication. It does not contain certificate authority privileges and cannot be used to sign subordinate certificates or create additional trust anchors. Instead, its purpose is to enable servers operating under the myclaw[.]360[.]cn namespace to prove domain ownership during TLS handshakes, allowing clients to establish encrypted connections that they believe originate from legitimate Security Claw infrastructure.

The provided certificate is an X.509 server certificate with the following key attributes:

Common Name: *.myclaw.360.cn
‍Subject Alternative Names: *.myclaw.360.cn myclaw.360.cn
‍Issuer: WoTrus RSA DV SSL CA 2
‍Organization: WoTrus CA Limited
‍Validity Period: Not Before: 2026-03-12 Not After : 2027-04-12
‍Public Key Algorithm: RSA 2048-bit
‍Certificate Serial Number: 98dfeafdc4c32371f0ab490c8a3c7819
‍The certificate’s SHA-256 fingerprint is: 5a0a0df9695395223a1d342d2ccf82f449b342a281ed056dfa7880965bcbe3ca

Private Key Validation

Cryptographic analysis confirms that the private key provided in the dataset corresponds directly to the public key embedded within the associated TLS certificate. This relationship was verified by extracting and comparing the RSA modulus from both the certificate and the private key. The modulus values match exactly, demonstrating that the two artifacts form a valid cryptographic key pair.

This verification establishes that the exposed private key is the genuine operational key associated with the certificate rather than unrelated or fabricated data. In other words, the key is capable of performing the cryptographic operations required to authenticate servers presenting the certificate during Transport Layer Security (TLS) negotiations.

Within TLS architecture, the private key represents the confidential element of the certificate pair and functions as the mechanism by which a server proves its identity to connecting clients. During the TLS handshake process, the server must demonstrate possession of this secret key in order to validate that it legitimately controls the certificate presented to the client. If the server successfully performs this proof, the client accepts the certificate as authentic and proceeds to establish an encrypted communication channel.

Consequently, possession of the private key enables any system holding it to complete TLS handshakes that appear fully legitimate to clients relying on standard certificate validation. This capability effectively allows the holder of the key to impersonate servers operating under the certificate’s domain namespace and establish encrypted connections that clients would normally interpret as trusted communications with the genuine service.

Infrastructure Attribution

To assess ownership and operational control of the namespace, passive DNS intelligence and domain-registration data indicate that the namespace is part of the broader Qihoo 360 domain ecosystem. This determination provides strong evidence that the infrastructure supporting the Security Claw platform is operated directly within the company’s network environment.

The parent domain 360[.]cn is registered to 北京奇虎科技有限公司 (Beijing Qihoo Technology Co., Ltd.), a major Chinese cybersecurity and internet-technology firm. Domain registration records show that the domain was originally created on 17 March 2003 and is maintained through the registrar Xiamen eName Technology Co., Ltd. These details align with long-standing records identifying Qihoo 360 as the primary operator of the 360[.]cn domain space and its associated services.

‍

The use of dedicated DNS and mail infrastructure under corporate-controlled domains strongly suggests that Qihoo 360 manages its core network services internally rather than outsourcing these functions to third-party providers. This pattern is typical of large security vendors that maintain tight operational control over their infrastructure for security, reliability, and compliance reasons.

Additional enrichment data indicates that the 360.cn domain environment routinely deploys wildcard TLS certificates issued by WoTrus, the same certificate authority responsible for the *.myclaw.360.cn certificate examined in this investigation. The reuse of this certificate authority and wildcard certificate deployment pattern across the broader Qihoo domain ecosystem reinforces the conclusion that the MyClaw certificate originates from the company’s established PKI practices rather than from an unrelated or externally managed infrastructure.

Taken together, the domain registration data, passive DNS records, and PKI deployment patterns provide strong attribution linking the myclaw.360.cn namespace to Qihoo 360’s operational infrastructure, supporting the assessment that the exposed TLS credentials were associated with a service environment under the company’s direct control.

Threat Analysis

The exposure of a Transport Layer Security (TLS) private key associated with a wildcard certificate introduces several potential attack scenarios that could compromise both the integrity and confidentiality of communications within the affected service environment. Because TLS certificates serve as the cryptographic mechanism through which clients authenticate remote servers and establish encrypted channels, possession of the corresponding private key effectively allows an attacker to masquerade as legitimate infrastructure. In this case, the affected certificate covers the wildcard namespace *.myclaw[.]360[.]cn, meaning that any service operating under that domain could theoretically be impersonated if the certificate remained trusted and unrevoked.

One of the most direct risks presented by such an exposure is server impersonation. An attacker in possession of the private key could deploy a malicious server configured to present the same certificate during TLS negotiation. Because the certificate chains to a publicly trusted certificate authority and matches the expected domain namespace, client applications connecting to the attacker’s infrastructure would likely complete the TLS handshake successfully and treat the connection as legitimate. The wildcard nature of the certificate significantly amplifies this risk, as it would allow the attacker to impersonate any host within the myclaw[.]360[.]cn namespace rather than a single specific service endpoint.

A related and potentially more damaging scenario involves man-in-the-middle (MITM) interception. If an attacker were able to manipulate DNS responses, compromise a local network, or otherwise redirect client traffic, they could route requests intended for legitimate MyClaw infrastructure to servers under their control. Because the attacker possesses the correct private key, the TLS handshake would succeed and encrypted sessions would be established without triggering certificate warnings. Under such circumstances, the attacker could decrypt and inspect traffic passing through the connection. Data potentially exposed through such interception could include authentication credentials, session cookies, API tokens used by the application, and the contents of AI prompts or conversation logs exchanged between the client and backend inference services.

Another risk concerns malicious update distribution. Many modern software platforms retrieve updates, configuration files, or model components from backend servers under their operational domain namespace. If the Security Claw client retrieves such resources from endpoints within myclaw[.]360[.]cn, an attacker capable of impersonating those endpoints could deliver modified update packages or configuration files. In the worst case, this could allow the distribution of malicious binaries to client systems, effectively transforming the incident into a supply-chain compromise affecting all users receiving the spoofed updates.

Finally, the exposure creates the possibility of AI response manipulation within the Security Claw platform itself. Because the platform functions as an AI assistant that communicates with backend inference services, impersonating those services could allow attackers to alter responses returned by the AI system. This could enable injection of malicious prompts, manipulation of analysis results, or the insertion of misleading security guidance into automated workflows. In environments where the AI system assists with security analysis or operational decision-making, such manipulation could have cascading effects on downstream processes.

Taken together, these scenarios illustrate how the compromise of TLS trust material, particularly a wildcard certificate, can extend beyond simple traffic interception and potentially affect software distribution mechanisms, AI service integrity, and user trust in the platform’s infrastructure.

Potential AI-Enabled Attack Scenarios Leveraging Compromised Security Claw Infrastructure

The exposure of a private key associated with the wildcard TLS certificate for *.myclaw[.]360[.]cn introduces not only traditional network security risks such as impersonation and interception, but also a set of potential AI-enabled attack vectors that could exploit the architecture of the Security Claw platform itself. Because the platform appears to function as a locally installed AI assistant communicating with cloud-hosted inference services, control over the cryptographic trust boundary between client and backend services could enable adversaries to manipulate the AI system’s behavior in ways that extend beyond conventional software compromise. The integration of AI inference services into the operational workflow effectively creates a new attack surface in which model outputs, prompts, and analytic results become potential targets for adversarial manipulation.

One plausible attack scenario would involve AI response manipulation at the inference layer. If an attacker were able to impersonate backend inference services using the compromised certificate, they could intercept requests from the Security Claw client and return modified outputs generated by a malicious or modified AI model. In practice, this could allow the adversary to alter the results of automated security analyses performed by the platform. For example, malware samples submitted for analysis could be falsely classified as benign, while legitimate system components could be flagged as malicious. Such manipulations could degrade the reliability of the platform’s analytic output and undermine trust in automated security recommendations generated by the system.

Logic Diagram for Potential Attacks From Mistake

Another potential attack vector involves prompt-injection attacks targeting the AI interaction pipeline. Modern AI assistant architectures often rely on structured prompts sent from the client to backend models, where contextual instructions and system policies guide the model’s behavior. An adversary positioned within the communication channel could modify these prompts before they reach the inference service or inject additional instructions into the prompt stream. By manipulating these inputs, attackers could influence the behavior of the AI model, potentially causing it to disclose sensitive data, generate misleading analyses, or execute unintended actions within automated workflows. This type of attack is conceptually similar to adversarial prompt injection techniques observed in other large-language-model deployments.

A related scenario involves model poisoning or model-substitution attacks. If the Security Claw platform retrieves model components, configuration files, or inference instructions from backend servers under the myclaw[.]360[.]cn namespace, an adversary capable of impersonating those endpoints could distribute modified model weights or configuration artifacts to client systems. Such modifications could subtly alter the behavior of the AI system over time. For instance, the modified model might consistently downgrade the severity of certain classes of threats, ignore specific indicators of compromise, or generate outputs designed to mislead analysts reviewing the results. Because AI models often behave probabilistically rather than deterministically, detecting such manipulation could be significantly more difficult than identifying conventional malware.

The compromise could also enable data exfiltration through the AI interaction channel. Security Claw appears to operate as an assistant capable of processing user prompts, system telemetry, and potentially sensitive security data. If adversaries intercepted or controlled the backend inference endpoint, they could capture large volumes of input data sent from client systems. This data could include malware samples, internal network information, security logs, configuration data, or investigative notes submitted by analysts interacting with the AI assistant. Over time, such data collection could yield valuable intelligence about organizational networks, defensive tools, and investigative workflows.

Another possible attack vector would involve AI-driven social engineering and influence operations directed at analysts using the platform. If attackers controlled the AI responses returned to users, they could craft outputs designed to subtly influence human decision-making. For example, the AI might recommend specific remediation steps that inadvertently weaken security controls, suggest the dismissal of legitimate alerts, or provide misleading threat-intelligence summaries. Because users may perceive AI-generated recommendations as authoritative, particularly when the platform is marketed as a cybersecurity assistant, such manipulation could have cascading operational consequences within security operations centers or incident-response teams.

The exposure could further facilitate autonomous reconnaissance and exploitation capabilities embedded within the AI service architecture. If the adversary were able to modify backend AI services rather than merely impersonate them, they could theoretically integrate automated reconnaissance capabilities into the system itself. In this scenario, the AI service might analyze telemetry collected from client systems and automatically identify exploitable vulnerabilities or network configurations. Rather than simply returning analytic results to the user, the compromised system could covertly transmit reconnaissance data to attacker infrastructure or generate tailored exploit payloads targeting discovered weaknesses.

Finally, there is the possibility of supply-chain amplification through AI-driven automation. Security Claw’s architecture suggests that it may be integrated with broader Qihoo security services, potentially including threat-intelligence feeds, malware analysis pipelines, or automated defensive tooling. If attackers were able to manipulate the AI system at the backend level, they could leverage this integration to propagate malicious outputs across multiple connected services. For example, manipulated threat classifications could influence automated detection signatures distributed to endpoint security products, potentially degrading detection capability across a large installed base of users.

Taken together, these scenarios illustrate how the compromise of cryptographic trust material in an AI-enabled platform could enable attack techniques that extend beyond traditional network security threats. In conventional systems, the theft of a TLS private key primarily enables impersonation or interception attacks. In AI-integrated architectures, however, control over the communication channel between client and inference service also enables adversaries to manipulate the informational outputs of the system itself. Because users increasingly rely on AI-generated analysis to support operational decisions, such manipulation could have downstream effects that propagate through automated workflows, investigative processes, and defensive strategies.

Root Cause Assessment

The most plausible explanation for the exposure of the TLS private key is a failure within the software build and packaging pipeline used to produce the Security Claw client installer. Evidence associated with the incident indicates that the certificate and its corresponding private key were present within files bundled in the application’s installation package, suggesting that sensitive credential material was inadvertently included during the software build process.

In contemporary software development environments, application installers are frequently generated automatically through continuous integration and continuous delivery (CI/CD) pipelines. These pipelines often assemble installation packages directly from development repositories or build directories that may contain configuration files, test certificates, and other credentials used during internal development and debugging. If the build pipeline does not explicitly exclude such files through filtering rules or packaging controls, sensitive artifacts can unintentionally become part of the final distribution bundle.

This type of exposure is consistent with a broader class of supply-chain vulnerabilities in which development credentials are mistakenly distributed alongside production software. Similar incidents have been documented across the software industry, including cases where application installers or container images contained embedded API keys, code-signing certificates, or cloud service credentials. In each case, the root cause typically involved insufficient separation between development assets and production build artifacts, allowing confidential materials to propagate into publicly accessible software packages.

Analytical Assessment

The exposure of a private key associated with a wildcard TLS certificate constitutes a serious failure in the protection of cryptographic trust material. Within modern internet security architecture, TLS certificates serve as the foundation of authenticated encrypted communication between clients and servers. The corresponding private key is the critical secret that enables a server to prove its identity during the TLS handshake process. When this key is exposed outside of controlled infrastructure, the integrity of the entire trust relationship established by the certificate is compromised. In this case, the risk is amplified by the fact that the certificate is a wildcard credential for the domain namespace *.myclaw[.]360[.]cn, meaning that the key could theoretically authenticate any service operating under that domain hierarchy. As a result, possession of the private key could allow an attacker to impersonate multiple services across the platform rather than a single isolated endpoint.

Although the ultimate operational consequences depend on several factors including whether the certificate was actively deployed in production infrastructure and how quickly the credential was revoked or replaced, the discovery of the key in a publicly accessible software artifact strongly suggests that sensitive trust material was mishandled during the platform’s build or distribution process. Software installers and packaged binaries should never contain cryptographic secrets intended for server-side authentication. Their presence in distributed software indicates that development or deployment environments likely included credential files that were not properly excluded during packaging. Such mistakes are typically symptomatic of weaknesses in build pipeline controls, including insufficient separation between development assets and production artifacts, inadequate secret-scanning procedures, or a lack of automated checks designed to prevent sensitive files from being included in release builds.

The incident is particularly notable because it involves Qihoo 360, a company whose core business is cybersecurity. As a major provider of antivirus software, enterprise security tools, and threat-intelligence services, Qihoo 360 operates infrastructure that supports hundreds of millions of users. Organizations of this scale are expected to maintain mature security engineering practices, including strict credential management policies, secure build pipelines, and rigorous release validation procedures. The appearance of operational cryptographic material in distributed software raises questions about the robustness of those internal controls.

Even if the certificate was never deployed in production systems or if the exposure window was short due to rapid incident response and key rotation, the leak nonetheless highlights systemic risks associated with credential management within modern software development environments. Large-scale platforms frequently rely on numerous certificates, API keys, and other authentication secrets to operate complex distributed architectures. Without strong safeguards, these secrets can inadvertently propagate through development repositories, build directories, or installer packaging processes.

In this context, the exposure should be understood not only as a discrete technical vulnerability but also as an indicator of broader process weaknesses. Effective security engineering requires strict segregation of sensitive credentials, automated detection mechanisms for secrets in build artifacts, and clear procedures for revocation and rotation when exposure occurs. The presence of a valid TLS private key in publicly distributed software suggests that at least some of these controls were insufficiently implemented or failed during the platform’s release cycle. As AI-enabled platforms like Security Claw become more deeply integrated into security workflows and enterprise environments, ensuring the integrity of the cryptographic infrastructure underpinning these systems becomes increasingly critical.

Conclusion

Cryptographic validation confirms that the exposed material is a legitimate and operational TLS key pair for *.myclaw[.]360[.]cn. The RSA modulus in the certificate and private key match exactly, proving authenticity. The certificate chains to WoTrus RSA DV SSL CA 2, a publicly trusted authority, meaning any server using this key would be accepted as legitimate by clients.

The certificate’s structure aligns with Qihoo 360’s broader PKI practices, which rely on WoTrus-issued, domain-validated wildcard certificates to secure microservice-based architectures. As such, compromise of the private key represents a direct breach of the platform’s cryptographic trust boundary.

If deployed in production, the impact is substantial. An attacker with the key could impersonate any host within the myclaw.360.cn namespace, enabling seamless TLS-authenticated connections that appear legitimate. This extends beyond single-host compromise to full namespace-level impersonation. Under traffic redirection conditions (e.g., DNS or network manipulation), the same capability enables decryption and inspection of encrypted sessions, exposing credentials, tokens, and AI interaction data.

The risk also extends into platform integrity. Impersonated endpoints could deliver malicious updates or configuration data, while spoofed inference services could manipulate AI outputs or inject instructions into the interaction pipeline.

Impact ultimately hinges on deployment status and response timing. Evidence indicates the certificate was rapidly rotated, suggesting effective incident response and a potentially limited exposure window. However, if the key was obtained prior to rotation, exploitation during that interval remains plausible.

Further analysis should focus on certificate transparency logs, passive DNS telemetry, and any vendor disclosures to establish timeline, exposure scope, and whether the compromised certificate was ever actively used.