SAFE. Guía para proteger tu vida digital y tu privacidad

16 jul 2026

Estudio de 85 extensiones de billeteras de criptomonedas detecta filtraciones

Investigadores de la KU Leuven probaron 85 de las billeteras de criptomonedas más populares que funcionan como extensiones de navegador y descubrieron que las propias billeteras presentan fugas de información suficientes para vincular y rastrear a sus usuarios.

La forma en que estas billeteras se comunican con sitios web y servidores blockchain puede conectar las distintas direcciones de una persona y permitir que terceros la sigan de un sitio a otro. Incluso en un sitio que ya contiene un nombre o correo electrónico, estas mismas fugas pueden asociar un nombre real a una identidad criptográfica "anónima".

Esto no es un hackeo. Las billeteras funcionan exactamente como fueron diseñadas. Las 85 extensiones suman alrededor de 35 millones de usuarios registrados en la Chrome Web Store.

El equipo, perteneciente al grupo de seguridad DistriNet de la universidad, publicó el artículo este mes y lo presentará en la conferencia de privacidad PETS 2026 en Calgary a finales de julio. Realizaron pruebas con billeteras reales en sitios Web3 reales e identificaron cinco vulnerabilidades de privacidad en la interacción entre billeteras y sitios web. Cuando informaron a los fabricantes de monederos sobre el problema de mayor alcance antes de su publicación, la mayoría se negó a considerarlo un error.

Problema 1: Tus direcciones de monedero se vinculan

Muchas personas mantienen varias direcciones de monedero a propósito para mantener separadas partes de su vida financiera. Esto solo funciona si nadie puede saber que las direcciones pertenecen a la misma persona. Pero para mostrar tu saldo, un monedero envía constantemente solicitudes a servidores externos, y esas solicitudes transmiten tu dirección, sin cifrar, a quien administra el servidor.

Cuando un monedero incluye dos de tus direcciones en una sola solicitud, el servidor sabe que son tuyas. Diecisiete monederos expusieron conexiones entre las direcciones de monedero de un usuario. Trece lo hicieron de la forma obvia, agrupando dos direcciones en una sola solicitud. Cuatro más se delataron al enviar solicitudes separadas con milisegundos de diferencia, una señal más débil pero aún útil.

En conjunto, estos monederos abarcan aproximadamente 23 millones de las instalaciones estudiadas. Quien administra el servidor, o cualquiera que obtenga sus datos posteriormente, puede unir las direcciones en un solo perfil.

Problema 2: Cerrar sesión a menudo no cierra la sesión por completo.

Este problema y el siguiente comparten un punto de partida: un sitio web puede saber qué billeteras tienes instaladas. Cada billetera se identifica en cada página que carga, por lo que un script puede leer el conjunto exacto que llevas, una huella digital que funciona incluso si nunca conectas una billetera y aunque bloquees las cookies.

Los investigadores descubrieron que 36 de las 85 billeteras hacen esto, y sus usuarios representan aproximadamente el 82% de las instalaciones estudiadas. Esas mismas 36 billeteras son las responsables de las cifras que se muestran a continuación.

Cuando conectas una billetera a un sitio y luego te desconectas, asumes que el sitio pierde el acceso. A menudo no es así, por dos razones distintas.

Primero, muchos sitios nunca le indican a la billetera que corte el acceso. De las 30 aplicaciones Web3 populares que el equipo probó, solo 11 enviaron una orden de revocación real cuando un usuario hizo clic en Desconectar o Cerrar sesión. El resto simplemente borró su pantalla.

Segundo, incluso cuando se envía la orden, muchas billeteras la ignoran. En 22 de esas 36 carteras, el sitio aún podía leer tu dirección después de solicitar a la cartera que la revocara, y ese acceso se mantuvo incluso después de borrar las cookies y reiniciar el navegador.

Esto convierte la dirección en una potente etiqueta de seguimiento. Es única a nivel global y, a diferencia de una cookie, no desaparece al borrar el navegador. El permiso obsoleto permanece en la extensión hasta que se abre la lista de "Sitios conectados" de la billetera y se elimina el sitio manualmente; hasta entonces, un script en la página sigue leyendo la dirección en segundo plano.

Problema 3: Una billetera a la que te conectaste puede exponerte en otros sitios.

Este último problema tiene mayor alcance. De esas 36 billeteras, 23 compartirán tu dirección desde dentro de un marco que una página ha cargado desde otro sitio. Por sí solo, esto no tiene ninguna consecuencia. El problema radica en lo que un rastreador compartido puede hacer con ella.

Supongamos que el mismo script de seguimiento se ejecuta en una aplicación de criptomonedas a la que te conectaste y en un sitio web común y corriente. En el sitio común, el rastreador carga silenciosamente la aplicación de criptomonedas dentro de un marco invisible.

La página de la aplicación ya estaba autorizada por la billetera, y estas billeteras responden desde dentro del marco, por lo que la billetera devuelve la dirección al script sin que el usuario haga clic. La aplicación debe permitir la integración para que esto funcione, aunque muchas lo permiten.

Vincula esa dirección a un nombre o correo electrónico que el sitio ya tenga registrado, y un perfil criptográfico seudónimo se convierte en una persona identificada. La dirección de una billetera es un registro público de sus saldos, transacciones y tenencias de tokens. Si la vinculas a una identidad real y a un historial de navegación, un atacante tiene un objetivo identificado cuyo dinero ahora está a la vista.

Los investigadores demostraron que este método es real y utilizable; no afirmaron que los rastreadores ya lo estén utilizando a gran escala.

Qué hacer y cómo respondió la industria

Para los usuarios, las soluciones son solo parciales. Abre tu billetera y elimina los permisos de sitios antiguos que ya no uses. Esto detiene el rastreo de direcciones obsoletas del Problema 2, pero no soluciona las filtraciones de direcciones a los servidores ni la huella digital de la billetera instalada.

La demostración de los investigadores muestra cómo funciona tu propia billetera; se ejecuta en tu navegador y, según afirman, no almacena nada. Usa una billetera desechable para mayor seguridad. También ayuda mantener las diferentes actividades en carteras o perfiles de navegador separados. Las soluciones más importantes están fuera del alcance de los usuarios.

Los investigadores centraron su informe en el problema de vulnerabilidad entre sitios y notificaron a los fabricantes de carteras afectadas antes de su publicación. Para una nueva prueba en febrero de 2026, Coinbase Wallet y Coin98 ya lo habían solucionado, y Hana Wallet lo hizo posteriormente. Sin embargo, de los ocho proveedores que, según el informe, respondieron a través de sus programas de recompensas por errores, la mayoría se negó a considerarlo un error.

MetaMask lo calificó como un problema conocido, cerró el informe como duplicado y afirmó que no tenía planes inmediatos de dejar de inyectar malware en su proveedor, ya que esto afectaría a demasiadas aplicaciones.

Rabby afirmó que el ataque requeriría que el mismo script malicioso se ejecutara en dos sitios simultáneamente, lo cual calificó de "prácticamente imposible", y concluyó que "la vulnerabilidad no existe". OKX coincidió en que el hallazgo era técnicamente correcto, pero lo cerró como informativo porque expone datos sin robar dinero.

Bybit, Backpack y Core lo consideraron de bajo riesgo o fuera de su alcance. Las respuestas completas se publican en el repositorio de los investigadores.

El estudio se basa en la investigación de 2023 de Christof Ferreira Torres y sus colegas, quienes fueron los primeros en demostrar que las carteras digitales filtraban direcciones a servidores externos. Este trabajo detecta filtraciones que las herramientas anteriores no detectaron, mapea el rastreo entre sitios y muestra cómo la misma filtración podría usarse para revelar la identidad de los usuarios.

Mientras que escáneres como WalletRadar y WalletProbe buscan errores evidentes, este artículo demuestra que una cartera digital no necesita un error para exponer a un usuario. Esto la diferencia de las extensiones de cartera falsas que robaron claves el año pasado. En esos casos, los delincuentes robaron. Aquí, no se roba nada, y la filtración está integrada en el diseño.

