Mostrando entradas con la etiqueta seguridad. Mostrar todas las entradas
Mostrando entradas con la etiqueta seguridad. Mostrar todas las entradas

domingo, 23 de octubre de 2022

Tratando de evitar ataques AITM (Adversary in the middle) a identidades cloud.

 

Dado que está resultando realmente exitoso para los atacantes. Empresas como Zscaler y el mismo Microsoft, han publicado diversos estudios y análisis sobre los ataques que se están llevando a cabo mediante AITM. Este formato consiste en situarse entre el usuario y el portal de validación para recoger una cookie de inicio de sesión que prevalece válida mientras dura la sesión del usuario validado.


Links de los estudios:

AITM Attack Targeting Microsoft Email Users | Zscaler

From cookie theft to BEC: Attackers use AiTM phishing sites as entry point to further financial fraud - Microsoft Security Blog

Una vez he repasados estos estudios, destaco lo siguiente. 

Los ataques se están produciendo con aplicaciones tales como: Evilginx2 -utilizado en mi video- Muraena y Modlishka. Todos ellos funcionan siendo un proxy entre la víctima y el servicio de destino, pudiendo ser desde Spotify hasta O365, pasando por Paypal, Instagram, Twitter, etc.

Buscando soluciones a este ataque, primeramente veo que como casi todo phising, suele llegar vía correo electrónico indicando al usuario que ha de validarse en una url. Por lo que aconsejo la puesta en marcha de Safe Links en Advanced Threath Management que forma parte de la protección avanzada de Microsoft Defender.

La diferencia entre Defender y Defender en versión avanzada, es que el segundo, protege al hacer click en urls peligrosas a día del mismo click en correos pero que pasaron a la bandeja de entrada del usuario, siendo validadas por un Defender más básico y no declarar estas peligrosas, por no estar localizadas en ese momento.


También observé en el piloto que construí, que Google Chrome marcó bastante antes mi URL maliciosa -yo registré el dominio Outloook.tk- mientras que Edge tardó algo más de 24 horas en avisarme.

A día de hoy, se mantiene activa una list de dominios utilizados como urls proxy que se puede consultar aquí: https://github.com/threatlabz/iocs/blob/main/aitm_phishing/microsoft_iocs.

Dado que en los análisis hechos por Zscaler existen inicios de sesión tras 8 minutos después de robar al  usuario su información y no existen registro de acciones realizadas, como pueden ser enviar mails u otras y viendo también en mi piloto, que el software proxy me devolví la contraseña del usuario en texto plano. Me inclino a pensar que el atacante, registra un nuevo segundo factor en la configuración del usuario, para garantizarse futuros accesos con su usuario y contraseña + doble factor registrado.


Protección en Azure AD ante este ataque

Una vez el correo ha llegado al usuario y mientras nuestro sistema de detección de URLs no indique que la dirección es peligrosa, Estamos expuestos a que el usuario haga click y se valide en la ventana de login, por lo que cabe entender el funcionamiento de Azure AD en cuanto a la sesión del usuario, para protegernos ante la adquisición de la cookie.


PIM

Por supuesto, ya que nos podemos caer en la trampa y nos pueden secuestrar una credencial. Lo que es muy aconsejable es que ninguna de ellas, tenga roles privilegiados asociados. Esto lo conseguimos utilizando y activando PIM, tal y como expliqué en este Webinar.


De forma general podemos tener en cuenta lo siguiente:

Situación de riesgo

Herramienta para la remediación

 

El mail llegó al buzón del usuario y días después, habiendo sido marcado el dominio como peligroso, aun pudo hacer click visitando la web del atacante.

 

 

Activación de Advanced Threath Management para garantizar control de urls actualizado en el día del acceso.

 

La propia realización de inicio de sesión.

Acceso por parte del atacante al existir una regla de permisividad del Login, excesivamente abierta. Permitiendo acceso desde su localización, lugar y dispositivo.

 

 

Este login se ha podido realizar al cumplir reglas, las cuales por defecto son, “cualquier parte del mundo”, “cualquier lugar”, cualquier dispositivo”. [1]

 

Se aconseja la creación reglas de acceso condicionar para delimitar países, lugares específicos como la oficina y dispositivos, distinguiendo entre logins desde equipos corporativos, sincronizados con AdConnect y considerados híbridos, y los no corporativos, considerados Register en Azure AD.

 

 

Posibilidad del inicio de sesión del atacante durante el periodo de validez de la cookie.

 

La cookie es válida mientras la sesión no se revoque.

 

 

 

Requerir re autenticación cada cierto tiempo si se realiza en equipos no corporativos.

 

