Pentesting thick-client Windows: aplicaciones de escritorio 2026

Un thick-client es una aplicación de escritorio que ejecuta lógica de negocio en la máquina del usuario y conserva estado local, en lugar de delegar todo a un navegador o a un backend remoto. En 2026 sigue siendo el formato dominante en banca de trading, ERP especializados, software industrial, plataformas hospitalarias y buena parte del software vertical que mueve operaciones críticas. Auditar una app web no tiene nada que ver con auditar un thick-client: el binario vive dentro del perímetro del atacante, la lógica de validación es accesible con un decompilador y los secrets que el desarrollador creía ocultos en la DLL se extraen en horas.

Esta guía cubre por qué un thick-client necesita pentest específico, qué arquitecturas dominan el panorama Windows actual, las fases técnicas de la auditoría, el tooling que un equipo serio usa, las familias de vulnerabilidad recurrentes, el caso particular de Electron y el endurecimiento mínimo de cualquier desarrollo desktop.

Lo esencial. Un thick-client expone su binario, su tráfico y su lógica al usuario final. Las vulnerabilidades más rentables no son web típicas sino reverse engineering de assemblies .NET, DLL hijacking, IPC sin autenticación, secrets hardcodeados y bypasses de autenticación local. La defensa pasa por firmar binarios, almacenar secrets en DPAPI o Windows Credential Manager, pinear certificados de verdad y aceptar que la obfuscación retrasa al atacante pero no lo detiene.

Por qué un thick-client merece pentest separado

Un thick-client cambia el modelo de amenazas respecto a una app web por tres razones técnicas.

Primero, la lógica del cliente es accesible. La app web entrega HTML, CSS y un bundle JavaScript minificado, pero la validación crítica vive en el servidor. En un thick-client la validación de licencia, los workflows de autorización local, los formularios firmados y a veces hasta la lógica de pricing viven dentro del binario. Quien tenga el ejecutable los lee.

Segundo, el debugging local es viable y barato. Un atacante sentado frente a su PC carga la app en WinDbg, x64dbg o dnSpy, pone breakpoints, inspecciona memoria y modifica el flujo. Eso no se hace contra un backend remoto sin previa explotación.

Tercero, los secrets acaban en el binario: API keys SaaS, strings de conexión a BD, certificados embebidos, tokens OAuth de cliente confidencial, claves simétricas, URL de endpoints internos. El desarrollador asume que "no se ve" porque está compilado; un grep de strings y un decompilador lo enseñan en minutos.

A esto se suma cumplimiento: PCI DSS, NIS2, DORA e ISO 27001 cubren el software que procesa datos sensibles, sin distinguir web o desktop. Un thick-client que mueve datos PCI o transacciones DORA entra en el alcance del pentest exigido.

Arquitectura típica de un thick-client Windows

La superficie varía con el stack. Las cinco familias que cubren la mayoría de aplicaciones desktop Windows en 2026:

• .NET (WPF, WinForms, MAUI). Stack dominante para software empresarial Windows nuevo. Assemblies .exe y .dll con código IL que se decompila con dnSpy o ILSpy a algo muy cercano al C# original. La obfuscación comercial (Dotfuscator, ConfuserEx) eleva el coste pero rara vez bloquea a un atacante motivado.
• MFC y C++ nativo. Legacy todavía habitual en industria, sanidad y banca. Binarios PE clásicos, sin IL intermedio. Reverse con IDA Pro o Ghidra, más caro pero más opaco.
• Electron. La opción de moda para apps multiplataforma que reutilizan equipo web. El binario es Chromium empaquetado con un bundle JavaScript dentro de un ASAR, que se desempaqueta con un comando.
• Java Swing y JavaFX. Sectores donde Java sigue siendo lengua franca: sanidad, administración pública, defensa. .class y .jar se descompilan con JD-GUI o CFR a Java legible.
• Delphi legacy. Miles de aplicaciones empresariales escritas en Delphi décadas atrás siguen en producción. Binarios complicados de revertir, pero la opacidad no equivale a seguridad.

Identificar el stack es el primer paso, porque condiciona herramientas, vectores y profundidad.

Fases de un pentest thick-client

La metodología que aplicamos en Secra se articula en cinco fases solapadas.

