Hace algo más de dos años, alguien me dijo que la idea que teníamos en Internet Security Auditors de conseguir un escáner de PANs que se ejecutara en todos los sistemas que se nos pudiera imaginar, con las capacidades técnicas de búsqueda de datos en cualquier objeto existente en un sistema y que, en todos los sistemas, tuviéramos el 100 % de las funcionalidades, hasta una potente GUI que permitiera la gestión de hallazgos y pudiera crecer en funcionalidades como el etiquetado de hallazgos, la remediación y otras, era imposible.
Sin duda, volver cosas imposibles en realidad es algo apasionante, y esta época lo hace más posible.
Detrás hay año y medio de desarrollo continuo, más de veinte versiones y cientos de compilaciones intermedias. El producto se prueba en un laboratorio propio con más de treinta máquinas, contra un corpus de miles de ficheros pensados para romper el scanner y con escaneos completos de máquinas reales. Y ya no se queda en el laboratorio: las pruebas de concepto y los ejercicios en los clientes donde se está utilizando están dando buenos resultados. Lo que sigue es lo que ha dejado ese recorrido.
Estar presente en esos sistemas no basta si se llega con una versión recortada. El reto era llegar con todo: los mismos motores, la misma interfaz y el mismo informe que en un portátil con Windows. Y construir para ellas exige otro oficio: arquitecturas distintas, compiladores y cadenas de herramientas propios de cada plataforma, bibliotecas que no siempre están empaquetadas para ellas y máquinas de pruebas que no se consiguen con un clic.
CardExpose Scanner se distribuye como binario nativo para quince combinaciones de sistema operativo y arquitectura. Las últimas en incorporarse son OpenVMS sobre x86-64 y z/OS sobre IBM Z.
Figura 1. Plataformas soportadas. Todas con CLI e interfaz gráfica; en IBM i, OpenVMS y z/OS la GUI se muestra mediante un servidor X (X11 forwarding).
Compatibilidad Linux: Cualquier distribución desde la generación de RHEL y Oracle Linux 7.
La palabra importante es «binario». Cada plataforma recibe un único ejecutable que se copia y se ejecuta, con todos sus motores dentro, incluidos los modelos de OCR y la base de firmas del clasificador de contenido. No hay instalador, ni runtime, ni dependencias que resolver. Y funciona en modo standalone en todas las plataformas, sin instalación de ningún tipo y sin necesidad de Agent ni de Console. Para un servidor de producción con política de cambios, esa es la diferencia entre poder auditarlo mañana y poder auditarlo el trimestre que viene.
El precio de esa decisión es que el listón técnico del proyecto lo fija lo que tienen en común todas ellas. Cada línea de código tiene que compilar y comportarse igual con quince combinaciones de sistema, arquitectura y compilador, y no solo en la última versión de cada sistema, sino en las que los clientes tienen en producción.
La primera lección incómoda llegó pronto: compilar en quince sitios no garantiza el mismo producto en quince sitios. Una biblioteca con la misma versión en todas las plataformas puede estar construida con capacidades distintas en una de ellas, y un inventario de versiones no lo ve. Desde entonces las capacidades de cada binario no se declaran: se comprueban sobre el propio binario, plataforma por plataforma, y el inventario de componentes (SBOM) de cada una se contrasta contra lo que realmente va dentro.
La interfaz gráfica viajó con el resto. El mismo binario funciona como línea de comandos en un servidor sin entorno gráfico y abre ventana en una estación que lo tiene, también en AIX y en Solaris SPARC, y en IBM i, OpenVMS y z/OS mediante un servidor X con X11 forwarding. En las arquitecturas big-endian, como IBM Z, SPARC o Power, hubo que resolver detalles que ninguna máquina x86 enseña. Es la clase de trabajo que separa «compila» de «se ve bien».
La última en llegar, OpenVMS sobre x86-64, es un hito por una razón distinta. No es un Unix ni un Linux: tiene su propio sistema de ficheros, su propio intérprete de comandos y sus propias convenciones, y su versión para x86-64 es todavía joven. Aun así, lo que corre allí sale de la misma revisión de código que el resto de plataformas. Fue, además, el primer destino de nuestra hoja de ruta en dejar de ser plan para ser realidad.
z/OS, sobre IBM Z, es el otro hito, y el que más pesa para el sector financiero. Es el sistema operativo de referencia de la banca, el que sostiene buena parte del núcleo bancario y de los procesadores de pagos. Hasta ahora llegábamos a IBM Z a través de Linux; ahora el scanner corre en el propio z/OS, con su sistema de ficheros, sus conjuntos de datos y su EBCDIC nativo, y sale de la misma revisión de código que el resto de plataformas.
La primera decisión que lo hace posible es no fiarse de la extensión. Cada objeto se clasifica por su contenido en el momento de abrirse, con una base de firmas que va dentro del binario, y esa clasificación decide qué motor lo analiza. Un .bak que en realidad es un ZIP se abre como ZIP. Un fichero sin extensión que es un mensaje de correo se analiza como correo. Un .dat que es una base SQLite se lee tabla a tabla.
El motor de expresiones regulares que sostiene esa clasificación es de tiempo lineal garantizado y es el mismo en las quince plataformas. El mismo fichero se clasifica igual en AIX que en Windows, y ningún contenido, por patológico que sea, puede degradar la clasificación a tiempo exponencial: los ataques ReDoS quedan fuera por diseño.
La segunda decisión es que la clasificación se aplica en cada nivel, no solo en el primero. Sigamos un objeto. Un correo dentro de un PST contiene un ZIP; el ZIP contiene un docx; el docx lleva incrustada una captura de pantalla con una tarjeta. El scanner extrae el mensaje, clasifica el adjunto, abre el ZIP, reconoce el docx como documento ofimático y no como ZIP crudo, extrae su texto, encuentra la imagen y la pasa por OCR.
Figura 2. Un objeto, cinco motores. Cada nivel se clasifica por contenido y va a su motor; la ruta del hallazgo conserva la cadena completa.
Cada miembro va a su motor, hasta una profundidad configurable, y el hallazgo final sabe de dónde viene: facturas.pst::Inbox/msg1!/adjunto.zip!/contrato.docx. La protección contra las bombas de descompresión es independiente del tamaño en disco: un ZIP pequeño que se expande a decenas de gigas se detiene por lo que descomprime, no por lo que ocupa.
Con esa base, ampliar la superficie fue cuestión de añadir motores, y cada uno tiene su matiz. El PDF se procesa en tres ejes para no pagar el OCR donde no hace falta: texto nativo siempre, OCR de las imágenes incrustadas, y rasterizado de la página completa solo cuando no contiene texto sustancial. Las bases de datos locales (SQLite, dBASE y FoxPro, Access desde la versión 97 hasta la actual, incluidos los MDB protegidos, y volcados de MongoDB) se leen celda a celda, y una celda binaria que contiene un PDF se analiza como PDF.
Las bases remotas (SQL Server, MySQL, PostgreSQL, Oracle, DB2, Firebird, MongoDB y Redis) se abren en modo de solo lectura. El escaneo se niega a empezar si el usuario tiene permisos de escritura, salvo autorización expresa, y en SQL Server se evita bloquear las tablas de producción que se están auditando.
Páginas de código EBCDIC: CP037 · CP273 · CP277 · CP278 · CP280 · CP284 · CP285 · CP297 · CP500 · CP870 · CP1047
Las imágenes pasan por OCR, por decodificación de códigos de barras y QR, y por un lector de metadatos que busca en EXIF, XMP y comentarios sin decodificar un solo píxel. El audio pasa por un detector de tonos DTMF, porque ahí es donde acaba un PAN tecleado en un IVR. Los ejecutables se analizan por sus regiones de datos, sin interpretar el código máquina como texto. Y las codificaciones incluyen once páginas de código EBCDIC y los decimales empaquetados COMP-3, que es como COBOL guarda un número de tarjeta en un registro.
Luego está lo que ya no es un fichero. Las imágenes de disco y los discos virtuales (EnCase E01, VMDK, VHD, VHDX, VDI, imágenes crudas y contenedores OVA, OVF y vbox) se abren sin privilegios y se recorren por dentro, reconociendo los sistemas de ficheros habituales: NTFS, FAT y exFAT, ext2/3/4, UFS, HFS+. Cada fichero encontrado conserva su procedencia, del estilo de imagen.e01::part0/Documents/fichero.txt.
En el sistema vivo, con elevación, el scanner recupera ficheros borrados leyendo la tabla de metadatos del sistema de ficheros, talla ficheros incrustados en datos crudos, analiza la papelera de Windows, macOS y Linux recuperando nombre original y fecha de borrado e inspecciona los Alternate Data Streams de NTFS. Las shadow copies se enumeran y escanean en Windows, en macOS, en ZFS, en btrfs, en LVM y en AIX, con un modo amistoso con los EDR activo por defecto. Un escáner que dispara el EDR del cliente no es un escáner útil.
En IBM i el concepto de «objeto» significa otra cosa, y el scanner lo respeta. Además del sistema de ficheros integrado, lee los miembros de ficheros físicos, los SAVF (incluidos SAVF dentro de SAVF), las áreas de datos, las colas de mensajes, el spool de las colas de salida, los receptores de diario y los espacios de usuario. Y, opcionalmente, los metadatos del objeto: texto de descripción, texto de miembro, cabeceras de columna y datos de usuario del spool.
OpenVMS x86-64 juega también con reglas propias, y el scanner las respeta igual que las de IBM i: no es un Unix con otro nombre. Llegar allí con los mismos motores que en el resto de plataformas, y no con una versión recortada, fue parte del reto.
z/OS tiene igualmente sus propias reglas, y el scanner también las respeta. Tampoco es un Unix con otro nombre: junto a su sistema de ficheros Unix conviven los conjuntos de datos nativos, y la codificación EBCDIC y los decimales empaquetados COMP-3 de los que hablábamos antes son aquí el pan de cada día.
Un escaneo de este tipo lee, por definición, contenido que nadie ha validado: ficheros corruptos, truncados o directamente hostiles. Y algunas de las bibliotecas que interpretan formatos complejos, ante una entrada así, no devuelven un error, sino que terminan el proceso.
Para eso el scanner se apoya en varias capas de protección que trabajan juntas y están siempre activas, sin configuración. Un fichero hostil no tumba el escaneo: se aparta, queda documentado y el recorrido sigue. Una interrupción no pierde el trabajo hecho: el escaneo continúa donde estaba. Un fichero enorme que avanza despacio no se confunde con uno bloqueado. Y el consumo de recursos se ajusta a la máquina donde corre, para que auditar un servidor de producción no lo ponga en riesgo.
El recorrido del sistema de ficheros sigue el mismo principio. Un directorio sin permisos, un enlace que da vueltas o un montaje de red que no responde se declaran, y no detienen ni falsean el resto. Esto importa más de lo que parece: un recorrido que se detiene ante el primer directorio sin permisos puede terminar con éxito habiendo mirado una fracción del disco. Un escáner que devuelve «todo bien» habiendo mirado una fracción es peor que ninguno.
Motivos de no análisis: cuarentena · cifrado · corrupto · permisos · tamaño · no soportado
De ahí la regla contable que cierra cada escaneo. Lo que se declaró al empezar se reconcilia con lo que se analizó, lo que no se pudo analizar y lo que se filtró, y la suma tiene que casar. Si no casa, queda registrada una laguna de cobertura. El informe clasifica cada omisión por su motivo, incluidos los volúmenes BitLocker o LUKS y los ZIP con contraseña, que se detectan y se declaran. No hay omisiones silenciosas.
Hay una parte de esta historia que no es nuestra. Los motores que leen PDF, imágenes, audio, documentos ofimáticos, archivos comprimidos, correo, bases de datos y sistemas de ficheros forenses se apoyan en decenas de bibliotecas de código abierto, mantenidas durante años por comunidades que muchas veces son de muy pocas personas.
Tener su código fuente fue lo que hizo posible el primer imposible. Donde no existe un paquete para AIX, para SPARC o para IBM i, se compila desde el fuente, con la misma revisión y las mismas capacidades que en el resto de plataformas. Sin ese código, este producto no habría llegado entero a esas plataformas.
Bibliotecas de código abierto dentro del producto: 70+; Vulnerabilidades identificadas en su código: 50+.
Y fue también lo que nos permitió devolver algo. Un escáner de PAN abre, por definición, contenido que nadie ha validado, así que auditamos el código de las bibliotecas que integramos con el mismo rigor que el nuestro. En ese proceso identificamos más de 50 vulnerabilidades en una veintena de proyectos. Las hemos documentado y las estamos trasladando a sus mantenedores mediante divulgación coordinada, para que la corrección llegue a todos los que usan ese código, no solo a nosotros.
No las detallamos aquí. Cada una se hará pública cuando su proyecto haya tenido ocasión de corregirla.
Marcas integradas: Visa · Mastercard · Amex · Discover · JCB · Diners · Maestro · UnionPay · y reglas propias
La búsqueda tolera los separadores y las codificaciones con que un número de tarjeta aparece en la práctica, y descarta los fragmentos de números más largos. Lo que sobrevive pasa el algoritmo de Luhn y las reglas de cada marca.
Sobre cada hallazgo se calcula una severidad que tiene en cuenta la marca, el contexto que lo rodea (una caducidad, un CVV o un titular cerca), el tipo de fichero y el lugar donde está. Un número dentro de una tabla de datos o de un binario baja de prioridad, pero se entrega. Todo eso clasifica; nada de eso descarta.
Figura 3. Estructura de las pistas ISO/IEC 7813 que el scanner exige completas. Ejemplo con la tarjeta de prueba 4111 1111 1111 1111, enmascarada como la muestra el informe.
Las tarjetas de prueba documentadas por las marcas se segregan, no se descartan. Un 4242 4242 4242 4242 se detecta, se marca, se cuenta aparte y se etiqueta como prueba. Ocultarlas del listado es una opción de presentación; el total del escaneo no cambia. El mismo contrato se aplica al triaje del analista: los hallazgos marcados como falso positivo en la GUI se conservan, y el informe íntegro y el triado del mismo escaneo siguen siendo comparables. El PAN sale enmascarado por defecto, también dentro del contexto que lo rodea.
Así construimos nuestro corpus de pruebas: miles de ficheros repartidos por familias, desde texto en todas sus codificaciones hasta ofimática, PDF, correo, bases de datos, imágenes, escritura a mano, audio, binarios, contenedores anidados, imágenes de disco y objetos de IBM i. La mayoría salen de un generador reproducible que planta los números y deja constancia de cada uno. Esa constancia es la verdad de campo, y nunca se deriva de lo que el propio scanner encuentra. Medirse contra la propia salida es medirse contra uno mismo.
Cada tipo de fichero tiene al menos tres variantes: una con tarjetas, que mide la detección; otra sin ellas, que mide los falsos positivos; y otra dañada, que mide si el scanner sobrevive. A eso se suman los casos extremos que un escáner rara vez ve en una demo: contenedores anidados a gran profundidad, anidamientos imposibles que el scanner tiene que cortar sin perder el control, números que parecen tarjetas y no lo son, y ficheros reales de entornos de producción.
Con ese corpus pusimos a CardExpose frente a otro escáner comercial muy extendido en el mercado, sobre los mismos ficheros y la misma verdad de campo.
Figura 4. Ficheros con tarjetas plantadas que detectó cada escáner, sobre la misma verdad de campo. Otro escáner comercial: 51 %; CardExpose Scanner: 89 %.
El otro escáner encontraba la mitad. CardExpose, casi nueve de cada diez. Y por cada fichero que solo veía la otra herramienta, CardExpose encontraba más de veinte que ella no veía.
Ese fue el momento en que supimos que habíamos conseguido algo muy potente. No tanto por la diferencia como por dónde estaba: CardExpose ganaba en todas las familias de ficheros salvo la escritura a mano, donde ninguno de los dos llega, y en audio la otra herramienta no encontraba nada.
Y el corpus no se usó una sola vez. Crece con cada formato nuevo, se pasa en cada plataforma, y las versiones se cierran además con escaneos completos de máquinas reales. Un resultado solo vale si es el mismo en todas las plataformas y si se mantiene de una versión a la siguiente.
Del journal salen los informes en HTML, JSON, PDF y CSV, regenerables en cualquier momento sin volver a escanear, y los eventos hacia Splunk, syslog o CEF, por donde solo viaja el PAN enmascarado.
Todo, línea de comandos, interfaz e informes, habla seis idiomas: español, inglés, alemán, francés, italiano y portugués.
El Agent es un servicio residente que lanza el scanner, recoge su progreso y sus hallazgos a medida que aparecen y los entrega a la Console por un canal cifrado y autenticado. Guarda lo pendiente si pierde la conexión, se actualiza solo y puede descubrir la red desde su posición.
La Console es la gestión central. Despliega y actualiza de forma automatizada los agentes y el scanner en los equipos, también en entornos sin conexión. Descubre los activos que hay que auditar, incluidos los que viven en la nube. Planifica los escaneos con políticas por grupos de activos, recoge los resultados de cada equipo y los consolida en un repositorio central de hallazgos, siempre con el PAN enmascarado. Todo ello para varias organizaciones en una misma instalación, con roles y ámbitos por activo, y con un registro de auditoría que no admite modificaciones ni borrados.
El License Server cierra el círculo. La licencia se valida en local, sin conexión y sin modo demo, y está ligada tanto a la máquina para la que se emitió como al binario entregado a cada cliente.
[Hoja de ruta] Más sistemas: HPE NonStop y Stratus VOS
Llevar el mismo código a AIX, a Solaris sobre SPARC, a IBM i, a IBM Z, a OpenVMS y ahora a z/OS sin renunciar a ninguna función nos enseñó algo más valioso que la propia lista de plataformas: el código es portable de verdad. Ha compilado y se ha comportado igual en arquitecturas big-endian, con compiladores distintos y en entornos con reglas propias, como el de IBM i, el de OpenVMS o el de z/OS.
Esa es la ruta que seguimos, y OpenVMS y z/OS ya la han confirmado. Los siguientes destinos son HPE NonStop y Stratus VOS, plataformas en las que se ejecutan sistemas de pago de primer nivel, y en las que encontrar dónde están los datos de tarjeta importa tanto como en cualquier otra. El objetivo es el mismo que hasta ahora: el producto completo, no una versión recortada.
Y un agradecimiento especial a los fabricantes que han colaborado con nosotros en el port a sus respectivas plataformas. Llegar con el producto entero a sistemas con reglas propias no se hace sin su ayuda.
[En diseño · 2027] Remediación
Con una decisión ya tomada: se ejecutará únicamente desde entornos gráficos, con copia de recuperación y registro auditable de cada acción, y sin opción en la línea de comandos. Un escáner que borra datos en producción con un flag es un incidente esperando a ocurrir.
Estará disponible durante 2027, tanto en la interfaz gráfica del Scanner como a través de la Console, para que quien gestiona los hallazgos de toda una organización pueda remediarlos desde el mismo sitio donde los revisa.
[En pruebas · último trimestre de 2026] CEIA, la inteligencia artificial de CardExpose
Un escaneo completo de un servidor puede devolver más de un millón de hallazgos, y nadie revisa un millón de nada. En nuestras pruebas, CEIA convierte un escaneo de más de un millón de hallazgos en poco más de mil casos que merecen un análisis de verdad. Es la diferencia entre una revisión imposible y una que cabe en la agenda. Y para un cliente que escanea cada semana, ese ahorro se repite cada semana: el tiempo es dinero.
Todo ocurre dentro de la red del cliente: el modelo se ejecuta en sus propias máquinas y ni un solo dato sale de ella. CEIA amplía además lo que se puede encontrar: incorpora la lectura de texto manuscrito, justo donde hoy no llega ningún escáner de los que hemos medido, y la de números de tarjeta dictados de viva voz en grabaciones. Está ya en pruebas, donde clasifica mejor que las reglas deterministas que usamos hoy, y estará disponible en el último trimestre de 2026.
Quien dijo «imposible» no se equivocaba en lo difícil. Se equivocaba en el método. Nada de lo anterior salió de una idea brillante de arquitectura. Salió de medir cada capacidad en cada máquina, de medirnos contra una verdad de campo que no dependía de nosotros, de tratar cada omisión como una laguna que hay que declarar, de apoyarnos en el trabajo de la comunidad y devolverle lo que encontramos, y de negarnos a que «funciona en Windows» fuera sinónimo de «funciona».
El resultado es un binario que se copia a un AIX, a un Solaris SPARC, a un IBM i, a un OpenVMS o a un z/OS, y encuentra el mismo PAN, con la misma procedencia y el mismo informe, que en un portátil con Windows 11. Y la lista de sistemas todavía no ha terminado.
Si quieres probar CardExpose Suite, o simplemente escanear donde nadie ha escaneado antes:
https://www.isecauditors.com/pages/cardexposesuite
Eso es lo que ha sido increíblemente mejor.
Sin duda, volver cosas imposibles en realidad es algo apasionante, y esta época lo hace más posible.
El resultado no es que haya sido posible: es que ha sido increíblemente mejor.
Cuando alguien te dice que algo es imposible, conviene preguntarle qué parte exactamente. Aquí la respuesta tenía tres partes, y cada una era imposible por una razón distinta. Este artículo cuenta cómo se desmontó cada una y qué significa para quien tiene que encontrar los datos de tarjeta de una organización.Detrás hay año y medio de desarrollo continuo, más de veinte versiones y cientos de compilaciones intermedias. El producto se prueba en un laboratorio propio con más de treinta máquinas, contra un corpus de miles de ficheros pensados para romper el scanner y con escaneos completos de máquinas reales. Y ya no se queda en el laboratorio: las pruebas de concepto y los ejercicios en los clientes donde se está utilizando están dando buenos resultados. Lo que sigue es lo que ha dejado ese recorrido.
Imposible 1 de 3: Todos los sistemas
Los datos de tarjeta se acumulan allí donde se procesan los pagos, y muchas organizaciones los procesan en plataformas que no son Windows ni Linux sobre x86: AIX sobre Power, Solaris sobre SPARC, IBM i, OpenVMS, z/OS, Linux sobre IBM Z. Son plataformas vivas, con versiones recientes y en plena producción, y sostienen algunos de los sistemas más críticos de un banco o de un procesador de pagos.Estar presente en esos sistemas no basta si se llega con una versión recortada. El reto era llegar con todo: los mismos motores, la misma interfaz y el mismo informe que en un portátil con Windows. Y construir para ellas exige otro oficio: arquitecturas distintas, compiladores y cadenas de herramientas propios de cada plataforma, bibliotecas que no siempre están empaquetadas para ellas y máquinas de pruebas que no se consiguen con un clic.
CardExpose Scanner se distribuye como binario nativo para quince combinaciones de sistema operativo y arquitectura. Las últimas en incorporarse son OpenVMS sobre x86-64 y z/OS sobre IBM Z.
Figura 1. Plataformas soportadas. Todas con CLI e interfaz gráfica; en IBM i, OpenVMS y z/OS la GUI se muestra mediante un servidor X (X11 forwarding).
Compatibilidad Linux: Cualquier distribución desde la generación de RHEL y Oracle Linux 7.
La palabra importante es «binario». Cada plataforma recibe un único ejecutable que se copia y se ejecuta, con todos sus motores dentro, incluidos los modelos de OCR y la base de firmas del clasificador de contenido. No hay instalador, ni runtime, ni dependencias que resolver. Y funciona en modo standalone en todas las plataformas, sin instalación de ningún tipo y sin necesidad de Agent ni de Console. Para un servidor de producción con política de cambios, esa es la diferencia entre poder auditarlo mañana y poder auditarlo el trimestre que viene.
El precio de esa decisión es que el listón técnico del proyecto lo fija lo que tienen en común todas ellas. Cada línea de código tiene que compilar y comportarse igual con quince combinaciones de sistema, arquitectura y compilador, y no solo en la última versión de cada sistema, sino en las que los clientes tienen en producción.
La primera lección incómoda llegó pronto: compilar en quince sitios no garantiza el mismo producto en quince sitios. Una biblioteca con la misma versión en todas las plataformas puede estar construida con capacidades distintas en una de ellas, y un inventario de versiones no lo ve. Desde entonces las capacidades de cada binario no se declaran: se comprueban sobre el propio binario, plataforma por plataforma, y el inventario de componentes (SBOM) de cada una se contrasta contra lo que realmente va dentro.
La interfaz gráfica viajó con el resto. El mismo binario funciona como línea de comandos en un servidor sin entorno gráfico y abre ventana en una estación que lo tiene, también en AIX y en Solaris SPARC, y en IBM i, OpenVMS y z/OS mediante un servidor X con X11 forwarding. En las arquitecturas big-endian, como IBM Z, SPARC o Power, hubo que resolver detalles que ninguna máquina x86 enseña. Es la clase de trabajo que separa «compila» de «se ve bien».
La última en llegar, OpenVMS sobre x86-64, es un hito por una razón distinta. No es un Unix ni un Linux: tiene su propio sistema de ficheros, su propio intérprete de comandos y sus propias convenciones, y su versión para x86-64 es todavía joven. Aun así, lo que corre allí sale de la misma revisión de código que el resto de plataformas. Fue, además, el primer destino de nuestra hoja de ruta en dejar de ser plan para ser realidad.
z/OS, sobre IBM Z, es el otro hito, y el que más pesa para el sector financiero. Es el sistema operativo de referencia de la banca, el que sostiene buena parte del núcleo bancario y de los procesadores de pagos. Hasta ahora llegábamos a IBM Z a través de Linux; ahora el scanner corre en el propio z/OS, con su sistema de ficheros, sus conjuntos de datos y su EBCDIC nativo, y sale de la misma revisión de código que el resto de plataformas.
Imposible 2 de 3: Cualquier objeto
Un PAN no es una cadena en un fichero de texto. Es una celda BLOB en una base de datos, un adjunto dentro de un PST, un PDF escaneado que solo contiene imágenes, la grabación de un IVR donde el cliente tecleó su tarjeta, un fichero borrado del que solo queda el inodo, una shadow copy de hace tres meses, un miembro de fichero físico en EBCDIC o un disco virtual olvidado en un backup. Si el escáner no llega ahí, la auditoría certifica lo que no ha mirado.La primera decisión que lo hace posible es no fiarse de la extensión. Cada objeto se clasifica por su contenido en el momento de abrirse, con una base de firmas que va dentro del binario, y esa clasificación decide qué motor lo analiza. Un .bak que en realidad es un ZIP se abre como ZIP. Un fichero sin extensión que es un mensaje de correo se analiza como correo. Un .dat que es una base SQLite se lee tabla a tabla.
El motor de expresiones regulares que sostiene esa clasificación es de tiempo lineal garantizado y es el mismo en las quince plataformas. El mismo fichero se clasifica igual en AIX que en Windows, y ningún contenido, por patológico que sea, puede degradar la clasificación a tiempo exponencial: los ataques ReDoS quedan fuera por diseño.
La segunda decisión es que la clasificación se aplica en cada nivel, no solo en el primero. Sigamos un objeto. Un correo dentro de un PST contiene un ZIP; el ZIP contiene un docx; el docx lleva incrustada una captura de pantalla con una tarjeta. El scanner extrae el mensaje, clasifica el adjunto, abre el ZIP, reconoce el docx como documento ofimático y no como ZIP crudo, extrae su texto, encuentra la imagen y la pasa por OCR.
Figura 2. Un objeto, cinco motores. Cada nivel se clasifica por contenido y va a su motor; la ruta del hallazgo conserva la cadena completa.
Cada miembro va a su motor, hasta una profundidad configurable, y el hallazgo final sabe de dónde viene: facturas.pst::Inbox/msg1!/adjunto.zip!/contrato.docx. La protección contra las bombas de descompresión es independiente del tamaño en disco: un ZIP pequeño que se expande a decenas de gigas se detiene por lo que descomprime, no por lo que ocupa.
Con esa base, ampliar la superficie fue cuestión de añadir motores, y cada uno tiene su matiz. El PDF se procesa en tres ejes para no pagar el OCR donde no hace falta: texto nativo siempre, OCR de las imágenes incrustadas, y rasterizado de la página completa solo cuando no contiene texto sustancial. Las bases de datos locales (SQLite, dBASE y FoxPro, Access desde la versión 97 hasta la actual, incluidos los MDB protegidos, y volcados de MongoDB) se leen celda a celda, y una celda binaria que contiene un PDF se analiza como PDF.
Las bases remotas (SQL Server, MySQL, PostgreSQL, Oracle, DB2, Firebird, MongoDB y Redis) se abren en modo de solo lectura. El escaneo se niega a empezar si el usuario tiene permisos de escritura, salvo autorización expresa, y en SQL Server se evita bloquear las tablas de producción que se están auditando.
Páginas de código EBCDIC: CP037 · CP273 · CP277 · CP278 · CP280 · CP284 · CP285 · CP297 · CP500 · CP870 · CP1047
Las imágenes pasan por OCR, por decodificación de códigos de barras y QR, y por un lector de metadatos que busca en EXIF, XMP y comentarios sin decodificar un solo píxel. El audio pasa por un detector de tonos DTMF, porque ahí es donde acaba un PAN tecleado en un IVR. Los ejecutables se analizan por sus regiones de datos, sin interpretar el código máquina como texto. Y las codificaciones incluyen once páginas de código EBCDIC y los decimales empaquetados COMP-3, que es como COBOL guarda un número de tarjeta en un registro.
Luego está lo que ya no es un fichero. Las imágenes de disco y los discos virtuales (EnCase E01, VMDK, VHD, VHDX, VDI, imágenes crudas y contenedores OVA, OVF y vbox) se abren sin privilegios y se recorren por dentro, reconociendo los sistemas de ficheros habituales: NTFS, FAT y exFAT, ext2/3/4, UFS, HFS+. Cada fichero encontrado conserva su procedencia, del estilo de imagen.e01::part0/Documents/fichero.txt.
En el sistema vivo, con elevación, el scanner recupera ficheros borrados leyendo la tabla de metadatos del sistema de ficheros, talla ficheros incrustados en datos crudos, analiza la papelera de Windows, macOS y Linux recuperando nombre original y fecha de borrado e inspecciona los Alternate Data Streams de NTFS. Las shadow copies se enumeran y escanean en Windows, en macOS, en ZFS, en btrfs, en LVM y en AIX, con un modo amistoso con los EDR activo por defecto. Un escáner que dispara el EDR del cliente no es un escáner útil.
En IBM i el concepto de «objeto» significa otra cosa, y el scanner lo respeta. Además del sistema de ficheros integrado, lee los miembros de ficheros físicos, los SAVF (incluidos SAVF dentro de SAVF), las áreas de datos, las colas de mensajes, el spool de las colas de salida, los receptores de diario y los espacios de usuario. Y, opcionalmente, los metadatos del objeto: texto de descripción, texto de miembro, cabeceras de columna y datos de usuario del spool.
OpenVMS x86-64 juega también con reglas propias, y el scanner las respeta igual que las de IBM i: no es un Unix con otro nombre. Llegar allí con los mismos motores que en el resto de plataformas, y no con una versión recortada, fue parte del reto.
z/OS tiene igualmente sus propias reglas, y el scanner también las respeta. Tampoco es un Unix con otro nombre: junto a su sistema de ficheros Unix conviven los conjuntos de datos nativos, y la codificación EBCDIC y los decimales empaquetados COMP-3 de los que hablábamos antes son aquí el pan de cada día.
Imposible 3 de 3: El 100 % de todo, en todos, y fiable
Tener las mismas funciones en quince plataformas es una condición necesaria. La suficiente es que un escaneo sobre terabytes de contenido no confiable termine y diga la verdad sobre lo que ha cubierto. Este resultó ser el imposible de verdad, y el que más enseñó.Un escaneo de este tipo lee, por definición, contenido que nadie ha validado: ficheros corruptos, truncados o directamente hostiles. Y algunas de las bibliotecas que interpretan formatos complejos, ante una entrada así, no devuelven un error, sino que terminan el proceso.
Para eso el scanner se apoya en varias capas de protección que trabajan juntas y están siempre activas, sin configuración. Un fichero hostil no tumba el escaneo: se aparta, queda documentado y el recorrido sigue. Una interrupción no pierde el trabajo hecho: el escaneo continúa donde estaba. Un fichero enorme que avanza despacio no se confunde con uno bloqueado. Y el consumo de recursos se ajusta a la máquina donde corre, para que auditar un servidor de producción no lo ponga en riesgo.
El recorrido del sistema de ficheros sigue el mismo principio. Un directorio sin permisos, un enlace que da vueltas o un montaje de red que no responde se declaran, y no detienen ni falsean el resto. Esto importa más de lo que parece: un recorrido que se detiene ante el primer directorio sin permisos puede terminar con éxito habiendo mirado una fracción del disco. Un escáner que devuelve «todo bien» habiendo mirado una fracción es peor que ninguno.
Motivos de no análisis: cuarentena · cifrado · corrupto · permisos · tamaño · no soportado
De ahí la regla contable que cierra cada escaneo. Lo que se declaró al empezar se reconcilia con lo que se analizó, lo que no se pudo analizar y lo que se filtró, y la suma tiene que casar. Si no casa, queda registrada una laguna de cobertura. El informe clasifica cada omisión por su motivo, incluidos los volúmenes BitLocker o LUKS y los ZIP con contraseña, que se detectan y se declaran. No hay omisiones silenciosas.
Lo que debemos al código abierto
Hay una parte de esta historia que no es nuestra. Los motores que leen PDF, imágenes, audio, documentos ofimáticos, archivos comprimidos, correo, bases de datos y sistemas de ficheros forenses se apoyan en decenas de bibliotecas de código abierto, mantenidas durante años por comunidades que muchas veces son de muy pocas personas.
Tener su código fuente fue lo que hizo posible el primer imposible. Donde no existe un paquete para AIX, para SPARC o para IBM i, se compila desde el fuente, con la misma revisión y las mismas capacidades que en el resto de plataformas. Sin ese código, este producto no habría llegado entero a esas plataformas.
Bibliotecas de código abierto dentro del producto: 70+; Vulnerabilidades identificadas en su código: 50+.
Y fue también lo que nos permitió devolver algo. Un escáner de PAN abre, por definición, contenido que nadie ha validado, así que auditamos el código de las bibliotecas que integramos con el mismo rigor que el nuestro. En ese proceso identificamos más de 50 vulnerabilidades en una veintena de proyectos. Las hemos documentado y las estamos trasladando a sus mantenedores mediante divulgación coordinada, para que la corrección llegue a todos los que usan ese código, no solo a nosotros.
No las detallamos aquí. Cada una se hará pública cuando su proyecto haya tenido ocasión de corregirla.
Qué es un hallazgo, y qué no
Con toda esa superficie, el riesgo obvio es ahogar al analista. La respuesta no fue filtrar más, sino clasificar mejor y no descartar nunca.Marcas integradas: Visa · Mastercard · Amex · Discover · JCB · Diners · Maestro · UnionPay · y reglas propias
La búsqueda tolera los separadores y las codificaciones con que un número de tarjeta aparece en la práctica, y descarta los fragmentos de números más largos. Lo que sobrevive pasa el algoritmo de Luhn y las reglas de cada marca.
Sobre cada hallazgo se calcula una severidad que tiene en cuenta la marca, el contexto que lo rodea (una caducidad, un CVV o un titular cerca), el tipo de fichero y el lugar donde está. Un número dentro de una tabla de datos o de un binario baja de prioridad, pero se entrega. Todo eso clasifica; nada de eso descarta.
Un falso positivo cuesta un clic en la revisión. Un falso negativo es una tarjeta que nadie volverá a ver.Las bandas magnéticas se detectan por estructura y no por patrón. Track 1 y Track 2, según ISO/IEC 7813, exigen la pista completa: el PAN ya validado pegado a su centinela y la caducidad en su posición. Para PCI DSS los datos de pista son Sensitive Authentication Data, que no pueden almacenarse tras la autorización en ningún caso, y por eso reciben la severidad máxima y su propio indicador en el informe.
Figura 3. Estructura de las pistas ISO/IEC 7813 que el scanner exige completas. Ejemplo con la tarjeta de prueba 4111 1111 1111 1111, enmascarada como la muestra el informe.
Las tarjetas de prueba documentadas por las marcas se segregan, no se descartan. Un 4242 4242 4242 4242 se detecta, se marca, se cuenta aparte y se etiqueta como prueba. Ocultarlas del listado es una opción de presentación; el total del escaneo no cambia. El mismo contrato se aplica al triaje del analista: los hallazgos marcados como falso positivo en la GUI se conservan, y el informe íntegro y el triado del mismo escaneo siguen siendo comparables. El PAN sale enmascarado por defecto, también dentro del contexto que lo rodea.
Cómo supimos que era mejor
Un escáner de PAN no se puede evaluar con los datos de un cliente, porque nadie sabe cuántas tarjetas hay en ellos. Para medirlo hace falta lo contrario: un conjunto de ficheros donde cada tarjeta se ha puesto a propósito y se sabe exactamente dónde está.Así construimos nuestro corpus de pruebas: miles de ficheros repartidos por familias, desde texto en todas sus codificaciones hasta ofimática, PDF, correo, bases de datos, imágenes, escritura a mano, audio, binarios, contenedores anidados, imágenes de disco y objetos de IBM i. La mayoría salen de un generador reproducible que planta los números y deja constancia de cada uno. Esa constancia es la verdad de campo, y nunca se deriva de lo que el propio scanner encuentra. Medirse contra la propia salida es medirse contra uno mismo.
Cada tipo de fichero tiene al menos tres variantes: una con tarjetas, que mide la detección; otra sin ellas, que mide los falsos positivos; y otra dañada, que mide si el scanner sobrevive. A eso se suman los casos extremos que un escáner rara vez ve en una demo: contenedores anidados a gran profundidad, anidamientos imposibles que el scanner tiene que cortar sin perder el control, números que parecen tarjetas y no lo son, y ficheros reales de entornos de producción.
Con ese corpus pusimos a CardExpose frente a otro escáner comercial muy extendido en el mercado, sobre los mismos ficheros y la misma verdad de campo.
Figura 4. Ficheros con tarjetas plantadas que detectó cada escáner, sobre la misma verdad de campo. Otro escáner comercial: 51 %; CardExpose Scanner: 89 %.
El otro escáner encontraba la mitad. CardExpose, casi nueve de cada diez. Y por cada fichero que solo veía la otra herramienta, CardExpose encontraba más de veinte que ella no veía.
Ese fue el momento en que supimos que habíamos conseguido algo muy potente. No tanto por la diferencia como por dónde estaba: CardExpose ganaba en todas las familias de ficheros salvo la escritura a mano, donde ninguno de los dos llega, y en audio la otra herramienta no encontraba nada.
Y el corpus no se usó una sola vez. Crece con cada formato nuevo, se pasa en cada plataforma, y las versiones se cierran además con escaneos completos de máquinas reales. Un resultado solo vale si es el mismo en todas las plataformas y si se mantiene de una versión a la siguiente.
La evidencia
Todo lo anterior acaba en el journal del escaneo: un registro cifrado y ligado a la licencia y a la máquina donde se hizo el escaneo. Si el escaneo se interrumpe, se reanuda desde ahí sin repetir lo ya hecho.Del journal salen los informes en HTML, JSON, PDF y CSV, regenerables en cualquier momento sin volver a escanear, y los eventos hacia Splunk, syslog o CEF, por donde solo viaja el PAN enmascarado.
Todo, línea de comandos, interfaz e informes, habla seis idiomas: español, inglés, alemán, francés, italiano y portugués.
La Suite
El scanner es deliberadamente simple en su relación con el mundo: no es un servicio residente y no expone ninguna interfaz de red. Valida su licencia, escanea, escribe journal e informe y termina. Todo lo demás lo hacen tres componentes más, y el scanner funciona con o sin ellos: en modo standalone basta el binario y su licencia.El Agent es un servicio residente que lanza el scanner, recoge su progreso y sus hallazgos a medida que aparecen y los entrega a la Console por un canal cifrado y autenticado. Guarda lo pendiente si pierde la conexión, se actualiza solo y puede descubrir la red desde su posición.
La Console es la gestión central. Despliega y actualiza de forma automatizada los agentes y el scanner en los equipos, también en entornos sin conexión. Descubre los activos que hay que auditar, incluidos los que viven en la nube. Planifica los escaneos con políticas por grupos de activos, recoge los resultados de cada equipo y los consolida en un repositorio central de hallazgos, siempre con el PAN enmascarado. Todo ello para varias organizaciones en una misma instalación, con roles y ámbitos por activo, y con un registro de auditoría que no admite modificaciones ni borrados.
El License Server cierra el círculo. La licencia se valida en local, sin conexión y sin modo demo, y está ligada tanto a la máquina para la que se emitió como al binario entregado a cada cliente.
Lo que todavía crece
El planteamiento original hablaba de llegar a todos los sistemas imaginables y de una GUI que pudiera crecer hacia el etiquetado de hallazgos, la remediación y otras funciones. El triaje de hallazgos ya forma parte del scanner; esto es lo que viene.[Hoja de ruta] Más sistemas: HPE NonStop y Stratus VOS
Llevar el mismo código a AIX, a Solaris sobre SPARC, a IBM i, a IBM Z, a OpenVMS y ahora a z/OS sin renunciar a ninguna función nos enseñó algo más valioso que la propia lista de plataformas: el código es portable de verdad. Ha compilado y se ha comportado igual en arquitecturas big-endian, con compiladores distintos y en entornos con reglas propias, como el de IBM i, el de OpenVMS o el de z/OS.
Esa es la ruta que seguimos, y OpenVMS y z/OS ya la han confirmado. Los siguientes destinos son HPE NonStop y Stratus VOS, plataformas en las que se ejecutan sistemas de pago de primer nivel, y en las que encontrar dónde están los datos de tarjeta importa tanto como en cualquier otra. El objetivo es el mismo que hasta ahora: el producto completo, no una versión recortada.
Y un agradecimiento especial a los fabricantes que han colaborado con nosotros en el port a sus respectivas plataformas. Llegar con el producto entero a sistemas con reglas propias no se hace sin su ayuda.
[En diseño · 2027] Remediación
Con una decisión ya tomada: se ejecutará únicamente desde entornos gráficos, con copia de recuperación y registro auditable de cada acción, y sin opción en la línea de comandos. Un escáner que borra datos en producción con un flag es un incidente esperando a ocurrir.
Estará disponible durante 2027, tanto en la interfaz gráfica del Scanner como a través de la Console, para que quien gestiona los hallazgos de toda una organización pueda remediarlos desde el mismo sitio donde los revisa.
[En pruebas · último trimestre de 2026] CEIA, la inteligencia artificial de CardExpose
Un escaneo completo de un servidor puede devolver más de un millón de hallazgos, y nadie revisa un millón de nada. En nuestras pruebas, CEIA convierte un escaneo de más de un millón de hallazgos en poco más de mil casos que merecen un análisis de verdad. Es la diferencia entre una revisión imposible y una que cabe en la agenda. Y para un cliente que escanea cada semana, ese ahorro se repite cada semana: el tiempo es dinero.
Todo ocurre dentro de la red del cliente: el modelo se ejecuta en sus propias máquinas y ni un solo dato sale de ella. CEIA amplía además lo que se puede encontrar: incorpora la lectura de texto manuscrito, justo donde hoy no llega ningún escáner de los que hemos medido, y la de números de tarjeta dictados de viva voz en grabaciones. Está ya en pruebas, donde clasifica mejor que las reglas deterministas que usamos hoy, y estará disponible en el último trimestre de 2026.
Quien dijo «imposible» no se equivocaba en lo difícil. Se equivocaba en el método. Nada de lo anterior salió de una idea brillante de arquitectura. Salió de medir cada capacidad en cada máquina, de medirnos contra una verdad de campo que no dependía de nosotros, de tratar cada omisión como una laguna que hay que declarar, de apoyarnos en el trabajo de la comunidad y devolverle lo que encontramos, y de negarnos a que «funciona en Windows» fuera sinónimo de «funciona».
El resultado es un binario que se copia a un AIX, a un Solaris SPARC, a un IBM i, a un OpenVMS o a un z/OS, y encuentra el mismo PAN, con la misma procedencia y el mismo informe, que en un portátil con Windows 11. Y la lista de sistemas todavía no ha terminado.
Si quieres probar CardExpose Suite, o simplemente escanear donde nadie ha escaneado antes:
https://www.isecauditors.com/pages/cardexposesuite
Eso es lo que ha sido increíblemente mejor.