https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-session-lifetime#user-sign-in-frequency-and-multifactor-authentication

 

 

Uso de sistema multifactor que genera cookie atacable

 

Usar sistemas multi factor que no generen cookie:

  •  Fido2 Security Keys
  • Windows Hello for Business
  • Certificado

 El resto, sms, llamada y mobile app, generan cookie utilizable.

[1]Reglas condicionales efectivas

Método

Protección

  • Requerir dispositivo como “compliant”

  • Protege

  • Requerir dispositivo híbrido o unido a Azure AD

  • Protege

  • Regla condicional de control de sesión

  • Protege solo durante una ventana de tiempo

  • Regla condicional en la que permitir login solo desde sitios de confianza

  • Protege


Saludos

miércoles, 10 de marzo de 2010

Encriptar carpetas

Hola.

El equipo de SBS ha publicado un artículo muy interesante donde explican como encriptar carpetas almacenadas en SBS2008 y por tanto en Windows Server 2008 y/o 2008 r2.

http://blogs.technet.com/sbs/archive/2010/03/09/help-secure-your-business-information-using-encrypting-file-system.aspx

Saludos

viernes, 7 de agosto de 2009

Mejor contraseña en blanco que "1234"

Y bueno, la verdad es que es un tanto sorprendente la siguiente información, pero pensándolo bien, si tienes seguridad física, recuerda que por ejemplo no tienes posibilidad de conectarte remotamente a un servidor 2003 o 2008 o Vista / Windows 7, si el usuario con permiso de conexión remota, tiene contraseña en blanco.

----------------------------------------------------------------------------------------
http://www.microsoft.com/protect/yourself/password/create.mspx

“Avoid using online storage. If malicious users find these passwords stored online or on a networked computer, they have access to all your information.”

(So SKYDRIVE = BAD)
The "blank password" option
A blank password (no password at all) on your account is more secure than a weak password such as "1234". Criminals can easily guess a simplistic password, but on computers using Windows XP, an account without a password cannot be accessed remotely by means such as a network or the Internet. (This option is not available for Microsoft Windows 2000, Windows Me, or earlier versions) You can choose to use a blank password on your computer account if these criteria are met:
• You only have one computer or you have several computers but you do not need to access information on one computer from another one
• The computer is physically secure (you trust everyone who has physical access to the computer)
The use of a blank password is not always a good idea. (DUH!) For example, a laptop computer that you take with you is probably not physically secure, so on those you should have a strong password.

http://www.microsoft.com/protect/yourself/password/create.mspx

jueves, 18 de diciembre de 2008

Actualización de seguridad

Hola.

Ayer Microsoft tuvo que romper el ciclo de actualizaciones que como sabéis es el segundo martes de cada mes, así que mejor que paséis por: http://update.microsoft.com/microsoftupdate/ .

Los que tenéis la estrellita, pues nada...

sábado, 1 de noviembre de 2008

¿Varias políticas de contraseñas en el mismo dominio?

Pues sí, algunos ya lo sabéis y otros ya lo habréis oido. Con windows server 2008 podemos tener diferentes políticas de contraseñas en el mismo dominio, la explicación en video y aquí:

http://technet.microsoft.com/en-us/windowsserver/2008/bb896051.aspx

Saludos.

domingo, 1 de junio de 2008

Cuidadín con Apple Safari para Windows

Que bonito es, ¡pero cuidadín con él!.

Blended Threat from Combined Attack Using Apple’s Safari on the Windows Platform

http://www.microsoft.com/technet/security/advisory/953818.mspx


Nota personal: Empezar esta semana a contar las maravillas de Small Business Server 2008.

martes, 27 de mayo de 2008

Depuración y análisis de un entorno Windows

Hola.

Muy bueno el último artículo de David Cervigón, donde se atreve a verle las tripas a su sistema y portátil corporativo nuevo de trinca :-D . El artículo está muy bien explicado y las herramientas que allí se utilizan y describen, para lo que se suele ver en el mundillo de la seguridad, análisis forense, etc., son de fácil manejo. Artículos como este, vienen muy bien de cara al verano donde solemos tener mas tiempo y sobre todo para los que no nos dedicamos a la seguridad, nunca viene mal un poco de culturilla general.

P.d.: David el antivirus se ve en la primera captura el cual además es el corporativo y no, no habría acertado en una porra sobre la marca del nuevo portátil, esos también son duros.

sábado, 23 de febrero de 2008

¿Y si nos pasamos por el forro a bitlocker?

Los bomberos dicen que a su temperatura todo arde y yo digo que con el tiempo todo se rompe, hasta Bitlocket, FileVault, dm-crypt, etc.: