miércoles, 28 de octubre de 2020

For, For, Fortificación de Sql Server for for for fun...

 Estimados amigos !!!

Me hace mucha ilusión participar en este artículo, ya que aúna dos de mis pasiones, una quizás más pasada y otra presente, pero sin dudas dos disciplinas que me han marcado en mi carrera. Me refiero a las bases de datos y la ciberseguridad.

El primer curso que impartí en mi vida fue sobre Sql Server 7 creo que recordar en 3000 informática allá por el 2000, y siempre me fascinó el funcionamiento interno del motor, la memoria, la optimización. Si es cierto que me gustaba más la parte de "sistemas" que desarrollo, y eso derivó en mi pasión por los servidores. Pero bueno, batallitas aparte, que este post va de Seguridad en Sql Server sobre Windows.

Comenzamos "asentando" nuestro Sql Server sobre una UO que nos permita luego filtrar el conjunto de GPO´s diseñadas para la labor y a continuación creamos la Directiva de grupo vinculada a dicha UO. Metemos el servidor a la UO y comenzamos el viaje...

Siguiente paso, quitar roles del servidor. Si no vas a imprimir, quita el rol de servidor de impresión. Hay ataques que explotan este servicio y cuando menos superficie de exposición, mejor.

Establecer el servicio de copias VSS manual y no iniciado. Podemos sufrir un incidente por este mecanismo y no es necesario ( a no ser que sí lo sea).

Cambia el nombre al usuario SA  y comprueba que está deshabilitado.

En las propiedades del servidor, en seguridad, habilitar la auditoría de inicio de sesión, correcto y erróneo. 

Habilita la auditoría general del sistema creando una nueva política y establece la rama "Seguridad" o el fichero donde quieres ques se guarde. Esto dependerá del uso que le vayas a dar, y si tienes un SIEM o un SYSLOG y la manera que tenga de recolectar la información.



Si te ves con fuerza actívala :-)

Otra buena práctica es dejar el servidor al antojo de los administradores Sql Server, por lo que yo pondría una GPO específica para ese o esos servers y habilitaría el inicio de sesión sólo a los miembros del grupo administradores de Sql Server... 

Usa el cifrado transparente TDE en las bases de datos para cifrar con un certificado los ficheros. Es útil para entornos en los que se puede realizar un ataque físico, por ejemplo, con acceso a un disco duro, a un backup etc. Por defecto en 2019 todas las bases de datos creadas se cifran, pero si vienes del pasado... sigue este procedimiento.

Otra buena idea es cifrar el contenido de una columna, por ejemplo datos sensibles, para que el administrador de la base de datos no tenga que ver el contenido de la misma.


Firewall

Uno de los aspectos claves para securizar una instancia de Sql Server es el firewall del sistema operativo que corre bajo el. Por defecto, el puerto TCP de Sql Server escucha en la "emisora" 1433. Sin embargo, en servicios "menos" pro como Sql Express la conexión con el motor se hace por puertos aleatorios. Como se puede saber el puerto, viendo el log, pero Sql Server gestiona esto con el Sql Browser, que escucha en el puerto UDP 1434. Según tu entorno, sabiendo esto, la recomendación es abrir solo el puerto 1433 y si es posible, deshabilitar el servicio Sql Browser para cumplir con el compromiso de minimizar la superficie de exposición... Si necesitas este "dinamismo" en los puertos de entrada, te recomiendo leer este documento, y filtrar el servicio por el ejecutable, no por el puerto.

Protección extendida

Imagina el concepto de un Rogue AP. Montar un acces point wifi similar a uno en producción, y esperar que los clientes se intenten conectar... enviando sus credenciales...

El mismo concepto se puede dar en un entorno de Man in the Middle contra un sql server mediante una autenticación basada en NTLM, en la que el cliente envía el desafío, pero un atacante "en medio", por ejemplo habiendo falseado una entrada DNS, puede hacer de relay contra el Sql Server real y así hacerse con el acceso.


Microsoft implementa el Extended Protection, lo que hace es añadir un token único para cliente, y establecer una whitelist de SPN, o cuentas en las que sí se podrá acceder. De esta manera podemos evadir dicho ataque de manera sencilla.

