Search Results for: cloud

Seguridad en Cloud computing

He decidido poner el término Cloud computing en el titulo del post para tener mas visitas, ya que es un termino de moda, pero si me disculpan la pequeña “trampa”, en su lugar voy a hablar de la seguridad en Infraestructuras compartidas, que es un tema tanto o más interesante en seguridad.

Cuando hablamos de Infraestructuras compartidas nos referimos a la serie de infraestructuras TI que en cualquier organización son compartidas por diversos proyectos. Por ejemplo es habitual que se comparta la infraestructura de red, el almacenamiento en una cabina de discos, o los mismos servidores físicos mediante virtualización; si es un proveedor de servicios el que ofrece la infraestructura, estos elementos estarán compartidos además entre diversos clientes que en si mismo son organizaciones diferentes (vamos, el servicio de hosting de toda la vida).

Así pues, vamos a comentar diversas vulnerabilidades que con las medidas adecuadas están contempladas y en teoría resueltas, pero que son en todo caso posibles vulnerabilidades que pueden aparecer cuando se comparten infraestructuras.

Infraestructura de red compartida: No es difícil imaginar un escenario donde tenemos varios servidores conectados a la misma infraestructura de red, donde, si todo se configura bien no deberían haber problemas, pero si se configura mal, pueden pasar entre otras las siguientes cosas: (1)

  • Sniffing: Un equipo puede ver el trafico del equipo de al lado; esto puede pasar si están conectados al mismo switch y no se han tomado las necesarias precauciones (arp posisoning).
  • DOS: Al estar un equipo próximo a otro, puede atacarlo con un gran ancho de banda o un gran numero de conexiones.
  • Interceptar/sustituir: Es posible que un equipo pueda suplantar a otro (p.e. cambiando la IP) para interceptar el trafico o suplantar respuestas.
  • Atacar: Es posible que al compartir una misma infraestructura de red, desde dentro de la misma red (por ejemplo dentro de la misma DMZ) los equipos puedan atacar a los otros, teniendo mas visibilidad de servicios que desde el exterior están cerrados. Una descripción de cómo hacer esto pueden encontrarla aquí.

¿Están las infraestructuras de red compartidas convenientemente independizadas en los servicios de hosting y de Cloud?

Infraestructura de disco compartida: En cualquier infraestructura TI, es habitual que se disponga de una cabina de disco (SAN/NAS) a la que se conectan todos los servidores (desde servidores internos, hasta servidores de la DMZ)(2)

  • Acceso a datos (no autorizados): Técnicamente es posible que un servidor se conecte al disco de otro servidor si comparte cabina, con lo que podría leer o incluso alterar los datos. Las cabinas de disco normalmente limitan qué servidor puede conectar a qué parte de disco, basándose en la direccion “MAC” (se llama WWN) de la tarjeta. ¿Podría un hacker cambiar esa dirección? ¿Tenemos hard-zoning para evitar este ataque? Aun no he visto ninguna instalación en que se configure hard-zoning ya que es bastante mas incómodo. Si piensa que es muy raro que todos los servidores tengan acceso a los mismos discos, piense en todos sus servidores host de virtualizacion que pueden acceder a todos los discos del cluster.
  • DOS/Carga: ¿Qué pasa si un servidor monopoliza todos los recursos?
  • Acceso a datos borrados: ¿Qué pasa si montamos una unidad de disco en el servidor de un cliente y luego la conectamos a otro servidor de otro cliente? ¿Si leemos el disco vemos los datos del otro cliente? Muchos me diréis que es una posibilidad muy extraña ya que las cabinas de discos limpian las LUNs antes de asignarlas, pero esto “se le paso” a Amazon Ec2.

