Supuesta violación: la evolución de la seguridad ofensiva...

El propósito de este post es singular: informarle a usted (inocente lector, cliente o competidor) sobre cómo TrustedSec está tratando de satisfacer las necesidades específicas de la industria que han crecido con el tiempo en términos de sospecha de pruebas de intrusión. En nuestro pequeño mundo infoseguro de flujos ubicuos e incesantes de información altamente técnica, este post toma un camino más contemplativo, y esperemos que humorístico, hasta su conclusión. Nada de relleno GPT, ni siquiera memes, sólo una mirada sensata y teñida de chanchullos a la industria ofensiva desde la perspectiva de un chico de campo con una conexión a Internet excesivamente rápida y una afición por las peonzas mentales.

Recomiendo leerlo con su bebida favorita, pero para los impacientes, cubro los detalles de nuestro supuesto modelo de pruebas de violación en la sección "Escenarios".

Un paseo salado por los recuerdos

Desde hace algún tiempo, las pruebas de red se dividen en dos categorías principales: externas e internas. Las pruebas externas suelen limitarse a la dirección IP/nombre de host y se ejecutan en una caja negra (sin credenciales, sin acceso remoto, búsquelo usted mismo), y las pruebas internas suelen ejecutarse desde un dispositivo de implementación de red entregado al cliente. Este dispositivo suele consistir en una distribución Linux, por ejemplo Kali, Ubuntu o BlackArch, y establece un túnel SSH inverso a la sede central, que el probador utiliza para iniciar sesión y ejecutar la prueba.

Estos conceptos son caminos trillados con los que la mayoría de las organizaciones se sienten razonablemente cómodas en 2024. Los temores de interrupciones importantes apenas se han materializado, aunque hay un lote ocasional de cuentas bloqueadas y alguien lo suficientemente estúpido como para juguetear con la configuración NC en Active Directory, pero en general la mayor sombra sobre la industria de la seguridad ofensiva son las empresas de pruebas que no prueban en absoluto, sino que simplemente imprimen los resultados de nmap/Nessus en un informe. Todavía oigo hablar de esto y es tan chocante hoy como lo era hace 10 años. Añade una dosis extra de asco para estas empresas, porque antes de la llegada de los controles basados en el comportamiento, el pentesting no sólo era fácil para los que conocían las artes oscuras, sino que también era una forma de mejorar la seguridad de los datos. glorioso.

Durante años, los equipos ofensivos se habían basado en técnicas de DA-by-lunch como Responder, Mimikatz y PowerSploit. Todas las conferencias impartidas por los miembros del Equipo Rojo insistían en la necesidad de respetar los "principios básicos" (el menor acceso posible, sistemas parcheados, buenos fundamentos de seguridad, etc.). ad nauseumhasta el punto de que se estigmatiza a los defensores con titulares en Twitter como "Ni siquiera podemos jugar con las reglas básicas, ¿cómo se supone que vamos a hacerlo? ??' Los defensores estaban inundados en lágrimas y culpabilidad, condenados a interminables revelaciones de lagunas, pesadillas de vacaciones y burlas de "McAfee LOL" por parte del equipo rojo, mientras un flujo interminable de hashdumps aparecía en la pantalla en una neblina de shellibrations infundidos por Red Bull. Pero el júbilo duró poco.

Para no quedarse atrás, la defensa hizo lo que siempre hace, y a veces hace bien: adaptarse. Como si salieran de la timidez de la adolescencia, los defensores se dieron cuenta de que el VA no iba a salvarles y empezaron a ingerir cantidades masivas de periódicos internos, decididos a aumentar la visibilidad allí donde importaba (en aquel momento, eran los puntos finales). La industria despertó en masa a códigos de eventos importantes como 4688, 4662 y 5145, aprendiendo que los valiosos datos que habían estado buscando todo este tiempo sólo estaban esperando el GPO adecuado para activarlos.

Se generaron gigabytes y más de registros, todos bien escondidos en SIEM comerciales y de código abierto como Splunk, Graylog y ELK Stack. Entraron en escena los compromisos de Purple Team, que mejoraron y perfeccionaron las detecciones, poniendo por primera vez en manos del SOC cuadros de mando de alertas de alta calidad. Y los SOC, al menos los que no suprimieron estos cuadros de mando porque nunca hicieron nada, disfrutaron de un sueño más tranquilo.