1. Information gathering. Inventario del binario y su entorno: arquitectura (32/64 bit), firmas Authenticode, DLLs cargadas, recursos embebidos, archivos de configuración, ramas de registro tocadas, servicios Windows asociados, puertos en escucha, certificados embebidos. Sigcheck, PEStudio y dependencies.exe cubren el grueso.
2. Reverse engineering. Decompilación según stack: dnSpy o ILSpy para .NET; IDA Pro o Ghidra para nativo; JADX o CFR para Java; asar extract y análisis estático del bundle JS para Electron. Búsqueda de strings sospechosas, claves criptográficas, endpoints internos y lógica de autorización parcheable.
3. Traffic analysis. Proxy interceptor (Burp Suite, mitmproxy) entre la app y el backend. Bypass de pinning, captura completa, identificación de protocolos custom (RPC binario, MQTT, AMQP, WebSocket). Wireshark para tráfico no HTTP.
4. Logic abuse. Manipulación del cliente: parcheo de checks de licencia, bypass de autenticación local, modificación de límites, abuso de roles cliente que el backend confía sin revalidar. La fase donde se confirma que el backend no es la frontera real.
5. IPC analysis. Canales entre procesos del propio software: named pipes, COM, RPC, sockets locales. Comprobación de autenticación, autorización y validación de entrada en cada uno. Uno de los vectores más infravalorados por desarrollo.

Tooling para pentest thick-client

Stack que cualquier auditor desktop tiene preparado:

• IDA Pro y Ghidra para reverse de binarios nativos. Ghidra gratuito y abierto; IDA Pro referencia en industria.
• dnSpy e ILSpy para .NET. dnSpy permite editar y recompilar assemblies en caliente, oro para validar bypasses.
• JADX y CFR para descompilar Java.
• Frida para instrumentación dinámica multiplataforma. Hookea funciones, modifica argumentos y retornos, neutraliza checks de integridad y pinning.
• WinDbg y x64dbg para debugging nativo. WinDbg es la herramienta canónica de Microsoft para análisis de memoria y dumps.
• Process Monitor (ProcMon) y Process Explorer de Sysinternals para observar registro, ficheros, red y procesos hijo. Imprescindibles para DLL hijacking y abuso de rutas controlables.
• Procdump para volcar memoria de un proceso vivo y buscar secrets que solo aparecen en runtime.
• Wireshark para tráfico no HTTP y captura cruda.
• Burp Suite como proxy HTTP, con un certificado CA propio importado en el almacén de Windows.
• API Monitor para interceptar llamadas Win32 sin debugger.

Vulnerabilidades comunes en thick-client

Las familias que aparecen en prácticamente todos los informes serios:

Hardcoded credentials y API keys en el binario

Strings de conexión a SQL Server con usuario y contraseña en plano, API keys de servicios cloud, tokens OAuth de cliente confidencial, claves de cifrado simétricas. Un strings.exe sobre el binario o un decompilador los entrega. La obfuscación de strings retrasa al atacante medio, no al motivado.

Insecure deserialization

BinaryFormatter en .NET, ObjectInputStream en Java, pickle en clientes Python embebidos. Si el thick-client recibe blobs serializados del backend o de IPC sin validación de tipo, un atacante con control del canal ejecuta código en la máquina cliente. Microsoft marcó BinaryFormatter como obsoleto y peligroso pero sigue apareciendo en código existente.

DLL hijacking y DLL preloading

El loader de Windows busca DLLs siguiendo un orden específico que incluye el directorio de trabajo y carpetas controlables. Si la app carga una DLL por nombre sin ruta absoluta y un atacante puede escribir en una carpeta del orden de búsqueda anterior al sistema, sustituye la DLL legítima por una maliciosa. ProcMon con filtro Result is NAME NOT FOUND y Path ends with .dll mapea el problema en minutos.

IPC inseguro

Named pipes sin ACL restrictiva, objetos COM accesibles desde sesiones de menor privilegio, endpoints RPC sin autenticación, sockets locales que escuchan en 0.0.0.0 cuando deberían escuchar en 127.0.0.1. Cualquiera de los cuatro convierte una app que se supone de un solo usuario en superficie multiusuario o incluso de red.

Registry abuse

Claves de configuración escritas en HKLM con permisos que permiten modificación por usuarios estándar, combinadas con servicios que leen esa configuración con SYSTEM. Un usuario sin privilegios modifica la ruta del binario que el servicio invoca y consigue ejecución como SYSTEM en el siguiente reinicio. Es un patrón de escalada de privilegios local clásico.

Path traversal en operaciones de fichero

Funciones de exportación, importación, gestión de plantillas o adjuntos que reciben un nombre de fichero del usuario y lo concatenan a una ruta base sin sanitización. Una entrada del tipo ..\..\Windows\System32\drivers\etc\hosts permite leer o escribir donde el proceso tenga permisos.

