miércoles, 23 de diciembre de 2020

Firma de scripts Powershell para cumplimiento elevado

 Estimados amigos de Inseguros !!!

El tema de hoy es la risa, porque no conozco empresa que lo tenga bien, y mira que doy vueltas por compañías de todo tipo...

Ejecución de scripts en Powershell. Recuerdo cuando se introdujo su uso, o mejor dicho, popularizó, con Server 2012 ejecutabas un script y no tiraba. En internet calculo que hay un millón y medio de post diciendo cómo desactivar la política de ejecución de scripts en Windows. ( 500.000 en castellano).

Hablo del famoso set-execution policy unrestricted

No voy a entrar en todos los modos que hay, ni los ámbitos de aplicación, ni como "hackear" esto. Voy a comenzar por el principio.

Por qué no dejas la configuración de ficheros firmados, e implementas la buena práctica de usar scripts firmados, o auto-firmados... pero desactivarlo la primera vez que usas PS y dejarlo así? así no my friend !!!

Los pasos son sencillos. Debemos instalar una Entidad emisora de Certificados como un role en nuestro server favorito. Siguiendo cualquier documental en video, o en Twich ( algún día opinaré sobre esto xD) o siguiente siguiente, podrás instalar por defecto una CA, que te vendrá bien para firmar tus apps internas, tu EFS, tu IPSEC o cualquier otro servicio que requiera de certificados dentro del dominio. En este caso, solo firmar tus scripts...

Con la CA instalada, el proceso es sencillo. Configuramos en la plantilla de certificados qué usuario o grupo podrá firmar scripts PowerShell.


Con esta modificación, o dejándolo por defecto para los administradores del dominio, habilitamos la plantilla para que esté disponible.


Ahora es el turno de cargar el complemento Certificados, en el almacén personal, solicitar un nuevo certificado de firma de código a la CA.


Una vez solicitado, exportamos el certificado que usaremos para cifrar.

Creamos una GPO e indicamos que este certificado es válido, de confianza. De esta manera podremos confiar en este script firmado en todo el dominio.


Después de una actualización Gpupdate, compruebo que tengo la política habilitada de solo firmados, ejecuto cualquier script chorra ( echo "hola mundo" ) y no lo ejecutará.

Firmas el script, y lo ejecutas y lo tienes...

$cert=(dir cert:currentuser\my\ -CodeSigningCert)
Set-AuthenticodeSignature ‘.\hello.ps1' $cert


Mira el contenido del script. Crees que si lo modificas la firma funcionará o tendrás que volver a firmarlo?

Sabes cómo ver las políticas de ejecución en tu dominio? Cómo cambiarlas? Cómo detectar si alguien quiere hacer un bypass? Sabes cómo hacer un bypass?



Estamos preparando el mejor curso de ciberseguridad Microsoft en castellano y tienes la posibilidad de recibir la información y descuento cuando salga. Si te interesa, apunta tu correo en el formulario y te informaré de las novedades.

Mientras tanto, y como siempre, me tienes aquí gratis para lo que necesites !!!

Gracias por leerme !!!


jueves, 17 de diciembre de 2020

Envía mail desde Powershell sin escribir a fuego la password en el fichero...

 Estimados amigos de Inseguros !!!

Creo que el título es suficientemente descriptivo como para todos los telespectadores xD pero por si acaso...

Un caso sencillo de scripts de envío de correo podría ir vinculado a un evento determinado, o por ejemplo una tarea programada que falla... los casos son muchos.


Escribir un script en Powershell para enviar correos es sencillo, pero tener una $password="12345678" es una mala práctica, porque los malos saben que lo haces/hacemos... y buscan en todo tipo de referencias buscando este tipo de comportamientos.

El procedimiento es más bien sencillo:

Volcamos en un fichero de texto la contraseña cifrada y hacemos el envío del correo ( o cualquier uso de credenciales)recuperando la clave cifrada y haciendo la magia descifrado.

El churro sería algo así:

"CacadeVaca123" | ConvertTo-SecureString -AsPlainText -Force | ConvertFrom-SecureString | Out-File "C:\EmailPassword.txt"

$Mensaje = "mimamamemima"
$User = "notificacionempresalab@gmail.com"
$File = "C:\EmailPassword.txt"

