Entradas de blog etiquetadas con ' cyberrisk ' Rss

¿Cuál es la amenaza?

Click2Shell es una vulnerabilidad del núcleo de WordPress que aprovecha el modo en que WordPress gestiona las solicitudes de instalación y vista previa de temas. Un atacante puede engañar a un administrador que haya iniciado sesión para que visite una URL especialmente diseñada. WordPress procesa la solicitud utilizando los permisos del administrador, lo que permite instalar un tema del repositorio de temas de WordPress.org sin que el administrador inicie la acción intencionadamente.

Por sí sola, la vulnerabilidad permite la instalación no autorizada de temas. Sin embargo, dado que WordPress puede cargar el código PHP de un tema inactivo durante la vista previa del Personalizador, los atacantes pueden acceder a la funcionalidad vulnerable del tema sin activarlo. Los investigadores demostraron que, si se instala un tema vulnerable, los atacantes pueden aprovechar sus debilidades para instalar complementos maliciosos, ejecutar código PHP, desplegar shells web o tomar el control de la aplicación WordPress.

Un aspecto destacable del ataque es que el tema visible del sitio puede que nunca cambie, lo que dificulta que los administradores detecten la vulnerabilidad.

¿Por qué es digno de mención?

Esta vulnerabilidad afecta al núcleo de WordPress, no solo a un plugin o tema específico. El ataque también pone en tela de juicio la suposición de que los temas inactivos son inofensivos. Un tema no necesita estar activado para que su código sea accesible durante el proceso de vista previa. Al combinarse con temas de terceros vulnerables, Click2Shell crea una vía práctica desde la ingeniería social hasta la ejecución de código del lado del servidor.

Dado que los temas y complementos recién instalados pueden permanecer prácticamente invisibles para los administradores, una intrusión exitosa podría pasar desapercibida durante un período prolongado.

¿Cuál es la exposicion o riesgo?

Las organizaciones que utilizan instalaciones de WordPress sin actualizar pueden ser vulnerables si un administrador que ha iniciado sesión accede a un enlace malicioso.

Una explotación exitosa puede dar como resultado:

• Instalación no autorizada de temas o complementos
• Ejecución remota de código
• Implementación de shell web
• Robo de credenciales
• Manipulación de datos
• Acceso persistente
• Desfiguración de sitio web
• Alojamiento de malware o actividad de phishing
• Compromiso total de la aplicación WordPress

El riesgo aumenta cuando los administradores navegan por correo electrónico o sitios web externos mientras tienen la sesión iniciada en WordPress, o cuando los entornos permiten modificar temas y complementos a través del panel de control de WordPress.

¿Cuáles son las recomendaciones?

La seguridad moderna necesita reducir la dependencia de que cada usuario sea capaz de reconocer una amenaza. La capacitación y la concientización siguen siendo importantes, pero una organización no debería dejar toda la responsabilidad en el momento del clic. Por lo que las siguientes recomendaciones permiten mitigar el impacto de la vulnerabilidad:

Actualizar WordPress

• Actualiza WordPress Core a la versión 7.1.1 o posterior.
• Aplique las actualizaciones de seguridad para las ramas compatibles si no es posible una actualización inmediata.

Actualizar temas y plugins

• Actualizar todos los temas instalados, incluidos los temas inactivos.
• Elimine los complementos que ya no sean compatibles o estén abandonados.
• Revise los entornos para los temas a los que se hace referencia en las investigaciones publicadas, incluida la Zona de Reparación Móvil 2.5.4.

Eliminar temas no utilizados

• Eliminar temas inactivos innecesarios.
• Conservar únicamente los temas activos y los temas de reserva necesarios.
• Supervise las adiciones inesperadas en wp-content/themes/.

Restringir el acceso administrativo

• Limite los privilegios de administrador de WordPress al personal necesario.
• Habilitar la autenticación multifactor (MFA) para las cuentas de administrador.
• Evite utilizar sesiones de administrador para la navegación rutinaria.

Reforzar los controles de modificación de archivos.

• Desactive la edición directa de temas y plugins siempre que sea posible.
• Restringir los permisos de escritura a los directorios necesarios.
• Considere la posibilidad de deshabilitar la instalación de plugins y temas en entornos de producción.