Criptografía insegura

Implementaciones custom de XOR, hashing sin salt, claves hardcodeadas en el binario, uso de ECB en lugar de modos autenticados, generadores pseudoaleatorios no criptográficos para tokens. La cripto custom casi siempre está rota; la única excepción son los protocolos estándar implementados con bibliotecas estándar.

Bypass de autenticación local

Modificación del assembly .NET para sustituir return false por return true en la función de validación de licencia. Parcheo del binario nativo para saltar el salto condicional que distingue cuenta de admin de cuenta normal. Edición del fichero de configuración local que el cliente cree autoritativo. Si la decisión vive en el cliente, el cliente la cambia.

Falta de protecciones de memoria

Binarios compilados sin DEP, sin ASLR, sin SafeSEH, sin CFG (Control Flow Guard). Convierten cualquier corrupción de memoria en ejecución de código trivial. Verificable con dumpbin /headers o con PEStudio en segundos.

Electron específicamente

Electron merece sección propia porque empaqueta Chromium completo y un runtime Node.js, y la configuración por defecto en aplicaciones nuevas suele dejar superficie abierta.

Los puntos a revisar siempre:

• nodeIntegration habilitado. Permite al código JavaScript de la ventana acceder a APIs de Node y, por extensión, al sistema de ficheros y a procesos hijo. Cualquier XSS en contenido cargado se convierte en RCE local.
• contextIsolation deshabilitado. Hace que el contexto JavaScript del preload comparta espacio con el de la página renderizada, dejando que código no confiable manipule los bindings expuestos.
• webSecurity deshabilitado o allowRunningInsecureContent activado. Apaga el Same-Origin Policy y permite cargar contenido HTTP en una ventana HTTPS.
• ASAR sin protecciones. El bundle JavaScript de la app vive en resources/app.asar y se desempaqueta con npx asar extract app.asar out/ en segundos. No es cifrado ni firma; es solo un empaquetador. Toda la lógica del cliente queda legible.
• DevTools en producción. Si el menú expone DevTools o un atajo los abre, el atacante inspecciona y modifica la app en caliente.

La auditoría de un Electron empieza por desempaquetar el ASAR, revisar el package.json para detectar versiones de Electron con CVE conocidos, mapear los BrowserWindow con sus webPreferences y enumerar los canales ipcMain.handle que el proceso renderer puede invocar.

Análisis del tráfico de red

El cliente habla con su backend de muchas formas más allá de HTTP plano. La auditoría debe cubrir las cuatro situaciones habituales.

HTTPS con certificate pinning. La defensa estándar moderna. Bypass con Frida si la implementación es de librería estándar (HttpClientHandler en .NET, OkHttp en Java); modificación del binario para sustituir el pin si es custom. El pinning bien hecho rota certificados desde el servidor y combina varias señales, pero el habitual es un hash hardcodeado fácil de localizar.

Protocolos custom sobre TCP. RPC binarios, formatos serializados propios. Wireshark captura el tráfico crudo y un análisis paralelo del binario revela el protocolo. Frecuente en software industrial y trading.

MQTT, AMQP, gRPC. Patrones cada vez más comunes en software IoT y en arquitecturas de microservicios. Cada uno tiene su propio modelo de autenticación y autorización que el auditor debe validar.

Comunicación local con servicios Windows. Named pipes, sockets en localhost, COM. Auditar como si fuera tráfico externo, porque otra cuenta de usuario en la misma máquina es atacante posible.

Hardening recomendado para thick-client

El conjunto mínimo que cualquier desarrollo de thick-client serio debería incorporar antes de salir a producción:

• Binarios firmados con Authenticode y certificado de organización válido, no autofirmado ni de desarrollo. Verificación de integridad en el arranque del propio software, no solo confianza en Windows.
• Secrets en DPAPI o Windows Credential Manager, nunca en el binario ni en ficheros de configuración planos. DPAPI cifra con clave derivada de la cuenta del usuario o de la máquina; Credential Manager es la opción correcta para credenciales de servicios externos.
• Certificate pinning real contra los backends, con rotación gestionada desde el servidor y plan de contingencia documentado para emergencia de revocación.
• Obfuscación de .NET con producto comercial maduro (Dotfuscator, ConfuserEx en su versión mantenida, Eziriz .NET Reactor). No frena al atacante motivado pero eleva el coste y filtra al casual.
• Integridad runtime. Verificación periódica de que el binario no ha sido modificado en memoria ni en disco. Limitada en valor (un atacante con control de la máquina la neutraliza) pero útil para detectar manipulación oportunista.
• Anti-debugging con moderación. Detecciones triviales como IsDebuggerPresent se saltan en segundos; las comerciales serias (Themida, VMProtect) elevan el coste pero rompen herramientas de análisis legítimas y dificultan el diagnóstico de errores en producción.
• Compilación con todas las protecciones del compilador activas: DEP, ASLR, SafeSEH, CFG, GS. Sin coste de rendimiento perceptible.
• Cobertura Sysmon en endpoints donde la app crítica corra, con reglas que detecten carga de DLLs no firmadas, escritura en rutas sensibles y creación de procesos hijo inesperados desde el binario.
• Política de actualización automática firmada y verificada, con manifest server-side que el cliente valide antes de aplicar.

Preguntas frecuentes

¿La obfuscación de .NET es suficiente para proteger el código?

No. La obfuscación eleva el coste de revertir el código pero ningún producto comercial bloquea a un atacante con tiempo. Sirve para filtrar al atacante casual y dificultar el copy paste de lógica propietaria. La defensa real es no poner en el cliente nada que el backend no pueda revalidar.

¿Electron es seguro para aplicaciones empresariales?

Sí si se configura correctamente. El problema no es Electron sino las configuraciones por defecto que muchos equipos no revisan: nodeIntegration: true, contextIsolation: false, dependencias desactualizadas, ASAR como única "protección" del bundle. Con contextIsolation: true, nodeIntegration: false, sandbox activado y dependencias auditadas, el riesgo se acerca al de una SPA web equivalente.

¿Cuánto tarda un pentest thick-client?

Depende del stack y la complejidad. Una app .NET de tamaño medio con un backend HTTP convencional se cubre en 8-12 días laborables. Una app C++ nativa de software industrial con protocolos custom y múltiples servicios IPC puede pedir 20-30 días. Las apps Electron suelen quedar más cerca del lado web. La auditoría completa incluye reporting y retest.

¿Por qué la banca de trading sigue usando thick-client en 2026?

Latencia y control. El thick-client procesa marketing data en local, ejecuta cálculos de riesgo sin round-trip al servidor y mantiene UI con tiempos de respuesta que un navegador no garantiza. Además permite integraciones con hardware (lectores de tarjetas, tokens criptográficos) que la web sigue limitando. La trade-off es superficie de ataque mayor, que se compensa con pentest específico.

¿Es ético implementar anti-debugging en producto comercial?

Depende del producto y la transparencia con el cliente. El anti-debugging dificulta el análisis legítimo por parte de equipos de seguridad del cliente y complica el debugging cuando un usuario reporta un crash. Productos que lo incorporan deberían documentarlo y permitir deshabilitarlo bajo NDA para auditorías autorizadas. Confiar en él como única capa de defensa es un error.

¿Cuándo conviene retesting tras parchear?

Tras cada bloque significativo de fixes, no después de cada bug individual. El equipo de desarrollo agrupa correcciones en una release y el equipo ofensivo valida el bloque completo. El retest debería estar incluido en el alcance original del pentest, no facturarse aparte, para evitar fricción que retrase el cierre de hallazgos críticos.

Recursos relacionados

• Qué es Mimikatz y credential dumping: herramienta clave para post-explotación local, complementa la fase de logic abuse cuando el thick-client comparte credenciales con el sistema.
• Pentesting Active Directory y modelo de tiers: contexto del entorno empresarial donde los thick-client suelen vivir, con el modelo de protección por capas.
• Top 10 herramientas de pentesting 2026: catálogo de utilidades que cubre IDA, Ghidra, Frida y el resto del stack desktop.
• Qué es la PKI: fundamentos de firma de binarios y emisión de certificados de Authenticode.
• Ataques Kerberos en Active Directory: vector adyacente cuando el thick-client se autentica contra recursos de dominio.

Auditoría thick-client con Secra

En Secra cubrimos pentesting de aplicaciones desktop Windows con perfiles especializados en reverse engineering nativo, .NET y Electron, instrumentación dinámica con Frida y WinDbg, análisis de protocolos custom y mapeo de hallazgos a OWASP ASVS adaptado al contexto desktop. Si tu organización desarrolla o despliega thick-client en entornos sensibles (banca, salud, industria, defensa) y necesita validación técnica seria, escríbenos desde contacto o consulta nuestros servicios de auditoría web y móvil y auditoría de infraestructura.