Pero los equipos de defensa interna no eran los únicos que prestaban atención. Los proveedores también se habían dado cuenta de que las herramientas de seguridad existentes eran ineficaces para detener... bueno, prácticamente todo, dejando un hueco en el mercado de herramientas que realmente funcionaran para detectar y prevenir ataques reales (y no sólo para "detener a los mimikatz" lol). Se lanzaron nuevos productos que, por primera vez en la historia, parecían cumplir el último sueño de la infoseguridad corporativa: una buena seguridad que se pudiera comprar. La EDR irrumpió en el mercado con una fuerza increíble y fue acogida con entusiasmo en pocos años. La gran mayoría de los clientes contra los que dirigimos equipos rojos utilizan ahora esencialmente uno de los dos sistemas de control de puntos finales: CrowdStrike o Microsoft. Ambos son eficaces. Por fin, los defensores se han dado cuenta de lo que siempre ha sido cierto: el campo de batalla les pertenece.

El equipo rojo, acostumbrado durante años a que le entregaran sus contraseñas (literalmente en el caso del CCDC, lo que no ayudó a nuestros egos), se vio acorralado y comenzó torpemente a reaprender el arte de la curiosidad, aletargado ante el incesante suministro de registros de los intervinientes. Poco acostumbrado a ser detectado, el equipo rojo puso en marcha el "protocolo fantasma" y empezó a ocultar los TTP en las redes sociales. Los enfrentamientos entre AdSim y el equipo rojo cobraron protagonismo, lo que dio al equipo rojo más tiempo para adaptarse a las defensas e investigar nuevos métodos de ataque. Aunque hirientes para el ego, las enormes mejoras en las defensas han obligado a los principales equipos rojos a realizar importantes inversiones en sus conocimientos y herramientas internas y, como resultado, a utilizarlas para mejorar las defensas de sus clientes de forma muy eficaz. Las organizaciones que han aprovechado esta situación se han beneficiado de una mejora significativa de su postura de seguridad.

A pesar de toda la palabrería sobre los TSO y los mezquinos pero divertidísimos debates sobre los C2 y términos como "bypass", la metodología rojo/azul ha demostrado su eficacia una y otra vez. Mejora el equipo rojo y mejorarás el equipo azul. Casi al mismo tiempo, los defensores se dieron cuenta de que el equipo rojo tenía realmente en mente sus mejores intereses y que la adversidad fabricada era realmente algo bueno. Los equipos rojos llegaron a la conclusión, con razón, de que una buena defensa es increíble... divertido...), y que si prestan atención, los defensores ayudarán al equipo rojo a desarrollar nuevas técnicas. ¿Cómo podemos continuar este ciclo de mejora?

Para seguir el ritmo de unas defensas que parecen mejorar día a día, los equipos rojos han respondido con el primer paso lógico: añadir más tiempo de compromiso. Esto funciona hasta cierto punto, y algunos clientes se comprometerán gustosamente a que una misión de los equipos rojos dure varios meses, priorizando el realismo y el sigilo por encima de todo. Pero el sigilo requiere tiempo, y no todo el mundo puede permitirse los movimientos más bajos y lentos de una red. La ventaja temporal sigue viéndose mermada por las detecciones basadas en el comportamiento, que ahora miden la actividad de los usuarios en semanas y meses. Los equipos rojos necesitaban una forma de ofrecer un valor específico sin arruinarse.

Entrar en la supuesta brecha

Las evaluaciones de violación supuesta (AB) están diseñadas para imitar un escenario de amenaza en el que un atacante ya ha obtenido acceso a la red interna de una forma u otra. Pero, ¿de qué escenarios estamos hablando? ¿No es eso lo que ya hace un pentest interno? Sí, en cierto modo. El escenario de amenaza más cercano que imita un pentest interno estándar es una intrusión física, pero incluso en ese caso el énfasis se pone en la cobertura. En otras palabras, se trata de cuántas vías de escalada vulnerables pueden descubrirse y qué vulnerabilidades se han documentado a lo largo del camino que puedan poner fin a esas vías si se parchean. Haga todo esto lo más rápido posible, apuntando a tantos sistemas como sea posible, y luego entregue los resultados con precisión y profesionalidad.

La postura de seguridad de una empresa puede ir desde lejos, y muchos lo han hecho, simplemente corrigiendo los resultados de su pentest. Irónicamente, la mayoría de los grandes pentesters que conozco subestiman seriamente sus propias habilidades. Tal vez esto sea algo bueno (al menos hasta cierto punto), ya que el rendimiento de un pentest asociado a una moralidad descontrolada puede derivar fácilmente en una actividad delictiva, como aludió el líder de LockBit en una reunión en 2022 entrevista con vx-underground.