Esta vulnerabilidad no es intrínseca de Sql Server, sino de la autenticación basada en NTLM, por lo que es aplicable a otros servicios, como el conocido uso de Responder o Inveight para el mismo concepto, pero implementando el ataque para la aplicación SMB ( compartición de carpetas) o HTTP ( las páginas wweeeeeee).

La recomendación genérica para entornos Microsoft, es deshabilitar la autenticación NTLMv1 pero ni siempre es posible, sobre todo, con sistemas Legacy o no Compliance 100% etc...y también se puede creackear.

Vamos a hacer una pequeña prueba de concepto para que veais lo "sencillo" que es aprovechar este fallo.

Voy a usar la herramienta Inveigh, el clon de Responder para Powershell. La tool ejecuta un servidor SMB falso y esnifa, escucha, peticiones NTLM en la red. El escenario teórico del ataque sería una red en la que conseguimos acceso a un sql server, por ejemplo mediante una SqlInyection y podemos ejecutar "cosas". Si podemos ejecutar una dirtree en una equipo remoto, es decir un DIR, estaremos pasando las claves NTLM* al equipo destino. Si ese equipo destino es la herramienta, esnifará la petición y obtendremos el codiciado hash. Luego lo usaremos de varias maneras, pero se extralimita de este propósito. Vamos a verlo. Ejecuto una consulta desde el SqlServer hacía Inveigh



Y ahora vemos en la herramienta como hemos capturado el hash.


Ahora vamos a configurar la seguridad extendida en el SqlServer, y vamos a comprobar el resultado.


*NTLM: Cuando hablamos de Ntlm me refiero a net-ntlm. No es lo mismo que NTLM, pero para centrar al lector en la seguridad del Sql Server los conceptos son los mismos, y a fin de cuentas, ambos hashes se pueden crackear. Esto es una aclaración para puristas. Si quieres saber la diferencia entre Net-NTLM y NTLM pincha aquí y estudia :-) *

Otro tip para tu conocimiento. Si has hecho esta POC, prueba a pedir desde el Sql Server el DirTree con nombre de equipo en vez de dirección IP, sabes qué ocurre? Cuando hacemos barra barra a un equipo pasa lo mismo !!! si lo hacemos por nombre, la autenticación es basada en Kerberos, y no entra en juego Ntlm... tip de seguridad genérico :-)

Actualizaciones

El tema de las actualizaciones siempre ha sido complejo, pero como todo en la vida, al final es un reto más, pero no podemos dejarlo de lado. En numerosas auditorías y pentest que hago informo de versiones de Sql Server Viejas y sin parches importantes. Como que a TIC, y si es una rama dev. más aún, les da la risa floja en plan: "ahora viene este a decirme que no parcheo la bbdd" pero es necesario.

Es importante conocer un poco más sobre esta tarea que no todo el mundo sabe. Por lo general, los parches se liberan el segundo martes de cada mes, como los Windows... por lo que por la noche, o el miércoles por la mañana, tendrás parches...

Las actualizaciones suelen dividirse en 3 grandes grupos: HotFix, suelen ser soluciones a errores puntuales. CU o actualizaciones acumuladas, que son un conjunto de HotFix. Services Pack, son un conjunto de CU´s y HotFix y suelen tener funcionalidades nuevas. El ciclo de publicación es mayor por lo que suelen estar mucho más testeadas y son mas seguras y estables.

Dentro de este modelo, también debemos separar dos "branches" de las actualizaciones, una basada en hotfix puntuales que tienes o no, y otra denominada GDR ( General Development Release). 

Imagina un hotfix que soluciona un problema X para los Sql Server sobre 2019 en versión castellano en servidores Hp de la gama ZYX... puede que tengamos ese parche, ese hotfix, si tenemos esa casuística concreta... pero si sale el service pack 1, esta "rama" de actualizaciones es general para todos los sql servers. El service pack 2 incluiría todas las actualizaciones del 1, por ser acumulativo.

Me gusta este video de mi líder mundial Enrique Catala

Usuario Servicio

