daxonix

GUÍA · 004DXN-GD-2026-004

Guía técnica · Para tu equipo de ingeniería

Antes del pentest.

Lo técnico que tu equipo debe tener listo para que el pentester arranque el día 1 sin perder tiempo. Solo lo necesario, sin trámites.

EDITADO POR Daxonix Offensive Security

2026 EDITION · 6 PÁG · TÉCNICO

GUÍA · DXN-GD-2026-004DAXONIX

CONTEXTO

El día 1 vale oro.
No lo gastes en accesos.

Un pentest tiene tiempo fijo. Si el día 1 se va resolviendo credenciales que no funcionan, builds que no instalan o documentación API obsoleta, el pentester pierde horas que ya no recupera. Esas horas eran las que iban a encontrar tu vulnerabilidad crítica.

Esta guía cubre solo lo técnico. Tres bloques esenciales:

01

Credenciales y cuentas

02

Entornos y accesos

03

Binarios y APIs

Los items marcados ★ son no-negociables: sin ellos el pentest no arranca de forma productiva. Los demás aceleran y profundizan el alcance.

★ La regla del 80/20

El 80% de los problemas operativos del día 1 son por credenciales que no funcionan, accesos que nunca se propagaron, o documentación API que no corresponde a la versión en staging. Resolver estos tres puntos antes del kickoff recupera entre 4 y 8 horas efectivas de auditoría.

Lo legal (NDA, contrato, alcance firmado, fechas) se resuelve en paralelo con tu sponsor. Esta guía no lo cubre.

DAXONIX02

01 · CREDENCIALES Y CUENTASDAXONIX

01 · CREDENCIALES

Usuarios, contraseñas
y tokens.

Sin cuentas funcionales, no hay pentest. Punto. Verifica todo 48 horas antes del kickoff con un test real desde la red del pentester.

Cuentas de prueba

Mínimo 2 cuentas por rol (regular × 2, admin × 2, etc.). Una para probar privilegios cruzados, otra para no perder acceso si la primera se bloquea

Contraseñas pre-establecidas que NO requieran cambio al primer login (ese cambio rompe scripts y rota tokens)

Cuentas con datos de prueba: saldos, transacciones, archivos. Una cuenta vacía no permite probar lógica de negocio

Cuentas separadas por escenario: usuario nuevo, usuario verificado, usuario suspendido, usuario premium

Etiquetas claras: pentest_admin_01, pentest_user_01 — fácil de identificar y limpiar después

Confirmación de que las cuentas no se desactivan por inactividad durante las próximas 3 semanas

2FA / MFA

2FA deshabilitado en cuentas de prueba o compartido el secret key TOTP para que el pentester lo agregue a su autenticador

Si MFA es obligatorio: usar app TOTP (no SMS), compartir el QR del enrolamiento con el pentester

Si la app envía OTP por SMS, configurar provider en sandbox o redirigir a un correo controlado

API tokens y secretos

API tokens válidos por rol con scopes equivalentes a la cuenta humana. Vigencia mínimo 30 días

Acceso al endpoint de generación de tokens si la app lo expone

Refresh tokens disponibles si la auth los usa

Acceso a panel administrativo para crear nuevos tokens si los actuales se invalidan

Cómo compartir credenciales

Vault compartido en 1Password, Bitwarden, Keeper o equivalente. Una sola sesión, accesos individuales por persona

NUNCA: chat, correo, ticket en Jira, archivo en Google Drive sin restricción

Si el cliente no tiene vault: enviar por correo cifrado con S/MIME, o link temporal con expiración 7 días

⚠ Error más común del día 1

Cuentas con 2FA SMS activo, sin acceso al teléfono del usuario asociado. El pentester pide un código, alguien del equipo del cliente lo manda, vuelve a pedir, se pierde, vuelve a pedir. Un día perdido. Solución: TOTP o 2FA off durante el engagement.

DAXONIX03

02 · ENTORNOS Y ACCESOSDAXONIX

02 · ENTORNOS

Dónde el pentester
va a trabajar.

Entorno de pruebas

Staging idéntico a producción (mismo stack, misma versión, mismas integraciones). Una versión "casi como prod" oculta vulnerabilidades reales

Datos de prueba realistas. Volumen, formato y relaciones similares a producción

Backup de la base de datos del entorno antes del kickoff (por si una prueba causa daño accidental)

Acceso a producción con ventana acordada si el alcance lo incluye

URLs y endpoints

URL de la aplicación frontend con todos los subdominios relevantes (api.staging, admin.staging, etc.)

Endpoints de APIs: REST, GraphQL, gRPC, WebSocket. Lista explícita

Información de balanceadores y CDNs si aplican filtrado

