DeepSeek’s rapid ascent in the AI space has made it impossible to ignore. Its sophisticated models and AI assistant have captured global attention. And, while headlines focus on DeepSeek’s capabilities, STRIKE research exposes critical security flaws, hidden data flows, and unanswered questions about who has access to the data and why.

STRIKE’s in-depth analysis of the DeepSeek Android application uncovered serious vulnerabilities, including hardcoded encryption keys, weak cryptographic algorithms, and potential for SQL injection attacks.

Data isn’t just being collected. It’s being transmitted to domains linked to Chinese state-owned entities, raising concerns about data sovereignty and national security. Additionally, embedded ByteDance code suggests possible data-sharing connections that aren’t clearly disclosed.

Perhaps most concerning, DeepSeek’s app employs anti-debugging mechanisms designed to obstruct security analysis—an unusual move for a company claiming transparency. 

While the app doesn’t exhibit overtly malicious behavior, the combination of poor security practices, aggressive data collection, and obscure third-party ties creates risks organizations can’t afford to overlook.

This deep peek  isn’t just about what DeepSeek does—it’s about what it leaves unsaid.

Key Findings overview

• The DeepSeek Android app has security vulnerabilities, such as weak encryption, SQL injection risks, and hardcoded keys.
• It has a broad data collection scope, including user inputs, device data, and keystroke patterns, stored in China.
• There are concerns about data transmission to Chinese state-owned entities and ByteDance.
• The app employs anti-debugging mechanisms.
• DeepSeek has faced regulatory scrutiny and bans in multiple countries.
• Code analysis reveals integration with ByteDance‘s services.
• The app requests permissions for internet access, phone state, and location.
• Third-party domains that the app connects to, like Ktor, have failing security scores, which raises business risks related to data security.
• Despite security weaknesses and  privacy concerns, no overtly malicious behavior was detected.

Version 1.0.8 was reviewed as updated on the Google Play store 

The linked DeepSeek privacy policy was reviewed as part of the analysis process to ensure no policy misconfigurations were present.

DeepSeek’s Privacy Policy Review

Starting with reviewing DeepSeek’s Privacy Policy, several aspects raise potential concerns:

Data Collection Scope

• User Input: The policy states that DeepSeek collects “text or audio input, prompt, uploaded files, feedback, chat history, or other content that you provide to our model and Services.” This encompasses a broad range of personal data, including potentially sensitive information.
• Technical Information: DeepSeek gathers detailed technical data such as device model, operating system, IP address, and notably, “keystroke patterns or rhythms.” The collection of keystroke dynamics is particularly intrusive, as it can be used to infer user behavior and identity.

Data Storage Location

• The policy indicates that collected information is stored on “secure servers located in the People’s Republic of China.” Given China’s data protection laws, this raises concerns about potential government access to user data.

Data Usage and Sharing

• While the policy outlines various uses for the collected data, such as service improvement and security, it lacks specificity regarding third-party data sharing. The absence of clear information about who has access to the data and under what conditions is concerning.

Regulatory Scrutiny

DeepSeek has faced international regulatory actions due to its data practices. 

• Italy’s data protection authority blocked DeepSeek for insufficient responses regarding their privacy policies.
• Australia banned DeepSeek from all government systems, citing national security concerns.
• The U.S. Navy advised personnel against using DeepSeek due to security and ethical issues

These actions highlight global apprehension about DeepSeek’s data handling practices. The broad data collection scope, storage of data in China, and perceived lack of clarity on data sharing, and international regulatory concerns all need to be investigated. 

So let’s see what’s going on.

Research Analysis Workflow

1. APK Extraction

• Identify the installed package
• Retrieve the APK path
• Pull the APK from the device

2. Static Analysis

• Decompile APK (Apktool)
• Review AndroidManifest.xml for permissions
• Inspect smali code and embedded resources

3. Dynamic Analysis

• Network Traffic Monitoring (Burp Suite)
  • Set up proxy
  • Capture and analyze HTTP/S traffic
• Runtime Instrumentation (Frida)
  • Install and attach Frida
  • Hook API calls and modify execution

4. Key Findings & Threat Intelligence

• Credential exposure (hardcoded keys, tokens)
• Network request analysis (data leakage, session risks)
• Cryptographic flaws (weak encryption, hardcoded keys)
• Exploitable vulnerabilities (SQL injection, code execution)