Mis disculpas por esta digresión. Entonces, ¿cuál es la diferencia material entre AB y pentesting? En resumen, y ya he aludido a ello, el pentesting es cobertura-mientras que los AB se basan en la cobertura escenario-sobre la base de un escenario. ¿Son los AB una "evolución" de los pentests? No exactamente. Las pruebas de penetración seguirán siendo útiles mientras existan entornos empresariales. Sin embargo, como hemos visto anteriormente, los controles han mejorado considerablemente, obligando a las tiendas de ofensivas a adaptar sus servicios. Incluso las empresas que siguen teniendo usuarios no informáticos con derechos de administración local pueden comprar un EDR y beneficiarse de una mejora inmediata de la seguridad de sus puntos de acceso, y por tanto de la frustración para el Equipo Rojo. Esto significa simplemente que los Red Teams necesitan restringir el propósito de las intrusiones, es decir, las pruebas basadas en escenarios, para las organizaciones maduras.

En TrustedSec, hemos identificado varios escenarios de amenazas:

• Violación del perímetro
• Trabajador descontento/interior malintencionado
• Ataque de ingeniería social con éxito
• Abuso de confianza
• Robo físico o pérdida de un dispositivo interno
• Intrusión física

Estas son, por supuesto, categorías de compromiso de alto nivel, y se supone que lo son. También se solapan. Por ejemplo, es fácil imaginar un ataque exitoso de ingeniería social que conduzca al uso indebido de credenciales. Los equipos rojos hacen esto todo el tiempo. Dicho esto, tuvimos que trazar ciertas líneas, e intentamos hacerlo de la forma más limpia posible.

¿Y el ransomware? Oigo la pregunta alto y claro, y a menudo los clientes me hacen preguntas similares. ¿No es el ransomware un escenario de amenaza válido? La respuesta directa es: no exactamente. Sí, el ransomware es una amenaza de alto impacto. resultado de un compromiso, pero no es el comprometida. La pérdida de datos también es un resultado potencial, pero no constituye una amenaza. Es importante categorizar nuestros términos y lo que queremos decir con ellos. Además, los requisitos para desplegar ransomware son similares a los objetivos de elevación estándar para un ejercicio AB o Red Team. Antes de poder desplegar ransomware a gran escala, el atacante debe tener privilegios elevados en los hosts objetivo. En resumen, solucione las rutas de escalada descubiertas durante un ejercicio AB y "contendrá la explosión" de un despliegue de ransomware. Pídele a tu amigable Red Teamer que descubra las rutas relacionadas con los sistemas de copia de seguridad. xD

Escenarios

TrustedSec ha desarrollado siete escenarios AB para cubrir estos escenarios de amenazas. Si observa la tabla que aparece a continuación, es posible que piense que algunos escenarios no forman parte de su modelo de amenazas. Esto es perfectamente normal (y discutible), ya que el objetivo es proporcionar diferentes tipos de pruebas dirigidas que se solaparán con tu modelo de amenazas.

1) Compromiso de firma única

• Escenario(s) de amenazaEmpleado descontento, ataque exitoso de ingeniería social (SE), abuso de identidad
• DescripciónTrustedSec: simulando el compromiso de una cuenta de O365, TrustedSec intentará acceder a servicios de terceros adjuntos al inquilino de O365 mediante SSO, exfiltrando y analizando la información accesible. El análisis de la red interna, si se lleva a cabo, no se realiza.
• Duración mínima1 semana
• Requisitos del cliente:
  • Información sobre el portal SSO (Okta, Ping, O365) al que dirigirse.
  • Credenciales válidas que representan a un usuario comprometido. Para obtener el máximo valor, TrustedSec recomienda utilizar un empleado en activo (preferido) o una cuenta que se haya dado de baja recientemente con derechos de acceso intactos.
  • Punto de contacto para proporcionar acceso MFA en caso necesario.

2) Pivote de red

• Escenario(s) de amenazaViolación con éxito del perímetro de la red, trabajador descontento, ataque con éxito a la ES, abuso de poder, etc.
• DescripciónTrustedSec trabajará con un empleado proporcionado por el cliente para simular el compromiso que puede lograrse mediante un ataque exitoso de ingeniería social. Utilizando infraestructura y cargas útiles autorizadas, se establece el C2 de la máquina de un usuario y se utiliza para atacar la red en busca de un único objetivo posterior a la explotación. La misión se centra en las actividades posteriores a la explotación y en la detección, no en pruebas evasivas de control de puntos finales.
• Duración mínima2 semanas
• Requisitos del cliente:
  • Uno de los siguientes :
    • Un empleado interno (preferiblemente no informático) que actuará como endpoint comprometido. TrustedSec trabajará con el empleado para establecer un C2 no intrusivo.
    • Un portátil y/o imagen Citrix VDI con credenciales de dominio (nombre de usuario/contraseña) con acceso que refleje un rol empresarial existente.
  • TrustedSec enviará por adelantado la carga útil y los detalles de la infraestructura para los usuarios autorizados.