El artículo se publicó en arXiv el 7 de julio y se presentará en PETS 2026 en Calgary, del 20 al 25 de julio. Por ahora, las carteras funcionan según lo previsto, y varios de sus fabricantes han afirmado, en efecto, que el diseño es correcto.

La solución real no es otra advertencia a los usuarios. Se trata de carteras que dejan de exponerse dentro de marcos integrados, y de un estándar del ecosistema que define qué debe hacer realmente el cierre de sesión.

Fuente: THN

Priorización y gestión de vulnerabilidades: CVSS, EPSS, SSVC y KEV (2 de...)

Leer Priorización y gestión de vulnerabilidades: CVSS, EPSS, SSVC y KEV (1 de...)


SSVC - Categorización de vulnerabilidades específicas de las partes interesadas

El Instituto de Ingeniería de Software (SEI) de la Universidad Carnegie Mellon, en colaboración con CISA, creó el sistema de Categorización de Vulnerabilidades Específicas para las Partes Interesadas (SSVC - Stakeholder-Specific Vulnerability Categorization ) en 2019 para proporcionar a la comunidad cibernética una metodología de análisis de vulnerabilidades que considere el estado de explotación de una vulnerabilidad, su impacto en la seguridad y la prevalencia del producto afectado en un sistema específico.

CISA colaboró ​​con SEI en 2020 para desarrollar su propio árbol de decisiones SSVC personalizado para examinar las vulnerabilidades relevantes para el gobierno de los Estados Unidos (USG), así como para los gobiernos estatales, locales, tribales y territoriales (SLTT), y las entidades de infraestructura crítica. La implementación de SSVC ha permitido a CISA priorizar mejor su respuesta a las vulnerabilidades y la comunicación pública sobre ellas.

¿Qué es un SSVC?

El SSVC es un marco de toma de decisiones diseñado para ayudar a los equipos de seguridad a priorizar y responder a las vulnerabilidades de manera eficiente. A diferencia del CVSS, que se centra en la gravedad técnica, el SSVC se centra en la respuesta operativa necesaria, es decir, qué acción se debe tomar y con qué urgencia.

El SSVC utiliza un "árbol de decisiones" para guiar a los analistas a través de una serie de preguntas contextuales, como:

  • ¿Es explotable la vulnerabilidad?
  • ¿Existe una explotación conocida públicamente?
  • ¿Qué tipo de impacto podría causar?

Cómo CISA utiliza SSVC

CISA utiliza su propio modelo de árbol de decisiones SSVC para priorizar las vulnerabilidades relevantes en cuatro posibles decisiones:

  • Track (Seguimiento): La vulnerabilidad no requiere acción por el momento. La organización continuará monitoreando la vulnerabilidad y la reevaluará si se dispone de nueva información. CISA recomienda remediar las vulnerabilidades de seguimiento dentro de los plazos de actualización estándar.
  • Track* (Seguimiento*): La vulnerabilidad contiene características específicas que podrían requerir una monitorización más estrecha para detectar cambios. CISA recomienda remediar las vulnerabilidades Track* dentro de los plazos de actualización estándar.
  • Attend (Atención): La vulnerabilidad requiere la atención de los supervisores internos de la organización. Las acciones necesarias incluyen solicitar asistencia o información sobre la vulnerabilidad, y pueden implicar la publicación de una notificación interna o externa. CISA recomienda remediar las vulnerabilidades de Atención antes de los plazos de actualización estándar.
  • Act (Actuar): La vulnerabilidad requiere la atención de los miembros internos, supervisores y directivos de la organización. Las acciones necesarias incluyen solicitar asistencia o información sobre la vulnerabilidad, así como publicar una notificación interna o externa. Normalmente, los grupos internos se reúnen para determinar la respuesta general y luego ejecutan las acciones acordadas. CISA recomienda remediar las vulnerabilidades de Actuar lo antes posible.

El árbol CISA SSVC determina las decisiones de  Track ,  Track *,  Attend y  Act  en función de cinco valores: 

  • Estado de explotación
  • Impacto técnico
  • Automatizable
  • Prevalencia de la misión
  • Impacto en el bienestar público

Uso de SSVC

SVC es una metodología para priorizar la respuesta a la vulnerabilidad según las necesidades de las distintas partes interesadas. Sus conceptos centrales son:

  • Roles de las partes interesadas : Los distintos participantes en el proceso de respuesta a vulnerabilidades tienen distintas necesidades y prioridades. Los roles pueden incluir proveedores de parches, implementadores, coordinadores y otros.
  • Decisiones : Cada rol de parte interesada debe tomar decisiones sobre cómo responder a las vulnerabilidades. Para un proveedor, la decisión podría ser sobre cómo priorizar la creación de parches. Para un implementador, la decisión podría ser sobre cómo priorizar la implementación de parches. Los coordinadores generalmente deben decidir si coordinar una respuesta y si publicar información sobre una vulnerabilidad que han coordinado.
  • Puntos de decisión : Cada decisión se basa en un conjunto de datos o puntos de decisión. Estos son los factores que influyen en la decisión. Por ejemplo, la decisión de implementar un parche podría verse influenciada por la gravedad de la vulnerabilidad, la disponibilidad de un exploit y el impacto de la vulnerabilidad en el sistema.
  • Resultados : Cada decisión tiene un conjunto de posibles resultados. Estos son los posibles resultados de la decisión. Por ejemplo, una decisión sobre la implementación de un parche podría tener resultados como "inmediato", "programado", "diferido" y "fuera de ciclo".

Comenzar un proceso SSVC desde cero

Usar SSVC para priorizar la respuesta a vulnerabilidades requiere algunos pasos:

  • Preparar: definir la decisión que desea tomar, los resultados que le interesan, los puntos de decisión que utilizará para tomar la decisión, la tabla de decisiones, los datos que necesita para informar los puntos de decisión y el proceso para mantener su modelo de decisión.
  • Recolectar: recopilar los datos que necesita para tomar decisiones informadas.
  • Utilice SSVC: para tomar decisiones sobre cómo responder a las vulnerabilidades.
  • Responder: a las vulnerabilidades según la priorización.


Continuará...

15 jul 2026

Priorización y gestión de vulnerabilidades: CVSS, EPSS, SSVC y KEV (1 de...)

Introducción

Toda organización que gestiona software y hardware convive con un flujo constante de vulnerabilidades. Como los recursos de remediación son limitados y las amenazas cambian de forma dinámica, el problema central no es solo detectar debilidades, sino decidir cuáles atender primero. Para ello conviene separar las actividades: identificar una vulnerabilidad, evaluarla, categorizarla, gestionarla y solucionarla (si corresponde).

El identificador CVE (Common Vulnerabilities and Exposures) actúa como el «nombre» único de cada vulnerabilidad pública, mientras que sistemas como CVSS, EPSS y SSVC aportan los criterios para priorizarla.

CVSS (Common Vulnerability Scoring System), mantenido por FIRST, responde a la pregunta «¿qué tan grave es?». Asigna una puntuación de 0 a 10 a partir de las características intrínsecas de la vulnerabilidad —cómo se explota y qué impacto tiene sobre la confidencialidad, la integridad y la disponibilidad—. Es una medida de severidad técnica, no de riesgo.

EPSS (Exploit Prediction Scoring System), también gestionado por FIRST, responde a «¿qué tan probable es que se explote?». Es un modelo basado en datos que estima, entre 0 y 1 (0% a 100%), la probabilidad de que una vulnerabilidad sea explotada en los próximos 30 días, incorporando inteligencia de amenazas y evidencia de explotación real. Tampoco debe interpretarse como una puntuación de riesgo.

SSVC (Stakeholder-Specific Vulnerability Categorization), creado por el SEI de la Universidad Carnegie Mellon —CISA desarrolló después su propio árbol de decisión—, responde a «¿qué debo hacer y con qué urgencia?». En lugar de un número, emplea árboles de decisión que combinan el contexto —estado de explotación, impacto técnico, criticidad de la misión— para recomendar una acción operativa concreta.

