TCPK

TCPK Security Audit Report

Generated 2026-07-06 05:16:54Z UTC · 35 findings

Executive summary

This audit of DVTA produced 35 findings (1 critical, 3 high, 8 medium, 12 low, 11 info). Evidence grade: 3 proven by IL/dynamic analysis; 12 confirmed; 18 to verify manually. Most significant: Update flow present; NO signature-verification primitives in first-party code; Hardcoded credential in .NET config appSettings (+1 more affected); High-entropy base64 token in DVTA.exe.config.

ApplicationDVTA
Version1.0.0.0
PublisherMicrosoft
Architecturex86
TypeWin32 application
Main exeDVTA.exe
RuntimeNative (C/C++)
PrivilegeasInvoker
InstallC:\ProgramData\DVTA
SigningNotSigned
UIunknown / custom
Networknot determined
Updatenone detected
3DLLs
2EXEs
0Drivers
2Endpoints
0Ports
0COM
0Pipes
0Services
0Handlers
0File-assoc
LLM: ollama / qwen2.5-coder:7b (available; pass -EnableLlm or pipe to Invoke-TcpkLlmCodeJudgment) · Time: scan 33s · Coverage: Coverage: 89 ran, 11 gated (no process), 0 need elevation, 21 quick-skip, 0 not implemented, 0 failed (of 121 checks)

RISK INDEX

100 CRITICAL

SEVERITY (35)

35 findings
Critical 1High 3Medium 8Low 12Info 11
Proven (IL/dynamic)3
Confirmed12
Inferred -- verify18
Likely-FP / Uncertain2

▾Standards coverage (OWASP Desktop App Top 10 + MITRE ATT&CK)

OWASP Desktop App Top 10 (2021) -- categories the findings map to (green = clear)
6
DA1
Injections
1
DA2
Broken Authentication
8
DA3
Sensitive Data Exposure
0
DA4
Improper Cryptography
0
DA5
Improper Authorization
1
DA6
Security Misconfiguration
4
DA7
Insecure Communication
7
DA8
Poor Code Quality
0
DA9
Components With Known Vulnerabilities
0
DA10
Insufficient Logging
by MITRE ATT&CK technique
T1059 Command and Scripting Interpreter7
T1553.002 Code Signing5
T1552.001 Credentials In Files4
T1027.002 Software Packing1
T1574 Hijack Execution Flow1
T1048 Exfiltration Over Alternative Protocol1

▾Remediation plan (20 prioritized fixes)