$cred=New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $User, (Get-Content $File | ConvertTo-SecureString)

$EmailFrom = "test_empresalab@gmail.com"

$EmailTo = "kinomakino_mecome_el_pepino@hotmail.com"

$Subject ="Alerta de registro."

$Body = "Se ha modificado el registro con ID $Mensaje"

$SMTPServer = "smtp.gmail.com"

$SMTPClient = New-Object Net.Mail.SmtpClient($SmtpServer, 587)

$SMTPClient.EnableSsl = $true

$SMTPClient.Credentials = New-Object System.Net.NetworkCredential($cred.UserName, $cred.Password); 

$SMTPClient.Send($EmailFrom, $EmailTo, $Subject, $Body) 

El comando ConverTo-SecureString hace uso de DPAPI ( Data Protection API) para usando un algoritmo de cifrado ( AES 256 en versiones modernas, 3DES en antiguas) para montar un hash en base al propio hash de la clave del usuario.

Si quieres conocer en profundidad cómo funciona el proceso de cifrado a bajo nivel, este es el mejor artículo que conozco.

Si te gustan estos artículos, hemos habilitado un formulario en la web para registrar tu correo y enviarte información para posibles formaciones de Ciberseguridad. Te apuntas?

Gracias por leerme !!!


lunes, 14 de diciembre de 2020

Microsoft, una compañía de ciberseguridad…

Estimados amigos de Inseguros !!!

Microsoft con el paso de los años se ha convertido en una empresa que constantemente estaba en el foco de las críticas por su modelo de ciberseguridad a ser una de las compañías que más apuesta por esta disciplina. No solo en cuanto a robustez de sus productos y servicios, sino como a su verticalidad con soluciones enfocadas a dicho segmento.
Si hace 20 años hiciéramos esta afirmación sin duda nos encontraríamos detractores, pero bueno, si lo hiciéramos hace 30 quizás ni se entendería el concepto. El mundo de la tecnología es así.
Cuántas discusiones sobre la seguridad de los sistemas Microsoft, sobre todo en bares de poca alcurnia con amigos linuxeros.

Recuerdo épocas en mi vida que haciendo "barra barra" a una IP pública (conectando equipos Windows 98 con modem) te daba acceso a la carpeta del usuario... o como barrer internet buscando Sql Servers con el usuario SA sin contraseña. Parece que esto fué hace siglos, y en ocasiones nos los encontramos, pero tenemos que reconocer que todo esto ha cambiado muchos en los últimos años.

Una fecha importante para la historia en la ciberseguridad de la empresa de Redmond fue el 15 de junio de 2002, donde Bill Gates envió una carta al persona con una iniciativa denominada Trustworthy Computing animando a los empleados a concienciarse en la ciberseguridad, con "todo eso del .net" y el futuro auge de Internet. Esto fue solo una carta... pero fue al pistoletazo de salida.

Organizaciones internacionales como Common Criteria realizan exhaustivos test de seguridad contra productos de distinta índole para certificar el grado de cumplimiento. No pienses en Catalina para Mac, Red Hat o Microsoft Server, hay todo tipo de productos que se ponen bajo el radar. Los sistemas operativos de la familia Microsoft siempre aparecen con altas certificaciones. 

Pero como todo en esta vida, habrá quien confíe más o menos en estos organismos, pero sin duda, el trabajo de Microsoft por establecerse como una compañía ciberseguridad, y más allá, de ciberseguridad, son patentes en pequeños gestos con un gran impacto. Pongamos como ejemplo la política de actualizaciones de Microsoft. Hace unos años era habitual encontrar con equipos MUY desactualizados. Tanto por un proceso formal, como por la calidad de los parches, los administradores encontraban en este requisito de actualización un gran problema. Un gran adelanto fue la programación mensual del ciclo de actualizaciones vigente en los productos. A día de hoy, lo veo una gran funcionalidad, el tener un calendario estable, en el que los departamentos puedan estar pendientes y planificar procesos de parcheo. No conozco muchos fabricantes que lo hagan así. Por ejemplo, un rival directo en los sistemas de bases de datos que todos conocemos por su Plsql es NEFASTO en esto. No en su "ciberseguridad". Todos los productos tienen fallos, sino en la gestión de los mismos. Paquetes de seguridad con 800 parches son el terror de cualquier SYSDBA y pone en valor la sencillez con la que Microsoft resolvió este proceso.