Los tres sistemas son complementarios, no intercambiables: miden dimensiones distintas (severidad, probabilidad y decisión operativa). Combinarlos permite pasar de una priorización reactiva, basada solo en la gravedad, a un enfoque basado en el riesgo real del entorno. Este documento describe cada sistema en detalle y, al final, propone una forma práctica de usarlos en conjunto.

A estos tres se suma el catálogo KEV (Known ExploitedVulnerabilities) de CISA, que no puntúa ni decide, sino que enumera las vulnerabilidades para las que existe evidencia confirmada de explotación activa en el mundo real. Actúa como una señal binaria de máxima prioridad: si un CVE figura en el KEV, su explotación deja de ser una probabilidad y pasa a ser un hecho, por lo que debe remediarse de forma inmediata con independencia de su puntuación CVSS o EPSS.

CVSS - Sistema común de puntuación de vulnerabilidades

En la seguridad de la información, una vulnerabilidad se define como una debilidad que se encuentra en un activo o en un control y que puede ser explotada por una o más amenazas, lo que deriva en un riesgo de seguridad.

En este sentido, la seguridad se enfoca en reducir los riesgos a un nivel que resulte aceptable, razón por la cual una de las actividades a las que se recurre con frecuencia consiste en identificar y evaluar debilidades asociadas a las plataformas de software y hardware, con la intención de evitar la materialización de eventos indeseados e inesperados.

En un ambiente donde los riesgos se encuentran en constante cambio, las amenazas son dinámicas y los recursos son limitados, resulta fundamental priorizar la aplicación de medidas de seguridad, luego de identificar las vulnerabilidades. Sin embargo, la complejidad radica en definir una escala y los criterios que permitan transformar los datos obtenidos en información.

Un elemento que aborda esta problemática y que ha sido adoptado por una cantidad importante de organizaciones y compañías enfocadas en seguridad, es CVE, por sus siglas en inglés Common Vulnerabilities and Exposures (Vulnerabilidades y exposiciones comunes). Es un identificador único para cada vulnerabilidad pública, funciona como un "DNI de vulnerabilidades".

El CVSS, por sus siglas en inglés Common Vulnerability Scoring System (Sistema común de puntuación de vulnerabilidades), evalúa y califica estas vulnerabilidades.

Las especificaciones CVSS son propiedad de FIRST, una organización sin fines de lucro con sede en EE.UU. cuya misión es ayudar a los equipos de respuesta a incidentes de seguridad informática de todo el mundo.

¿Qué es el CVSS?

En resumen, es un marco muy utilizado para clasificar y calificar las vulnerabilidades de software. A través de este marco abierto, las organizaciones pueden calcular una puntuación CVSS, que es una puntuación numérica que representa la gravedad de una vulnerabilidad. Las características de una vulnerabilidad que han contribuido a la puntuación CVSS se representan en una cadena de texto conocida como cadena de vectores CVSS.

El CVSS NO es una medida de riesgo. Es un método utilizado para proporcionar una medida cualitativa de la gravedad.

¿Cómo se calcula el impacto con CVSS?

Para determinar el impacto que representa una vulnerabilidad se utiliza una escala que va del 0 al 10. La clasificación cualitativa depende de la versión de CVSS. En CVSS v2.0 se emplean tres niveles: baja (0.0–3.9), media (4.0–6.9) y alta (7.0–10.0). En CVSS v3.x y v4.0 —las versiones vigentes— la escala tiene cinco niveles: Ninguna (0.0), Baja (0.1–3.9), Media (4.0–6.9), Alta (7.0–8.9) y Crítica (9.0–10.0).

Para calcular un puntaje asociado a una vulnerabilidad, CVSS utiliza tres grupos de métricas:

  • Las métricas base representan las características intrínsecas a la vulnerabilidad, que son constantes en el tiempo y en el entorno del usuario. En CVSS v3.x incluyen el vector de ataque, la complejidad del ataque, los privilegios requeridos, la interacción del usuario y el alcance (las versiones v2.0 usaban vector de acceso, complejidad de acceso y autenticación), de manera que permiten definir cómo se puede acceder a una vulnerabilidad y si se cumplen las condiciones para ser explotada. Las métricas de impacto miden la manera en la que una vulnerabilidad, si se explota, afecta de forma directa a los activos de TI. Los impactos se determinan de manera independiente, como el grado de pérdida de confidencialidad, integridad y disponibilidad, ya que una vulnerabilidad podría causar pérdida parcial de integridad y disponibilidad, pero tal vez no afecte la confidencialidad.
  • El segundo grupo corresponde a las métricas temporales, que representan las características de una vulnerabilidad que pueden cambiar en el tiempo, pero que son constantes en el ambiente de un usuario. Debido a que los riesgos planteados por una vulnerabilidad pueden cambiar a lo largo del tiempo, se consideran tres factores que influyen en ello: la madurez del código de explotación (explotabilidad), es decir, la disponibilidad de código o técnicas que permitan la explotación; el nivel de remediación disponible; y el nivel de confianza en el reporte, que refleja la credibilidad de la existencia de la vulnerabilidad y de sus detalles técnicos. Estas métricas son opcionales e incluyen un valor que no afecta a la evaluación cuando un usuario cree que la métrica en particular no existe y quiere omitirla.
  • Las métricas de entorno corresponden al tercer grupo y representan las características de una vulnerabilidad que son relevantes y únicas para el entorno de un usuario en particular. Se definen debido a los distintos ambientes que pueden denotar una gran influencia sobre el riesgo que representa una vulnerabilidad para una organización. Este grupo de métricas se enfoca en las características de una vulnerabilidad asociadas al entorno del usuario. En CVSS v3.x y v4.0 se componen de las métricas base modificadas, que permiten reajustar cualquier métrica base según el entorno concreto, y los requisitos de seguridad de confidencialidad, integridad y disponibilidad (CR, IR y AR). El daño potencial colateral y la distribución de objetivos que definía CVSS v2.0 se eliminaron a partir de la versión 3.0. Al igual que las métricas temporales, son opcionales y cada una tiene un valor sin efecto en la evaluación, el cual es utilizado cuando un usuario considera que la métrica en particular no existe y la omite.

Cuando se asignan valores a las métricas, la ecuación calcula la puntuación y crea una cadena de texto (vector) con dichos valores asignados, que es utilizada para comunicar la forma en que se generó cada puntuación de la respectiva vulnerabilidad, razón por la cual, el vector suele mostrarse junto a la calificación de la vulnerabilidad.

De manera general, el grupo de métricas base pretende definir y comunicar las características fundamentales de una vulnerabilidad, para otorgar a los usuarios una clara e intuitiva representación de una vulnerabilidad.

Es posible utilizar los grupos de entorno y temporal para proporcionar información contextual que refleje el riesgo de un ambiente específico, lo que permite tomar decisiones más informadas cuando se trata de mitigar los riesgos derivados de las vulnerabilidades. Para poner en práctica el método descrito, los usuarios pueden hacer uso de la calculadora CVSS v4.0. Cabe señalar que la calculadora y las evaluaciones del CVSS v2.0 fueron retiradas del NVD y ya no se aplican a los CVE publicados recientemente, por lo que debe emplearse una versión vigente (v4.0 o v3.1).

Versiones de CVSS, y su compatibilidad con el NVD

El CVSS v2.0 y el CVSS v3.x constan de tres grupos de métricas: Base, Temporal y Ambiental. El CVSS v4.0 es ligeramente diferente y consta de los grupos de métricas Base, Amenaza, Ambiental y Suplementaria.

La Base de Datos Nacional de Vulnerabilidades (NVD) proporciona enriquecimiento del CVSS para todos los registros de CVE publicados.

El NVD (National Vulnerability Database) es compatible con los estándares del Sistema Común de Puntuación de Vulnerabilidades (CVSS) v2.0, v3.x y v4.0. Sin embargo, según el anuncio de retirada del CVSS v2.0 del NVD , ya no ofrece evaluaciones del CVSS v2.0 para los registros CVE recién publicados.

El NVD proporciona evaluaciones del CVSS de las métricas base, las características innatas de cada vulnerabilidad. Actualmente, el NVD no ofrece evaluaciones de métricas temporales o de amenaza (métricas que cambian con el tiempo debido a eventos externos a la vulnerabilidad), métricas ambientales (métricas personalizadas para reflejar el impacto de la vulnerabilidad en una organización específica) ni métricas complementarias (métricas utilizadas para proporcionar contexto adicional).

No obstante, el NVD proporciona una calculadora del CVSS para cada versión del CVSS que permite a los usuarios evaluar métricas no base.

¿Se puede utilizar CVSS para evaluar las vulnerabilidades relacionadas con la IA?

CVSS puede ser útil para evaluar tipos específicos de vulnerabilidades de ciberseguridad que a menudo se descubren en aplicaciones de IA, incluido el envenenamiento de modelos, la denegación del servicio o la divulgación de información. Sin embargo, CVSS podría ser menos útil para las vulnerabilidades relacionadas con la IA que se relacionan principalmente con el sesgo, la ética o las preocupaciones legales, según FIRST. Estas vulnerabilidades se relacionan con la inferencia, la inversión de modelos y la inyección de instrucciones.


Leer Parte 2...

14 jul 2026

Actualizaciones de seguridad de JULIO para todas las empresas, murió el CVSS

Microsoft publicó hoy su mayor actualización de seguridad hasta la fecha, y dos de las correcciones solucionan vulnerabilidades que los atacantes ya estaban explotando. La actualización cubre 622 vulnerabilidades propias de Microsoft, más del triple del máximo anterior de junio, que rondaba las 200.

Debido a la cantidad de CVE, ordenar por criticidad de CVSS deja de tener sentido. Se debe ordenar y priorizar de acuerdo la vulnerabilidad que se esté analizando, usando KEV, EPSS y la bandera de vulnerabilidades de Microsoft, no por la "simple" puntuación de CVSS.

A continuación se muestra el número aproximado de errores en cada categoría de vulnerabilidad:

  • 254 Vulnerabilidades de elevación de privilegios
  • 17 Vulnerabilidades de omisión de funciones de seguridad
  • 145 Vulnerabilidades de ejecución remota de código
  • 102 Vulnerabilidades de divulgación de información
  • 35 Vulnerabilidades de denegación de servicio
  • 16 Vulnerabilidades de suplantación de identidad

Además, Google corrigió 468 fallos en Microsoft Edge/Chromium este mes, los cuales no se incluyeron en este resumen de actualizaciones de seguridad. Como parte de las actualizaciones de seguridad de junio del mes pasado, Google corrigió 360 fallos que posteriormente se implementaron en Microsoft Edge.

3 Vulnerabilidades de día cero, 2 explotadas

En la actualización de seguridad de este mes, se corrigen tres vulnerabilidades de día cero: dos explotadas en ataques y una divulgada públicamente. Las dos vulnerabilidades de día cero explotadas activamente que se corrigen en la actualización de seguridad de este mes son:

  • CVE-2026-56164, una vulnerabilidad de SharePoint Server que, según Microsoft, está siendo explotada activamente, permite a un atacante no autenticado escalar privilegios en la red. Sin credenciales, sin interacción del usuario y de forma remota. Microsoft atribuyó el descubrimiento a los responsables de respuesta a incidentes de Mandiant y al equipo FLARE de Google.
    Si utiliza SharePoint autohospedado, esta es la vulnerabilidad que debe actualizarse primero, y hay un segundo plazo: hoy también finaliza el soporte extendido para SharePoint Server 2016 y 2019. A diferencia de Windows Server o SQL Server, ninguno de los dos cuenta con un programa ESU de pago.
    Además de parchear, el aviso de Microsoft señala que habilitar AMSI en modo completo en el servidor reduce la efectividad del ataque. SharePoint ha sido un objetivo prioritario para los atacantes desde que la cadena ToolShell arrasó con servidores sin parchear en 2025, y sigue siéndolo.
  • La vulnerabilidad CVE-2026-56155, que Microsoft también identifica como explotada en los Servicios de federación de Active Directory (AD FS), permite a un atacante ya autenticado elevar privilegios localmente mediante controles de acceso débiles.
    AD FS es el servidor que gestiona los tokens para el resto de los fideicomisos de la red, por lo que una vulnerabilidad etiquetada como "local" en ese servidor merece mayor atención de la que sugiere su denominación. Microsoft no ha especificado qué privilegios otorga ni cómo la utilizaron los atacantes.

La vulnerabilidad de día cero divulgada públicamente que fue corregida es: CVE-2026-50661, una omisión de la función de seguridad BitLocker de Windows. Según se ha divulgado públicamente, podría permitir a los atacantes acceder a datos cifrados. "Un atacante que logre eludir la función de cifrado de dispositivo BitLocker en el dispositivo de almacenamiento del sistema. Un atacante con acceso físico al objetivo podría explotar esta vulnerabilidad para acceder a los datos cifrados", explica Microsoft.

Microsoft reconoce la importancia de las respuestas a incidentes para ambas vulnerabilidades explotadas. Se trata de fallos de elevación de privilegios en la infraestructura de identidad y colaboración: CVE-2026-56164 en SharePoint Server local y CVE-2026-56155 en los Servicios de Federación de Active Directory.

Ninguna de estas dos vulnerabilidades críticas es de ejecución remota de código. Son fallos de privilegios en dos sistemas que son más importantes de lo que sugieren sus puntuaciones: el repositorio de documentos de la empresa y el servidor que firma los inicios de sesión.

El tercer fallo de día cero se hizo público, pero no está siendo explotado es: CVE-2026-50661, otra vulnerabilidad que permite eludir BitLocker. Requiere acceso físico al dispositivo, por lo que no se trata de una emergencia remota. Se parchea, pero no tiene prioridad. 

SharePoint recibió una segunda corrección importante. Rapid7 Labs reveló CVE-2026-55040, una vulnerabilidad que permite eludir la autenticación JWT que desarrollaron para su participación en Pwn2Own Berlin. La puntuación varía según la fuente: Rapid7 le otorga una puntuación de 5.3 y afirma que Microsoft le asignó una gravedad media, mientras que ZDI la clasifica como crítica con una puntuación de 9.1.

Su funcionamiento es indiscutible. Rapid7 la encadenó a un fallo de ejecución remota de código independiente para lograr la ejecución remota de código sin autenticación contra un servidor vulnerable, y la parte de ejecución remota de código aún no se ha parcheado. Microsoft tiene previsto solucionarlo en agosto.

La limpieza de RC4 que puede provocar fallos en los inicios de sesión

Esta actualización también finaliza el endurecimiento de Kerberos RC4 que Microsoft ha estado implementando durante varios años. El despliegue de julio elimina el interruptor de reversión RC4DefaultDisablementPhase, la vía de escape que los administradores han utilizado desde que Microsoft comenzó las medidas de seguridad en enero.

A partir de ahora, RC4 solo funcionará para las cuentas configuradas explícitamente para permitirlo. Si alguna cuenta de servicio en su entorno aún solicita tickets Kerberos RC4, la autenticación podría fallar en el momento en que se implemente la actualización.

El orden es importante: primero, auditar utilizando los eventos de auditoría de RC4 que Microsoft añadió en enero; luego, rotar las contraseñas de las cuentas de servicio marcadas para que Windows genere claves AES; y, finalmente, aplicar el parche. La rotación solo corrige las cuentas que carecen de claves AES.

Cualquier sistema configurado para usar RC4, o un cliente antiguo que solo admita RC4, necesita una corrección antes de que se implemente la actualización. Esta corrección no provoca una brecha de seguridad; causa problemas, pero te avisará a las 2 de la madrugada si omites la auditoría.

Por qué un mes tranquilo batió un récord

Julio es históricamente uno de los meses con menos actualizaciones en el calendario de Microsoft, lo que hace que una actualización de este tamaño destaque. Solo Windows representa 416 de las 622 vulnerabilidades, y ZDI contabilizó 95 vulnerabilidades de ejecución remota de código en toda la actualización.