De-duplicated, highest risk first -- one row per fix. P1 = critical, P2 = high, P3 = medium/low.
P1
Sign update manifests with an offline-keyed RSA signature; sign each downloaded payload (Authenticode or detached PKCS#7); verify before any extract/exec.
update.no-signature-verification · CWE-345, CWE-347, CWE-494
CRITICAL1 finding
P2
Do not store credentials/API keys in appSettings. Use DPAPI, Windows Credential Manager, or a key vault and inject at runtime; rotate the exposed secret.
secrets.config-hardcoded-secret · CWE-260, CWE-798
HIGH1 finding
P2
Never ship a symmetric or private key in config. Derive a per-user key (DPAPI) or fetch from a key vault; rotate the exposed key. With key+IV+ciphertext all present, the protected value is trivially decryptable.
secrets.config-hardcoded-crypto-key · CWE-321, CWE-798
HIGH1 finding
P2
Do not ship secrets in files. Load them from a protected store (DPAPI / OS keychain / server-issued token) at runtime and rotate any exposed value.
entropy.high-entropy-token · CWE-312, CWE-798
HIGH1 finding
P3
Decompile the method (ILSpy / dnSpy) to confirm whether this is a real bug or a safe context.
callsites.base64-as-encryption, callsites.env-var-path-use, callsites.insecure-temp, callsites.sql-command-construction, callsites.ssrf-request-build · CWE-15, CWE-326, CWE-377, CWE-426, CWE-89, CWE-918
MEDIUM5 findings
P3
Exclude .pdb/.map from the shipped artifact (publish without symbols, or strip them).
devartifact.debug-symbols · CWE-489, CWE-540
MEDIUM1 finding
P3
Use https:// with certificate validation. If the host is HTTP-only, proxy it through an authenticated TLS endpoint.
scheme.cleartext-http · CWE-319
MEDIUM1 finding
P3
Use FTPS (FTP over TLS) or SFTP (SSH-based). Never send data or credentials over plain FTP, and never embed credentials in the URL.
scheme.cleartext-ftp · CWE-319
MEDIUM1 finding
P3
Move authorization / licensing decisions server-side; never trust a client-side boolean for access control.
authflags.client-side-gate · CWE-602, CWE-603
MEDIUM1 finding
P3
Obtain a SHA-256 (or stronger) code-signing certificate and re-sign.
authenticode.weak-cert-hash · CWE-327, CWE-347
MEDIUM1 finding
P3
Do not hardcode the IV. Generate a fresh random IV per encryption and store or transmit it alongside the ciphertext.
secrets.config-hardcoded-iv · CWE-329, CWE-798
MEDIUM1 finding
P3
Sign every shipped EXE/DLL with the company code-signing certificate.
authenticode.pe-not-signed · CWE-347, CWE-494
MEDIUM1 finding
P3
Sign the assembly during build (csc.exe /keyfile, or <SignAssembly>true</SignAssembly> in csproj).
strongname.unsigned
LOW1 finding
P3
Set ClearPageFileAtShutdown=1 in the registry (or via Local Security Policy: Shutdown: Clear virtual memory pagefile).
pagefile.no-clear-at-shutdown &middot; CWE-316
LOW1 finding
P3
For password and token handling, use SecureString and Marshal.SecureStringToGlobalAllocUnicode / ZeroFreeGlobalAllocUnicode, or wrap in ProtectedMemory blocks.
mem.hygiene-absent &middot; CWE-316
LOW1 finding
P3
If the logic/IP or any client-side check matters, apply an obfuscator AND move trust decisions server-side. Never rely on obfuscation to hide secrets.
obfuscation.absent &middot; CWE-1294, CWE-656
LOW1 finding
P3
Use TypeNameHandling.None / allowlisted KnownTypes / System.Text.Json polymorphism. Confirm runtimeconfig.json EnableUnsafeBinaryFormatterSerialization=false.
deser.xmlserializer &middot; CWE-502
LOW1 finding
P3
Never persist raw credentials to the registry. Protect them with DPAPI (ProtectedData) scoped to the current user, or use the Windows Credential Manager; store only non-reversible tokens where possible.
storage.registry-credential &middot; CWE-312, CWE-522
LOW1 finding
P3
For sensitive backends, pin the leaf or root cert thumbprint via ServerCertificateCustomValidationCallback (and confirm the callback actually pins, not just returns true).
tls.pinning-absent &middot; CWE-295
LOW1 finding
P3
Prefix any cell that starts with = + - @ (tab, CR) with a single quote, or enable the library's injection sanitisation (e.g. CsvHelper SanitizeForInjection).
csv.formula-injection-risk &middot; CWE-1236
LOW1 finding

▾Reconnaissance -- Network & Attack Surface

Network endpoints (backend hosts)

HostSample URL / auth markersFirst seen in
code.google.comhttp://code.google.com/p/excellibrary/ | auth markers in same PE: (none in nearby PE) [first-party; cleartext]ExcelLibrary.dll
msdn.comhttp://msdn.com/data/ef | auth markers in same PE: (none in nearby PE) [first-party; cleartext]EntityFramework.dll

Listening ports (live process)

No listening ports observed. (Live-port scan only runs when a ProcessName is supplied AND the app is running.)

Transport security posture

  • certificate pinning: ABSENT
All (35)CRITICAL (1)HIGH (3)MEDIUM (8)LOW (12)INFO (11)

▾CRITICAL (1)

#001 CRITICAL Inferred Update flow present; NO signature-verification primitives in first-party code update.no-signature-verification
CWE-494CWE-345CWE-347TASVS-NETWORK Network Communication
CVSS v4.09.3 · CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
WhatIf downloaded update content is not signature-verified before execution, anyone who can write to the update origin (or MITM the channel) achieves persistent RCE on every client. Confirm in ILSpy that DownloadUpdate / CheckForUpdate methods do not call any cryptographic verification path.
ImpactDirect compromise: code execution, privilege escalation, or exposure of live credentials with little/no precondition.
Why herePattern/heuristic match in a first-party binary; not proven by IL or dynamic analysis -- verify manually.
FileC:\ProgramData\DVTA\EntityFramework.dll
Evidenceupdate keywords: CheckForUpdate,UpdateAvailable,UpdateUrl,UpdateManifest,DownloadUpdate,LatestVersion,update-manifest,/firmware | sig keywords absent
Verify
verify
# WHAT THIS CHECKS: Inspects the app's update/download flow for missing integrity checks.
# STEP 1 - RUN THIS IN POWERSHELL:
Test-TcpkUpdateFlow -Path 'C:\ProgramData\DVTA'
# STEP 2 - READ THE OUTPUT:
#   VULNERABLE  if  it applies a downloaded update with NO signature or hash check (remote code execution via a poisoned update server).
#   OK          if  it verifies a signature or hash before extracting or running the payload.
# NOTE: decompile the update method to confirm the check actually runs.
# TOOL: PowerShell + a .NET decompiler
FixSign update manifests with an offline-keyed RSA signature; sign each downloaded payload (Authenticode or detached PKCS#7); verify before any extract/exec.
Audit notes [TCPK correlation: a CRITICAL/HIGH secret was also found in this audit -- combining a leaked credential with an unverified update flow is a supply-chain primitive against all customers.]

▾HIGH (3)

#002 HIGH Inferred High-entropy base64 token in DVTA.exe.config entropy.high-entropy-token
CWE-798CWE-312T1552.001 Credentials In FilesTASVS-STORAGE Sensitive Data StorageDA3 Sensitive Data Exposure
CVSS v4.06.9 · CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
WhatA high-entropy string was found in a shipped text/config file. Such tokens are frequently API keys, bearer tokens, or symmetric keys that prefix-based rules miss. Confirm whether it is a live credential.
ImpactSerious exposure: an attacker meeting a modest precondition can steal secrets, escalate, or bypass a security control.
Why herePattern/heuristic match in a first-party binary; not proven by IL or dynamic analysis -- verify manually.
FileC:\ProgramData\DVTA\DVTA.exe.config
EvidenceJ8gLXc...v8k8 (len=32, H=4.539)
Verify
verify
# WHAT THIS CHECKS: Surfaces long high-entropy strings in the file that might be embedded secrets.
# STEP 1 - RUN THIS IN POWERSHELL:
Select-String -Path 'C:\ProgramData\DVTA\DVTA.exe.config' -Pattern '[A-Za-z0-9+/_-]{24,}' -AllMatches | ForEach-Object { $_.Matches.Value }
# STEP 2 - READ THE OUTPUT:
#   VULNERABLE  if  a printed high-entropy string turns out to be a live key or secret.
#   OK          if  the strings are hashes, cache-busters, or asset IDs.
# TOOL: PowerShell
FixDo not ship secrets in files. Load them from a protected store (DPAPI / OS keychain / server-issued token) at runtime and rotate any exposed value.
#003 HIGH Inferred Hardcoded cryptographic key in .NET config appSettings (+1 more affected) secrets.config-hardcoded-crypto-key
CWE-798CWE-321T1552.001 Credentials In FilesTASVS-STORAGE Sensitive Data StorageDA3 Sensitive Data Exposure
CVSS v4.08.5 · CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
ImpactSerious exposure: an attacker meeting a modest precondition can steal secrets, escalate, or bypass a security control.
Why herePattern/heuristic match in a first-party binary; not proven by IL or dynamic analysis -- verify manually.
File2 files
Affected (2)
  • C:\ProgramData\DVTA\DVTA.exe.config
  • C:\ProgramData\DVTA\DVTA.vshost.exe.config
EvidenceJ8gLXc454o5tW2HEF7HahcXPufj9v8k8 [src=utf8] [2 affected: C:\ProgramData\DVTA\DVTA.exe.config; C:\ProgramData\DVTA\DVTA.vshost.exe.config]
Verify
verify
# WHAT THIS CHECKS: Scans the file's text for things that look like LIVE secrets - Azure storage keys, connection strings, PEM private keys, AWS access keys, or JWT tokens.
# STEP 1 - RUN THIS IN POWERSHELL:
([regex]::Matches([Text.Encoding]::Unicode.GetString([IO.File]::ReadAllBytes('C:\ProgramData\DVTA\DVTA.exe.config')),'DefaultEndpointsProtocol=https?;[A-Za-z0-9=;._/+\-]{0,300}AccountKey=[A-Za-z0-9+/=]{20,}|AccountKey=[A-Za-z0-9+/=]{20,}|-----BEGIN [A-Z ]+KEY|AKIA[A-Z0-9]{16}|eyJ[A-Za-z0-9_-]{10,}')).Value
# STEP 2 - READ THE OUTPUT:
#   VULNERABLE  if  it prints a real secret - e.g. AccountKey=..., a DefaultEndpointsProtocol=... connection string, an AKIA... AWS key, an eyJ... JWT, or a -----BEGIN ... KEY----- block.
#   OK          if  it prints nothing (only placeholders, or there are no secrets in the file).
# NOTE: this reads the file as UTF-16 (Unicode) text. If the secret is stored as plain ASCII, change ::Unicode to ::UTF8 and run it again. To dump EVERY readable string instead: strings.exe -u 'C:\ProgramData\DVTA\DVTA.exe.config'
# TOOL: PowerShell built-in (alternative: Sysinternals strings.exe)
FixNever ship a symmetric or private key in config. Derive a per-user key (DPAPI) or fetch from a key vault; rotate the exposed key. With key+IV+ciphertext all present, the protected value is trivially decryptable.
Audit notes [TCPK: 2 occurrences of this rule aggregated into one finding; see the affected list.]
#004 HIGH Inferred Hardcoded credential in .NET config appSettings (+1 more affected) secrets.config-hardcoded-secret
CWE-798CWE-260T1552.001 Credentials In FilesTASVS-STORAGE Sensitive Data StorageDA3 Sensitive Data Exposure
CVSS v4.08.5 · CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
ImpactSerious exposure: an attacker meeting a modest precondition can steal secrets, escalate, or bypass a security control.
Why herePattern/heuristic match in a first-party binary; not proven by IL or dynamic analysis -- verify manually.
File2 files
Affected (2)
  • C:\ProgramData\DVTA\DVTA.exe.config
  • C:\ProgramData\DVTA\DVTA.vshost.exe.config
EvidenceCTsvjZ0jQghXYWbSRcPxpQ== [src=utf8] [2 affected: C:\ProgramData\DVTA\DVTA.exe.config; C:\ProgramData\DVTA\DVTA.vshost.exe.config]
Verify
verify
# WHAT THIS CHECKS: Scans the file's text for things that look like LIVE secrets - Azure storage keys, connection strings, PEM private keys, AWS access keys, or JWT tokens.
# STEP 1 - RUN THIS IN POWERSHELL:
([regex]::Matches([Text.Encoding]::Unicode.GetString([IO.File]::ReadAllBytes('C:\ProgramData\DVTA\DVTA.exe.config')),'DefaultEndpointsProtocol=https?;[A-Za-z0-9=;._/+\-]{0,300}AccountKey=[A-Za-z0-9+/=]{20,}|AccountKey=[A-Za-z0-9+/=]{20,}|-----BEGIN [A-Z ]+KEY|AKIA[A-Z0-9]{16}|eyJ[A-Za-z0-9_-]{10,}')).Value
# STEP 2 - READ THE OUTPUT:
#   VULNERABLE  if  it prints a real secret - e.g. AccountKey=..., a DefaultEndpointsProtocol=... connection string, an AKIA... AWS key, an eyJ... JWT, or a -----BEGIN ... KEY----- block.
#   OK          if  it prints nothing (only placeholders, or there are no secrets in the file).
# NOTE: this reads the file as UTF-16 (Unicode) text. If the secret is stored as plain ASCII, change ::Unicode to ::UTF8 and run it again. To dump EVERY readable string instead: strings.exe -u 'C:\ProgramData\DVTA\DVTA.exe.config'
# TOOL: PowerShell built-in (alternative: Sysinternals strings.exe)
FixDo not store credentials/API keys in appSettings. Use DPAPI, Windows Credential Manager, or a key vault and inject at runtime; rotate the exposed secret.
Audit notes [TCPK: 2 occurrences of this rule aggregated into one finding; see the affected list.]
No findings match the current filter.