¿Están las infraestructuras de almacenamiento convenientemente independizadas en los servicios de hosting y de Cloud? (3)

  • Virtualización: Cualquier entorno TI de hoy en día dispone de servidores virtualizados, ya que es una de la manera mas efectivas de compartir recursos, garantizar la disponibilidad, ahorrar energía y muchas otras cosas. Numerosos sistemas Cloud (IAAS) están basados fundamentalmente en sistemas virtualizados, con APIs de autoprovisionamiento. Veamos algunos de los ataques que se pueden realizar en este tipo de entornos.
    • Ataques de guest a host: Ya han aparecido vulnerabilidades mediante las cuales un guest ha podido ejecutar código en el espacio del host, y por lo tanto desde un servidor virtual es posible atacar a otras maquinas virtuales. Véase este enlace para más detalles.
    • Consolas remotas compartidas (el “control panel” del cloud): Si tenemos un sistema de virtualización compartido, al cual accedemos desde una consola de gestión remota a través de Internet, ¿qué pasa si esta consola de gestión tiene alguna vulnerabilidad y alguien coge el control? Pueden haber muchos posibles problemas, desde vulnerabilidades de la aplicación de gestión remota (XSS para robo de sesión sería un ataque viable) a posibles pérdidas de credenciales. La autenticación de estos sistemas por ahora es simple y sin dispositivos robustos. Otro vector de ataque pueden ser las APIs de gestión de ofrecidas por los servicios de cloud, ya que mediante estas APIs se pueden crear o destruir servidores; ¿seguro que no hay vulnerabilidades mediante las cuales se puedan crear o destruir servidores de otro cliente?
    • Carga/DOS/QOS: ¿Qué pasa si un cliente monopoliza todos los recursos?
    • Vulnerabilidades del host (desde fuera, o desde los guests): El host es otro sistema que puede ser atacado, bien desde donde sea accesible (consola de gestión p.e.) o bien desde los propios guest que debido a alguna vulnerabilidad son capaces de coger control de host. Dicho de otra forma, aunque uno pueda tener su servidor web y sus aplicativos securizados, quizá el host que los alberga no lo está.
  • Servidores web/servidores de aplicaciones compartidos: Es habitual compartir el mismo servidor de aplicaciones entre diversos proyectos, pero hay que contemplar los problemas que nos podemos encontrar:(4)
    • Tienen acceso al mismo almacenamiento.
    • Son el mismo usuario de maquina/BBDD/memoria.
    • QOS: Puede un usuario degradar el rendimiento de todos los usuarios.

    Un ejemplo de estos servicios en la nube son: Windows azure o Google Application Engine.

¿Están las infraestructuras de virtualización convenientemente independizadas en los servicios de hosting y de Cloud?

Hosting/Aplicaciones SAAS compartidas: Dentro de lo que está tan de moda del cloud, también se incluyen de alguna manera las aplicaciones compartidas modelo cloud (SAAS). En el fondo, éste es el modelo mas antiguo de hosting, en el que las aplicaciones originales eran servidores web, servidores de correo compartidos entre diversos clientes. Hoy en día se ofrecen aplicaciones mas elaboradas que ofrecen más valor a las organizaciones. Veamos qué problemas nos podemos encontrar en estos modelos.

Imagínese que comparte aplicación entre “perfiles” o clientes. Es posible que dos usuarios de la misma aplicación, por algún error de diseño de ésta, tengan acceso a lectura o modificación de otro usuario. Por ejemplo, recordarán que hace poco sucedió que un usuario de facebook podía ver cualquier conversación del chat de otro. Así pues, si usamos de manera compartida una “aplicación” SAAS, nos podemos encontrar con posibles problemas si no ésta no está bien implementada. ¿Podría pasar que en nuestro CRM en SAAS por un error de programación pudiéramos ver los clientes de otra empresa también albergada en este SAAS? Facebook tuvo una vulnerabilidad con la que podías ver los chats de otros usuarios.

¿Están las aplicaciones convenientemente independizadas en los servicios de hosting y de Cloud? (5)