En una publicación del 9 de julio, Microsoft comunicó a sus clientes que esperaran un "mayor volumen de actualizaciones de seguridad incluidas en cada versión a medida que la IA le ayuda a descubrir más problemas". Este trabajo incluye MDASH, su sistema de escaneo multimodal con agentes, que encontró 16 de las vulnerabilidades en el Patch Tuesday de mayo por sí solo. Microsoft no ha especificado cuántas de las 622 de julio surgieron de este proceso.

La misma automatización funciona en ambos sentidos. Una vez que se publica un parche, los atacantes pueden compararlo con la última versión, encontrar el error que corrige y crear un exploit funcional antes de que la mayoría de las empresas hayan terminado las pruebas. Esto elimina el antiguo margen de tiempo de espera y reduce la brecha hasta el "Miércoles de Explotación".

También debilita el análisis basado en CVSS. Cuando una versión contiene más de 600 CVE y una gran parte se clasifica como Alta o Crítica, la categoría "Crítica" deja de ser relevante para la clasificación. Los dos errores explotados este mes lo demuestran: ninguno es una vulnerabilidad grave de la versión 9.8, ambos son fallos de privilegio de nivel medio y ambos ya están en uso.

Actualizaciones recientes de otras compañías

Otros proveedores que publicaron actualizaciones o avisos en mayo de 2026 incluyen:


Grok Build subió repositorios Git completos al almacenamiento de xAI (sin autorización)

La interfaz de línea de comandos (CLI) de codificación Grok Build de xAI estaba subiendo repositorios Git completos, con todo el historial de confirmaciones incluido, a un bucket de Google Cloud Storage administrado por xAI, y no solo los archivos necesarios para una tarea de codificación.

Un investigador que publica bajo el seudónimo de cereblab, probando la versión 0.2.93, capturó una de estas cargas, clonó el paquete Git de la solicitud interceptada y recuperó un archivo que el agente tenía instrucciones explícitas de no abrir.

La carga utiliza un canal independiente del modelo, y la distribución de bytes es difícil de refutar. En un repositorio de 12 GB con archivos que el modelo nunca leyó, el tráfico de la función `model-turn` hacia `/v1/responses` alcanzó aproximadamente 192 KB, mientras que el canal de almacenamiento hacia `/v1/storage` movió 5,10 GiB, una diferencia de aproximadamente 27.800 veces entre lo que el modelo necesitaba y lo que salía de la máquina.

La carga del almacenamiento se realizó en 73 fragmentos de aproximadamente 75 MB, cada uno devolviendo un código HTTP 200. Durante el análisis del tamaño del repositorio, el volumen rastreado representó el tamaño total del repositorio. El bucket de destino, grok-code-session-traces, se nombra en el binario y en un archivo metadata.json preparado, cuyas rutas de archivo apuntan a gs://grok-code-session-traces/.

El archivo no leído era src/_probe/never_read_canary.txt, al que se le añadió un marcador único. La clonación del paquete capturado lo recuperó tal cual, junto con el historial completo de confirmaciones del repositorio, y la misma prueba se replicó en un segundo repositorio independiente. Lo que establecen las capturas es la transmisión, la aceptación y el almacenamiento, no el entrenamiento.

El análisis de limpieza no afirma que xAI se haya entrenado con el código, que el personal lo haya leído ni que los archivos ignorados por Git se incluyan siempre. Lo que muestra la red son los archivos rastreados y el historial.

La ruta secreta es independiente y sencilla. Cuando Grok lee un archivo, su contenido pasa al modelo y un archivo .env rastreado se envía con él sin censurar, con los valores API_KEY y DB_PASSWORD incluidos. El mismo contenido también se guarda en un archivo session_state destinado al almacenamiento. Los secretos introducidos eran falsos, por lo que no se filtró información real en la prueba. El problema persiste: un archivo de credenciales que el agente leyó durante una tarea se envió y se almacenó sin censurar.

Un repositorio puede contener código propietario, URL internas, datos de clientes y credenciales que se eliminaron del árbol de trabajo, pero que aún permanecen en el historial de confirmaciones. En la comparación entre herramientas realizada por Cereblab, Claude Code y Codex se encuentran en el paquete del repositorio; Gemini no envió nada en una prueba inactiva, aunque su ejecución de tarea realista se bloqueó por cuota antes de finalizar.

Respuesta de xAI: El 13 de julio, el mismo binario 0.2.93 dejó de realizar solicitudes de almacenamiento. Cereblab realizó seis pruebas y no detectó ninguna carga en /v1/storage, y el servidor ahora devolvía disable_codebase_upload: true y trace_upload_enabled: false.

El desarrollador Peter Dedene informó que se devolvió el mismo indicador para su cuenta, por lo que el cierre no fue solo una observación de Cereblab en una sola máquina. El cliente probado permaneció en la versión 0.2.93 mientras se modificaban los ajustes de su servidor, por lo que se trató de un cambio del lado del servidor, no de una corrección incluida en una actualización. xAI no ha confirmado si afecta a todas las cuentas o si es permanente.

Fuente: THN

13 jul 2026

Atacante utiliza un script de PowerShell generado por IA para mapear Active Directory

Investigadores de ciberseguridad han detectado una intrusión en la que un atacante desconocido utilizó un script de PowerShell codificado con Vibe para la enumeración de Active Directory (AD).

"El script buscó el controlador de dominio (DC) y mapeó usuarios, equipos y dominios, antes de crear un directorio y exportar varios archivos, y finalmente crear AD_Report.html para medir el éxito del intento de enumeración", explicaron los investigadores de Huntress, Jevon Ang y Dray Agha.

La cadena de ataque consistió en que el atacante estableciera acceso mediante el Protocolo de Escritorio Remoto (RDP) a un servidor Windows unido al dominio con credenciales previamente comprometidas, para luego instalar las herramientas en la carpeta "C:\ProgramData\". El incidente tuvo lugar a principios de junio de 2026.

Esto incluyó una carga útil generada por inteligencia artificial (IA) para mapear el entorno de Active Directory. La evaluación se basa en varias señales reveladoras, como el título de la iteración de la solicitud, cadenas de texto de marcador de posición, código excesivamente complejo con múltiples métodos para encontrar un controlador de dominio y una salida de consola con formato de color cian, verde, rojo y amarillo.

Huntress describió el script de PowerShell personalizado como "muy agresivo" y "ruidoso", utilizando un "mecanismo de reserva en cascada de cinco pasos" para facilitar el reconocimiento y el descubrimiento. Su título es "100% Working AD Information Gathering Script - FULLY FIXED" lo que sugiere una interacción constante con un modelo de lenguaje extenso (LLM).

Una vez localizado el controlador de dominio principal, inicia una rutina de recopilación de datos para obtener sistemáticamente usuarios, equipos, grupos, unidades organizativas (OU) y relaciones de confianza de Active Directory, y almacenar los detalles en un directorio temporal.

Aproximadamente 30 minutos después, el atacante procedió a desplegar s5cmd, una herramienta legítima para operaciones masivas de archivos, junto con SharpShares, una utilidad de enumeración de recursos compartidos de red basada en C#, para buscar repositorios de datos accesibles para los usuarios.

En la etapa final, los datos se guardan en archivos CSV, se archivan y se extraen a un servidor remoto, no sin antes crear un archivo HTML que resume el robo de datos en forma de informe de inventario de Active Directory.

Este desarrollo es una señal más de que los ciberdelincuentes están ampliando su arsenal con malware codificado mediante inteligencia artificial, generado con la ayuda de modelos de IA, aunque la tecnología no se esté utilizando de formas nunca antes vistas. Lo que sí cambia es que reduce las barreras de entrada para el cibercrimen, permitiendo que actores menos experimentados desarrollen herramientas altamente sofisticadas y evasivas con un mínimo esfuerzo.

En un informe publicado la semana pasada, Sygnia reveló que los atacantes con IA no necesariamente necesitan malware novedoso ni vulnerabilidades de día cero, sino que el verdadero cambio radica en que las intrusiones cibernéticas se pueden orquestar a una velocidad y escala mayores de las que los defensores pueden contener.