Otra de toda la vida... Si instalas un SqlServer con permisos de administrador del dominio, el SqlServer se ejecuta con este contexto de seguridad. Si un atacante accede a la bbdd, accede con esos permisos... Es sencillo. Hay que crear usuarios específicos para el servicio, y fortificarlos para que tengan solo los permisos necesarios para la labor de ejecutar el servidor. No tiene sentido que ese usuario tenga acceso de escritura a la carpeta "nóminas" de ese fileserver... si no es necesario.


NMAP

Un básico de los sistemas y más estos, es realizar auditorías periódicas para conocer el estado real de la seguridad de los mismos. Es común creer que nuestros entornos son más seguros de lo que lo son, y en el peor de los casos, podemos aprender de cambios no controlados. Nos ocurre muchas veces que encontramos planteamientos distintos de los que creían en la organización, por un cambio en un partner, una reparación rápida y "provisional", etc...

Aunque no estés muy puesto en este mundo, lanzar desde un linux algo así : nmap --script ms-sql-info,ms-sql-empty-password,ms-sql-xp-cmdshell,ms-sql-config,ms-sql-ntlm-info,ms-sql-tables,ms-sql-hasdbaccess,ms-sql-dac,ms-sql-dump-hashes --script-args mssql.instance-port=1433,mssql.username=sa,mssql.password=,mssql.instance-name=MSSQLSERVER -sV -p 1433 192.168.1.1 siempre es bueno.

PORT     STATE SERVICE  VERSION

1433/tcp open  ms-sql-s Microsoft SQL Server  15.00.2000.00

| ms-sql-ntlm-info: 

Host script results:

| ms-sql-info: 

|   192.168.1.101:1433: 

|     Version: 

|       name: Microsoft SQL Server 

|       number: 15.00.2000.00

|       Product: Microsoft SQL Server 

|_    TCP port: 1433

Transact Sql

El propio lenguaje de gestión del Sql Server te proporciona algunos procedimientos y funciones relacionadas con la seguridad, que si bien te pueden sonar a chino si no las necesitas, es bueno conocerlas y darles un repaso, lo mismo identificas implementaciones inseguras o valores no deseados. Las principales son: sys.database_permissions, sys.database_principals, sys.database_role_members, sys.database_scoped_credentials, sys.master_key_passwordssys.user_tokensys.credentials, sys.login_token, sys.securable_classes, sys.server_permissionssys.server_principals, sys.server_role_members, sys.sql_logins, sys.system_components_surface_area_configuration, sys.asymmetric_keys, sys.certificatessys.column_encryption_key_values, sys.column_encryption_keys, sys.column_master_keys, sys.crypt_properties, sys.cryptographic_providerssys.key_encryptions, sys.openkeys, sys.security_policies, sys.security_predicatessys.symmetric_keys, sys.server_audits, sys.server_audit_specifications, sys.database_audit_specifications,  PWDCOMPARE (Transact-SQL)CERTPRIVATEKEY (Transact-SQL)PWDENCRYPT (Transact-SQL)CURRENT_USER (Transact-SQL)SCHEMA_ID (Transact-SQL)DATABASE_PRINCIPAL_ID (Transact-SQL)SCHEMA_NAME (Transact-SQL)sys.fn_builtin_permissions (Transact-SQL)SESSION_USER (Transact-SQL)sys.fn_get_audit_file (Transact-SQL)SUSER_ID (Transact-SQL)sys.fn_my_permissions (Transact-SQL)SUSER_SID (Transact-SQL)HAS_PERMS_BY_NAME (Transact-SQL)SUSER_SNAME (Transact-SQL)IS_MEMBER (Transact-SQL)SYSTEM_USER (Transact-SQL)IS_ROLEMEMBER (Transact-SQL)SUSER_NAME (Transact-SQL)IS_SRVROLEMEMBER (Transact-SQL)USER_ID (Transact-SQL)ORIGINAL_LOGIN (Transact-SQL)USER_NAME (Transact-SQL)PERMISSIONS (Transact-SQL)

Azure

Como pudimos ver hace unos días, el propio Azure nos permite fortificar o supervisar la seguridad de nuestros sistemas, integrando en el Security Center nuestras instancias, tanto en la nube como On Premise.