Vigile la actividad sospechosa.

Revise los registros para detectar accesos inesperados a:

• /wp-admin/theme-install.php
• /wp-admin/admin-ajax.php
• Solicitudes relacionadas con el personalizador

Investigar:

• Nuevos temas o complementos
• Archivos PHP inesperados
• Archivos de tema modificados recientemente

Reducir el riesgo de ingeniería social

• Capacite a los administradores para que eviten hacer clic en enlaces no solicitados mientras estén conectados a WordPress.
• Utilice perfiles de navegador independientes para las actividades de administración.
• Siempre que sea posible, solicite una nueva autenticación para las acciones sensibles.

Utilice WAF y parcheo virtual.

• Implementa reglas que identifiquen actividades sospechosas de instalación de temas.
• Bloquear las solicitudes que contengan parámetros de tema anómalos o intentos de manipulación del selector.

Investigar la posible exposición

Si los sistemas no estaban actualizados:

• Revisar si hay temas o complementos inesperados.
• Examine los registros administrativos y del servidor web.

• Si se sospecha que el sistema se ha visto comprometido, cambie las credenciales de administrador y revoque las sesiones activas.

La IA está compitiendo por el presupuesto de TI

La adopción de inteligencia artificial requiere inversión. Infraestructura, plataformas, software especializado, procesamiento de datos y nuevas herramientas forman parte de una ecuación que está obligando a muchas organizaciones a redistribuir sus recursos.

De acuerdo con la encuesta, 18 % de los participantes afirmó que su organización ha reasignado parte del presupuesto destinado a software de seguridad para financiar la adopción de IA. A primera vista, podría parecer una señal de presión para los equipos de ciberseguridad. Sin embargo, el comportamiento de otras áreas de TI muestra una diferencia importante.

Mientras el gasto en software de seguridad continúa creciendo, 47 % de los encuestados señaló reducciones en herramientas de operaciones y monitorización de TI, y 46 % reportó recortes en herramientas de productividad y colaboración para financiar iniciativas de IA.

La diferencia también aparece cuando se analiza el personal. Las organizaciones están replanteando sus necesidades en soporte técnico y mesa de ayuda, desarrollo de software, operaciones, infraestructura y administración de TI. En ciberseguridad, en cambio, la reducción prevista es menor: 23 % de los encuestados espera disminuir su plantilla de profesionales de seguridad.

La razón puede encontrarse en un aspecto fundamental: la misma tecnología que permite automatizar tareas también está proporcionando nuevas capacidades a los atacantes.

Cuando los atacantes también tienen IA

La discusión sobre inteligencia artificial suele concentrarse en cuánto trabajo puede automatizar una organización. Sin embargo, existe otra pregunta que resulta igual de importante: ¿qué ocurre cuando esa misma capacidad está disponible para los ciberdelincuentes?

La IA puede ayudar a acelerar la creación de contenido malicioso, automatizar procesos, analizar grandes cantidades de información y adaptar ataques con una velocidad que difícilmente podría alcanzarse mediante procesos completamente manuales.

Esto cambia las reglas del juego. Un atacante no necesariamente necesita reemplazar todas sus herramientas actuales por sistemas de IA; basta con utilizarla para aumentar la velocidad, escala y eficiencia de operaciones que ya realizaba.

Para las empresas, esto significa que detectar una amenaza después de que el daño ocurrió resulta cada vez menos viable. La seguridad necesita evolucionar hacia modelos capaces de analizar grandes volúmenes de eventos, identificar comportamientos anómalos y responder antes de que una amenaza pueda convertirse en un incidente mayor.

Y aquí aparece una de las principales paradojas de la transformación impulsada por IA: la automatización puede reducir determinadas tareas manuales, pero también puede generar más trabajo de seguridad que nunca.

Menos personal no significa necesariamente menos trabajo

La encuesta de ETR muestra que 96% de las organizaciones utiliza IA en algún nivel. Al mismo tiempo, 34 % está limitando el crecimiento futuro de sus plantillas y 20 % afirma estar reduciendo estratégicamente su personal a medida que adopta estas tecnologías.

Sin embargo, la inversión general en TI continúa creciendo. Los encuestados reportaron un incremento interanual de 3.8 % en el gasto de TI, mientras que 72 % afirmó que su organización planea continuar aumentando esa inversión.