La empresa de respuesta a incidentes informó haber detectado un ataque en la nube asistido por IA que, en aproximadamente 72 horas, se propagó desde el acceso inicial hasta una vulneración generalizada de un entorno de gran tamaño basado en Amazon Web Services (AWS). Se estima que el objetivo final de la actividad fue económico, utilizando el acceso a la infraestructura en la nube de la víctima como herramienta de extorsión.

Para ejercer mayor presión sobre las víctimas, el atacante llevó a cabo una serie de acciones:

  • Denegar el acceso a los buckets de S3
  • Limitar los servicios o contenedores de ECS a una capacidad máxima de cero
  • Crear reglas ACL para bloquear el acceso a la red
  • Vaciar las colas de SQS

"La importancia no radicaba en que la IA introdujera nuevas técnicas de ataque, ya que cada acción observada se correspondía con comportamientos adversarios ya conocidos, sino en que redujo el tiempo y el esfuerzo necesarios para implementar dichas técnicas en un entorno complejo", señaló Sygnia.

Fuente: THN

Servidor expuesto de de delincuente revela puertas traseras en miles de sitios de WordPress

Un grupo de ciberdelincuentes dejó uno de sus servidores completamente expuesto en Internet durante tres semanas, revelando así el funcionamiento interno de la operación: las herramientas de hacking, los registros de actividad y listas de objetivos con más de 1,4 millones de sitios web. Un servidor WP-SHELLSTORM abierto expuso herramientas, registros y listas de objetivos que nombran 1,4 millones de sitios, y los investigadores validaron 25.195 vulneraciones.

Si bien se logró acceder a muchos menos sitios, los archivos expuestos mostraron a los investigadores cómo se lleva a cabo una operación de hackeo masivo desde dentro.

La operación, ahora conocida como WP-SHELLSTORM, es lo que SOCRadar denomina una red de acceso a webshells: un grupo que accede a sitios web a gran escala, instala una puerta trasera oculta (una "webshell") en cada uno y empaqueta ese acceso para su reventa.

La mayor actividad se centró en sitios de WordPress con plugins desactualizados. Si utilizas WordPress o Joomla, las dos vulnerabilidades más importantes se encontraban en el plugin de caché Breeze y en el editor JCE de Joomla; consulta la lista de verificación a continuación si este es tu caso.

Un servidor olvidado

Dos equipos analizaron la misma carpeta expuesta. El equipo de inteligencia de amenazas de SOCRadar lo detectó el 11 de junio de 2026 en un servidor alquilado en EE.UU. (137.175.93[.]126) sin contraseña. En su interior se encontraron aproximadamente 800 MB distribuidos en 434 archivos: webshells, scripts de explotación, resultados de escaneos, el historial de comandos del operador y la configuración de comando y control.

Ctrl-Alt-Intel también había analizado el mismo directorio, tras encontrarlo en la plataforma de directorios abiertos Hunt.io, y publicó el 22 de junio, semanas antes del informe de SOCRadar del 9 de julio. La vulnerabilidad se debió a un simple descuido: el operador inició un servidor web Python para transferir archivos y lo dejó funcionando durante 22 días.

El equipo aprovechó vulnerabilidades conocidas públicamente en plugins web, la mayoría en WordPress, y creó escáneres automatizados para lanzar esos exploits contra enormes listas de objetivos obtenidas de FOFA, un motor de búsqueda chino para sistemas conectados a Internet, similar a Shodan.

Cuando un sitio web ejecutaba una versión vulnerable, el exploit podía instalar un webshell: un pequeño script que permite al atacante ejecutar comandos en el servidor desde cualquier lugar, leer archivos, robar contraseñas y acceder a niveles más profundos de la red.

El conjunto de herramientas cubría 27 vulnerabilidades conocidas, aunque unas pocas fueron las que generaron la mayor parte del trabajo. La más importante fue una vulnerabilidad en el plugin de caché Breeze (CVE-2026-3844), que el equipo lanzó contra más de 45.000 objetivos y, según sus propios cálculos, creó puertas traseras en más de 17.000 de ellos.

Las cifras, en términos sencillos

La cifra principal requiere una aclaración. El recuento de 1,4 millones se refiere a la cantidad de dominios incluidos en las listas de objetivos, no a la cantidad de sitios comprometidos, y dichas listas abarcaban WordPress, Joomla y otras plataformas. El archivo más grande contenía una lista de 587.034 objetivos de Joomla.

La cantidad real de sitios comprometidos fue mucho menor, y los dos equipos de investigación la calcularon de forma diferente: el recuento deduplicado de Ctrl-Alt-Intel encontró 25.195 sitios con evidencia de compromiso confirmada o validada, mientras que SOCRadar, contabilizando los webshells activos, estimó la cifra real en más de 5.700.

Un fallo muestra claramente esta discrepancia: un exploit de Joomla se lanzó contra más de 560.000 objetivos, pero solo afectó a 77 de ellos.

Estar en la lista de escaneo de alguien no es lo mismo que haber sido hackeado. Tenga esto en cuenta siempre que un informe comience con una cifra alarmante de objetivos.

Las herramientas y una campaña anterior

La puerta trasera principal, un archivo llamado down.php, estaba altamente ofuscada, con cuatro capas de profundidad, y parece una variante de una webshell china de código abierto llamado BestShell. Una vez en ejecución, podía gestionar archivos, ejecutar comandos, abrir shells inversas, escanear la red y comprobar qué software de seguridad utilizaba el host.

Para su propio acceso remoto, el grupo utilizó un dropper SNOWLIGHT para instalar VShell, una puerta trasera sigilosa que disfraza su nombre de proceso como [kworker/0:2] para mimetizarse con los hilos del kernel en una lista de procesos.

Estas dos herramientas tienen un historial: en abril de 2025, Sysdig vinculó esta cadena SNOWLIGHT-VShell con el presunto grupo estatal chino UNC5174. Sin embargo, VShell es una herramienta común en los círculos criminales de habla china, por lo que su sola presencia no apunta a un actor estatal.

El servidor también contenía rastros de un ataque anterior, muy diferente. SOCRadar descubrió que, antes del sonado ataque a WordPress, el mismo grupo llevó a cabo una campaña más discreta a principios de mayo de 2026 contra sistemas Java corporativos. Extrajeron 613 archivos de configuración de 11 sistemas de nueve empresas de los sectores de tecnología financiera, comercio electrónico, logística, videojuegos y electrónica.

El botín incluía claves de acceso a la nube para AWS, Alibaba Cloud, Oracle, Tencent y DigitalOcean, contraseñas de bases de datos y claves privadas RSA de Alipay. Se aprovecharon de una vulnerabilidad antigua y conocida en Nacos, un servidor de configuración (CVE-2021-29441), que permite a un atacante eludir el inicio de sesión falsificando una sola cabecera web.

SOCRadar interpreta la secuencia temporal como una secuencia: primero, obtener credenciales corporativas de alto valor; luego, semanas después, centrarse en el ataque de puertas traseras de mayor volumen; una ronda de financiación antes de la expansión.

Técnicas de trabajo deficientes

Ambos equipos evalúan con un grado de confianza medio-alto que el operador es chino o habla chino. Señalan el dominio del chino simplificado en todo el código y el historial de comandos, la dependencia de FOFA (que, según los investigadores, requiere un número de teléfono chino para registrarse) y las herramientas Godzilla y VShell, preferidas en foros de habla china.

SOCRadar va un paso más allá, interpretando que el grupo actuaba por motivos económicos en lugar de estar dirigido por el Estado. Los nombres en los archivos (tance, chen-kk, chenyk) se consideran pistas, no pruebas concluyentes. Un cabo suelto destaca: una única dirección IP en Taiwán realizó más de 42.000 solicitudes para descargar las herramientas del propio grupo. Podría tratarse de un segundo operador, un cliente u otro investigador. Los registros no permiten esclarecerlo.