Como puedes ver, hay muchas formas de abordar el proceso de robustecimiento de nuestros motores de base de datos SQL Server, no es un proceso cerrado, y seguro que entre todos se nos ocurren más procesos, verdad?

Espero que te guste, gracias por leerme !!!

martes, 27 de octubre de 2020

Fortificación sencilla de SQL en Azure..y en On Premise...

 Estimados amigos de Inseguros !!!

Nube segura, seguro? por defecto si o por defecto no? pues depende !!! la nube, en este caso Azure, nos proporciona principalmente "seguridad del hardware" y disponibilidad, bueno y la seguridad de no tener que gestionar el sistema operativo que hay por debajo... pero podemos subir un poquito más las cotas de ciberseguridad de nuestros Sql Server en la nube mediante unos pequeños procesos. Pero espera... quizás nos sirva para On premise...


Los ataques que podemos experimentar en nuestros motores de bases de datos son los típicos ataques de fuerza bruta, inyecciones de código y algunos comportamientos denominados atípicos. El sistema es capaz de detectar elementos inseguros ( XP_cmd...) y configuraciones débiles, por ejemplo, demasiados permisos en usuarios... Esto se realiza mediante el análisis de vulnerabilidades y la monitorización constante.

El conjunto de funcionalidades de seguridad de nuestras bases de datos no se queda en esta capa, existen numerosas funcionalidades como el etiquetado de datos sensibles, transporte cifrado... quizás esto sea objetivo de otro post...

Como siempre, las teclas del piano son muy sencillas y la configuración inicial es más bien un paseo... para eso nos hemos quedao :-)



Podemos apreciar como desde el inicio el análisis me aporta valor.


El sistema nos indica, en un Sql Server recien instalado, que solo tenemos un usuario, el DBO y que esto es peligroso... bieeeen.

Pero bueno, todos sabemos que las nubes están muy ricas y son muy buenas, pero seguimos teniendo elementos On-Premise, y más, los que consumen recursos altos. El proceso es muy sencillo, solo tenemos que instalar el servicio Azure Arc, descargar el script y ejecutarlo en nuestro servidor On-Premise. En unos minutos veremos nuestro Sql Server, o mejor, los resultados, en el centro de seguridad.


Aunque recuerda que puedes ejecutar el análisis de vulnerabilidades sin nada de todo esto en los nuevos SqlServe 2019.



Como ves, es muy sencillo usar estas funcionalidades para mejorar la seguridad y sobre todo monitorización de nuestros servidores Sql Server.

Espero que te sirva, gracias por leerme !!!


lunes, 26 de octubre de 2020

No disimules y simula: Simulación de ataque con Microsoft 365

 Estimados amigos del Inseguros !!!

Una de las patas más importantes en el juego de la ciberseguridad es el usuario. Nos quejamos constantemente de usuarios poco preparados, que lo aceptan todo, bien, si, pero seamos realistas, no todos deben ser unos auténticos cracks con la informática... y por qué no decirlo, todos hemos caido total o parcialmente en algún "problema", ya sea un virus, un spam o un casi phishing...

En el episodio de hoy mostraros unas pequeñas ayudas que tenemos con el servicio ATP de Microsoft. 

Nos quejamos muchas veces del coste del servicio M365 ( Office 365) pero al final si vas sumando funcionalidades, el ahorro es considerable. Compara una solución de correo+antivirus potente + software de simulación de phishing...al final para decir que algo es caro o barato hay que compararlo.

Si eres un afortunado de contar en tu plan de licenciamiento el ATP, es importante conocer el simulador de ataques

Por el momento podemos simular dos escenarios de ataques al usuario final, fuerza bruta ( horizontal y vertical) y phishing ( robo de credenciales y adjuntos).


Como casi todo lo del gigante de Seattle, el proceso es muy sencillo.


Elegimos la lista de destinatarios desde una lista de direcciones o uno o más ficheros csv.
Continuamos...


Sin muchos más clicks, tenemos el correo enviado en el buzón del destinatario con cierto aspecto raro ( se puede cambiar lo que quieras).


Si continuamos con la farsa nos aparecen el caso de phishing con unas credenciales...


El proceso acaba con una "landing" que te muestra lo ocurrido. Puedes verla en esta url: http://portal.prizesforall.com/Login/Phished