Esto plantea una situación interesante. Las empresas pueden estar buscando hacer más con menos personas, pero la tecnología también permite que los equipos existentes asuman tareas que anteriormente simplemente no podían realizar por falta de tiempo o recursos.

En ciberseguridad, esta diferencia es especialmente importante. Una herramienta automatizada puede analizar miles de eventos en cuestión de segundos, pero alguien debe definir qué se considera una amenaza, establecer las reglas de respuesta, investigar los casos complejos y validar que las acciones automatizadas sean las adecuadas.

La IA puede convertirse en un multiplicador de capacidades. No necesariamente en un sustituto absoluto del conocimiento especializado.

El reto es todavía mayor para las pymes

Para las pequeñas y medianas empresas, esta transformación puede representar tanto una oportunidad como un desafío.

Durante años, muchas pymes han tenido dificultades para contratar y retener profesionales especializados en ciberseguridad. Los puestos vacantes podían permanecer abiertos durante meses, mientras las empresas competían por un grupo limitado de especialistas.

La incorporación de IA y automatización puede ayudar a reducir parte de esa presión. Las organizaciones pueden utilizar tecnología para automatizar tareas repetitivas, priorizar alertas y proporcionar mayor visibilidad sobre lo que ocurre en sus entornos.

Pero automatizar no elimina la necesidad de experiencia. Al contrario, cuando las amenazas se vuelven más rápidas y sofisticadas, comprender lo que ocurre detrás de una alerta puede ser todavía más importante.

Para una pyme, la pregunta ya no debería limitarse a cuántas personas necesita incorporar a su equipo de seguridad. También debe considerar cuánto trabajo puede automatizar, qué capacidades necesita mantener internamente y qué funciones puede respaldar mediante servicios especializados.

La nueva ecuación de la ciberseguridad

Todavía es demasiado pronto para determinar exactamente cómo transformará la IA al mercado laboral de ciberseguridad. Lo que sí comienza a quedar claro es que la ecuación no puede reducirse simplemente a "IA = menos personas".

Los atacantes también adoptarán estas tecnologías. Si consiguen utilizarlas para aumentar simultáneamente el volumen y la sofisticación de sus ataques, las organizaciones necesitarán capacidades de defensa capaces de responder a esa misma escala.

Esto podría llevar a un escenario donde humanos y sistemas de IA trabajen conjuntamente: agentes automatizados encargándose de grandes cantidades de eventos y tareas repetitivas, mientras los profesionales especializados supervisan, investigan, toman decisiones y gestionan los casos que requieren contexto y criterio.

El verdadero desafío estará en administrar correctamente ese ecosistema. Porque incluso los sistemas automatizados necesitan supervisión, reglas, objetivos y controles. Una organización no puede asumir que una herramienta será capaz de tomar siempre la decisión correcta simplemente porque utiliza inteligencia artificial.

La ciberseguridad no desaparece: evoluciona

La llegada de la IA está obligando a las empresas a reconsiderar cómo distribuyen sus presupuestos, cómo contratan personal y qué tareas pueden automatizar. Pero la necesidad de proteger la información y las operaciones permanece.

De hecho, a medida que las organizaciones incorporan más inteligencia artificial, también necesitan asegurarse de que sus sistemas, usuarios, aplicaciones y datos estén protegidos frente a nuevas formas de ataque.

La tendencia apunta hacia una ciberseguridad más automatizada, más orientada al análisis continuo y con mayor capacidad de respuesta. El profesional de seguridad no necesariamente desaparecerá; su función tendrá que evolucionar junto con las herramientas que utiliza.

Para las empresas, especialmente las pymes, esto significa que invertir en ciberseguridad no se trata únicamente de aumentar el número de personas o adquirir más herramientas. Se trata de construir una estrategia capaz de combinar tecnología, automatización, inteligencia y experiencia humana.

Porque si la IA permite que las amenazas evolucionen a la velocidad de las máquinas, la defensa también tendrá que aprender a hacerlo.

Ataques sobre el Linux más complejos que nunca