Para un grupo que utilizaba un conjunto de herramientas realmente capaz, la negligencia del grupo fue notable. Dejó el servidor abierto, un archivo de configuración de FOFA que esta organización puede rastrear a través de su canal de investigación, y un historial de comandos sin editar que lo revelaba todo. Cuando finalmente se percató de su detección, entre el 2 y el 4 de julio, eliminó varias líneas de registro. Tres semanas demasiado tarde.

Este error es recurrente. En marzo de 2026, la misma organización de investigación descubrió al grupo ruso Fancy Bear (APT28) de la misma manera: un directorio abierto que había olvidado expuso las herramientas de phishing y los registros del grupo, en una campaña que Hunt.io denominó Operación Roundish.

¿Qué hacer?

Si utiliza alguno de los programas afectados, revíselo hoy mismo. No se trata de vulnerabilidades desconocidas: dos de ellas están siendo explotadas activamente en otros lugares.

Wordfence registró decenas de miles de ataques bloqueados contra la vulnerabilidad de Everest Forms Pro (CVE-2026-3300) esta primavera, y el fallo JCE de Joomla (CVE-2026-48907) es una vulnerabilidad de máxima gravedad que CISA ha añadido a su lista de Vulnerabilidades Explotadas Conocidas.

Lo que hace que WP-SHELLSTORM merezca atención no es su sofisticación, sino su aparente normalidad. Exploits públicos, escaneo automatizado y una lista de objetivos de un millón de líneas fueron suficientes para comprometer sitios web a gran escala, sin necesidad de vulnerabilidades de día cero. Los detalles son públicos únicamente porque el grupo olvidó apagar su propio servidor.

Fuente: THN

11 jul 2026

Guía de hardening para Linux

El propósito de esta guía "How To Secure A Linux Server" es enseñarte a proteger un servidor Linux. Hay muchas cosas que puedes hacer para proteger un servidor Linux, y esta guía intentará cubrir la mayor cantidad posible.

Los playbooks de Ansible de esta guía están disponibles en "Cómo proteger un servidor Linux con Ansible" de moltenbit.

¿Por qué proteger tu servidor?

Supongo que estás usando esta guía porque, con suerte, ya entiendes por qué es importante una buena seguridad. Este es un tema complejo y su explicación detallada está fuera del alcance de esta guía. Si no sabes la respuesta a esa pregunta, te recomiendo que investigues primero.

En términos generales, en el momento en que un dispositivo, como un servidor, es de dominio público (es decir, visible para el mundo exterior), se convierte en un objetivo para los ciberdelincuentes. Un dispositivo sin seguridad es un terreno fértil para ciberdelincuentes que buscan acceder a tus datos o usar tu servidor como plataforma para ataques DDoS a gran escala.

Lo peor es que, sin una buena seguridad, es posible que nunca sepas si tu servidor ha sido comprometido. Un ciberdelincuente podría haber accedido sin autorización y copiado tus datos sin modificar nada, por lo que nunca te enterarías. O tu servidor podría haber sido víctima de un ataque DDoS, sin que lo supieras. Basta con ver muchos de los casos de filtraciones de datos a gran escala que aparecen en las noticias: las empresas a menudo no descubrieron la fuga de datos o la intrusión hasta mucho después de que los ciberdelincuentes se hubieran marchado.

Contrariamente a la creencia popular, los ciberdelincuentes no siempre buscan modificar algo o bloquear el acceso a tus datos a cambio de dinero. A veces, simplemente quieren los datos de tu servidor para sus almacenes de datos (el big data genera grandes beneficios) o para usar tu servidor de forma encubierta con fines maliciosos.

¿Por qué otra guía?

Esta guía puede parecer redundante o innecesaria, ya que existen innumerables artículos en línea sobre cómo proteger Linux, pero la información está dispersa en distintos artículos que tratan temas diferentes y de maneras diversas. ¿Quién tiene tiempo para revisar cientos de artículos?

Existen numerosas guías proporcionadas por expertos, líderes de la industria y las propias distribuciones. No es práctico, y en ocasiones infringe los derechos de autor, incluir todo el contenido de dichas guías. Recomiendo consultarlas antes de comenzar con esta guía.

El Centro para la Seguridad en Internet (CIS) proporciona estándares exhaustivos, instrucciones paso a paso y de confianza para la industria, para proteger diversas distribuciones de Linux. Consulte su página "Acerca de nosotros" para obtener más información. Recomiendo leer primero esta guía y LUEGO la guía del CIS. De esta manera, sus recomendaciones prevalecerán sobre cualquier información de esta guía.

Para obtener guías de seguridad y protección específicas para su distribución, consulte la documentación de su distribución.

Estudio de aplicaciones VPN gratuitas para Android detecta fugas de tráfico, datos sin cifrar y rastreo

Investigadores sometieron 281 de las aplicaciones VPN gratuitas más populares de Google Play Store a un nuevo sistema de pruebas y descubrieron que muchas fallan en la función básica para la que se instala una VPN: mantener el tráfico privado y seguro.

Las aplicaciones que presentaron al menos un problema se han instalado más de 2.400 millones de veces.

Los problemas son básicos, no complejos.

  • 29 aplicaciones permiten que el tráfico del usuario se filtre fuera del túnel cifrado, incluyendo las consultas DNS que revelan los sitios web visitados.
  • 61 aplicaciones envían datos en texto plano que cualquier persona que monitorice el tráfico en esa red puede leer.
  • Cinco de ellas envían el archivo de configuración de la aplicación sin cifrar, lo que permite a un atacante en la red redirigir la conexión a un servidor bajo su control.

El sistema, llamado MVPNalyzer, fue presentado en la conferencia de seguridad NDSS en febrero de 2026 por investigadores de la Universidad de Michigan, la Universidad de Nuevo México y el IIT Delhi.

Se trata de la versión móvil del estudio VPNalyzer, realizado anteriormente por el mismo laboratorio para analizar el software VPN de escritorio. Los investigadores lo describen como el primer marco de trabajo diseñado para auditar de forma sistemática y repetida las aplicaciones VPN de Android.

Una VPN encapsula tu tráfico en un túnel cifrado, impidiendo que tu proveedor de internet o un intruso en la red vean tu actividad. La contrapartida es que la aplicación VPN ahora tiene acceso a todo el tráfico. No se elimina la necesidad de confiar en alguien, sino que esa confianza se traslada del proveedor de internet al desarrollador de la aplicación.

El estudio se pregunta si estas aplicaciones se merecen esa confianza. Para muchas, la respuesta es no.

El fallo más grave: el secuestro del túnel.

El hallazgo más preocupante se refiere a las cinco aplicaciones que descargan su archivo de configuración sin cifrar. Este archivo indica a la aplicación a qué servidor conectarse. Si se transmite en texto plano, un atacante en la misma red, por ejemplo, un operador de Wi-Fi público, puede modificarlo durante la transmisión y redirigir la aplicación a un servidor bajo su control.

El usuario se conecta, ve la pantalla habitual de "conectado" y todo se redirige a través del atacante. Los investigadores crearon este ataque y confirmaron que funcionaba en teléfonos bajo su control.

Indicaron el problema como prioritario para los cinco proveedores. Dos respondieron, prometiendo trasladar el archivo a HTTPS. Uno afirmó que enviaría los archivos de configuración "de forma segura mediante HTTPS con la validación de certificado adecuada". Los otros tres no respondieron.

Filtraciones y aplicaciones que no ocultan nada

De las 29 aplicaciones, 24 filtraban tráfico DNS, exponiendo los sitios web visitados por los usuarios a la red local; solo estas aplicaciones representan aproximadamente 360 ​​millones de instalaciones. Seis filtraban todo el tráfico de navegación fuera del túnel, y cuatro ejecutaban "túneles" sin ningún tipo de cifrado, con algunas aplicaciones fallando en más de un sentido.

Por otro lado, 169 aplicaciones no intentaban disimular su tráfico como si fuera una VPN, por lo que un operador de red o un censor gubernamental puede detectarlas y bloquearlas con herramientas básicas. Casi dos tercios de estas aplicaciones anuncian que son capaces de sortear el bloqueo o el desbloqueo de contenido restringido. Hacen la promesa y no hacen nada para cumplirla.Para alguien que vive en un país donde usar una VPN ya es arriesgado, ser fácilmente identificado como usuario de VPN es justo lo contrario de lo que esperaba.