5. CWE Mapping & Risk Assessment

• Identify security issues based on CWE classification
• Document API usage tied to vulnerabilities
• Assess severity and potential impact

Research Analysis Setup

Research was performed using Android Development Studio, an emulated Android Virtual Device (AVD) Pixel 9 Pro running Android 15 with the DeepSeek application installed from the play store directly.

Step 1: APK Extraction

Before conducting static and dynamic analysis, we need to retrieve the APK from a connected Android device. We use ADB (Android Debug Bridge) to locate and extract the APK:

1.1 Identifying the Installed Package

These commands connect to the emulated android device for installed packages related to DeepSeek. Once the package name is confirmed, we proceed with locating its installed path:

Output:

1.2 Pulling the APK from the Device

Using the extracted path, we pull the APK file from the device:

Step 2: Static Code Analysis

Static analysis allows us to inspect the app’s source code without execution. This can help identify vulnerabilities such as hardcoded credentials, insecure storage, or misconfigured security settings.

2.1 Decompiling the APK

To convert the APK back into readable code, we use Apktool:

This produces a directory with smali code, resources, and configuration files

From here, we analyze:

• AndroidManifest.xml for permission overreach
• smali/ directory for potential security flaws
• res/ folder for embedded assets

Quick manual checks into the decompiled code can reveal how the log functions work and what data they are capturing.

Leveraging Android Developer Studio tooling, the majority of issues revolve around non-cyber security development practices 

Extracted connectivity elements from static and dynamic code.(In appendix below in full)

• Unique Domains: 20
• Unique URLs: 26
• Unique IPs: 9

Note: IPs captured in Frida.

Capturing these IP’s in their IPv6 compressed form, we just need to map the hex to the IPv4 address.  The last 32 bits represent the IPv4 address.

• 0:0:0:0:0:ffff:2d08:e534
• 2d08:e534 are the IPv4 address in hexadecimal.
• Convert 2d08 to decimal → 45.8
• Convert e534 to decimal → 229.52
• IPv4: 45[.]8[.]229[.]52

This method is commonly used to allow IPv6 systems to communicate with IPv4 hosts.

Step 3: Dynamic Code Analysis

After the static review, we monitor the application’s runtime behavior using Burp Suite (for HTTP/S traffic interception) and Frida (for function hooking and code manipulation).

3.1 Setting Up Burp Suite for HTTPS Interception

Intercepting Network Traffic

1. Set up Burp Suite Proxy:
   • Open Burp Suite → Proxy tab → Options → Add a listener on 127.0.0.1:8080.
2. Configure the Android device to use Burp as a proxy:

1. Install Burp’s CA certificate on the device:
   • Open http://burpuite in the device browser and install the certificate.
2. Start capturing traffic by launching the app and observing Burp’s HTTP history.

3.2 Setting Up Frida for Runtime Analysis

Frida allows us to hook into the app’s methods and dynamically modify code execution.

Installing Frida on the Device

Verifying Frida Connection

On the host machine:

3.3 Hooking Methods with Frida

Once attached to the target application, Frida enables dynamic instrumentation of functions at runtime. In the example below, we focus on bypassing SSL pinning to intercept and analyze network traffic from the installed DeepSeek application

Strike then wroke a script to specifically hook into the crypto functions of the application in an attempt to capture encryption keys.

Key Findings

CWE Mappings to Source Code Snippets

Leveraging the MITRE list of   Common Weakness Enumeration (CWE™)  in software and hardware with attributes that could lead to a vulnerability the following weaknesses were discovered in the decompiled APK.

These findings, and their code sections can be found in full in the appendix below.

Credential Exposure & Sensitive Data Leakage

Analysis of extracted sensitive data revealed instances of API keys, passwords, and authentication tokens stored in plaintext within the application files. This increases the risk of unauthorized access and account takeover as evidences by burp interception and Frida

Network Request & Response Analysis

Analysis of network requests and responses identified no known TTP’s or patterns of potentially malicious behavior, including unauthorized data collection and transmission to external servers. This is all covered in the privacy policy

How Requests Work:

From DeepSeek’s API documentation

• User Sends Request – A request is sent with chat messages, model choice, and optional parameters (e.g., temperature, max tokens).
• Model Processes Input – The model (e.g., deepseek-chat) analyzes the input and applies parameters like frequency/presence penalties and sampling methods (temperature/top_p).
  