La vulnerabilidad ZcopyReaper (CVE-2026-43502) es un fallo de escalada de privilegios local en la ruta de envío zerocopy de RDS (Reliable Datagram Sockets) del kernel de Linux. Este problema existe desde la versión 4.17 del kernel de Linux.

Los atacantes pueden aprovechar un manejo inadecuado de la memoria durante el proceso de limpieza de RDS para obtener privilegios de administrador. Una vez elevados, pueden acceder a datos confidenciales, instalar malware y moverse lateralmente por las redes corporativas.

La publicación de una prueba de concepto pública aumenta el riesgo de explotación y reduce la barrera técnica para los atacantes.

¿ZcopyReaper?

La vulnerabilidad ZcopyReaper es especialmente preocupante porque afecta a los sistemas Linux desde la versión 4.17 del kernel. Como resultado, muchos sistemas implementados a lo largo de varios años podrían ser vulnerables.

La disponibilidad de una prueba de concepto pública aumenta la probabilidad de ataques activos. Linux también impulsa infraestructuras críticas, entornos en la nube y servidores empresariales en todo el mundo, lo que convierte a esta amenaza en una prioridad para las organizaciones que dependen de sistemas basados en Linux.

¿Cuál es la exposición o el riesgo?

Las organizaciones que utilizan versiones afectadas del kernel de Linux (4.17 y posteriores) se enfrentan a un riesgo significativo debido a la vulnerabilidad ZcopyReaper (CVE-2026-43502). Si se explota, los atacantes con acceso local pueden obtener privilegios de administrador y tomar el control total del sistema. Este acceso puede permitir el acceso no autorizado a datos, la instalación de malware, la creación de puertas traseras persistentes y la modificación de configuraciones críticas del sistema.

Los atacantes también pueden usar un sistema comprometido como punto de entrada para moverse lateralmente a través de las redes corporativas. La vulnerabilidad pública de prueba de concepto (PoC) aumenta aún más el riesgo al hacer que la explotación sea más accesible.

Los entornos en la nube, los centros de datos y los servidores empresariales que ejecutan sistemas Linux sin actualizar son especialmente vulnerables.

Recomendaciones para reducir el riesgo

• Actualiza a la última versión del kernel de Linux que soluciona la vulnerabilidad CVE-2026-43502.
• Desactive o incluya en la lista negra el módulo rds.ko si su entorno no requiere Reliable Datagram Sockets (RDS).
• Restrinja el acceso de los usuarios a los sistemas críticos e implemente controles de acceso con privilegios mínimos.
• Mejorar la monitorización y el registro de eventos para detectar intentos de escalada de privilegios y actividades inusuales.
• Revise las configuraciones del sistema y aplique las mejores prácticas de refuerzo de seguridad de Linux.
• Manténgase al tanto de las directrices y las actualizaciones de los proveedores de Linux, incluidos Red Hat, Ubuntu y SUSE.
• Pruebe los parches en un entorno de prueba antes de implementarlos en los sistemas de producción.

KATARU... está atacanto a Linux?

KATARU es una variante de malware para IoT y Linux que ataca dispositivos con servicios Telnet expuestos y credenciales débiles o predeterminadas. Tras obtener acceso, descarga y ejecuta una carga útil maliciosa e intenta obtener privilegios de administrador mediante vulnerabilidades conocidas de Linux.

Una vez establecido, KATARU instala mecanismos de persistencia que le permiten sobrevivir a los reinicios y mantener el acceso a largo plazo. Utiliza comunicaciones de comando y control cifradas para evadir la detección y puede lanzar ataques DDoS, realizar ataques de fuerza bruta SSH, ejecutar comandos remotos y descargar malware adicional.

¿Por qué es digno de mención?

KATARU combina vulnerabilidades de seguridad de larga data, como servicios Telnet expuestos, contraseñas débiles y sistemas Linux sin parchear, con capacidades de malware modernas, como comunicaciones C2 cifradas y acceso persistente de nivel root. A diferencia de muchas botnets de IoT de corta duración, KATARU está diseñado para mantener el control a largo plazo de los dispositivos comprometidos. Este malware demuestra cómo los ciberdelincuentes pueden combinar herramientas y exploits disponibles públicamente para crear ataques efectivos y escalables.