Otro de los procesos de mejora de la ciberseguridad que acometió Microsoft fue la creación de un programa de Bug Bounty o recompensa. Es un sistema en el que se "anima" a los investigadores a que realicen pruebas de seguridad contra determinados objetivos o áreas, y en función de los hallazgos se recompensa al investigador. Es decir, como hace el mundo del cibercrimen, ¡¡¡¡pero la recompensa es legal :-) Microsoft paga por reportar fallos !!!  no está mal, hay otras empresas que denuncia a los investigadores... 

¡¡¡Pero lo que todos lectores de esta humilde publicación quieren tecnología !!! quieren siglas, productos, protocolos!!! Microsoft más lejos de su programa interno, cuenta con un centro de respuesta e investigación muy potente a nivel mundial, que lucha contra el cibercrimen para los usuarios de internet, no solo para sus clientes. 

Tenemos más "siglas" para ti, Atp, el antivirus de nueva generación de Microsoft con capacidades de EDR. Si esto lo hubieran previsto los vendors de la industria hace 15 años diría que tienen capacidades de "futurología". Microsoft haciendo antivirus, además, de los más potente del mercado. No se basa en la detección por firmas, sino que implementan un potente motor heurístico con todo tipo de servicios añadidos, no sólo la detección del malware, sino el comportamiento, aprendizaje, etc. Sin duda una revolución en la ciberseguridad Microsoft !!!

Si hablamos de la nube de Microsoft, Microsoft 365 y Azure la ciberseguridad es una pata más de los servicios, como puedan ser los Gigas de Ram o las instancias de CPU. Los servicios de ciberseguridad de Microsoft contemplan toda la fase de un incidente, Impedir, detectar, mitigar, investigar, responder... Podemos conectar nuestros SIEM´s, pero también tenemos el SIEM de Microsoft, Sentinel !!!. Algo joven pero prometedor, que está abarcando las miradas de toda la industria relacionada por su potencia. podemos usar servicios de Data Lost Prevention, gestión de identidades, podemos analizar cumplimientos normativos como PCI-DSS... 

MSRC 1

El centro de respuesta de seguridad de Microsoft se alza como uno de los organismos protector de la ciberseguridad mundial en ámbitos de nuestra vida de todo tipo. 

A finales del mes de octubre, el MSRC reportaba un fuerte ataque del grupo denominado APT35 con origen en Irán, basado en una campaña de phishing dirigida a los miembros de importantes conferencias de seguridad nacional, con el objetivo de obtener de realizar contra-inteligencia a los gobiernos. Las primeras actividades del denominado APT35 se vienen desarrollando desde 2013 y se continúa con la lucha para dar caza a dicho colectivo.

En un ámbito un poco más tecnológico, el MSRC desmanteló recientemente la famosa red de ransomware Trickbot. Esta red llevaba desde 2016 casi 1 millón de infecciones controladas. La compañía analizó más de 60.000 variantes de código de dicha pieza de malware.

Estas redes emplean mecanismos de evasión de seguridad y persistencia para hacer muy difícil el análisis y comportamiento, y así rentabilizar la inversión tecnológica del grupo criminal, haciendo que durante más tiempo la muestra sea indetectable por las soluciones de seguridad, y así poder infectar al más número posible de víctimas, o simplemente permanecer más tiempo vigente.

En el último reporte de actividad publicado por Microsoft podemos conocer de primera mano las tendencias en ciberataques detectados por el MSRC de la última parte del año y el impacto del Covid19 en el panorama del cibercrimen.

Conclusión

Adoptar las tecnologías de Microsoft siempre ha tenido la ventaja de la interoperabilidad entre sus distintos componentes, y sin duda, poder contar con el gigante de Redmond como aliado en nuestro proceso de mejora de la ciberseguridad es algo positivo. Bien empleando de manera segura sus servicios/productos, o usando los destinados a proteger la organización, contamos con una apuesta firme y continuidad de la casa y lo considero una apuesta ganadora.


Gracias por leerme

viernes, 4 de diciembre de 2020

Usar Windows Event Forwarding para aglutinar logs centralizadamente sin herramientas de terceros

 Estimados amigos de Inseguros !!!

