El banco dice que fuiste tú.
Siempre dice que fuiste tú.
Cada vez que una transferencia no reconocida sale de la cuenta de una empresa o de una persona física, el banco tiene una sola respuesta: «La operación se realizó desde su IP, con sus credenciales, desde su dispositivo autorizado. No hay evidencia de vulneración a nuestros sistemas. La responsabilidad es del usuario.»
Esa es la línea. Es la línea de todos los bancos. De todos. La he escuchado en juicios contra los cinco bancos más grandes de México. La he leído en dictámenes periciales de los peritos del banco. La he visto en las resoluciones genéricas de CONDUSEF. Es la misma línea, caso tras caso, año tras año: fue tu IP, fue tu contraseña, fue tu culpa.
Y en la mayoría de los casos, nadie la cuestiona. El empresario al que le vaciaron la cuenta se queda con el golpe. Su abogado presenta una reclamación ante CONDUSEF. CONDUSEF emite una resolución genérica que dice algo como «no se acreditó la responsabilidad de la institución bancaria» — porque CONDUSEF no tiene la capacidad técnica para investigar una intrusión de red, no tiene peritos forenses, no tiene laboratorio. Y el empresario absorbe la pérdida, cierra el caso y se queda con la convicción amarga de que el sistema está diseñado para proteger al banco.
Les soy franco: en muchos casos, tiene razón.
Pero no en todos. Porque hay casos donde la transferencia sí salió de la IP de la empresa, sí se usó la contraseña correcta, sí el dispositivo es el que está registrado en el banco — y aun así la operación fue fraudulenta. Porque lo que nadie revisó — ni el banco, ni CONDUSEF, ni el perito del banco — es el router.
Llevo 17 años haciendo informática forense. He formado a más de 1,300 peritos en 10 países. Y tengo un récord que no digo por soberbia sino porque es el dato más relevante que puedo darle al empresario que está leyendo esto a las tres de la mañana buscando respuestas: en casos donde Duriva ha presentado peritaje contra un banco por transferencia no reconocida, no hemos perdido. Ni uno. Cero.
No es suerte. Es que sabemos dónde buscar lo que el banco no quiere que busques.
Empresario al que le vaciaron la cuenta y el banco le dijo que fue su culpa: lo que sigue en este artículo es la historia técnica de cómo se demuestra lo contrario. No es teoría. Es lo que hicimos. Es lo que funcionó. Y es lo que puede funcionar en su caso si la evidencia existe.
Abogado del empresario que está armando la demanda contra el banco: lo que necesita no es un argumento jurídico más elaborado. Lo que necesita es un peritaje informático que destruya la línea del banco desde sus cimientos técnicos. Ese peritaje es lo que va a leer en las próximas páginas.
Perito del banco que va a leer esto porque le toca la contraparte: con todo respeto, y se lo digo de frente porque nos vamos a ver en audiencia: si su análisis se limitó a verificar que la IP coincide y que las credenciales fueron correctas, no hizo un peritaje. Hizo una lectura de logs. Y hay un abismo de diferencia entre las dos cosas.
Contador de la empresa que fue quien detectó el faltante: lo que viene aquí le va a dar contexto técnico para entender qué pasó. Y más importante, le va a dar argumentos para que el empresario y el abogado entiendan que esto no fue un error de dedo ni una negligencia contable. Fue un ataque.
El caso: la IP que mentía
Voy a contar un caso tipo — basado en casos reales que ha investigado Duriva, con datos modificados para proteger a los involucrados — porque ilustra con precisión quirúrgica el patrón de ataque que hemos visto repetirse una y otra vez.
Una organización. Puede ser una empresa, puede ser una ONG, puede ser una sociedad civil. El tamaño no importa. Lo que importa es que tenía una cuenta empresarial en un banco mexicano, con banca en línea habilitada, y que un día aparecieron transferencias por varios millones de pesos que nadie en la organización autorizó.
El área de finanzas detectó el faltante en la conciliación bancaria. Llamó al banco. El banco confirmó que las transferencias se habían ejecutado correctamente. Desde la IP registrada de la organización. Con el usuario y contraseña correctos. Con el token de autenticación validado.
«La operación se realizó desde su red. No hay anomalía en nuestros sistemas. La responsabilidad es del cliente.»
La organización presentó su reclamación ante CONDUSEF. CONDUSEF solicitó al banco la información de la operación. El banco presentó su evidencia: logs de acceso, IP de origen, timestamp de la operación, estatus del token. Todo cuadraba. La transferencia salió de la IP de la organización. Para CONDUSEF, caso cerrado. Resolución genérica. «No se acredita responsabilidad del banco.»
Y ahí es donde, en la mayoría de los casos, la historia termina. El empresario absorbe la pérdida. El banco sigue operando. CONDUSEF archiva el expediente.
Pero esta organización hizo algo diferente. Contrató a Duriva.
Lo que encontramos: envenenamiento DNS del router
Cuando mi equipo llegó a las oficinas de la organización, lo primero que hicimos fue lo que hacemos siempre: no asumir nada. No asumir que fue el banco. No asumir que fue un empleado desleal. No asumir que fue un «hackeo sofisticado.» Auditar todo. Desde el cable de red hasta el servidor del banco.
Y lo primero que revisamos fue el router.
El router. Ese aparato que está en la esquina de la oficina, cubierto de polvo, con las luces parpadeando, que nadie ha tocado desde que el técnico del proveedor de internet lo instaló hace tres años. Ese aparato que conecta toda la red de la empresa a internet. Ese aparato que resuelve los nombres de dominio — es decir, que cuando alguien en la oficina escribe «bancoenlinea.com.mx» en su navegador, es el router el que traduce ese nombre a la dirección IP del servidor del banco.
Y ahí estaba. La configuración DNS del router había sido alterada.
En castellano: alguien había entrado a la configuración del router — que probablemente tenía la contraseña de fábrica, porque nadie la cambió, porque nadie pensaba que el router fuera relevante para la seguridad bancaria — y había cambiado los servidores DNS. En lugar de apuntar a los DNS del proveedor de internet o a los de Google (8.8.8.8, como los conoce todo el mundo), apuntaban a servidores controlados por los atacantes.
¿Qué significa eso en la práctica? Que cuando el contador de la organización escribía «bancoenlinea.com.mx» en su navegador, el router no lo mandaba al banco. Lo mandaba a una réplica exacta de la página del banco, alojada en un servidor de los atacantes. Una página idéntica. Mismos colores. Mismo logo. Mismo formulario de login. Mismo campo para el token. Indistinguible a simple vista.
El contador ingresaba su usuario. Su contraseña. Su token. La página falsa capturaba todo. Lo reenviaba al banco real para que la sesión se abriera normalmente — el usuario no notaba nada, la página cargaba como siempre, veía su saldo, todo normal. Pero los atacantes ya tenían las credenciales. Y el token que acababa de ingresar todavía era válido por unos segundos — suficientes para usarlo en una sesión paralela y ejecutar la transferencia fraudulenta.
El ataque se llama pharming, y es una variante del man-in-the-browser. No requiere malware en la computadora del usuario. No requiere que nadie haga clic en un enlace sospechoso. No requiere ingeniería social sofisticada. Solo requiere acceso al router.
Y acceder al router de la mayoría de las PYMES en México es trivial. Contraseña de fábrica: admin/admin. O 1234. O password. O el nombre del fabricante. O nada — porque algunos routers vienen con acceso abierto por defecto. Treinta segundos. Dos líneas de configuración. Y toda la red de la empresa queda comprometida.
IP privada = «Interior 1234»: la analogía que el juez entendió
Aquí viene el argumento técnico que le ganó el caso al empresario. Y necesito que lo entiendan el abogado, el empresario y el contador, porque es la base de toda la defensa.
El banco dice: «La transferencia salió de la IP de la empresa.»
Correcto. La transferencia salió de la IP pública de la empresa. Eso no está en discusión. Los logs del banco lo confirman. Nadie lo niega.
Pero la IP pública de una empresa es como la dirección de un edificio. «Avenida Reforma 500.» Eso te dice en qué edificio estás. No te dice en qué piso. No te dice en qué oficina. No te dice quién estaba sentado frente a la computadora.
La IP pública es la dirección del edificio. La IP privada — la que tiene cada dispositivo dentro de la red, asignada por el router — es el «Interior 1234.» Y el banco solo registró la dirección del edificio.
Si yo le digo a un juez: «Señor juez, la transferencia se hizo desde Avenida Reforma 500,» el juez me pregunta: «¿Y quién la hizo?» Y yo le digo: «No sé. Pero fue desde ese edificio.» Eso no prueba nada. En ese edificio hay 200 oficinas, 500 personas y probablemente 300 dispositivos conectados a internet. Cualquiera de esos dispositivos — incluyendo un dispositivo del atacante que logró conectarse a la red a través del router comprometido — pudo haber ejecutado la transferencia.
Esa fue la analogía que usamos en el juicio. Y el juez la entendió perfectamente. Porque es sentido común. La IP pública no identifica al usuario. Identifica a la red. Y si la red estaba comprometida, la IP pública no significa nada.
El perito del banco argumentó que la IP coincidía con la registrada. Correcto. Coincide con la dirección del edificio. Pero el edificio tenía la puerta abierta y alguien entró sin que nadie se diera cuenta. Y ese alguien ejecutó la transferencia desde adentro del edificio, con credenciales robadas a través del mismo router comprometido.
La IP del edificio no le da la razón al banco. Le da la razón a quien demuestre qué pasó dentro del edificio. Y eso lo demuestra la auditoría forense del router, no los logs del banco.
Lo que el perito del banco no revisó (y nunca revisa)
Esto lo digo con el respeto profesional que merece cualquier perito, pero con la franqueza que requiere la situación: en la inmensa mayoría de los casos de transferencia no reconocida que he visto, el perito del banco hace lo siguiente:
- Revisa los logs del banco.
- Confirma que la IP, el usuario, la contraseña y el token coinciden.
- Concluye que «no hay evidencia de vulneración a los sistemas del banco.»
- Fin del análisis.
Y tiene razón en su conclusión limitada: no hay evidencia de vulneración a los sistemas del banco. Los sistemas del banco no fueron hackeados. El servidor del banco funcionó correctamente. La banca en línea procesó la operación como procesa cualquier otra.
Pero eso no es la pregunta. La pregunta no es si los sistemas del banco fueron hackeados. La pregunta es si la persona que ejecutó la operación era el titular de la cuenta o un tercero que obtuvo las credenciales de manera fraudulenta. Y esa pregunta no se responde mirando los logs del banco. Se responde mirando la red del cliente.
Lo que el perito del banco no revisó — y en mi experiencia, nunca revisa — es:
La configuración del router de la empresa. Los servidores DNS. Las tablas ARP. El firmware. Las credenciales de acceso administrativo. El historial de cambios de configuración. Si el router fue comprometido, la evidencia está ahí. Pero nadie la busca.
Los registros de tráfico de red. Si la empresa tenía un firewall o un sistema de monitoreo de red — y la mayoría no lo tiene, lo cual es parte del problema –, los registros de tráfico pueden mostrar conexiones sospechosas a servidores desconocidos en los minutos previos a la transferencia. Conexiones a la página falsa del banco. Conexiones a servidores de los atacantes que capturaban las credenciales.
El estado de las computadoras de la red. Análisis de malware, man-in-the-browser, keyloggers, troyanos bancarios. Si la computadora desde la que se accedió a la banca en línea tenía algún tipo de software malicioso, esa es evidencia directa de que las credenciales fueron comprometidas. Pero si nadie analiza la computadora, el malware se queda ahí, invisible, mientras el banco culpa al usuario.
Los certificados SSL de las sesiones bancarias. Cuando accedes a la página real de tu banco, el navegador verifica el certificado SSL — ese candadito verde que dice que la conexión es segura y que el sitio es quien dice ser. Si la sesión bancaria se realizó a través de una página clonada con un certificado falso o auto-firmado, los registros del navegador pueden contener advertencias de certificado que nadie vio porque el router redirigía al usuario sin que este lo notara. Esa advertencia, si existe en los logs del navegador, es evidencia de pharming.
El perito del banco mira la capa superficial. La capa de «la operación fue ejecutada con las credenciales correctas desde la IP registrada.» Y desde esa capa, todo cuadra. Pero debajo de esa capa hay un mundo entero de evidencia que el banco no quiere que se examine. Porque si se examina, la narrativa de «la culpa es del usuario» se derrumba.
La auditoría de red que ganó el juicio
Esto es lo que presentó Duriva ante el juez. Y esto es lo que le ganó el caso al empresario.
Primero: evidencia del envenenamiento DNS. Se documentó que la configuración DNS del router había sido alterada para apuntar a servidores no autorizados. Se identificaron los servidores DNS maliciosos por su IP. Se verificó que esos servidores habían sido reportados en bases de datos de amenazas como servidores asociados a ataques de pharming financiero. Se presentó la configuración original de fábrica del router y se contrastó con la configuración encontrada. La diferencia era clara: alguien cambió los DNS.
Segundo: evidencia de la página clonada. Se demostró que los servidores DNS maliciosos redirigían el dominio del banco a una IP diferente a la IP real del banco. Se capturó y se certificó el sitio falso — que todavía estaba activo al momento de la investigación, porque los atacantes no siempre desmontan su infraestructura inmediatamente. Se presentó una comparación visual y técnica entre la página real del banco y la página clonada: idénticas en apariencia, diferentes en infraestructura.
Tercero: evidencia de la captura de credenciales. Se analizó el código fuente de la página clonada. El formulario de login no enviaba las credenciales al servidor del banco. Las enviaba a un servidor de los atacantes. Y simultáneamente — esto es lo elegante del ataque — reenviaba al usuario a la página real del banco con una sesión limpia, para que el usuario no sospechara nada. El usuario pensaba que había iniciado sesión normalmente. En realidad, había entregado sus credenciales al atacante y el atacante las había usado en paralelo.
Cuarto: evidencia de la vulnerabilidad del router. Se demostró que el router tenía la contraseña de fábrica. Que era accesible desde internet — porque el proveedor de internet había dejado habilitada la administración remota. Que no tenía firmware actualizado. Que tenía vulnerabilidades conocidas documentadas en CVE (Common Vulnerabilities and Exposures). En resumen: entrar al router era trivial. Cualquier persona con un escáner de puertos y cinco minutos de paciencia podía hacerlo.
Quinto: la reconstrucción cronológica del ataque. El peritaje presentó una línea de tiempo que mostraba: (1) la fecha aproximada en que el router fue comprometido, basada en el análisis de los logs disponibles; (2) el periodo durante el cual los DNS estuvieron alterados y las credenciales fueron capturadas; (3) la fecha y hora de las transferencias fraudulentas; (4) la relación causal entre el compromiso del router y la ejecución de las transferencias.
Todo sustentado con el artículo 210-A del Código Federal de Procedimientos Civiles. Todo con valor hash SHA-256 de cada pieza de evidencia. Todo con cadena de custodia documentada. Todo firmado por perito certificado.
El juez vio la evidencia. El juez entendió la mecánica del ataque. El juez comprendió que la IP de la empresa no significaba que la empresa hubiera autorizado la transferencia — significaba que la empresa había sido víctima de un ataque que usó su propia red como plataforma.
El banco perdió.
CONDUSEF: por qué sus resoluciones no te sirven
Voy a ser directo con esto porque el empresario necesita entenderlo antes de perder tres meses esperando una resolución que no le va a servir.
CONDUSEF — la Comisión Nacional para la Protección y Defensa de los Usuarios de Servicios Financieros — es un organismo de mediación. No es un tribunal. No emite sentencias. No tiene capacidad coercitiva real sobre los bancos. Y lo más importante para efectos de este artículo: no tiene la capacidad técnica para investigar un fraude informático.
Cuando un usuario presenta una reclamación ante CONDUSEF por una transferencia no reconocida, el proceso es el siguiente: CONDUSEF le pide al banco la información de la operación. El banco presenta sus logs. CONDUSEF revisa los logs. Los logs dicen que la operación fue ejecutada con las credenciales correctas desde la IP registrada. CONDUSEF concluye que «no se acredita responsabilidad de la institución bancaria.»
Es un proceso circular. La única evidencia que CONDUSEF evalúa es la que el banco presenta. Y el banco presenta la evidencia que le conviene: los logs que confirman que «todo fue normal.» CONDUSEF no tiene peritos forenses que analicen el router del cliente. No tiene laboratorio para detectar envenenamiento DNS. No tiene la capacidad de auditar la red de la empresa para determinar si las credenciales fueron comprometidas.
CONDUSEF mira lo que el banco le muestra. Y lo que el banco le muestra es que la operación fue «correcta.» Fin del análisis.
Las resoluciones de CONDUSEF son genéricas, predecibles y, en la mayoría de los casos de fraude informático, inservibles como instrumento de defensa. Le soy franco al empresario que está leyendo esto: ir a CONDUSEF no le va a devolver su dinero. Lo que le va a devolver su dinero es un juicio civil o mercantil con peritaje informático que demuestre la responsabilidad del banco.
CONDUSEF puede servir como un paso preliminar — genera constancia de la reclamación, genera un expediente. Pero no lo trate como la solución. Trátelo como un paso administrativo mientras arma la estrategia real.
Man-in-the-browser: la otra cara del fraude
El envenenamiento DNS del router es una modalidad. Pero no es la única. Hay otra que hemos visto en el laboratorio de Duriva y que es igualmente devastadora: el man-in-the-browser.
En esta modalidad, el ataque no está en el router. Está en la computadora del usuario. Un malware — un troyano bancario — se instala en el navegador y se activa cuando el usuario accede a la página de su banco. No redirige a una página falsa. Deja que el usuario interactúe con la página real del banco. Pero modifica la información en tiempo real, sin que el usuario lo note.
El usuario ve en su pantalla: «Transferencia a Proveedor XYZ, cuenta CLABE 012345678901234567, monto: $150,000.»
El banco recibe: «Transferencia a cuenta CLABE 987654321098765432, monto: $1,500,000.»
El usuario confirma. Ingresa su token. Piensa que está autorizando una transferencia rutinaria a su proveedor. En realidad, está autorizando una transferencia por diez veces el monto a una cuenta desconocida. Y cuando revisa su estado de cuenta después, el monto y la CLABE no coinciden con lo que vio en su pantalla.
El man-in-the-browser es sofisticado. Requiere malware específico para cada banco. Requiere conocimiento de la interfaz de la banca en línea del banco objetivo. Requiere programación avanzada. Pero existe. Opera en México. Lo hemos documentado en el laboratorio.
Y cuando el empresario va al banco y dice «yo vi otra CLABE y otro monto en mi pantalla,» el banco responde: «Señor, la operación se ejecutó con las credenciales correctas y la instrucción que recibimos fue la que se procesó.» El banco no puede ver lo que el usuario vio en su pantalla. El banco solo ve la instrucción que llegó a su servidor. Y la instrucción que llegó — modificada por el malware — es la que se ejecutó.
Para demostrar man-in-the-browser, el perito necesita analizar la computadora del usuario. Buscar el malware. Identificarlo. Documentar su funcionamiento. Demostrar que estaba activo al momento de la transferencia. Y presentar esa evidencia ante el juez.
Es un análisis forense más complejo que el del router. Pero es igualmente demostrativo. Y es igualmente ganador en juicio.
El artículo 210-A y la prueba pericial: la base legal que sostiene todo
Todo lo que he descrito — el envenenamiento DNS, la página clonada, el man-in-the-browser, la auditoría de red — tiene valor probatorio únicamente si se presenta bajo el marco legal correcto.
El artículo 210-A del Código Federal de Procedimientos Civiles establece los requisitos para que la información generada por medios electrónicos tenga valor ante un juez: fiabilidad del método, atribuibilidad del contenido y accesibilidad para consulta posterior.
Un dictamen pericial en informática que documente la configuración del router comprometido, que presente los hashes de la imagen forense del disco duro, que muestre la evidencia del envenenamiento DNS con cadena de custodia, que reconstruya cronológicamente el ataque con datos verificables — ese dictamen cumple con los tres requisitos del 210-A. Y es la prueba que el juez necesita para entender que la IP no es sinónimo de identidad.
Sin el peritaje, el abogado del empresario tiene un argumento: «Mi cliente no hizo esa transferencia.» Con el peritaje, tiene una demostración: «Aquí está cómo un tercero comprometió la red del cliente, capturó sus credenciales y ejecutó la transferencia fraudulenta desde la misma red — por eso la IP coincide.»
El argumento es impugnable. La demostración es ciencia.
Lo que necesita saber cada persona que lee esto
Empresario al que le vaciaron la cuenta:
No acepte la respuesta del banco como definitiva. «Fue su IP, fue su culpa» no es un veredicto. Es la versión del banco. Y la versión del banco no es imparcial — es la versión de la parte que no quiere pagar.
Antes de ir a CONDUSEF — o después de ir y recibir la resolución genérica que probablemente va a recibir –, haga esto: no toque el router. No lo reinicie. No lo formatee. No lo cambie. Ese router puede contener la evidencia que le gane el juicio. Si ya lo cambió, pregunte al proveedor de internet si tiene registros de la configuración anterior. Si el router tiene logs, presérvelos.
No formatee ninguna computadora de la red. Si hay malware, necesita encontrarse, no borrarse. El malware es evidencia. El malware es la prueba de que usted no autorizó esa transferencia. Borrarlo es como destruir la grabación de la cámara de seguridad que muestra al ladrón entrando.
Contacte a un perito en informática forense. No a un «experto en ciberseguridad» que le va a vender un firewall. A un perito forense que sepa auditar la red, analizar el router, buscar malware, documentar la intrusión y generar un dictamen pericial con valor probatorio ante un juez.
Y hable con un abogado que tenga experiencia real en litigio bancario. No un abogado que «también lleva casos mercantiles.» Un abogado que haya enfrentado a un banco en juicio y que entienda que la batalla se gana con peritaje, no con alegatos.
Abogado del empresario:
La defensa del banco es una sola: «la IP coincide, las credenciales eran correctas, no hay vulneración de nuestros sistemas.» Su trabajo es destruir esa defensa. Y se destruye con una sola prueba: el peritaje informático que demuestre que la red del cliente estaba comprometida.
No pida el peritaje después de perder en CONDUSEF. Pídalo desde el día uno. Porque la evidencia se degrada. Los routers se reinician. Las computadoras se formatean. Los logs se sobreescriben. Cada día que pasa sin preservar la evidencia es un día donde su caso se debilita.
El peritaje cuesta una fracción de lo que está en juego. Si le vaciaron la cuenta por dos millones y el peritaje cuesta $3,000 dólares, la matemática se hace sola. No es el costo del peritaje lo que debería preocuparle. Es el costo de no tenerlo.
Perito del banco que va a enfrentar este dictamen en audiencia:
Con todo respeto profesional: si su análisis se limitó a los logs del banco y su conclusión es que «la operación fue realizada con las credenciales correctas del usuario,» prepárese para una contrapericial que le va a preguntar si revisó el router, si analizó el tráfico de red, si buscó malware en la computadora del usuario, si verificó los certificados SSL de la sesión bancaria, si revisó la configuración DNS, si hizo algo más allá de leer los logs de su propio cliente.
Si la respuesta a todas esas preguntas es «no,» su dictamen está incompleto. Y un dictamen incompleto que se presenta como conclusivo es peor que no presentar dictamen. Porque demuestra que el banco no investigó — solo confirmó su propia narrativa.
Contador de la empresa que detectó el faltante:
Usted no es el responsable. Si las credenciales fueron robadas a través de un router comprometido o un man-in-the-browser, usted fue víctima del ataque, no cómplice. Lo que necesita hacer es documentar con precisión qué pasó: qué vio en su pantalla, a qué hora accedió a la banca en línea, qué monto y CLABE confirmó, qué token usó. Esa declaración, contrastada con el peritaje forense que demuestre la alteración de la operación, completa la cadena probatoria.
Y un consejo: guarde los registros contables de la conciliación bancaria donde detectó la discrepancia. La fecha en que usted reportó el faltante es relevante para demostrar que la empresa actuó con diligencia al detectar el fraude.
Preguntas frecuentes
Mi caso tiene más de un año. ¿Todavía se puede hacer el peritaje?
Depende del estado de la evidencia. Si el router original ya no existe y las computadoras fueron formateadas, la evidencia de la intrusión puede haberse perdido. Pero no necesariamente todo está perdido: el proveedor de internet puede tener registros históricos, los logs del banco todavía están disponibles mediante solicitud judicial, y si hay respaldos de la configuración de red, pueden analizarse. Cada caso es diferente. Lo que no debe hacer es asumir que ya no se puede sin consultarlo con un perito.
El banco me ofrece un «convenio» por un porcentaje del monto. ¿Debo aceptar?
Esa es una decisión jurídica que debe tomar con su abogado. Lo que puedo decirle desde la perspectiva técnica es lo siguiente: si el banco le ofrece un convenio, es porque su propia evaluación de riesgo le dice que puede perder el juicio. Los bancos no regalan dinero. Si le están ofreciendo pagar una parte, es porque saben que la evidencia no está a su favor — o que puede no estarlo si usted contrata un peritaje. Use esa información como le parezca conveniente.
¿CONDUSEF puede ordenar al banco que me pague?
No. CONDUSEF puede mediar, puede emitir recomendaciones, puede sancionar al banco con multas administrativas. Pero no puede ordenar al banco que le devuelva su dinero. Eso solo lo puede hacer un juez. CONDUSEF es un paso, no la solución.
¿Puedo demandar al banco y al proveedor de internet?
Potencialmente sí. Si el proveedor de internet instaló el router con credenciales de fábrica y habilitó la administración remota sin informarle de los riesgos, hay un argumento de responsabilidad. Pero ese es un análisis jurídico que debe hacer su abogado con base en los hallazgos del peritaje.
El banco dice que fuiste tú porque la IP coincide. Y la IP coincide porque el ataque se ejecutó desde tu propia red. Eso no significa que fuiste tú. Significa que alguien usó tu red sin tu conocimiento, con credenciales robadas a través de tu router comprometido, para ejecutar una transferencia que tú no autorizaste.
Demostrar eso es trabajo del perito forense. Es trabajo técnico. Es trabajo de laboratorio. Es trabajo que requiere auditar la red, analizar el router, buscar el malware, reconstruir el ataque, documentar cada paso con cadena de custodia y presentarlo ante un juez con el rigor que exige el artículo 210-A.
En Duriva, eso es lo que hacemos. Lo que hemos hecho caso tras caso contra los bancos más grandes de México. Y el resultado habla por sí mismo: récord invicto. No porque los bancos sean incompetentes. Son instituciones con recursos enormes y equipos jurídicos formidables. Sino porque cuando la evidencia técnica demuestra que el cliente fue víctima de un ataque y no autor de la transferencia, no hay log bancario que sostenga la narrativa del banco.
La IP no es identidad. El router es la escena del crimen. Y cuando alguien sabe leer esa escena, el banco pierde.
Siempre.