3) Compromiso y pivotamiento de los puntos finales

• Escenario(s) de amenazaViolación con éxito del perímetro de la red, trabajador descontento, ataque con éxito a la ES, abuso de poder, etc.
• DescripciónTrustedSec trabajará con un empleado proporcionado por el cliente para simular el compromiso que puede lograrse mediante un ataque exitoso de ingeniería social. Utilizando una infraestructura personalizada y cargas útiles evasivas, se establece el C2 de la máquina del usuario y se utiliza para atacar la red de forma sigilosa y selectiva para lograr objetivos posteriores a la explotación.
• Duración mínima3 semanas
• Requisitos del cliente:
  • Un empleado interno (preferiblemente no informático) actuará como el endpoint comprometido. *TrustedSec trabajará con el empleado para establecer un C2 no intrusivo.
  • El cliente puede elegir dos objetivos (aplicación, servidor, dirección IP, nivel de acceso).

*Nota: para esta evaluación no se admite un "portátil de repuesto" o una "imagen dorada" con credenciales de dominio genéricas, ya que los atacantes dependen en gran medida del uso diario para conocer la situación.

4) Compromiso del perímetro

• Escenario(s) de amenazaViolación exitosa del perímetro de la red, ataque SE exitoso
• DescripciónTrustedSec: Simulando el compromiso de una aplicación web externa, TrustedSec adquiere el C2 de un servidor web o servidor de base de datos designado (ataque de inyección SQL exitoso) e intenta violar una aplicación o entorno de red objetivo desde una variedad de perspectivas. Esto puede adoptar diversas formas, como un shell web o un C2 completo.
• Duración mínima3 semanas
• Requisitos del cliente:
  • La ejecución de un implante en un servidor web o en un servidor de base de datos elegido en el contexto de la cuenta de la aplicación.
  • Dependiendo de las reglas del cortafuegos, puede ser necesaria una anulación para autorizar el tráfico saliente necesario.

5) DevOps

• Escenario(s) de amenazaEmpleado descontento, abuso de confianza
• DescripciónUtilizando un portátil proporcionado por el cliente, TrustedSec se conectará a la red interna y buscará vulnerabilidades relacionadas con las operaciones DevOps, como privilegios de repositorio, credenciales codificadas y acceso inadecuado a la infraestructura. Los ataques están muy dirigidos al entorno DevOps del cliente y a la infraestructura correspondiente.
• Duración mínima3 semanas
• Requisitos del cliente:
  • Una cuenta con privilegios de desarrollador
  • Ordenador portátil con versión estándar para desarrolladores
  • Acceso remoto al entorno DevOps

6) Compromiso de los puestos de trabajo

• Escenario(s) de amenazaEmpleado descontento, robo físico o pérdida de material
• DescripciónTrustedSec probará una estación de trabajo física o una imagen Citrix VDI en busca de una variedad de configuraciones erróneas de seguridad, incluyendo vulnerabilidades de hardware y software cuando corresponda. La explotación se limita generalmente a la máquina local y no cruza los límites de la red. Cualquier hardware proporcionado puede ser desmontado a discreción de TrustedSec.
• Duración mínima2 semanas
• Requisitos del cliente:
  • Portátil con acceso estándar y/o Citrix VDI
  • Credenciales de inicio de sesión para no administradores
  • (Opcional) Acceso remoto a la red de la empresa

7) Violación física

• Escenario(s) de amenazaEmpleado descontento, intrusión física exitosa...
• DescripciónTrustedSec: TrustedSec simulará un compromiso físico exitoso enviando un dispositivo especial que puede evadir la mayoría de los sistemas NAC y no requiere exención de firewall saliente. Destinado a ser un dispositivo realmente sigiloso, TrustedSec utilizará la conexión correspondiente para comprometer la red utilizando técnicas estándar.
• Duración mínima2 semanas
• Requisitos del cliente:
  • Una máquina física con conectividad de red interna persistente
  • Proximidad al servicio celular LTE

Conclusión

Espero que este artículo te haya hecho reflexionar sobre tu propio modelo de amenazas y cómo podría aplicarse a tus próximas rondas de pruebas ofensivas, y si te he hecho sonreír por el camino, eso es un plus de felicidad. Si formas parte de un equipo interno, puedes adaptar estos escenarios a tu conveniencia, ya que sin duda dispones de más tiempo y capacidad que un tercero.

Y si me has seguido todo este tiempo, te mereces un paseo, o un sorbo, como mejor te parezca.

Por ti.