El código de ética: ser hacker no es ser criminal

Intro con gancho

Son las 2:13 a.m. Estás en el Oxxo con un café que sabe a castigo, tu laptop ya está soplando como si fuera a despegar, y tú “nomás estabas viendo” un bug.

Abriste DevTools, cambiaste un parámetro en una request… y de pronto aparecen datos que no tendrías que ver. No fue un exploit de película, fue un click chiquito. Y justo por eso pega más: te cae el veinte de que esa curiosidad ya tocó una línea.

Ahí se abren dos caminos. El de “pues ya que estoy aquí…” (y terminas inventándote excusas). O el de “alto: permiso, scope y reporte” (y te vuelves alguien confiable para trabajar en security). Ser hacker no es ser criminal. Pero ser hacker tampoco es “si se puede, se hace”.

Qué vas a aprender

• La diferencia real (sin meme) entre hacker, pentester y criminal.
• Un código de ética usable en el jale: permiso, alcance, mínima intrusión y evidencia.
• Qué hacer si te topas una vulnerabilidad “sin querer”.
• Un workflow de responsible disclosure que funciona en México/LatAm.
• Errores clásicos que te meten en broncas aunque tu intención sea ayudar.

Contexto práctico

La cultura pop te vende al “hacker” como alguien que teclea rápido y tumba satélites. En la vida real, un hacker es alguien que entiende sistemas lo suficiente para doblarlos: a veces para arreglarlos, a veces para romperlos.

La diferencia no está en el teclado. Está en estas cinco cosas:

• Consentimiento: ¿tienes permiso explícito?
• Alcance (scope): ¿qué está autorizado probar y qué no?
• Intención: ¿reduces riesgo o estás sacando ventaja?
• Impacto: ¿minimizas daño y evitas exfiltrar datos?
• Responsabilidad: ¿documentas y reportas con cuidado?

En México/LatAm se pone más rudo por dos realidades bien comunes:

1. “Hazlo rápido y que no cueste”. Te piden: “nada más revisa tantito seguridad” sin contrato, sin ticket, sin scope. Y si algo truena, el rollback no lo paga la empresa: lo pagas tú con tu nombre.

2. El IT todólogo. El sysadmin que trae red, backups, el ERP, y la impresora poseída, termina probando cosas en production porque “no hay staging”. A veces el bug ni es tuyo, pero el incidente sí te lo cargan.

La ética hacker es tu freno de mano cuando el proceso viene chueco.

Paso a paso: tu código de ética operativo (sí, para usarlo mañana)

1) Regla cero: permiso explícito o no hay juego

Si no hay permiso, no es pentest. Punto.

Permiso explícito = algo por escrito (correo, ticket, contrato) que diga:

• quién autoriza,
• qué sistemas,
• qué fechas,
• qué métodos están permitidos (scan, explotación, ingeniería social, etc.).

Escena típica:

• “Oye, ¿puedes revisar si se puede cambiar el precio en el checkout?”

Respuesta ética (y profesional):

• “Va. Mándamelo por correo con el scope. Y dime si lo hacemos en staging o production. Si es production, solo pruebas no destructivas y sin tocar datos de clientes.”

Si te dicen “ay, tú dale, no pasa nada”, tu salida es simple:

• “Sin autorización y sin alcance, no puedo. Pero en 15 minutos armamos el scope y ya le damos.”

2) Define alcance como si fuera mapa de zona sísmica

El scope es lo que evita que un “testeíto” termine en caída de servicio y en junta de crisis.

Incluye:

• Dominios/IPs permitidos
• Apps/paths permitidos
• Usuarios de prueba
• Ventana de pruebas
• Límites: no DoS, no fuerza bruta, no tocar PII, no pivoting, etc.

Tip de guerra cuando hay deadline:

• negocia un scope mínimo que sí puedas cumplir.

Ejemplo:

• “Solo autenticación y control de acceso en /admin, sin escaneo masivo, sin fuzzing agresivo.”

3) Mínima intrusión: prueba lo suficiente, no lo máximo

La ética no es “nunca explotar”. La ética es explotar lo mínimo para demostrar el riesgo y frenar antes de hacer daño.

Ejemplos concretos:

• Si encuentras un IDOR (cambiar user_id=123 por 124), no te pongas a bajar todo el historial. Con demostrar acceso a un recurso ajeno (y documentarlo con redacción) alcanza.
• Si ves SQLi, no te vayas directo a “a ver si saco tarjetas”. Valida con un payload controlado (error-based o time-based) y párale.

Regla práctica:

• “Prueba para comprobar, no para presumir.”

4) Evidencia limpia: screenshots sí, datos no

Para reportar bien necesitas evidencia. Pero tu evidencia no debe volverse un botín guardado en tu disco.

Buenas prácticas:

• Difumina o redacta PII en capturas.
• Guarda logs/requests con cuidado (evita tokens/cookies en texto plano si no hace falta).
• Usa usuarios de prueba.

Mini plantilla de evidencia (la que sí sirve en un pull request o en un ticket):

• Qué intenté
• Qué pasó
• Qué debería pasar
• Riesgo (impacto + probabilidad)
• Cómo reproducir (pasos)
• Recomendación

5) Responsible disclosure: reporta como adulto funcional

Si el sistema es de tu empresa/cliente: reporte interno.
Si es externo y no hay bug bounty: pisa con cuidado.

Workflow recomendado:

