- La mayoría de los ATMs ejecuta Windows (XP y 7), con presencia residual de Linux y pruebas con Android.
- El estándar XFS y la mensajería ISO 8583 vertebran la comunicación entre software, periféricos y core bancario.
- Malware como Tyupkin, Skimer o campañas tipo Carbanak explotaron redes internas y procesos de actualización.
- El legado del core bancario y los altos costes de cambio frenan migraciones; la defensa exige varias capas.
Los cajeros automáticos son, en esencia, ordenadores conectados a una red financiera, y no cualquier red: hablamos del corazón del sistema bancario. A pesar de su apariencia robusta, su software y su arquitectura arrastran decisiones tecnológicas de hace décadas que condicionan su seguridad, su mantenimiento y, por extensión, la experiencia del cliente.
Si te preguntas qué sistema operativo llevan, la respuesta corta es: mayoritariamente Windows, en versiones antiguas y más recientes, con casos residuales de Linux y pruebas con Android. La respuesta larga implica entender el ecosistema ATM, los estándares que lo sostienen (XFS e ISO 8583), la dependencia del core bancario heredado, y por qué todo ello ha abierto la puerta a campañas de malware y fraudes altamente sofisticados.
Qué sistema operativo usan hoy los cajeros automáticos
A día de hoy, la gran mayoría de cajeros del mundo ejecuta alguna edición de Windows, con una presencia histórica muy amplia de Windows XP y una transición extensa a Windows 7. Sigue habiendo equipos en XP y en 7, pese a que el soporte extendido de XP terminó a mediados de 2014. Según estimaciones citadas en 2014, alrededor del 95% de los cajeros seguían en XP en aquel momento, con costes operativos significativamente mayores frente a Windows 7.
La cuota de Linux en ATMs es minoritaria: menos del 1% (principalmente SUSE) según fuentes del sector. También hay iniciativas que exploran Android y sistemas operativos IoT para terminales táctiles, impulsadas por fabricantes como NCR, aunque ese movimiento suscita debates de seguridad por el amplio ecosistema y superficie de ataque de Android.
¿Por qué persiste Windows en cajeros? Por compatibilidad con un parque de hardware muy heterogéneo, por la dependencia de middlewares y drivers de fabricantes de periféricos (dispensadores, lectores, impresoras), y por la integración con suites comerciales y estándares de facto. En otras palabras, el coste de migrar es elevado y el riesgo operativo también, lo que frena los cambios drásticos.
No es solo el sistema operativo: el software que dialoga con el hardware ATM y con el core bancario suele estar construido sobre estándares XFS (en sus variantes WOSA/XFS, J/XFS o implementaciones multivendor), lo que ata la elección de plataforma a pilas tecnológicas probadas y certificadas durante años.
Fabricantes, plataformas XFS y multivendor
El mercado global está dominado por tres nombres: Wincor Nixdorf (ahora parte de Diebold Nixdorf), Diebold y NCR. Existen otros actores como Triton, WRG o Nautilus, pero su cuota es menor. Estos fabricantes integran hardware (perimetrales) y software que gobierna cada dispositivo del cajero.
Todos implementan la familia de estándares XFS (Exchange Financial Services), base de la comunicación entre la aplicación ATM y los periféricos. Hay varias implementaciones: WOSA/XFS, J/XFS y proyectos como FreeXFS, además de capas multivendor que permiten operar con hardware de diferentes marcas.
Algunas soluciones representativas del ecosistema XFS y multivendor son: NCR Aptra; Diebold Agilis; Wincor ProCash/ProBase; KAL Kalignite; y propuestas históricas como Jam Services y FreeXFS. Estas capas posibilitan que una misma aplicación maneje lectores, dispensadores y sensores aunque el cajero sea de un fabricante distinto, lo que facilita la estandarización y el mantenimiento a gran escala.
El modelo por capas es clave: aplicación de proveedor, API XFS, gestor XFS y drivers del sistema operativo. Cada capa aporta una pieza del puzzle para que el cajero reciba la orden, valide la transacción y active el hardware de forma segura y auditada.
Cómo se conectan a la red bancaria: ISO 8583, TCP/IP y VPN
Un cajero no decide por sí mismo si autoriza o deniega tu retirada: consulta al core bancario. La comunicación con el host transaccional se realiza sobre TCP/IP por su ubiquidad y fiabilidad, habitualmente encapsulada a través de VPNs privadas que enlazan con el centro de procesamiento.
El formato de mensajes que viaja entre cajero y core responde al estándar ISO 8583, que define campos y estructuras para operaciones con tarjeta. Este estándar es la columna vertebral de la mensajería financiera retail: retiro, consulta, reverso, advice, etc.
Un punto delicado del sector es que, por interoperabilidad y legado, hay implementaciones que no cifran el payload de aplicación por defecto, confiando el canal seguro a la VPN. Cuando esto se combina con segmentaciones débiles o con controles insuficientes de integridad, aumenta la exposición si un atacante llega a la red interna.
Los cajeros registran eventos en un Journal (registro de actividad) a nivel XFS y, en ocasiones, también a nivel del sistema operativo. Es la fuente primaria para correlación y forense en caso de incidente, y su gestión es una práctica de seguridad básica en la operación diaria.
Malware, jackpotting y por qué un cajero es un objetivo jugoso
Al margen de ataques físicos (skimming, cámaras, superposiciones de teclado), el foco criminal se ha desplazado hacia el control lógico del cajero y de la red bancaria. Las razones son claras: el ordenador del cajero suele estar menos blindado que la caja fuerte del efectivo, y los módulos se conectan a través de interfaces estándar (USB, COM) que, mal protegidas, abren caminos.
En el congreso SAS 2016, especialistas de Kaspersky explicaron que muchos ATMs siguen operando con sistemas sin soporte y con software desactualizado (por ejemplo, reproductores o herramientas de administración remota). La falta de controles de integridad, de autenticación entre aplicación y periféricos y de antivirus en algunas instalaciones multiplica el riesgo.
Ejemplos conocidos ilustran este panorama: el troyano Tyupkin afectó a cajeros específicos, el backdoor Skimer (detectado en 2009) tomó control del núcleo del ATM con comando activable desde el teclado, y campañas tipo Carbanak alcanzaron centros de procesamiento para mandar órdenes a cajeros sin tocar físicamente el terminal. Estos casos no son teoría, son incidentes estudiados por fuerzas de seguridad y compañías de ciberseguridad.
Incluso dispositivos sencillos, como un miniordenador con batería y conectividad inalámbrica, han servido en pruebas de laboratorio para demostrar que si se llega a un puerto accesible y no hay medidas de hardening, es factible provocar comportamientos anómalos. Por motivos de seguridad, evitamos detallar técnicas específicas o nombres de componentes operativos; el objetivo aquí es concienciar, no dar instrucciones.
De la sucursal a la cadena de actualización: cómo se orquestan los ataques avanzados
Las bandas más sofisticadas no se conforman con un cajero: buscan la red corporativa. La secuencia típica arranca con la intrusión en una oficina o área periférica, mediante phishing o dispositivos USB que un empleado conecta sin sospecharlo. A partir de ahí, roban credenciales, escalan privilegios y mapean la topología.
Una vez comprendida la infraestructura, ponen la vista en los sistemas que distribuyen parches y software a los ATMs. Si logran acceder al servidor de actualizaciones y suplantar un paquete legítimo, pueden introducir una actualización fraudulenta que habilite servicios remotos o instale componentes maliciosos en serie.
Con el canal plantado, abren sesiones remotas contra múltiples cajeros y prueban en unidades concretas con la ayuda de mulas in situ. Cuando validan que la manipulación funciona, despliegan a mayor escala herramientas centradas en la extracción de efectivo o el robo de datos. Al terminar, limpian rastros y cierran conexiones para dificultar el forense.
Este patrón, documentado en ataques reales a bancos con sedes en distintos países, demuestra que la seguridad de un cajero no es solo “la seguridad del cajero”. Es la seguridad de toda la cadena: desde el puesto del empleado hasta el servidor que compila y firma la actualización.
Arquitectura por capas del software ATM (sin cruzar la línea roja)
El software de un cajero opera en cuatro capas: aplicación del proveedor (interfaz y lógica de negocio), API XFS (permisos y conectores hacia dispositivos), gestor XFS (core de mensajería estandarizada) y drivers del sistema operativo (que hablan con el hardware). Este diseño modular facilita el diagnóstico y la interoperabilidad entre marcas.
En la práctica, existen ejecutables y bibliotecas específicas para cada fabricante y periférico, así como métodos estandarizados (comandos XFS) para acciones como aceptar efectivo, dispensar, reposicionar o resetear unidades. Por responsabilidad, evitamos listar DLLs, IOCTLs o llamadas concretas que podrían usarse indebidamente; basta con saber que el estándar y sus SDKs describen estos flujos con detalle.
La consecuencia operativa es clara: cualquier proceso con privilegios elevados en el sistema puede intentar interactuar con controladores si no hay medidas adicionales (control de integridad, whitelisting, aislamiento de cuentas de servicio). El principio de mínimo privilegio y la segmentación estricta son imprescindibles en equipos que gobiernan hardware con dinero real detrás.
En algunos modelos se han observado puertos adicionales (p. ej., FireWire en ciertas series) y predominio de conexiones USB para periféricos. La gestión de BIOS/UEFI y el deshabilitado de puertos no necesarios son controles básicos que reducen la superficie de ataque físico.
Buenas prácticas habituales (y sus límites)
El sector recomienda un conjunto amplio de medidas: cifrado de comunicaciones de red (a menudo vía VPN), cifrado de disco, protección de BIOS, endurecimiento del sistema operativo, listas blancas de aplicaciones, antivirus, y controles específicos para la pila XFS. También se exige cumplir estándares como PCI, con revisiones periódicas.
La gestión de parches suele pactarse con el fabricante con ventanas trimestrales o similares. El problema es que algunos componentes críticos de terceros (por ejemplo, entornos de ejecución) no siempre se actualizan al ritmo deseable por compatibilidad, abriendo huecos en el tiempo entre parches.
La correlación de eventos descansa en el Journal de XFS y, en ocasiones, en registros del sistema. Extraer, consolidar y monitorizar estos logs es vital para detectar desviaciones (errores de dispositivos, entradas inesperadas, patrones de fraude) y responder a tiempo.
Además, los bancos despliegan contramedidas físicas contra skimming, políticas de respuesta a incidentes y controles de acceso a personal (transportistas, técnicos, proveedores). Documentar quién toca qué y cuándo es clave para la trazabilidad, tanto en mantenimiento como en investigación de incidentes.
El peso del legado bancario: por qué cuesta tanto cambiar
El problema de fondo no está solo en los cajeros: muchos cores bancarios superan de largo la década (en Europa, encuestas de 2010 situaban entre 11 y 30 años la edad de la mayoría, con un 11% anterior a los 80). En 2014 apenas un 10% de bancos había renovado su plataforma en los tres años previos, y el coste de mantener el core absorbe entre el 70% y el 80% del presupuesto de TI, muy por encima de otros sectores y más del doble que en compañías nativas digitales.
Esa masa de legado implica COBOL y tecnologías veteranas, con equipos de desarrollo cuya media de edad ronda los 50 años y escasez de relevo generacional. COBOL ya no se enseña con la intensidad de antaño, y eso complica evoluciones profundas. A su vez, los cores fueron diseñados para back-office, no para la agilidad que exige la banca móvil y la personalización actual.
El resultado: más parches, más redundancias, definiciones de datos dispares y documentación insuficiente de código antiguo. La arquitectura se vuelve frágil, lenta y cara, y cada intento de colgarle una característica moderna al lado puede tensionar la estabilidad del conjunto.
El Reino Unido vivió varios incidentes notables en grandes bancos (caídas de cajeros, bloqueos de tarjetas, servicios online fuera de juego) que afectan a millones de clientes. La lectura común de reguladores, clientes y competidores es que el déficit de inversión en TI agrava los riesgos operativos. Sin una arquitectura de primer nivel, es difícil competir por experiencia de cliente y rapidez al mercado.
¿Por qué siguen tantos cajeros en Windows XP/7?
Modernizar cuesta, y no solo económicamente. Cambiar hardware (de equipos basados en arquitecturas antiguas a plataformas modernas) y certificar de nuevo todo el stack puede no mostrar un retorno inmediato de cara al usuario. Muchos clientes no “ven” el cambio, así que internamente compite con otras prioridades de negocio.
Durante la retirada de XP, algunas entidades negociaron soporte extendido por equipo, lo que dilató la migración. El razonamiento: si el cajero está aislado y bien gestionado, el riesgo es aceptable. Pero el aislamiento perfecto no existe: los incidentes demostraron que la red interna, los procesos de actualización y los puestos de trabajo son vectores viables.
Otro factor es la compatibilidad de drivers y suites XFS existentes para el parque de periféricos, más el esfuerzo de recertificar aplicaciones críticas. Cuando además se depende de proveedores que marcan el ritmo, el calendario de parches y upgrades entra en contratos y SLAs que no siempre permiten moverse con la velocidad deseable.
Algunas estadísticas históricas señalaban que el coste operativo de XP en ATM podía ser varias veces superior al de versiones más nuevas, por necesidad de mitigaciones, soporte y controles adicionales. El coste de no cambiar también existe, aunque a veces sea más difícil de ver hasta que llega el incidente.
Periféricos, buses y superficie de ataque
Los dispensadores de efectivo, validadores, lectores de tarjetas y sensores conforman el “perímetro” del cajero y son ejemplos de periféricos de salida. Su comunicación suele ir por USB, y en algunos modelos por buses adicionales. Si el chasis donde está el PC no es tan robusto como la caja fuerte y los bloqueos físicos son pobres, el acceso a puertos se vuelve el eslabón débil.
El diseño habitual asume que “donde no hay dinero no hace falta blindaje extremo”, pero el ordenador que gobierna los periféricos es el que, a la postre, da la orden de dispensar. Por eso el hardening físico del compartimento del PC y el control de puertos son tan relevantes como el cifrado de la red.
Algunos ataques combinan ingeniería social y dispositivos externos para entrar por esa vía. El control de medios removibles y políticas de USB estrictas son una necesidad en cualquier entidad financiera; no basta con confiar en que un equipo “no tiene Internet”.
Por otro lado, herramientas de escaneo de Internet han llegado a listar cajeros o componentes de su cadena mal segmentados. Exponer innecesariamente servicios o paneles a redes públicas es una invitación al desastre, incluso si el propio ATM no está “directamente” en Internet.