• Observed Behavior: Application sends user interaction data to external analytics servers.
• Security Concern: Authentication tokens in headers increase the risk of session hijacking if intercepted.

How Responses Work

• Response Generation – The model generates a response based on the chat history while considering max_tokens, stop sequences, and other constraints.
• Response Delivery – The API returns the response in JSON format, including metadata like model ID, token usage, and timestamps.

• Observed Behavior: Application receives tracking data and stores persistent session cookies.
• Security Concern: If cookies lack proper security flags, they can be stolen via MITM attacks.

Additional Interesting findings to note

• During static analysis code was searched for non-ASCII characters, captured and then translated

• These comments were captured to translate and understand if there were any significant insights.
• The text contains several elements that point towards debugging, error logging, and crash reporting on an Android system. Based on the structure of the words, here’s what it could indicate:

Here is a sampling of the decoding and translated characters.  

The most interesting finding was the hint of Anti-Debugging Mechanisms: Analysis of the application’s Smali code revealed multiple anti-debugging techniques. 

• The application invokes android.os.Debug.isDebuggerConnected() and android.os.Debug.waitForDebugger() to detect active debugging sessions. Additionally, system properties are queried using System.getProperty(“ro.debuggable”) and System.getProperty(“ro.secure”) to determine if the application is running in a debug-enabled environment.
  •  If debugging is detected, the application force-closes itself (I did experience this behavior in the beginning of this research and was able to circumvent the checks) to prevent analysis. Further, dynamic instrumentation detection is implemented by checking for Frida hooks through string comparisons of /proc/self/maps against known Frida signatures.

ByteDance Code Implications

The analysis of the extracted codebase reveals multiple direct references to ByteDance–owned libraries, services, and telemetry frameworks, including ApmInsight, SlardarConfigManager, and WebViewMonitorHelper. These references suggest deep integration with ByteDance’s analytics and performance monitoring infrastructure. Specifically:

• ApmInsight – Captures app performance, errors, and user interactions.
• SlardarConfigManager – Enables remote configuration, feature flagging, and policy enforcement.
• WebViewMonitorHelper & TrafficTransportService – Tracks web interactions, monitors network requests, and may intercept encrypted traffic.

Key Concerns

• Data Collection – User behavior and device metadata likely sent to ByteDance servers.
• Remote Control – ByteDance can dynamically alter app behavior post-installation.
• Privacy Risks – Potential compliance issues with GDPR, CCPA, and national security laws due to data transmission to ByteDance-controlled endpoints.

What does all of this mean? 

• The DeepSeek application as analyzed is not performing any malicious requests, or operating outside of its permissions scope.
• The connectivity outbound to any domains and IP address do not immediately raise suspicion for malicious connection, there are data privacy concerns. 
  • There are instances where third party providers may have been victim to a historical breach, ransomeware or have known CVE’s. 
• There are vulnerabilities in the Android application that expose AES keys, API keys and other sensitive data when inspected both dynamically and statically.
• Examining the AndroidManifest.xml, we identified permissions such as android.permission.INTERNET, android.permission.READ_PHONE_STATE, and android.permission.ACCESS_FINE_LOCATION, indicating the potential for data collection beyond normal usage.

• Dynamic Analysis: Consistent outbound connections to domains such as abtest.volceapplog.com, apmplus.volces.com, and gator.volces.com. These domains resolve to IP ranges registered under Chinese ASN entities, including AS4808 (China Telecom) and AS4134 (China Unicom).

Final Considerations

Even if an application is not malicious as written, where you are sending data is a risk to accept.  Please review privacy policy and application permissions. 

• Extensive Data Collection: DeepSeek gathers user input, device data, IP addresses, and even keystroke patterns, raising concerns about privacy and potential behavioral profiling.
• Data Stored in China: All collected data is stored on servers in the People’s Republic of China, making it subject to Chinese data laws and potential government access.
• Regulatory Actions & Bans: DeepSeek has faced bans or restrictions from Italy, Australia, and the U.S. Navy, citing national security and privacy risks.
• Security Weaknesses in App Code: The Android app contains vulnerabilities including hardcoded encryption keys, weak cryptography (DES), SQL injection risks, and improper file permissions.
• ByteDance Ties: Code analysis reveals integration with ByteDance’s analytics and monitoring services, suggesting potential data sharing with ByteDance-controlled infrastructure.
• No Malicious Behavior Detected: Despite privacy concerns, the app operates within its defined permissions and does not show overt malicious intent. However, the destination of collected data remains a privacy and security risk.