Para las organizaciones con entornos de IoT o OT, KATARU refuerza la importancia de la aplicación de parches, el endurecimiento de la seguridad y una gestión sólida de las credenciales.

¿Cuál es la exposición o el riesgo?

Las organizaciones se enfrentan al mayor riesgo cuando los dispositivos IoT o Linux conectados a internet tienen Telnet habilitado, utilizan credenciales débiles o ejecutan firmware y sistemas operativos obsoletos. Una vez comprometidos, los dispositivos pueden formar parte de una botnet utilizada para ataques DDoS a gran escala y otras actividades maliciosas. Dado que KATARU incluye capacidades de escalada de privilegios y persistencia, las infecciones pueden sobrevivir a los reinicios y ser difíciles de eliminar.

El malware afecta a una amplia gama de dispositivos basados en Linux, incluidos routers, equipos IoT y otros sistemas conectados. Los dispositivos sin parchear o sin soporte pueden proporcionar a los atacantes una ventaja a largo plazo en el entorno.

¿Cómo pueden los compradores de software proteger las aplicaciones codificadas con Vibe?

Los compradores de software deben asumir que algunos componentes de las nuevas aplicaciones que utilicen en 2026 podrían haber sido codificados con Vibe. Esto no significa que contengan vulnerabilidades por defecto, sino que deben tomar medidas para limitar las consecuencias de cualquier aplicación que pueda contener un error de codificación explotable. En otras palabras, deben adoptar protocolos de seguridad de confianza cero.

La seguridad de confianza cero surgió antes de la IA, partiendo de la premisa de que cada usuario y aplicación era potencialmente vulnerable. En la era de la IA, podemos asumir que cada aplicación está potencialmente comprometida mediante código Vibe, y que cada aplicación con código Vibe posee vulnerabilidades explotables.

Puedes examinar rigurosamente cada aplicación de tu infraestructura para detectar estas vulnerabilidades, pero:

• Esto requiere un tiempo del que no dispones.
• Incluso la revisión más exhaustiva puede pasar por alto vulnerabilidades.
• Sus usuarios están incorporando aplicaciones codificadas con Vibe sin la aprobación del departamento de TI porque la TI en la sombra nunca murió.
• Al tratar cada aplicación como sospechosa, puede diseñar su infraestructura para limitar el impacto de una vulnerabilidad explotada.

¿Cómo reduce el modelo de confianza cero los riesgos de seguridad del código generado por IA?

La arquitectura de confianza cero está diseñada para aplicar una autenticación mejorada a cada intercambio de datos y ubicar a los usuarios y las aplicaciones dentro de segmentos de red estrictamente definidos mediante perímetros definidos por software.

En la práctica, esto significa que cada aplicación, ya sea codificada con Vibe o no, se ubica dentro de su propio perímetro. Este perímetro define las formas en que una aplicación puede interactuar con usuarios, datos y otras aplicaciones. Además, garantiza que los privilegios normales de la aplicación solo incluyan las dependencias específicas que necesita para funcionar.

Esto garantiza que, si una aplicación contiene una vulnerabilidad explotable que es el objetivo de un atacante, la superficie de ataque potencial es mínima. Además, el atacante no podrá moverse lateralmente a otras aplicaciones ni escalar privilegios. Si bien la aplicación codificada con Vibe puede contener más vulnerabilidades, el atacante se limita al acceso más básico.

Recomendaciones para reducir el riesgo

• Desactive Telnet y proteja el acceso remoto. Utilice SSH u otros métodos de administración seguros y restrinja el acceso a redes de confianza o VPN.
• Utilice credenciales seguras y únicas. Elimine las contraseñas predeterminadas y limite el acceso administrativo siempre que sea posible.
• Actualiza el firmware y los núcleos de Linux. Aplica las últimas actualizaciones de seguridad a los dispositivos basados en Linux.
• Segmenta las redes de IoT y OT. Restringe las comunicaciones innecesarias y limita el acceso directo a internet.
• Aísle y reconstruya los dispositivos comprometidos. Desconecte los sistemas afectados, realice un restablecimiento de fábrica o reinstale el sistema operativo, y aplique las actualizaciones de seguridad antes de volver a conectarlos.
• Reemplace los dispositivos que ya no son compatibles. Retire el hardware que ya no puede recibir actualizaciones de seguridad o configurarse de forma segura.