1. Encuentra canal: security@, soporte, formulario, un ticket formal, o sí… a veces LinkedIn del CTO.
2. Reporta claro, sin drama y con datos accionables.
3. Da tiempo razonable de corrección (30–90 días según severidad).
4. No publiques detalles explotables antes del parche.

Correo decente (plantilla):

Asunto: Reporte responsable de vulnerabilidad (control de acceso)

Hola equipo,

Detecté una vulnerabilidad de control de acceso en https://ejemplo.com/...
Permite que un usuario autenticado acceda a recursos de otros usuarios modificando un parámetro.

Impacto: Exposición de información (PII) / posible toma de cuenta dependiendo del endpoint.

Pasos (resumidos):
1) Iniciar sesión con usuario de prueba.
2) Solicitar /api/orders?user_id=MI_ID
3) Cambiar user_id por otro valor.

Evidencia: (adjunto capturas con datos redactados)

Sugerencia: Validar autorización en backend usando el usuario autenticado, no parámetros del cliente.

Quedo pendiente para apoyar.

Saludos,
Nombre
Contacto

Si te contestan “gracias”: perfecto.
Si te contestan con amenaza: no te enganches. Documenta, guarda tu comunicación y retírate. Tu objetivo es reducir riesgo, no ganar una discusión.

6) Si fue “accidental”, aplica el protocolo de freno

Si por curiosidad ya viste algo indebido:

• No copies, no compartas, no sigas.
• Captura evidencia mínima (redactada) para explicar el riesgo.
• Reporta con contexto: “Esto ocurrió durante X tarea. No se extrajo información. Sugiero corregir así.”

No eres mala persona por encontrarte un hoyo. Te vuelves problema si lo conviertes en tour.

Screenshots sugeridos

• Ejemplo de correo/ticket de autorización con alcance (datos tachados).
• Captura de una request en DevTools/Network mostrando un parámetro vulnerable con valores anonimizados.
• Ejemplo de reporte en formato Markdown (impacto, pasos, recomendación).
• Pantalla de un programa de bug bounty (HackerOne/Bugcrowd) mostrando “scope” y “out of scope”.

Errores comunes + solución

Error 1: “Si es para ayudar, no pasa nada”

Realidad: la intención no te blinda. Sin permiso puede ser acceso no autorizado, así de simple.

Solución: permiso por escrito + scope. Si no te lo dan, no lo hagas. Ofrece alternativas seguras: checklist, revisión de configuración, threat modeling, hardening, lo que sea sin tocar sistemas ajenos.

Error 2: Probar en production porque “no hay staging”

Realidad: un scan agresivo o una prueba torpe tumba el sitio en hora pico. Luego viene el “¿quién fue?” y tu nombre sale primero.

Solución: ventana de pruebas, rate limits, y pruebas no destructivas. Si necesitas explotación real, exige staging o un entorno espejo.

Error 3: Guardar evidencia con datos reales (PII, tokens, cookies)

Realidad: conviertes tu laptop en un riesgo. Se te sincroniza a Drive, lo mandas a Slack, lo reenvías en WhatsApp… y ya se regó.

Solución: redacción, usuarios de prueba, almacenamiento cifrado si aplica. Nunca compartas capturas crudas.

Error 4: “Encontré X, lo publico para que me hagan caso”

Realidad: quemas al equipo y expones a usuarios. Eso ya es jugarle al villano aunque te jures “white hat”.

Solución: responsible disclosure. Si quieres crédito, pide un acknowledgment después del parche.

Error 5: Mezclar ego con seguridad

Realidad: “Mira cómo entré” suena a amenaza aunque no lo sea.

Solución: habla en lenguaje de riesgo: impacto, alcance, costo, fix. Menos película, más ingeniería.

Checklist final

• Tengo permiso explícito por escrito.
• Tengo alcance claro (qué sí / qué no).
• Tengo ventana de pruebas y límites (rate, no DoS, no brute force).
• Uso cuentas y datos de prueba.
• Pruebo lo mínimo necesario para demostrar el riesgo.
• Evidencia redactada (sin PII, sin tokens).
• Reporte accionable (impacto + pasos + recomendación).
• Plan de comunicación: responsable, sin exposición prematura.

FAQ

1) ¿Entonces “hacker” es bueno o malo?

“Hacker” describe habilidad y mentalidad. Lo ético o criminal depende de permiso, intención e impacto. Un hacker ético trabaja con consentimiento y reduce riesgo.

2) ¿Si una web es pública, puedo “probarle cositas”?

No. Que esté accesible no significa que tengas autorización para atacar, escanear o explotar. Si quieres ayudar, busca un canal oficial o un bug bounty.

3) ¿Qué hago si mi jefe me pide hackear a un competidor o a un ex empleado?

Bandera roja gigante. Pide que lo ponga por escrito (muchas veces ahí se frenan solos). Propón alternativas legales: auditoría interna, revisión de accesos, asesoría legal. Si insisten, aléjate.

4) ¿Puedo hacer port scanning a IPs “para aprender”?

En tu lab, sí. En redes ajenas, sin permiso, no. Aprende con CTFs (TryHackMe/Hack The Box), laboratorios locales (VMs) o entornos intencionalmente vulnerables.

5) ¿Cómo cobro/estructuro un pentest sin meterme en broncas?

Con un documento mínimo: alcance, metodología, fechas, entregables, límites y una autorización firmada. Si el cliente no quiere firmar, no es cliente: es riesgo.

Siguiente episodio

La ética es el volante. Lo que sigue es el mapa: cómo pensar como atacante sin romper nada.

Vamos a armar un threat model light para encontrar riesgos antes de que se vuelvan incendio en production.