Contact STRIKE for Incident Response

If you suspect your organization has been impacted by Operation Phantom Circuit, Operation 99, or similar Lazarus activities, contact the STRIKE Incident Response team immediately. Our experts provide:

• Rapid Containment: Minimize damage and halt ongoing breaches.
• Forensic Analysis: Understand how attackers gained access and what data was affected.
• Strategic Guidance: Strengthen your security posture against evolving threats.

Proactively Mitigate Supply Chain Risks

To protect your organization from future supply chain attacks, SecurityScorecard’s Supply Chain Detection and Response (SCDR) solution offers the tools to:

• Monitor and assess your software supply chain for vulnerabilities.
• Detect suspicious activity across your development pipelines.
• Receive actionable insights to prevent advanced threats.

Take control of your supply chain security today. Contact us for assistance or to learn more about SCDR and incident response services.

For STRIKE media inquiries, contact us here.

Appendix

For a downloadable copy of communications, see: STRIKE_SecurityScorecard_DeepPeek_STIX.json

1. CWE-327: Use of Weak Cryptographic Algorithm

• Risk Level: High
• Detected API Usage:
  • javax.crypto.Cipher.getInstance(“DES”)
  • javax.crypto.Cipher.init(int, Key)
• Code Snippet:
  • Cipher cipher = Cipher.getInstance(“DES”);
  • cipher.init(Cipher.ENCRYPT_MODE, key);

2. CWE-89: SQL Injection

• Risk Level: High
• Detected API Usage:
  • android.database.sqlite.SQLiteDatabase.rawQuery(String, String[])
  • java.lang.StringBuilder.append(String)
• Code Snippet:

• • String query = “SELECT * FROM users WHERE username = ‘” + userInput + “‘”;
  • Cursor cursor = database.rawQuery(query, null);

3. CWE-94: Improper Control of Code Generation (Code Injection)

• Risk Level: Low
• Detected API Usage:
  • java.lang.ClassLoader.loadClass(String)
• Code Snippet:

• • ClassLoader classLoader = getClassLoader();
  • Class<?> clazz = classLoader.loadClass(userInput);

4. CWE-502: Deserialization of Untrusted Data

• Risk Level: Low
• Detected API Usage:
  • java.io.ObjectInputStream.readObject()
• Code Snippet:

• • ObjectInputStream in = new ObjectInputStream(socket.getInputStream());
  • Object obj = in.readObject();

5. CWE-321: Use of Hard-Coded Cryptographic Key

• Risk Level: High
• Detected API Usage:
  • javax.crypto.spec.SecretKeySpec
  • java.lang.String.getBytes()
• Code Snippet:

• • byte[] keyBytes = “hardcoded_key”.getBytes();
  • SecretKeySpec key = new SecretKeySpec(keyBytes, “AES”);

6. CWE-79: Improper JavaScript Execution

• Risk Level: High
• Detected API Usage:
  • android.webkit.WebSettings.setJavaScriptEnabled(true)
• Code Snippet:

• • WebView webView = new WebView(context);
  • WebSettings webSettings = webView.getSettings();
  • webSettings.setJavaScriptEnabled(true);

7. CWE-732: Overly Broad File Permission

• Risk Level: High
• Detected API Usage:
  • java.io.File.exists()
• Code Snippet:

• • File file = new File(“/storage/emulated/0/mydata.txt”);
  • if (file.exists()) { … }

8. CWE-276: Incorrect Default Permissions on Files

• Risk Level: Moderate
• Detected API Usage:
  • android.os.Environment.getExternalStorageDirectory()
• Code Snippet:

• • File file = new File(Environment.getExternalStorageDirectory(), “mydata.txt”);

9. CWE-78: Improper Use of External Commands

• Risk Level: Moderate
• Detected API Usage:
  • java.lang.Runtime.exec(String)
• Code Snippet:

• • String command = intent.getStringExtra(“command”);
  • Runtime.getRuntime().exec(command);