Mira por dónde, sin quererlo, he acabado hablando de Cloud Computing, nada nuevo respecto a lo que ya conocemos en cuanto a infraestructuras compartidas, pero sin duda una novedad en cuanto a que está todo junto, con las ventajas que esto aporta, pero con el añadido que hay que considerarlo todo conjuntamente.

Por repasar los tipos de Cloud existentes:

  • IAAS, Infraestructure as a service: básicamente podríamos decir que tenemos una macroplataforma virtualizada bajo demanda (1)(2)(3).
  • PAAS, Platform as a Service: tenemos una especie de servidor de aplicaciones distribuido y autoescalable (4).
  • SAAS, Software as a Service: tenemos una aplicación general la cual nos da servicio (5).

En este post hemos revisado algunas vulnerabilidades desde un punto de vista técnico que aparecen si compartimos infraestructuras. Desde el punto de vista de control sobre los servicios externalizados y concentrados en datacenters de megacorporaciones también hay mucho que hablar, y por otro lado los proveedores de sistemas virtuales están redefiniendo sus productos haciendo que cada vez se parezcan mas a una nube “privada” en cuanto a que se dispone de unas infraestructuras compartidas autogestionadas. Todas la posibles vulnerabilidades mencionadas sólo son posibles puntos de fallo por donde aparecerán vulnerabilidades, que aunque en principio ya están contempladas y cubiertas, debemos contar que irán apareciendo nuevas vulnerabilidades causadas por compartir infraestructura. Si dicha infraestructura es sólo compartida entre proyectos internos de la organización los riesgos son unos, pero si la infraestructura es compartida con no sabemos quién, y disponible en Internet los riesgos son mayores. Esto es lo que hay que saber valorar.

A pesar de ello, los servicios en Cloud son la evolución lógica de hosting (infraestructuras compartidas de toda la vida). Todo lo que tuviera sentido en ese entorno ahora lo puede tener en la nube; en todo caso los proyectos que necesitan una grandísima escalabilidad normalmente están asociados a accesos desde Internet, en cuyo caso la nube tiene todo el sentido del mundo, ya que nos permite acceder a proveedores con grandes capacidades de almacenamiento, ancho de banda y servidores. Es más, me atrevería a apostar que los proveedores serios de Cloud sí tienen en mente que todos los recursos compartidos deben estar independizados, y probablemente sean más conscientes de estos riesgos que los provedores de hosting más tradicionales, con aproximaciones más “ligeras” al Cloud.

Dicho esto, pasen un buen fin de semana, y ¡¡nos vemos en la nube!!

¿Qué pasa con la Seguridad y el Cloud Computing?

Algunos tuvimos la oportunidad de celebrar el pasado día mundial de Internet con una mesa redonda sobre Cloud Computing en la que participaron ocho personalidades de distintas multinacionales, de las que solo una de ellas era española. La mesa redonda estuvo moderada por la Consejera de Justicia y Administraciones Públicas de la Generalitat Valenciana y la verdad es que fue bastante interesante, e incluso yo diría que pertinente y adecuada en los tiempos que corren, tanto por la forma, como por el fondo.

Cloud es una moda. Todos estaban de acuerdo en que ya no es una utopía. Es una realidad, pero una realidad de moda. También parecían estar todos de acuerdo que una de las grandes ventajas que tiene este nuevo paradigma (así lo presentan algunos) es la reducción de costes. “Es una nueva forma de hacer outsourcing en un entorno global y virtual”, decían algunos. “Es una forma clara de reducir costes e incluso de incrementar la productividad”, decían otros. La verdad es que en medio de todas estas afirmaciones, vertidas incluso en ocasiones con pasión, yo me preguntaba si no será este otro de esos conceptos que usan las grandes firmas para seguir haciendo negocio con cosas que el resto de los mortales no acaban de entender.

En mi humilde opinión Cloud Computing es un concepto muy interesante que seguro ya tiene y tendrá aplicaciones en diversos campos, ahora bien, la solución a todos los problemas no es el Cloud Computing, ni siquiera es un modelo de gestión o una tecnología disruptiva equivalente, como algunos defienden, a la aparición de Internet. Para empezar, porque es un modelo que ya funciona en la red desde hace tiempo y porque lo único que se ha hecho es bautizarlo con un nombre pegadizo que estoy seguro moverá cifras millonarias en los próximos años.

