A menudo se habla de los hackers crypto como si todos realizaran el mismo trabajo y solo variaran sus motivos. En la práctica, la frontera entre un investigador de seguridad whitehat y un atacante blackhat se define tanto por la autorización, el alcance y lo que finalmente ocurre con los fondos como por la habilidad técnica. Ambos pueden entender smart contracts, bridges, wallets, validators, private keys y la lógica de los protocolos a un nivel experto. Lo que los separa es cómo se aplica ese conocimiento.

Los hackers whitehat buscan vulnerabilidades para que puedan corregirse antes de que los usuarios pierdan dinero. Los blackhats explotan debilidades para robar, extorsionar, manipular mercados, acceder a información privada o controlar infraestructura. Crypto complica esta distinción porque, en una emergencia, un whitehat a veces puede mover fondos vulnerables durante un ataque activo, mientras que un blackhat puede devolver activos robados más tarde y pedir conservar una parte del botín como recompensa.

Esa zona gris se ha vuelto más visible a medida que los protocolos DeFi concentran grandes volúmenes de activos en código que cualquiera puede inspeccionar. El seguimiento del sector, como los informes anuales de cripto crimen de Chainalysis, ha registrado más de mil millones de dólares robados de plataformas crypto en cada año reciente, lo que mantiene la pregunta sobre quién está probando un protocolo —y bajo qué شروط— en el centro de las discusiones de seguridad. Entender la diferencia exige mirar más allá de la etiqueta que un hacker se da a sí mismo y preguntar si la actividad estaba autorizada, si los usuarios fueron puestos en riesgo y si existían términos de recompensa antes de mover los fondos.

¿Qué es un hacker crypto whitehat?

Un hacker crypto whitehat es un investigador de seguridad que encuentra debilidades y actúa dentro de un proceso autorizado de divulgación o recuperación. Sus objetivos pueden incluir smart contracts, bridges, wallets, infraestructura de exchanges, frontends, APIs, sistemas de validación, configuraciones multisig y otros componentes capaces de exponer activos digitales.

La mayor parte del trabajo whitehat ocurre antes de que se produzca un exploit. Un proyecto publica una crypto bug bounty con objetivos, exclusiones, niveles de severidad, reglas de reporte y límites de pago definidos. Los investigadores inspeccionan el código, reproducen la vulnerabilidad de forma segura, envían evidencia de manera privada y dan tiempo al equipo para corregirla.

El investigador no necesita tomar dinero real para demostrar que el fallo existe. Las principales plataformas de bounty de Web3 suelen exigir pruebas de concepto y, al mismo tiempo, prohíben pruebas que pongan en riesgo contratos en vivo, redes públicas, usuarios o sistemas de terceros. Las reglas actuales de whitehat de Immunefi, por ejemplo, prohíben probar contratos de mainnet y de public testnet bajo su marco predeterminado. Plataformas como Immunefi, Sherlock, Code4rena y Hats Finance han convertido este proceso en una parte estándar de la preparación de los protocolos para su lanzamiento, combinando auditorías competitivas y recompensas continuas con las revisiones de seguridad tradicionales.

Por eso, la caza técnica de recompensas se parece más a una garantía de calidad adversarial que a un robo sancionado. Los investigadores piensan como atacantes, pero el trabajo permanece dentro de los límites fijados por el proyecto. Quienes estén interesados en esa vía pueden pasar del trabajo general de recompensas a la investigación de seguridad mediante un flujo de trabajo para crypto bounty hunter estructurado en torno a pruebas seguras, evidencia y divulgación responsable.

¿Qué es un hacker crypto blackhat?

Un hacker blackhat explota un sistema sin permiso y con un propósito que perjudica al propietario o a los usuarios. En crypto, el objetivo suele ser el beneficio financiero directo, porque smart contracts, bridges, exchanges y wallets pueden contener activos transferibles en cuestión de minutos tras una intrusión exitosa.

Los ataques blackhat no siguen un único patrón técnico. Un atacante de smart contracts puede explotar una contabilidad defectuosa, controles de acceso, supuestos sobre oráculos, reentrancy o un error lógico. Otros grupos comprometen private keys, manipulan empleados mediante ingeniería social, toman control de infraestructura de desarrollo, envenenan dependencias de software o atacan los sistemas operativos que rodean a un protocolo en lugar de sus contratos.