Por supuesto que podemos linkar esta landing con formación dedicada nuestra o whatever you want...

En esta ocasión podemos ver un reporte desde la consola de administración donde nos mostraría el % de usuarios que han abierto, han clickeado o han introducido las credenciales.


Ahora vamos a probar un ataque sencillo de fuerza bruta desde el portal ATP. Los clicks son muy intuitivos y descriptivos...


Este tipo de acciones suelen tener un gran impacto en la ciberseguridad, de nuestros compañeros y empleados, y si bien no es tecnológicamente apasionante ... es muy efectivo...

Sueles emplear campañas de este tipo para entrenar a tus usuarios?

Espero que te sirva, gracias por leerme !!!



viernes, 23 de octubre de 2020

Usas inicio de sesión único en Azure Active Directory... resetea la contraseña Kerberos...Mimikatz la quiere xD

 Estimados amigos de Inseguros !!!

Seguro que muchos de vosotros tenéis un Directorio Activo sincronizado con Azure para una o varias funciones. Principalmente lo usamos para conectar las cuentas del dominio local con cuentas de Office 365.

Una de las funcionalidades que tenemos disponibles es la Inicio de sesión único de conexión directa, un SSO para no tener que estar autenticando nuestros Office online en cada uso.

Esta sincronización se hace mediante un ticket kerberos que se le pasa al navegador para autenticar con el portal de Office por ejemplo. 

El funcionamiento interno del ticket Kerberos se hace mediante una cuenta de equipo denominada AZUREADSSOACC. Cuando el usuario hace login en el portal de office, el controlador de dominio On-Premise genera un ticket kerberos usando esta cuenta, que representa el "azure ad".


Cómo imaginas, esta cuenta es muy importante y es necesario resetear el ticket kerberos que se genera de vez en cuando, por lo menos una vez al mes, para evitar que si se ve comprometida la cuenta o el ticket, un atacante no siga teniendo el control del usuario.

El ataque sería muy sencillo usando Mimikatz por ejemplo:

mimikatz.exe "lsadump::dcsync /user:AZUREADSSOACC$" exit


Con esta información estamos a disposición de crear un Silver Ticket mediante este ataque e impersonar a cualquier usuario.


Bueno, pero el propósito de este post no es otro que ayudar con la defensa, como casi siempre, y es importante que de vez en cuando, una o dos veces al trimestre... al semestre... hagais un reset del ticket kerberos para evitar persistencia en el sistema. No se os ocurra cambiar la clave de la cuenta.


El proceso es muy sencillo. Os recomiendo comprobar el estado de vuestra conexión, resetear el ticket, y volver a comprobarlo.


Import-Module “C:\Program Files\Microsoft Azure Active Directory Connect\AzureADSSO.psd1”

New-AzureADSSOAuthenticationContext 

Get-AzureADSSOStatus | ConvertFrom-Json

$Clave = Get-Credential

Update-AzureADSSOForest -OnPremCredentials $Clave

Espero que os sirva un poco para conocer cómo funciona esta particularidad, y sobre todo, para os asegureis !!!

Gracias por leerme !!!


jueves, 22 de octubre de 2020

Crackers no son galletas... tampoco maleantes... cracking con Aws Gpu as a services

 Estimados amigos de Inseguros !!!

Si has vivido el comienzo de internet hará ya más de 20 años, inevitablemente habrás vivido el comienzo del hacking... van de la mano.

La cultura hackers apareció en los medios, prensa, televisión, cine... de una manera poco documentada como suele pasar. Ya conoces las películas legendarias... No sé por qué se asociaba el movimiento hacker con el punk... el cyberpunk!!! como si los expertos del momento pasaran los días en discotecas tomando drogas... que no digo que no...pero al final no eran como en las películas.

Una de las cosas que solían aparecer eran los "diccionarios" la jerga... en la que se definía que era un hacker, un lammer, un cracker... siendo este último término asociado a "hackers malos". Bueno, al final esto era una paja mental del periodista de turno. Un cracker tampoco son galletas... en este caso lo oriento al concepto de crackear, crackear un hash o una contraseña, averiguar su contenido en formato legible...