Conoce más en el siguiente video

¿Por qué la seguridad del código generado por IA supone un riesgo empresarial real?

A medida que la IA ha ido ganando terreno en el ámbito laboral, se han producido numerosas brechas de seguridad relacionadas con vulnerabilidades en el código generado por IA:

• Moltbook, una red social con codificación Vibe para agentes de IA, nunca habilitó la seguridad a nivel de fila, exponiendo 1,5 millones de claves API.
• Una farmacia que utilizaba un sitio web con código Vibe expuso los mensajes de los pacientes a través de un formulario de contacto configurado incorrectamente.
• Una aplicación de codificación de ambientes conocida como "Orchids" contenía una vulnerabilidad que permitía a los investigadores de seguridad acceder de forma remota a los puntos finales de los usuarios.
• Los datos de encuestas y ejemplos reales sugieren que muchos desarrolladores utilizan ahora herramientas de IA para escribir código. Mientras tanto, las vulnerabilidades de software pueden tardar años en descubrirse. Por ello, es probable que las vulnerabilidades que hemos visto hasta ahora representen solo la punta del iceberg.

¿Cómo produce vulnerabilidades el código generado por IA?

Los modelos de codificación generados por IA se entrenan con código escrito por humanos. Parte de los datos de entrenamiento contienen vulnerabilidades. Por lo tanto, los modelos de IA pueden replicar estas mismas vulnerabilidades en producción.

La respuesta más extensa es que las herramientas de codificación de IA desconocen sus propias limitaciones. Es posible que al modelo de codificación no se le haya mostrado un ejemplo de cómo debe ser un código seguro en un contexto específico. Cuando un desarrollador le indica al modelo que "codifique este módulo de forma segura", el modelo produce un código que parece plausiblemente seguro, pero que en realidad contiene vulnerabilidades.

Cuando decimos "aparentemente seguro", nos referimos a que el código hace referencia a bibliotecas y utiliza configuraciones de seguridad. Sin embargo, tras un análisis más detallado, se observa que la biblioteca es incorrecta y que las configuraciones de seguridad están mal configuradas. Esto se debe a que la IA genera resultados similares a sus datos de entrenamiento, en lugar de crear algo nuevo.

Es importante señalar que las vulnerabilidades que produce el código generado por IA no son novedosas. Errores como credenciales expuestas, entradas sin validar y autenticación faltante son comunes en el código generado por humanos, por lo que también lo son en el código generado por IA.

¿Es posible detectar vulnerabilidades en aplicaciones codificadas con Vibe?

La buena noticia es que las vulnerabilidades codificadas mediante Vibe son lo suficientemente comunes como para detectarlas con el mismo tipo de pruebas de software y prácticas de desarrollo seguro que se utilizan para identificar errores e inseguridades en el código tradicional. Sin embargo, la mala noticia es que las prácticas de desarrollo seguro podrían ser menos frecuentes de lo que cabría esperar.

Un informe de la Linux Foundation revela que casi un tercio de los desarrolladores desconoce las prácticas de desarrollo seguro. Si bien la mayoría recibe capacitación en seguridad, esto puede tardar hasta cinco años. Además, las investigaciones demuestran que la mayoría de los desarrolladores saben que el código generado por IA que distribuyen probablemente contenga vulnerabilidades . Aproximadamente un tercio de los desarrolladores distribuirá este código de todos modos.

El problema radica en la presión. La codificación Vibe acelera el desarrollo de aplicaciones. Esto significa que una empresa de software competitiva puede lanzar su producto al mercado antes que nadie. Los desarrolladores pueden preocuparse de que las medidas de seguridad ralenticen el desarrollo sin aportar un valor real a los compradores. Por lo tanto, existe un incentivo importante para minimizar las comprobaciones de seguridad antes de que una aplicación entre en producción.

¿Cómo pueden los compradores de software proteger las aplicaciones codificadas con Vibe?

Los compradores de software deben asumir que algunos componentes de las nuevas aplicaciones que utilicen en 2026 podrían haber sido codificados con Vibe. Esto no significa que contengan vulnerabilidades por defecto, sino que deben tomar medidas para limitar las consecuencias de cualquier aplicación que pueda contener un error de codificación explotable. En otras palabras, deben adoptar protocolos de seguridad de confianza cero.