Se habla de la consolidación de unos cuantos Data Centers gigantes a nivel mundial como proveedores de servicios en la nube y su connivencia con unos cuantos operadores y algunos proveedores de aplicaciones en la misma nube. Se habla del traslado de cantidades ingentes de información a la nube, de información de todo tipo y color, se habla de los inmensos beneficios que le puede suponer para una empresa de tamaño medio hacer uso de este modelo, e incluso, alguno se atreve a poner un ejemplo dónde los ahorros de costes superan el 50%, citando incluso la organización en cuestión.

Yo no sé si esto será exacto o si será una “realidad aumentada”, pero ¿alguien se ha parado a pensar lo que realmente significa esto? ¿Alguien se ha parado a pensar en las implicaciones de seguridad que puede tener el traslado indiscriminado del conocimiento de las organizaciones de todo tipo a la nube? ¿Alguien se ha parado a pensar en el riesgo de la concentración de activos y conocimiento para una compañía o para un estado? Si a veces no pueden las organizaciones confiar en sus propios equipos, ¿por qué van a hacerlo en los equipos de terceros de forma masiva e indiscriminada? ¿No creen ustedes que aunque este modelo tiene y va a tener sentido para algún tipo de aplicaciones e información no lo puede tener nunca para otro?

Yo creo que como siempre se han hecho algunos análisis interesados de las virtudes de este concepto y que se han propagado a los cuatro vientos sus ventajas, pero también creo que no se ha contado de la misma forma sus inconvenientes, aunque me consta que si se han analizado. No hay más que ver el estudio que ha publicado recientemente la Cloud Security Alliance (CSA) [PDF] donde tímidamente o superficialmente (como quieran ustedes llamarlo) analizan los principales problemas de seguridad con los que se encuentra el Cloud Computing llevado a sus extremos. Cloud Computing es por tanto una moda con grandes virtudes y con grandes defectos. Si no se desarrolla con sumo cuidado, el mismo concepto es, en sí mismo, una amenaza para la seguridad de las organizaciones. No conté las palabras que se usaron en la mesa redonda pero les aseguro que la palabra Seguridad salió muchas veces y la usaron todos los participantes en la mesa redonda, incluyendo algunos invitados del público. Evidentemente esto quiere decir algo, ¿no creen?

Seguro que seguiremos hablando del recién nacido “Cloud” porque va a dar mucho juego….

GRU: Forest Blizzard – una visita a sus operaciones más interesantes desde el inicio de la guerra con Ucrania

Este artículo marca el inicio de una serie dedicada a explorar los Actores Estados más activos de los últimos años, con el propósito de comprender en profundidad sus operaciones, modus operandi, victimología y otros aspectos clave. En esta primera entrega, analizaremos el clúster Forest Blizzard y algunas de sus operaciones desde el inicio del conflicto entre Rusia y Ucrania en 2022.

El clúster Forest Blizzard – también conocido como APT28 o Fancy Bear – ha sido atribuido de forma colectiva por el Servicio de investigación del Congreso de EEUU a las unidades 26165, 74455 y 54777 del Directorio Principal del Alto Estado Mayor de las Fuerzas Armadas de la Federación de Rusia (GRU). Estas unidades han sido identificadas como responsables de diversas operaciones ofensivas y de campañas de  desinformación. En concreto, la unidad 26165 ha estado implicada en operaciones a entidades políticas estadounidenses, como el Comité Nacional Demócrata junto a otras entidades como el IRA (Internet Research Agency) y el SVR (Servicio de Inteligencia Exterior), mientras que la Unidad 74455 ha realizado ciberataques como el malware NotPetya en 2017, o la liberación de correos electrónicos robados durante las elecciones presidenciales de 2016. Por su parte, la Unidad 54777, conocida como el 72º Centro de Servicios Especiales, se ha focalizado en operaciones psicológicas y campañas de desinformación a gran escala. La siguiente imagen muestra la estructura jerárquica de las organizaciones de inteligencia y sus respectivos clústers, basada en los análisis realizados por múltiples agencias de inteligencia gubernamentales y privadas.