Los atacantes orientados al usuario suelen optar por una ruta más sencilla. Los crypto wallet drainers pueden imitar mints legítimos, airdrops, páginas de staking o portales de soporte y convencer a una víctima de firmar una transacción peligrosa. Algunos ataques dependen de malicious token approvals que otorgan al atacante permiso para mover activos más adelante sin llegar nunca a conocer la seed phrase.

Una vez que los activos están bajo control del atacante, comienza la segunda fase. Los fondos pueden dividirse entre wallets, cambiarse por activos más líquidos, transferirse entre chains, enviarse a través de exchanges descentralizados o canalizarse hacia servicios que dificultan la atribución. Las blockchains públicas exponen gran parte de este movimiento, pero las visibles on-chain transactions no revelan automáticamente a la persona que controla una dirección. Las empresas de análisis blockchain y los equipos de seguridad rastrean de forma habitual estos flujos y han permitido incautaciones policiales en casos importantes, lo que explica por qué las devoluciones negociadas se han vuelto una característica recurrente en incidentes de gran tamaño.

Whitehat vs blackhat en crypto

Los métodos técnicos pueden coincidir casi por completo. Un whitehat y un blackhat pueden detectar la misma falla contable y construir una prueba de concepto casi idéntica. La diferencia aparece en lo que se les permite hacer con ese conocimiento y en cómo actúan una vez que la vulnerabilidad se confirma.

Por eso un proyecto con una sólida smart contract security sigue necesitando canales claros de divulgación y procedimientos de incidentes. Las auditorías pueden pasar por alto errores, las integraciones pueden cambiar y las nuevas condiciones económicas pueden exponer supuestos que eran inofensivos cuando el sistema se lanzó.

Cómo operan los hackers whitehat

La investigación whitehat suele comenzar con el alcance. El investigador identifica qué contratos, dominios, aplicaciones o infraestructuras son elegibles y luego estudia cómo se mueven los activos y los permisos a través del sistema. En DeFi, eso puede significar seguir depósitos, retiros, lógica de liquidación, dependencias de oráculos, rutas de actualización, privilegios administrativos y llamadas entre contratos.

Un fallo prometedor se reproduce en un entorno controlado. El investigador documenta las condiciones necesarias para activarlo, el impacto probable, los activos afectados y una prueba de concepto segura. Una buena presentación ofrece a los ingenieros suficiente información para reproducir el problema sin obligar al investigador a demostrarlo frente a usuarios reales.

Tras el análisis inicial, el proyecto decide si el informe es válido, cuán grave es y si entra dentro de los términos del bounty. El pago depende del programa. Una vulnerabilidad crítica que podría vaciar un protocolo puede valer mucho más que un fallo de bajo impacto en el frontend, mientras que los hallazgos duplicados o fuera de alcance pueden no recibir nada. Los informes críticos de primer nivel en plataformas importantes han llegado históricamente a pagar millones de dólares, reflejando la escala de las pérdidas que un solo error puede causar.

Cómo operan los hackers blackhat

Los blackhats también comienzan con reconocimiento, pero no existe un límite contractual sobre lo que pueden probar. Pueden inspeccionar código público, seguir actualizaciones de gobernanza, estudiar participantes de multisig, buscar credenciales filtradas, monitorizar wallets privilegiadas, mapear identidades de empleados y probar dependencias externas hasta encontrar el punto más débil.

Algunos de los mayores hackeos crypto de la historia no surgieron de fallos criptográficos exóticos. El compromiso de private keys, debilidades en bridges, control de validadores, errores de smart contracts y fallos de seguridad operativa han producido pérdidas medidas en cientos de millones de dólares. Casos como Ronin Bridge y los episodios de Cross River (Euler Finance) siguieron trayectorias técnicas muy distintas, lo que subraya que la superficie de ataque abarca tanto a las personas y la infraestructura como al código.

La ejecución suele diseñarse para ir rápido. Una vez que se aprovecha una debilidad, el atacante puede necesitar vaciar varios contratos, apoderarse de colateral, alterar una fuente de precios, acuñar activos sin respaldo o mover fondos antes de que los mantenedores puedan pausar el sistema. Después, el atacante enfrenta otro problema: convertir transacciones transparentes en la cadena en activos que puedan conservarse o gastarse sin que sean recuperados o congelados.

¿Por qué algunos whitehats hackean primero y se quedan con un bounty?

Suelen confundirse dos situaciones muy diferentes bajo esta pregunta.