Podría ser crackear un programa... pero no es el caso...

Pudimos ver en otro artículo del blog como crackear hashes NTLM con la potencia de las máquinas virtuales en Azure y las GPU ( tarjetas gráficas). Usando herramientas como jhon the ripper o hashcat.

En esta ocasión vamos a ver algo similar, pero mucho más "as a services". Más sencillo. En este caso es un software denominado NPK (sodio, fósforo y potasio) que los amantes al cultivo de la yerba conocerán muy bien. Se trata de un software que empleando las capacidades serverless de Amazon, los S3, las sondas lambda, y la potencia de Terraform, conseguir desplegar dinámicamente instancias Amazon diseñadas con gran cantidad de recursos, incluidas potentes GPU, para optimizar el proceso de cracking. Todo esto mediante un frontend muy intuitivo y sencillo, aunque tengo que decir algo crispante.

Vamos a verlo para que imagineis lo sencillo de usar.




Eliges el tipo de hash, el tipo de instancia que quieres usar, subes el fichero, eliges el diccionario o las máscara de hashcat y te da una estimación de coste máximo para la previsión que tiene, en base a los requisitos. (la sonda lambda está constantemente monitoreando el coste).

Y al final si todo ha ido bien, tenemos nuestros hash descifrado o desencriptado xD.

Si bien el manual en el github es "claro", yo he perdido mucho tiempo en ponerlo a rodar por algunas cosas mías, por ejemplo, la edad, mi IQ, mi afición a no estar solo haciendo una cosa, etc xD pero básicamente tienes que llevar algunas precauciones. Cuando crees el profile del aws client. usa el nombre NPK o Terraform no sabrá donde buscar las credenciales. Usa Terraform v11 normal o dockerizado pero no me funciono ni 11,noseque ni 12.

Revisa los límites que tienes paras las instancias y si es necesario, abre un ticket para poder ampliarlo. En muchos tipos de instancias hay un límite por defecto para cuestiones de escalado y demás.

Un proyecto muy interesante que le cuesta un poco de afinar, tiene falta de documentación, logs, pero me gusta mucho el concepto de levantar las instancias dinámicamente.

Espero que te guste, gracias por leerme !!!

lunes, 5 de octubre de 2020

Tipos de Login en sistemas Microsoft. 101

 Estimados amigos de Inseguros !!!

Imaginas que en este post habláramos de la necesidad de usar claves seguras en el login... de más de 8 caracteres ... no  !!! este post no va de eso.

Vamos a hablar de algunos aspectos de los mecanismos de autenticación básicos de los sistemas Microsoft que por comentarios y experiencia sospecho que no todo el mundo conoce.

Es importante conocer en profundidad los sistemas que manejamos, porque si todo va bien, es muy sencillo administrar un "guindo" pero si algún día tienes problemas, o sufres un incidente o tienes que estudiar si estás sufriendo un incidente... conocer estos términos te será fácil.

Vamos a empezar con el proceso de login, el denominado login interactivo. Es el que se produce cuando nos "sentamos" delante del equipo, cuando pulsamos ctrl+alt+spr. Dentro del login interactivo podemos incluir el que realizamos por RDP, podemos imaginar el RDP como un "túnel" en el que nos sitúa delante del pc. Realmente podemos denominarlo login remoto interactivo. 

Cuando realizamos este login, estamos accediendo a la SAM ( Security Account Manager) o a un dominio. Es muy importante entender esto. Si usamos un pc de empresa por ejemplo, podemos autenticarnos contra el propio pc, o contra el dominio. Esto se puede modificar, ya lo sabemos, pero es importante entender estos conceptos. Si haces login en la SAM, en local, si entras a una carpeta de red de un pc de dominio, tendrás que autenticarte en el equipo destino.

*imagina usuario1/contraseña1 en pc1. imagina usuario1/contraseña2 en pc2. Cuando te conectas con usuario1 desde pc1 al pc2, pc2 te pedirá la contraseña2, la del equipo destino...*

Otro tipo de login interactivo es el que realizamos con una tarjeta, una smart card.

El siguiente grupo de logins es el denominado de red. El que realizas cuando te conectas a un recurso de red, como pueda ser una carpeta compartida o una GPO. Otro tipo de login puede ser como proceso Batch y como servicio.