Ilustración 1: Organizaciones de inteligencia con capacidades ciber
[Read more…]

C2: La clave oculta en las operaciones de Red Team

Dentro de un ejercicio de Red Team, el Command and Control (C2) actúa como el engranaje principal dentro de la Cyber Kill Chain, ya que permite al adversario mantener el control sobre los sistemas comprometidos y, de esta manera, facilitar la obtención del control completo de la infraestructura de una organización.

Importancia

Un C2 permite desplegar un punto de control dentro de un ejercicio donde se prioriza el sigilo, de manera que crea el entorno clave de dominio sobre los defensores, dado que otorga un sistema de comunicación encubierta sobre los sistemas infectados. De esta manera, proporciona una serie de ventajas a un atacante, dado que permite efectuar comandos, exfiltrar datos sensibles y expandir su presencia por la red sin llegar a ser detectados.

Extrapolemos los puntos claves de un C2:

  1. Persistencia, dado que permite mantener un control sobre los sistemas comprometidos a largo plazo.
  2. Exfiltración, dado que permite extraer información de las redes víctimas sin llegar a ser detectado.
  3. Pivoting, dado que permite realizar movimientos laterales para poder desplazarse y explotar sistemas de redes adyacentes.

Técnicas Implementadas

El objetivo de un C2 es mantener una comunicación continua y encubierta con los sistemas comprometidos por el Red Team. Con este objetivo en mente, implementan técnicas como las siguientes:

  • Tunelización DNS: Permite la transmisión de datos a través de la encapsulación de los mismos mediante el protocolo DNS. Abusa de la confianza de la esencialidad del tráfico DNS en las redes corporativas, que generalmente suele estar permitido por los diferentes dispositivos de seguridad.
  • C2 basado en HTTPS: Permite el establecimiento de la comunicación cifradas mediante HTTPS entre el atacante y el sistema comprometido. Con esta técnica se permite camuflar el tráfico malicioso del atacante con el tráfico web legítimo.
  • Beaconing: Permite la comunicación mediante beacons a intervalos regulares o aleatorios, desde el sistema comprometido al C2. Normalmente se debe hacer una instalación de un implante malware en el sistema comprometido, pero la ventaja que tiene es que ayuda a evitar aquellos sistemas de seguridad más avanzados que se basan en una detección por patrones.
  • C2 en Cloud: Permite la comunicación con el C2 mediante el uso de servicios cloud, como AWS, Drive, Dropbox, Azure, entre otros. La ventaja radica en que, si se ha detectado el uso de una de estas tecnologías durante la fase de reconocimiento, sería una buena aproximación utilizar está técnica para camuflar el tráfico malicioso como operaciones normales del usuario.
  • C2 Satelital[1]: Es una técnica donde se establece la comunicación entre el C2 y los sistemas comprometidos haciendo uso de enlaces satelitales. Este escenario requiere un alto nivel de sofisticación y recursos; sin embargo, proporciona un grado elevado de sigilo e indetectabilidad frente a los equipos de seguridad de las organizaciones. Este modelo tiene varias ventajas:
    • El tráfico C2 pasa a través de redes satelitales, evitando las rutas de internet convencionales. El rastreo de una dirección IP asociada a comunicaciones satelitales hacia una ubicación física resulta sumamente complejo de realizar.
    • Permite la simultaneidad en la unidireccionalidad y bidireccionalidad de la comunicación C2 según convenga. De este modo, reduce la posibilidad de ser detectado y facilita tanto el envío de comandos como la exfiltración de datos.
  • P2P: Este modelo es interesante, dado que implica la generación de redes P2P entre los sistemas comprometidos para que se comuniquen directamente entre sí, de esta manera formando una red descentralizada. Esta técnica elimina la necesidad de un servidor C2 centralizado, aumentando la resiliencia de la red maliciosa.
[Read more…]

ATT&CK: El juego de las casillas

El mundo de la ciberseguridad cada vez se vuelve más complejo y desafiante. Con cada nueva amenaza, desde capacidades dañinas como malware o 0 days, hasta los cambios en las infraestructuras, habiendo pasado de entornos on-premise a híbridos o full-cloud, surge la urgente necesidad de esquemas y metodologías que ayuden a enfrentar estas adversidades. No solo buscamos minimizar el impacto de cualquier amenaza, sino también de alcanzar un nivel de detección y neutralización con el que nos sintamos confiados, aunque a menudo esto puede dar una sensación de falsa seguridad.

Hoy día encontramos diversos esquemas que nos ayudan a entender y contextualizar el modus operandi de los actores hostiles. Desde el ampliamente reconocido MITRE hasta el Malware Behavior Catalogue (MBC), pasando por Microsoft Attack Kill Chain y Lockheed Cyber Kill Chain, estas herramientas nos ofrecen una guía para comprender y enfrentar las tácticas, técnicas y procedimientos (TTPs) utilizados por los adversarios. Dentro de este panorama MITRE ATT&CK el esquema más reconocido. Su matriz desglosa las distintas técnicas, tácticas y procedimientos (TTPs) utilizados por los actores hostiles.

Imagen 1: Ejemplo de Mitre ATT&CK
[Read more…]

Atacando entornos en Microsoft Azure

Hace unos años, la arquitectura de red convencional incluía un Directorio Activo y algunos servicios importantes como: correo electrónico, aplicaciones, servicios compartidos, etc. Sin embargo, como todos estamos viendo a diario, ese modelo ya forma parte de la prehistoria informática. Ahora, lo que más nos encontramos son entornos Cloud. Ambos permiten a los usuarios acceder a los recursos corporativos desde cualquier parte del mundo y desde cualquier dispositivo, evitando la necesidad de tener que pasar por la VPN y reduciendo así los costes que conlleva mantener estos servicios. ¡Lo que tampoco viene nada mal, ¿no?!

Entre los componentes que forman parte del escenario híbrido, debemos tener en cuenta un agente conocido como ADConnect, ya que es el que permite que se sincronicen ciertos recursos locales con los servicios SaaS de Microsoft 365, como por ejemplo el correo electrónico. 

Por tanto, si recapitulamos, hemos pasado de tener un servicio crítico, que era el Directorio Activo de la organización, a tres servicios críticos: Directorio Activo local u On-Premise, Directorio Activo en Azure y servicios de Microsoft 365. Sin embargo, obviamente todos estos cambios en los entornos han afectado a otros ámbitos de la ciberseguridad:

  1. La seguridad perimetral conocida hasta ahora se ha tenido que adaptar. La perpetua herramienta de monitorización y prevención de ataques, nuestro querido SNORT (NIDS) y la monitorización de conexiones basadas en direcciones IP, se echan a un lado para dar paso a una nueva era basada en la geolocalización y las identidades de los usuarios.
  2. Los atacantes se han visto obligados a cambiar las técnicas que utilizaban hasta ahora para poder enfrentarse a sus nuevos y desconocidos objetivos, y precisamente eso es lo que hemos venido a aprender aquí: una técnica de ataque basada en la cadena de suministros (Supply Chain Attack) para un entorno de Microsoft Azure.

Para ello, vamos a detallar la taxonomía del ataque, elaborada a partir de MITRE | ATT&CK, y que habrá que adaptar en función de la arquitectura de cada organización:

IDTácticaTécnica
1ReconnaissanceT1591-Gather Victim Org Information 
2ReconnaissaneT1589-Gather Victim Identity Information
3Resource DevelopmentT1583-Acquire Infrastructure
4Initial AccessT1566-Phishing
5PersistenceT1098-Account Manipulation
6DiscoveryT1087-Account Discovery
7Lateral MovementT1534-Internal Spearphishing
8Privilege EscalationT1184-Domain Policy Modification
9PersistenceT1199-Account Manipulation
10ExfiltrationT1048-Exfiltration Over Alternative Protocol
[Read more…]

Los peligros de andar por las nubes: DFIR en O365 (V)

N.d.A.: Esta serie de posts es una narración de un análisis forense de un caso práctico de respuesta ante incidentes totalmente ficticio. Una breve explicación con algunas notas aclaratorias se puede leer al comienzo del primer artículo.

Recursos: i) vídeo del taller que el autor dio en las XV Jornadas STIC del CCN-CERT, ii) slides de la presentación, iii) evidencias ya trabajadas para poder seguir el caso paso por paso, iv) evidencias en bruto para hacer investigación propia, v) CTF DFIR preparado que va desgranando el caso a medida que se responde a los diversos retos


Entradas de la serie:
=> Primera parte
=> Segunda parte
=> Tercera parte
=> Cuarta parte
=> Quinta parte

En el artículo anterior Ángela había terminado de desgranar todas las acciones de los atacantes, por lo que ya sabía lo que había sucedido realmente y tenía una explicación completa del incidente:

  1. Los atacantes envían un phishing a Pepe Contento, que cae en el mismo e introduce las credenciales.
  2. Leen el correo de Pepe Contento, y no encuentran nada de interés
  3. Crean una app maliciosa en su tenant de Azure y la configuran para que solicite entre otros acceso al correo.
  4. Entran con la cuenta de O365 de Pepe Contento a Teams, y convencen a Inocencio Crédulo para que de permisos a esa aplicación, dando a los atacantes acceso a su correo.
  5. Leen el correo de Inocencio Crédulo y encuentran las credenciales de la cuenta de emergencia.
  6. Inician sesión con la cuenta de emergencia, y despliegan todas las acciones de evasión (usuario administrador global, regla de correo) y de espionaje (permisos sobre los buzones de correo y sitios de Sharepoint).
  7. Desde la cuenta de emergencia, intentan engañar (sin éxito) a la Directora General para que instale un Grunt de Covenant.
  8. La Directora General comparte el documento con uno de sus adjuntos, que poco después lo comparte con el otro adjunto vía O365.
  9. Los atacantes exfiltran el documento del O365 de Pepe Contento, y lo filtran al “Happy Gossipy”.

Sabiendo todo lo que han hecho los atacantes, Ángela puede pasar a la fase de contención y erradicación (que en este caso ocurre de forma simultánea, y según el “método Pelayo”, se realiza con contundencia):

[Read more…]

Los peligros de andar por las nubes : DFIR en O365 (II)

N.d.A.: Esta serie de posts es una narración de un análisis forense de un caso práctico de respuesta ante incidentes totalmente ficticio. Una breve explicación con algunas notas aclaratorias se puede leer al comienzo del primer artículo.

Recursos: i) vídeo del taller que el autor dio en las XV Jornadas STIC del CCN-CERT, ii) slides de la presentación, iii) evidencias ya trabajadas para poder seguir el caso paso por paso, iv) evidencias en bruto para hacer investigación propia, v) CTF DFIR preparado que va desgranando el caso a medida que se responde a los diversos retos


Entradas de la serie:
=> Primera parte
=> Segunda parte
=> Tercera parte
=> Cuarta parte
=> Quinta parte

En el artículo anterior habíamos visto cómo se había producido un intento de descarga de malware en el equipo de la Directora General de Festejos del MINAF, y que el malware se había descargado desde el propio Sharepoint. Llegado este momento, es necesario obtener evidencias de O365 porque está claro que la nube está implicada en el incidente. Para ello vamos a contar con las siguientes fuentes de información:

  • UAL (Unified Access Logging): Log básico de O365, guarda todas las acciones relevantes de los usuarios y administradores.
  • Message Trace: Guarda los metadatos de los correos enviados.
  • Salida de Hawk, herramienta de detección de compromisos en entornos O365.
  • Full eDiscover:  salida completa de todos los correos, mensajes de Teams y ficheros de OneDrive y Sharepoint (afortunadamente, la nueva política de seguridad de la información permite estas adquisiciones siempre que estén debidamente justificadas).
[Read more…]

Así que quieres dedicarte a la ciberseguridad

Esta entrada ha sido elaborada con la inestimable (y necesaria) ayuda de Maite Moreno (@mmorenog) y el equipo de ciberseguridad de S2 Grupo.


Una de las buenas cosas que la Seguridad de la Información comparte con otras disciplinas de la informática es la gran variedad de recursos formativos disponibles, tanto gratis como para presupuestos ajustados.

Sin una gran inversión económica, cualquier persona con tiempo y ganas (y un mínimo conocimiento de informática, para lo que existe a su vez otro gran número de recursos que no vamos a cubrir aquí) puede formarse prácticamente desde cero hasta niveles expertos en prácticamente cualquier ámbito de la ciberseguridad.

A continuación recogemos algunos de los recursos disponibles en Internet ya sean gratis o por un coste reducido, teniendo en cuenta que:

  • Este listado no pretende ser exhaustivo. Siéntete libre de comentar aquel contenido que creas que falte y lo añadiremos en cuanto podamos.
  • Algunas plataformas tienen un enfoque freemium, combinando contenidos y funcionalidades gratis con otras de pago.
  • Aunque los ámbitos menos técnicos de la Seguridad de la Información como GRC están menos (muy poco) representados en el listado, las páginas de formación más generalistas incluyen cursos sobre protección de datos, marcos de control, gestión de riesgos, etc.
  • La mayor parte de los cursos están en inglés, por lo que es necesario un mínimo nivel para entender instrucciones y textos. Nivel que por otro lado es imprescindible hoy en día en el ámbito de las tecnologías de la información.
  • Se dejado fuera blogs, vblogs y podcasts sobre Seguridad de la Información, pero existen infinidad de recursos extremadamente útiles. Esto incluye los miles de webinars sobre cualquier temática imaginable.
  • Tampoco se han incluido plataformas más generales como edX o Coursera, que contienen no obstante muchos cursos de universidades y entidades prestigiosas.
  • Por último, tampoco hemos recogido los cursos de los propios fabricantes de dispositivos, software o proveedores de cloud, que en algunos casos son gratuitos, y que en ocasiones proporcionan también versiones libres (con limitaciones) de sus productos. Me vienen a la cabeza AWS, Tenable o Splunk, pero hay muchos otros.
[Read more…]

10 consejos para asegurar los datos alojados en Amazon S3

El uso de Amazon Simple Storage Service S3 está cada vez más extendido, utilizándose en multitud de casos de uso: repositorios de datos sensibles, almacenamiento de logs de seguridad, integración con herramientas de backups…, por lo que debemos tener especial atención en la forma en la que configuramos nuestros buckets y como los exponemos a internet.

En este post hablaremos sobre 10 buenas prácticas de seguridad que nos permitirán gestionar de una forma correcta nuestros buckets S3.

Empecemos.

1 – Bloquea el acceso público a los buckets de S3 en toda la organización

Por defecto los buckets son privados y únicamente pueden ser utilizados por los propios usuarios de nuestra cuenta, siempre que tengan establecido correctamente los permisos para ello.

Adicionalmente, los buckets tienen una opción “S3 Block Public Access” que impide que los buckets puedan ser considerados públicos. Esta opción se puede activar o desactivar en cada bucket de la AWS Account. Para prevenir que un usuario pueda desactivar dicha opción, podemos crear una política SCP en nuestra organización para que ninguna AWS Account miembro de la organización pueda hacerlo.

[Read more…]