Cuando hablamos de ciberseguridad, siempre nos gusta hablar de complejas técnicas de ataque, de exploits de nueva generación con evasión de AMSI y todo tipo de perrerias técnicas.

Desde Inseguros siempre apostamos por construir un sistema desde lo básico, con el Fix The Basics y las ideas claras, y pasito a pasito.

Al igual que digo que la seguridad empieza por el inventario, la gestión de eventos, de logs, es la siguiente pieza para una correcta visibilidad, monitorización.

Mi experiencia en el mundo Microsoft es que los logs se emplean para realizar resolución de problemas, cuando tienes algo que no va... esto en el mejor de los casos. Otros administradores buscan ayuda fuera o en Google sin ni siquiera mirar sus eventos...

Los que nos dedicamos a la ciberseguridad tenemos claro que el SIEM es una pieza importante, ese sistema que concentra los logs de todo tipo de sistemas, y que aportan un sinfín de ventajas a la hora de detectar ataques.

En los entornos menos maduros es inviable la adquisición del mismo, ya que si bien el coste al final son euros o dólares o pesos... el factor humano de la gestión es fundamental, y mucho más costoso que el licenciamiento. No os imagináis la cantidad de organizaciones que compran el SIEM fantástico de turno e incluso está apagado.

En el artículo de hoy vamos a repasar una función de los sistemas Microsoft Server 2012 en adelante que es la capacidad de enviar-adquirir eventos.

Vamos con las imágenes que se explican mejor que yo.


Una vez habilitado el colector, activamos una GPO sobre los equipos que queremos habilitar con enviadores. Para esto, lo mejor es una UO de servidores?


Server=http://Myservername(fqdn):5985/wsman/SubscriptionManager/WEC

El siguiente paso es usar el grupo restringido Lector de registro de evento y añadir el usuario Servicio de Red al grupo para darle permisos de lectura.



Si usas un sistema 2016 o 2019 como collector, deberás cambiar los permisos del webservices que escucha WINRM mediante estos comando. Puedes leer el por qué aquí

netsh http delete urlacl url=http://+:5985/wsman/

netsh http add urlacl url=http://+:5985/wsman/ sddl=D:(A;;GX;;;S-1-5-80-569256582-2953403351-2909559716-1301513147-412116970)(A;;GX;;;S-1-5-80-4059739203-877974739-1245631912-527174227-2996563517)

netsh http delete urlacl url=https://+:5986/wsman/

netsh http add urlacl url=https://+:5986/wsman/ sddl=D:(A;;GX;;;S-1-5-80-569256582-2953403351-2909559716-1301513147-412116970)(A;;GX;;;S-1-5-80-4059739203-877974739-1245631912-527174227-2996563517)

Por último, tienes que configurar el formato de los eventos que se envían para que lo haga en el formato del visor de eventos nativos

Wecutil.exe ss ata /cf:Events

Si eres como yo, algo nervioso, puedes forzar un evento en el "sender" para comprobar que recibes.


Si tienes seguridad en el WINRM, tendrás que cambiar la directiva de grupo que restringe las direcciones IP de origen de la comunicación, pero solo si estás en un entorno altamente securizado.


Una vez configurado el sistema, nos vamos a la rama del visor de eventos de suscripciones, como empezó todo esto, y gráficamente podemos indicar sobre qué equipos queremos recibir los eventos y qué tipo de eventos.


Es aquí donde puedes configurar un pre-indexer para ahorrar envio, y solo recibir los id de eventos que te interesan.

Sin duda, muy útil, tanto si estás en un entorno con SIEM o sin él. Si tienes uno, te ahorras estar desplegando en todos los servidores el agente de turno. Puedes centralizarlo todo en en servidor y posteriormente instalar el agente solo en el "hub" que aglutina los eventos.

Y después de unos Gpupdate /force tendrás tus logs centralizados bajo la rama que hayas configurado.


Espero que te haya servido de ayuda.

En unos días lanzaremos un curso en profundidad de seguridad en sistemas Windows, para conocer mejor las bases técnicas de los Windows y Active Directory, como atacarlos, y cómo defenderlos.

Si crees que puedes estar interesado, puedes enviar un mail a formacion@seguridadsi.com y te mantendremos informado.

Gracias por leerme !!!