La seguridad de confianza cero surgió antes de la IA, partiendo de la premisa de que cada usuario y aplicación era potencialmente vulnerable. En la era de la IA, podemos asumir que cada aplicación está potencialmente comprometida mediante código Vibe, y que cada aplicación con código Vibe posee vulnerabilidades explotables.

Puedes examinar rigurosamente cada aplicación de tu infraestructura para detectar estas vulnerabilidades, pero:

• Esto requiere un tiempo del que no dispones.
• Incluso la revisión más exhaustiva puede pasar por alto vulnerabilidades.
• Sus usuarios están incorporando aplicaciones codificadas con Vibe sin la aprobación del departamento de TI porque la TI en la sombra nunca murió.
• Al tratar cada aplicación como sospechosa, puede diseñar su infraestructura para limitar el impacto de una vulnerabilidad explotada.

¿Cómo reduce el modelo de confianza cero los riesgos de seguridad del código generado por IA?

La arquitectura de confianza cero está diseñada para aplicar una autenticación mejorada a cada intercambio de datos y ubicar a los usuarios y las aplicaciones dentro de segmentos de red estrictamente definidos mediante perímetros definidos por software.

En la práctica, esto significa que cada aplicación, ya sea codificada con Vibe o no, se ubica dentro de su propio perímetro. Este perímetro define las formas en que una aplicación puede interactuar con usuarios, datos y otras aplicaciones. Además, garantiza que los privilegios normales de la aplicación solo incluyan las dependencias específicas que necesita para funcionar.

Esto garantiza que, si una aplicación contiene una vulnerabilidad explotable que es el objetivo de un atacante, la superficie de ataque potencial es mínima. Además, el atacante no podrá moverse lateralmente a otras aplicaciones ni escalar privilegios. Si bien la aplicación codificada con Vibe puede contener más vulnerabilidades, el atacante se limita al acceso más básico.

Zero trust y su apoyo a las organizaciones

La seguridad de confianza cero puede ayudar a reducir el riesgo al limitar el acceso de cada aplicación, exigir la verificación de la identidad en cada intercambio y contener el impacto de una vulnerabilidad explotada con éxito.

Los compradores de software deben asumir que las nuevas aplicaciones pueden incluir componentes generados por IA y prever la posibilidad de errores de codificación que puedan ser explotados.

La programación basada en la dinámica del entorno puede acelerar el desarrollo, pero la presión por lanzar los productos rápidamente puede llevar a los equipos a minimizar las comprobaciones de seguridad antes de que las aplicaciones lleguen a producción.

Conoce más en el siguiente video

¿Cuál es la amenaza?

Este problema afecta al comportamiento de transferencia de archivos en las sesiones de Soporte y Acceso Remoto de ScreenConnect y podría exponer a las organizaciones a riesgos a través de la funcionalidad de transferencia de archivos para técnicos de la plataforma. Si bien ConnectWise no ha revelado detalles técnicos sobre la causa raíz, ha proporcionado recomendaciones provisionales para reducir la exposición. En concreto, las organizaciones deben eliminar los permisos de transferencia de archivos de los roles de técnico hasta que se publique una solución definitiva.

¿Por qué es digno de mención?

Las plataformas de administración remota, como ScreenConnect, suelen tener acceso privilegiado a múltiples puntos finales y entornos de clientes. En consecuencia, las vulnerabilidades relacionadas con el movimiento de archivos pueden generar importantes riesgos de seguridad.

ConnectWise también señala que los ciberdelincuentes ya habían atacado vulnerabilidades de ScreenConnect, incluyendo campañas vinculadas a operadores de ransomware y grupos patrocinados por estados. Además, Shadowserver rastrea cerca de 6000 instancias de ScreenConnect expuestas a internet, lo que aumenta el potencial de explotación oportunista si los permisos de transferencia de archivos permanecen habilitados.

¿Cuál es la exposición o el riesgo?

Las organizaciones se exponen a riesgos cuando los roles de técnico de ScreenConnect conservan permisos de transferencia de archivos para las sesiones de Soporte y Acceso. Los ciberdelincuentes podrían aprovechar estos permisos para transferir archivos maliciosos o confidenciales durante las sesiones remotas.