La primera es un rescate de emergencia genuino. Ya hay un exploit en curso, el protocolo ha autorizado previamente la intervención y otro investigador de seguridad mueve los activos vulnerables antes de que el blackhat pueda tomarlos. El marco SEAL Whitehat Safe Harbor existe precisamente para este escenario. Los protocolos participantes definen activos protegidos, direcciones de recuperación, requisitos de identidad y términos de recompensa antes de que ocurra un incidente. Un whitehat puede entonces intervenir durante un exploit activo y devolver los fondos rescatados bajo esas condiciones publicadas.

Algunas configuraciones de Safe Harbor incluso permiten que el whitehat conserve directamente el bounty permitido antes de devolver el saldo. Eso no es lo mismo que tomar el dinero primero y fabricar una recompensa después: la autoridad y la fórmula de pago ya existían.

La segunda situación comienza con un exploit no autorizado. El atacante drena activos, luego afirma ser un whitehat, ofrece devolver la mayor parte de los fondos y pide quedarse con un porcentaje. Un proyecto puede aceptar el acuerdo porque recuperar 90% es mejor que no recuperar nada, pero un acuerdo posterior al exploit no convierte retroactivamente el ataque original en un bug bounty autorizado.

La reciente recuperación de Liquid Network muestra lo difícil que puede volverse esa línea. Unos supuestos whitehats retiraron casi 4,000 BTC, pidieron a Blockstream que corrigiera la falla y más tarde devolvieron 3,400 BTC tras negociaciones en la cadena. Aproximadamente 598.5 BTC seguían bajo su control el 8 de septiembre. No existía un acuerdo divulgado públicamente que estableciera ese remanente como un bounty aprobado, por lo que describirlo como una recompensa whitehat confirmada iría más allá de lo que sostienen los hechos disponibles.

Por eso, llamarse whitehat no significa nada sin la autorización que lo respalde. Un marco de rescate genuino requiere independencia respecto del atacante original, una amenaza activa, cumplimiento de las reglas del protocolo y devolución de fondos según el proceso acordado. Iniciar el exploit uno mismo queda fuera de esa protección.

¿Puede un blackhat convertirse en whitehat devolviendo el dinero?

Devolver fondos robados puede reducir pérdidas y puede conducir a un acuerdo negociado, pero no cambia automáticamente la naturaleza del acceso original. Un proyecto puede decidir ofrecer un bounty después de un exploit porque la recuperación práctica vale más que una persecución prolongada, pero ese acuerdo sigue siendo distinto de una divulgación responsable o de un rescate preautorizado.

Los investigadores que quieren ingresos legítimos por bounty no necesitan crear esa ambigüedad. Los programas formales ofrecen una vía para reportar vulnerabilidades, establecer la gravedad y recibir pago sin tomar custodia de los fondos de los usuarios. El investigador recibe pago por el hallazgo y la evidencia, no por retener activos como rehén.

Por qué crypto necesita hackers whitehat

Los sistemas crypto son objetivos atractivos porque el código puede controlar directamente activos líquidos. Una vulnerabilidad en software ordinario puede exponer datos o interrumpir un servicio. Una vulnerabilidad en un bridge, un mercado de préstamos o una wallet puede convertirse en la transferencia de millones de dólares antes de que un operador humano tenga tiempo de reaccionar.

Los whitehats añaden una capa adversarial permanente alrededor de las auditorías y de los equipos internos de seguridad. Siguen probando supuestos después del lanzamiento, revisan nuevas integraciones y aportan investigadores independientes a sistemas cuyos incentivos económicos cambian constantemente. Los bug bounties no hacen que un protocolo sea seguro por sí solos, pero hacen más rentable reportar ciertas vulnerabilidades que explotarlas.

Veredicto final

Los hackers crypto whitehat y blackhat pueden tener las mismas capacidades técnicas, estudiar el mismo código y descubrir la misma vulnerabilidad. La autorización y la conducta los separan. Los whitehats trabajan dentro de reglas de divulgación, recompensa, auditoría o rescate diseñadas para proteger a los usuarios. Los blackhats explotan sistemas sin permiso y deciden después si conservan, mueven, extorsionan o devuelven lo que tomaron.

Los rescates whitehat de emergencia son el caso excepcional en el que mover fondos reales puede ser legítimo, pero solo cuando la autoridad y los términos de recuperación ya existen. Un hacker que ataca primero y negocia un bounty después puede ayudar a recuperar activos, pero eso no es lo mismo que una investigación whitehat responsable.