Otro tipo de login muy interesante es el de la cache. Imagina un portátil corporativo que se inicia en casa del empleado sin haber levantado vpn contra la empresa. Usa las credenciales almacenadas en el equipo,por defecto 10 veces máximo, para autenticarse dentro de un entorno de dominio. Este comportamiento se debe cambiar, si los procesos de la empresa lo permiten, para evitar esta funcionalidad. Imagina un caso muy sencillo: se resetea la clave porque se ha comprometido. El atacante tendría 10 logins "locales" en el equipo hasta que sea obligado a autenticarse contra el DC con la nueva password...

Otro tipo de login, denominada 10 es el que se produce cuando ejecutamos Runas /netonly. Con este parámetro el equipo se ejecutará en local con el usuario que levanta la consola, es decir, el que se logueo en el sistema local, pero si el programa accede a la red, usará el equipo usuario proporcionado con el comando runas.

Una vez explicados los logins, vamos a hablar de los dos grandes proveedores de autenticación en los sistemas Microsoft, NTLM y KERBEROS.

Imagina que un equipo cliente se conecta a un servidor de ficheros. Mediante el handshake NTLM se establece una conexión entre pc y cliente, con un desafío o challenge que se cifra con el hash del password del fichero... y el servidor de ficheros comprueba la contraseña del cliente consultando al controlador de dominio... quien es el jefazo de la organización y conoce las claves de los usuarios.( el funcionamiento de este mecanismo se ha simplificado para la comprensión del lector)

El proceso con Kerberos es algo distinto, ya que el el servidor de ficheros no se conecta al DC. El cliente solicita al DC un ticket de servicio para conectarse a un servidor destino, el DC le concede el ticket ( el funcionamiento de este mecanismo se ha simplificado para la comprensión del lector) y cuando el cliente se quiere conectar con el dichoso fileserver, le enseña ese ticket.


Voy a poner el ejemplo del parque de atracciones. Una persona entra al parque, y en la caseta le dan una pulsera. Cuando vas a la atracción, enseñas la pulsera. No va el tipo de la atracción a preguntar al de la caseta si realmente esa pulsera es válida. Entiende que si.

Un apunte sobre esta diferencia, cuando hacemos "barra barra" para conectarnos a un recurso de red, si usamos IP en vez de Nombre, estaremos usando NTLM en vez de Kerberos. Existen ataques muy conocidos para NTLM basados en man in the middle por lo que es una buena práctica generalizada usar siempre nombres DNS, no direcciones IP.

Tenemos otros proveedores de autenticación en los sistemas Microsoft, estos se denominan SSPI (Security Support Provider Interface) y aquí tienes todos los disponibles

Esta imagen es la típica para explicar qué son estos interfaces.


Aquí aparece el famoso LSASS, el sistema local de autenticación, el encargado de recibir las credenciales del login y según el caso, equipo local ( SAM) o dominio ( DC) comprobar las credenciales. Otra función básicas del sistema LSA es proporcionar la "cache" de autenticación, es decir, lo que proporciona el Single Sign On del cliente. Te imaginas tener que meter la clave cada vez que accedes a un recurso del dominio? a una carpeta? a un buzón Exchange?

De esta manera, las credenciales "suelen" cachearse en memoria, en ese proceso. Haciendo Debug a ese proceso conseguimos obtener las credenciales en memoria con herramientas como Mimikatz. Vas hilando el asunto...?  Una de las guías que más mecanismos de protección presenta es esta del SANS.

Estos tips son muy básicos y son cosas que pasan en tus Windows sin darte cuenta. Otro día haremos un troubleshooting y veremos cómo trackear todo esto, al igual que debugear el logon. Muchas veces nos encontramos con tipos de registros que no muestran el equipo externo. Imagina un Imap de Exchange expuestos a internet produciendo fallos de login en un DC... crees que va a salir la ip del malo en Rusia? es un ejemplo !!! no os lo tomeis todo al pie de letra.

Por supuesto que el propósito de este post no es ofensivo. Ni tan siquiera defensivo, es solo algo de conceptos que debes conocer.

Gracias por leerme !!!!