Hostnames internos si aplica testing desde dentro de la red

Acceso a la red

IPs del pentester en allowlist de WAF, IDS, rate limiters durante el engagement (Cloudflare, AWS WAF, Imperva, etc.)

VPN dedicada al pentest si el entorno es interno o requiere conexión segura

Credenciales de VPN probadas desde la IP del pentester antes del kickoff

SOC notificado: "tráfico anómalo desde estas IPs es del pentester, no es ataque real"

Proveedor cloud notificado (AWS / GCP / Azure) si el alcance toca servicios cloud

Test de humo · 48 h antes

El pentester intenta loguearse desde su IP, hace 1 request al endpoint principal, valida acceso a recursos. Si algo falla, hay tiempo de arreglar antes del kickoff. Si esto se descubre el día 1, la primera mañana se va en troubleshooting.

DAXONIX04

03 · BINARIOS Y APISDAXONIX

03 · BINARIOS Y APIS

Apps móviles, código
y documentación API.

Apps móviles · binarios

APK firmado (Android) entregado directamente. Versión idéntica a la de Play Store o staging

IPA firmado (iOS) entregado directamente. Versión idéntica a la de App Store o TestFlight

Acceso a TestFlight (iOS) o Internal Testing (Android) si el ciclo de release lo permite

Build de la app que apunte al entorno de staging configurado, no a producción

Versión sin obfuscación adicional ni RASP de runtime si fueron acordados como bypass dentro del scope

Build con SSL pinning desactivado opcional, o acordar que el bypass es parte del trabajo

Hardware específico

Dispositivo de prueba si la app requiere hardware específico (lector de huella, NFC, biometría avanzada)

Cuenta de Apple Developer si el pentester necesita firmar builds modificados

Confirmación de soporte para dispositivos rooted/jailbroken (algunas apps los detectan y bloquean)

Documentación API

OpenAPI / Swagger actualizado con todos los endpoints del alcance. Validado contra el código fuente, no contra una versión vieja

Postman collection con autenticación pre-configurada y ejemplos válidos

Diagrama de arquitectura de alto nivel (qué servicios conversan con qué)

Lista de tecnologías y versiones (framework, base de datos, cache, queue)

Convenciones de IDs (UUIDs, integers, encoded base64, hashids) — útiles para detectar IDOR

Código fuente (cuando aplica)

Acceso de solo lectura al repositorio si el engagement incluye revisión de código (white-box)

Branch específico que corresponde a la versión desplegada en staging

README actualizado con instrucciones de build local si el pentester necesita correr el código

⚠ Sobre los binarios

El binario que entreges es lo que el pentester va a auditar. Si entregas el APK de hace 6 meses pero la app en producción tiene 6 meses de cambios, el reporte va a quedar desfasado. Genera un build fresco la semana del kickoff.

DAXONIX05

04 · ERRORES QUE PIERDEN TIEMPODAXONIX

04 · ERRORES

Los 5 más caros.

1. Credenciales que no funcionan el día 1

El error más común. La cuenta de prueba se creó hace dos meses, el password fue rotado, el usuario fue desactivado por inactividad. Solución: verificar 48 horas antes con un test real desde la red del pentester.

2. Documentación API desactualizada

El OpenAPI no refleja los endpoints reales en staging. Hay 30 endpoints adicionales no documentados que el pentester va a descubrir por enumeración pero perdiendo tiempo. Solución: validar el spec contra el código fuente la semana del kickoff.

3. SOC sin avisar

El SOC genera tickets de incidente por cada test, agota recursos del blue team y eventualmente bloquea el tráfico del pentester por reputación. Solución: notificar fechas, IPs origen y tipos de prueba esperados con 1 semana de anticipación.

4. Binarios viejos

El IPA o APK que entregas tiene 4 meses, pero la app en producción ha tenido 4 meses de cambios. El reporte queda obsoleto antes de entregarse. Solución: build fresco la misma semana del kickoff.

5. 2FA con SMS sin acceso al teléfono

El pentester pide un código, alguien del equipo lo manda, repite. Un día completo perdido. Solución: usar TOTP con secret compartido, o desactivar 2FA durante el engagement.

★ Si solo lees una página

Lee la página 03 de credenciales. El 80% de los proyectos que arrancan mal lo hacen ahí. Todo lo demás es secundario si las cuentas no funcionan.

DAXONIX06

daxonix

Listo para
hacerlo bien.

Si tu equipo tiene los 3 bloques resueltos, el pentest arranca al 100% el día 1. Si dudas en algún punto, te ayudamos a aterrizarlo.

Programar llamada → Enviar mensaje

EMAIL

[email protected]

CALENDLY

calendly.com/daxonix

/in/isaac-milan-soto