Hasta que ConnectWise publique una solución definitiva, las organizaciones se enfrentan a un mayor riesgo de movimiento no autorizado de archivos y posteriores ataques informáticos en entornos gestionados. El riesgo es especialmente alto en entornos donde las cuentas de técnico tienen amplios privilegios.

¿Cuál son las recomendaciones?

Las siguientes recomendaciones son realizadas para reducir el riesgo:

• Implemente de inmediato la solución provisional de ConnectWise: Elimine el permiso TransferFiles, o TransferFilesInSession para roles heredados, de los grupos de sesión pertinentes en Administración > Seguridad > Roles. Aplique los cambios a todos los roles aplicables.
• Revise todas las implementaciones de ScreenConnect: verifique tanto las instancias alojadas en la nube como las locales. Identifique y corrija los roles de técnico que conservan permisos de transferencia de archivos.
• Supervise la actividad sospechosa de transferencia de archivos: revise las acciones administrativas de ScreenConnect e investigue las transferencias de archivos recientes de las sesiones de Soporte y Acceso para detectar comportamientos inusuales, especialmente en entornos con altos privilegios.
• Prepárese para implementar la solución permanente: consulte el aviso de ConnectWise para obtener información actualizada, detalles sobre las vulnerabilidades CVE y versiones parcheadas a medida que estén disponibles.

• Minimice las interrupciones operativas: Identifique los flujos de trabajo de los técnicos que dependen de la transferencia de herramientas, scripts, registros o paquetes. Establezca alternativas aprobadas hasta que ConnectWise publique y valide una solución definitiva.

Hoy ese escenario está cambiando.

Cuando los ciberdelincuentes ponen su atención en una infraestructura crítica, las consecuencias pueden salir rápidamente del mundo digital y convertirse en un problema para toda una comunidad. Un sistema comprometido ya no representa únicamente archivos inaccesibles o pérdidas económicas. Puede afectar el suministro de agua, la generación de energía, los procesos industriales o servicios esenciales de los que dependen miles de personas.

Las recientes amenazas dirigidas contra sistemas de agua y tecnologías de control industrial vuelven a poner este riesgo sobre la mesa. Una presunta campaña cibernética iraní que habría afectado sistemas hídricos en distintos estados de Estados Unidos, junto con nuevas advertencias sobre amenazas dirigidas a controladores lógicos programables “PLC” utilizados en entornos industriales, demuestran que la infraestructura crítica continúa siendo un objetivo atractivo.

Y hay un elemento que vuelve este escenario todavía más preocupante: la tecnología que controla muchos de estos servicios fueron diseñados en una época muy diferente.

El correo que ves no siempre es todo lo que contiene

Aquí es donde aparece una técnica conocida como text salting, una estrategia que aprovecha una característica fundamental de los correos electrónicos: lo que el usuario observa en pantalla no necesariamente representa todo lo que existe dentro del mensaje.

Un atacante puede construir un correo que, para una persona, parece completamente normal. Puede mostrar una promoción, una notificación de una cuenta, una supuesta recompensa o cualquier otro mensaje diseñado para provocar una acción. Sin embargo, dentro del código HTML puede incorporar grandes cantidades de texto adicional que permanecen ocultas para el destinatario. Ese contenido puede utilizar palabras y frases aparentemente inocentes con el objetivo de modificar la interpretación que realizan los sistemas automatizados.

La diferencia puede parecer pequeña, pero tiene implicaciones importantes. El usuario ve un mensaje; el sistema de seguridad analiza una estructura mucho más compleja. Si esa estructura está deliberadamente manipulada, el atacante puede intentar alterar las señales que utiliza una herramienta para determinar si el correo es legítimo o malicioso.

El concepto no es completamente nuevo. Durante años, los atacantes han utilizado diferentes técnicas de ofuscación para esconder contenido, modificar patrones o dificultar el trabajo de los filtros. Lo que cambia ahora es el escenario en el que se utilizan. Cuando los sistemas de defensa incorporan inteligencia artificial y modelos capaces de interpretar lenguaje, los atacantes tienen un nuevo objetivo: influir en la información que recibe el modelo para intentar influir en su decisión.