Rastreo, incluso desde aplicaciones diseñadas para evitarlo

A menudo, las personas instalan VPN para evitar ser rastreadas. Sin embargo, muchas de estas aplicaciones rastrean de todos modos. 76 enviaron el ID de publicidad del dispositivo, un código único que los anunciantes usan para seguir a una persona de una aplicación a otra.

El estudio reveló que más del 80% de las aplicaciones (246 en total) se conectaron con servidores de publicidad y rastreo conocidos. Muchas también enviaron detalles como el modelo del teléfono, la versión del sistema operativo y el tamaño de la pantalla.

Por sí solos, estos datos parecen inofensivos, pero combinados, forman una "huella digital" que puede identificar un dispositivo. Una aplicación incluso envió las coordenadas GPS exactas del teléfono.

Configuraciones débiles

Los investigadores también analizaron los archivos de configuración de OpenVPN incluidos con 108 de las aplicaciones, una verificación independiente de las pruebas de tráfico en tiempo real mencionadas anteriormente. Solo una de ellas cumplió con todas las buenas prácticas de seguridad evaluadas en el estudio.

Aproximadamente el 89% dependía de un único método de autenticación, ya fuera contraseña o certificado, en lugar de combinar ambos. Casi uno de cada cinco utilizaba cifrado débil u obsoleto, incluyendo el antiguo cifrado Blowfish y el triple DES. Algunos configuraban el cifrado de datos del túnel como "ninguno", lo que desactiva completamente el cifrado. Ambos cifrados antiguos presentan vulnerabilidades conocidas desde hace tiempo (CVE-2016-6329 y CVE-2016-2183) que permiten a un atacante recuperar datos de conexiones de larga duración.

La mayoría de estos problemas tienen la misma raíz: las aplicaciones apenas reciben mantenimiento y las comprobaciones automáticas de la Play Store las permiten. Muchas aparecen entre los primeros resultados de búsqueda, donde las etiquetas de seguridad de Google y su distintivo "Verificado" para aplicaciones VPN pretenden ser una señal de confianza. El estudio afirma que estas etiquetas funcionan más como señales de marketing que como una garantía de seguridad real.

Esto no es un caso aislado.

Otras investigaciones recientes apuntan en la misma dirección. En agosto de 2025, investigadores del Citizen Lab de la Universidad de Toronto y de la Universidad Estatal de Arizona descubrieron que varias aplicaciones VPN populares para Android, con más de 700 millones de descargas combinadas, estaban vinculadas secretamente, compartían contraseñas codificadas y recopilaban datos de ubicación de forma encubierta.

En octubre de 2025, la empresa de seguridad móvil Zimperium informó que tres de las aproximadamente 800 aplicaciones VPN gratuitas que analizó aún incluían una versión de la biblioteca OpenSSL vulnerable a Heartbleed, un fallo conocido que se corrigió en 2014. Muchas también solicitaban permisos de acceso al teléfono que iban mucho más allá de lo necesario para una VPN.

Los tres estudios coinciden: las aplicaciones VPN gratuitas siguen combinando una sólida promesa de privacidad con una ingeniería deficiente, y siguen alcanzando millones de instalaciones antes de que nadie lo detecte.

Qué pueden hacer los usuarios

Los fallos más graves, la obtención de la configuración en texto plano y la configuración débil del túnel, son invisibles para el usuario. No se pueden detectar simplemente mirando la aplicación, y ahí radica el problema. Por lo tanto, la verdadera defensa no reside en el protocolo que anuncia la aplicación, sino en quién está detrás de ella.

Se ruega a los proveedores que publiquen una auditoría de seguridad independiente reciente. Desconfíe de las aplicaciones gratuitas que le bombardean con anuncios. Considere las afirmaciones de "verificado" o "sin registros" como un punto de partida, no como una prueba.

Los investigadores enumeran todas las aplicaciones señaladas en el apéndice del artículo, para que pueda comprobar si la que tiene en su teléfono se encuentra entre ellas.

El equipo planea lanzar MVPNalyzer públicamente para que las tiendas de aplicaciones y los reguladores puedan realizar estas comprobaciones por sí mismos. Con esta evidencia, tendrán que hacerlo.

Se ha preguntado a Google si está revisando o eliminando las aplicaciones señaladas, y cuál es su respuesta a la conclusión del estudio de que las etiquetas de seguridad de Play Store y la insignia "Verificado" funcionan más como marketing que como garantías de seguridad. También hemos solicitado al equipo de investigación de MVPNalyzer que identifique las cinco aplicaciones vulnerables al secuestro de túneles y que confirme si los proveedores notificados han implementado soluciones. Esta noticia se actualizará con cualquier respuesta que recibamos.

Fuente: THN

10 jul 2026

Operación First Light expone billetera de criptomonedas de U$S 122 vinculada a lavado de estafas románticas

La Operación First Light de Interpol descubrió lavado de criptomonedas vinculado a estafas románticas y las autoridades incautaron 293 millones de dólares en activos ilícitos.

Una billetera de criptomonedas vinculada a un presunto lavador de dinero de estafas románticas procesó más de 122,5 millones de dólares en 10 meses, según Interpol, mientras las autoridades expandían una ofensiva global contra el fraude en línea.

Interpol dijo el jueves que las autoridades tailandesas arrestaron a dos sospechosos y descubrieron una red de lavado de dinero que canalizaba los ingresos de estafas románticas hacia criptomonedas, utilizando exchanges de tokens entre cadenas para obscurecer el rastro.

La investigación tailandesa fue parte de la Operación First Light 2026, una campaña coordinada por Interpol que apunta a estafas de ingeniería social y la infraestructura financiera utilizada para lavar sus ingresos. La operación involucró a autoridades en 97 países y territorios, lo que resultó en 5.811 arrestos y la incautación de 293 millones de dólares en activos ilícitos vinculados a fraude y lavado de dinero.

Durante la Operación se identificaron más de 142.000 víctimas en todo el mundo, lo que pone de manifiesto la magnitud de las estafas y el fraude mediante ingeniería social, que se han convertido en una grave amenaza transnacional que afecta a personas, empresas y gobiernos. Otros resultados significativos incluyen:

  • 152.808 casos analizados
  • 31.014 cuentas bancarias bloqueadas
  • 23.715 casos resueltos
  • 15.606 sospechosos identificados
  • 99 notificaciones y comunicados emitidos

Tomonobu Kaya, director del Centro de Delitos Financieros y Anticorrupción de Interpol, dijo que las estafas de ingeniería social "siguen planteando una amenaza significativa para nuestra sociedad", agregando que ningún país puede abordar el problema solo.

Interpol dijo que las autoridades participantes apuntaron a cuentas bancarias y billeteras de criptomonedas utilizadas para mover fondos ilícitos. La operación analizó 152.808 casos, bloqueó 31.014 cuentas bancarias, resolvió 23.715 investigaciones e identificó a 15.606 sospechosos.

Las autoridades también utilizaron el sistema de congelación de pagos de Interpol, conocido como la Intervención Rápida Global de Pagos, para ayudar a bloquear transferencias ilícitas que involucran activos virtuales y fiduciarios.

Las autoridades de Palau también deportaron a 22 personas presuntamente involucradas en dos centros de estafas basados en hoteles que utilizaban criptomonedas y sitios web de juegos de azar ilegales para apuntar a víctimas en el extranjero.

El caso sigue a la creciente preocupación por el uso de criptomonedas en estafas románticas y de inversión.

En abril, el Buró Federal de Investigación de EEUU (FBI) informó que los estadounidenses presentaron 181.565 denuncias de estafas relacionadas con criptomonedas por un total de más de 11.000 millones de dólares en pérdidas en 2025.

Las estafas románticas, también conocidas como estafas de "matar cerdos", a menudo implican que los criminales construyen confianza con las víctimas a través de las redes sociales o plataformas de citas en línea antes de dirigirlos hacia esquemas de inversión fraudulentos.

Fuente: