Habilitar BitLocker en Windows 10 desde Microsoft Intune

BitLocker es una tecnología de cifrado a nivel de unidad disponible desde Windows 7 Enterprise. En un principio, solo se podía activar en ediciones Enterprise y su administración era a través de directivas de grupo; sin embargo, el producto evolucionó en cuanto a características y pasó a ser parte de Pro en Windows 8/1 en adelante, además de agregar administración desde Microsoft BitLocker Administration and Monitoring (MBAM), consola que me permitía gestionar todas las operaciones de una forma mucho más productiva que simples directivas de grupo.

Con la evolución de Microsoft Intune y la nueva era de escritorio moderno, la administración de BitLocker ahora se está llevando a la nube para mayor simplicidad y aunque ya Microsoft anunció varias características interesantes que vienen pero no están listas, ya es posible aprovechar otras tantas funcionalidades desde Intune.

En este artículo vamos a configurar Intune para activar un cifrado básico en todos los equipos Windows 10 que estén registrados.

Requerimientos

  1. Tener el dispositivo Windows registrado en Microsoft Intune
  2. Licencia de EMS + Security o Intune de forma independiente
  3. Tener instalado como mínimo Windows 10, versión 1803. Recomiendo 1903

Grupo de dispositivos

Aunque la asociación de Intune suele hacerse hacia los usuarios que estén registrados, la directiva se aplica directivamente a cada dispositivo. Es por esta razón que debemos asegurarnos de tener un grupo que cumpla nuestras funciones de piloto antes de crear la directiva.

Para crear el grupo, ingresamos al portal de Azure, vamos al Azure Active Directory, luego en Groups y creamos un nuevo grupo haciendo clic en el botón superior de New group

image

En la página de New Group, le indicamos un nombre a nuestro grupo de dispositivos, descripción opcional y luego hacemos clic en Members:

image

En la página de Members, buscamos el dispositivo por su nombre, hacemos clic sobre él y luego clic en el botón Select.

Nota: aquí es donde aprovechamos a agregar todos los dispositivos que recibirán la directiva.

image

De vuelta en la página de New Group, hacemos clic en el botón de Create para que el grupo quede agregado a Azure AD.

Creación de directiva

En el portal de Azure, vamos a Intune, luego Device Configuration, Profiles y hacemos clic en el botón de Create profile en la parte superior:

image

En la página de Create Profile, indicamos un nombre, seleccionamos Windows 10 and later como Platform, Endpoint protection como Profile type, le damos clic en el botón de Settings y finalmente escogemos Windows Encryption:

image

En el nodo de Windows Encryption es donde podremos configurar todas las opciones disponibles de BitLocker para unidades de sistema operativo y externas, esto incluye: recuperación, tipos de seguridad, mensajes opcionales, etc. Adicional a esto, hay otras tantas directivas OMA-URI disponibles para BitLocker, pero no entraremos en detalle aquí.

Para este artículo, vamos a empezar por habilitar el cifrado cambiando a Require la opción de Encrypt devices en la categoría de Windows Settings:

image

En la categoría de BitLocker OS Drive Settings, activamos lo siguiente:

Additional authentication at startup: Require

OS drive recovery: Enable

Save BitLocker recovery information to Azure Active Directory: Enable

Store recovery information in Azure Active Directory before enabling BitLocker: Require

image

Lo más importante a destacar aquí es que utilizaremos TPM con alguna de las opciones adicionales como PIN o llave y guardaremos la clave de recuperación en el objeto de Azure AD.

Hacemos clic en el botón OK de Windows Encryption al final del panel, luego OK en el panel de Endpoint protection y finalmente Create en la página de Create Profile para terminar.

Asignación de directiva

Como regla general en Intune, cada directiva que se cree debe asignarse a un grupo de usuarios o dispositivos para que pueda empezar a funcionar, muy similar al las directivas de grupo tradicionales.

Para asignar la directiva, estando dentro de la política en cuestión, hacemos clic en Assigments:

image

En la página de Assignments, debajo de Include, hacemos clic en Select groups to include, buscamos nuestro grupo de dispositivos creados previamente, hacemos clic sobre él y luego clic en el botón de Select:

image

Por último, hacemos clic en el botón de Save que se habilitará luego de agregar el grupo:

image

Pruebas funcionales

Si todo sale bien, en cuestión de minutos todos los equipos que pertenecen al grupo y reciben la política deberían indicar que es necesario hacer el cifrado de máquina:

SNAGHTML5fd115ad

En caso de que el usuario cierre el mensaje haciendo clic en el botón de No, el mensaje se volverá a mostrar después de un rato o de un reinicio. Si el usuario selecciona «No volver a preguntar», el cifrado no se iniciará y tampoco volverá a aparecer el mensaje.

Infortunadamente, no he encontrado forma soportada de evitar que se pueda seleccionar esa opción o que al menos se pueda forzar a aparecer el cuadro de nuevo, la única manera fue recurriendo a Process Monitor y viendo qué hacía Windows al momento de escoger «No volver a mostrar»:

image

Como pueden ver, se crea un valor llamado UserOptedOutEncryptionNotification con un tipo de dato REG_DWORD y contenido de 1, es decir, habilitado en la sublcave:

HKEY_LOCAL_MACHINE\Software\Microsoft\BitLockercsp\UserOptions

Basta con eliminar ese valor y reiniciar o esperar un rato a que el cuadro vuelva a aparecer.

Como dato adicional, es necesario seleccionar la primera opción para iniciar el cifrado. Cuando presionemos Sí, Windows iniciará el asistente normal de cifrado de unidad de BitLocker:

image

En el primer paso normalmente conviene utilizar una contraseña personal para desbloquearla, después escogemos el método de recuperación que deseemos:

image

*Nota: sin importar cuál escojamos, desde las directivas ya estamos obligando a que la clave de recuperación se guarde en la nube, es decir, la primera opción.

En la página de Elegir qué cantidad de la unidad desea cifrar, dejamos la opción predeterminada y hacemos clic en Siguiente:

image

En la página de Elección del modo de cifrado que se usará, dejamos el de Modo de cifrado nuevo y clic en Siguiente:

image

Finalmente, en la página de ¿Está listo para cifrar esta unidad?, hacemos clic en Continuar:

image

Solo nos queda esperar hasta que el cifrado se complete:

image

En un próximo artículo explicaré el proceso de recuperación que existe actualmente en caso de que el usuario tenga problemas para ingresar en un disco cifrado.

Saludos,

—Checho

Ejecutar scripts de PowerShell desde un paquete de Advanced Installer

Aunque este fue creado principalmente para hablar de temas alrededor de Windows, me gusta compartir cosas que comparto y que me gustan con tecnologías o productos que utilizo. En esta ocasión, quiero hablar nuevamente de Advanced Installer, pues suelo utilizarlo bastante y cada vez me parece más indispensable tenerlo (junto con Snagit).

Muchas veces en los proyectos en los que estoy necesitamos realizar alguna tarea que implica hacer configuraciones, no siempre complejas, pero que sí requieren varios pasos, así que trato siempre de de automatizar todo creando un paquete de instalación con Advanced Installer, pues me permite agregar archivos, claves/valores de registro, configuración de permisos, entre muchas otras.

En este caso en particular, necesitaba instalar unos módulos de PowerShell  después de instalar algunos componentes de Microsoft, y aunque ejecutando el script de por sí es sencillo, no quería complicar a la persona que despliega con pasos manuales que requiere la ejecución de scripts, así que opté por utilizar Advanced Installer para facilitar un poco la tarea.

Cabe aclarar que en este artículo no explicaré cómo crear y configurar paquetes de Advanced Installer, solo me enfocaré en las acciones personalizadas.  

Custom Actions en Advanced Installer

Las Acciones personalizadas (Custom Actions) nos permiten ejecutar tareas o acciones que se lanzan en varias partes del proceso de instalación, casi siempre en la mitad o al final. Estas acciones son manejadas por el proceso de instalación, así que todo se mantiene en una sola ventana y la mayoría de veces permite automatización completa para que no haya demasiada interacción por parte del usuario, todo depende de qué se quiera hacer dentro de la lista disponible.

image

Hay una lista bastante grande debajo del cuadro de Add Custom Action. Cada acción tiene una leve descripción en la parte inferior del cuadro y todas están un poco más documentadas en la página oficial de Advanced Installer. Para agregar alguna basta con hacer clic en los botones de la derecha; la primera opción es la más sencilla pues se agrega al proceso natural de instalación:

image

Existen dos tareas que son particulamente útiles para el caso de este artículo:

Run PowerShell inline script: esta es una acción personalizada que me permite agregar un script completo de PowerShell dentro del ambiente de Advanced Installer, probarlo antes de compilar y agregarlo al proceso normal de instalación.

image

Run PowerShell script file: a diferencia del anterior, esta tarea me permite agregar el archivo de PowerShell completo para ser ejecutado. Puede ser desde una ubicación en disco o adjunto al paquete de instalación.

image

Ambas opciones permiten probar el script antes de compilar y guardar, así que es cuestión de qué tan completo sea el script.

En la experiencia personal, me ha funcionado mejor utilizar la primera opción y ejecutar todo el script desde el editor integrado. Para mi caso, quise instalar unos módulos de PowerShell para administración de diferentes componentes de Office 365.

Consideraciones a la hora de ejecutar scripts de PowerShell con Advanced Installer

A continuación les listaré, basados en lo que tuve que pasar, todo lo que es necesario tener en cuenta a la hora de ejecutar un script de PowerShell:

  1. Indispensable: cada línea debe de poderse ejecutar sin ninguna interacción del usuario, pues predeterminadamente la respuesta de Advanced Installer es rechazar la petición. Es muy común ver esto en algunos algunos cmdlets como Install-Module, así que siempre es necesario agregar el parámetro de –Force al final, por ejemplo:

    Install-Module -Name AzureAD –Force

  2. Es muy importante probar toda la ejecución del script aparte, pues muchas veces algún módulo, como el de AzureAD, requiere instalar previamente un Nuget y esto debemos garantizaro igualmente de forma automatizada

  3. En caso de ir a ejecutar el paquete en un equipo de 64 bits, debemos marcar la opción de 64 bit script en la parte superior derecha, pues de lo contrario el script no funcionará

SNAGHTML2315f52a

Lo que sigue de aquí es solamente compilar el paquete, desplegarlo y listo. Advanced Installer se encarga de configurar la ejecución de scripts remota (Set-ExecutionPolicy) para no tener ese tipo de problemas.

En caso de tener problemas, la mejor opción es habilitar los logs detallados del Advanced Installer y analizar la respuesta de PowerShell: https://www.advancedinstaller.com/user-guide/faq-ca.html#question98

Espero sea de utilidad.

Saludos,

—Checho

Crear directiva de cumplimiento para Windows 10 en Intune

Como indiqué en un artículo anterior, el procedimiento natural después de unir uno o múltiples dispositivos a Microsoft Intune es empezar a gestionarlos, es decir, aplicarle directivas de configuración o de seguridad, se a través de las que están preestablecidas o utilizando las que hacen parte del OMA-URI.

Ahora bien, por motivos de seguridad siempre es conveniente tener una base de cumplimiento para saber que cada dispositivo unido cumple con estándares definidos por la organización. Microsoft Intune nos permite crear algunas directivas de cumplimiento tanto para dispositivos móviles como para estaciones Windows de una forma muy sencilla, así que utilizaré el resto del artículo para describir el proceso, aunque solo me enfocaré en Windows 10 por ahora.

Requisitos

1. Es necesario contar con licencia de Intune y de Azure Active Directory Premium. Ambas están incluídas en los planes de Enterprise Mobility + Security (EMS)

2. Utilizar una plataforma soportada:

  • Android
  • iOS
  • macOS
  • Windows 8.1
  • Windows 10

3. El dispositivo tiene que estar inscrito en Microsoft Intune

4. Para Conditional Access: no están soportados los equipos unidos con la inscripción múltiple de dispositivos, tiene que ser individual

Crear directiva de cumplimiento

1. Iniciamos sesión en el portal de Azure con la cuenta administrativa: https://portal.azure.com

2. En la barra de búsqueda de arriba, digitamos Intune y seleccionamos Intune:

image

3. En la página de Microsoft Intune, seleccionamos Device Compliance en el panel izquierdo:

image

4. En la página de Device Compliance, hacemos clic en Policies y luego en Create Policy

image

5. En la página de Create Policy, indicamos un nombre, descripción y como plataforma escogemos Windows 10 and later:

image

6. Hacemos clic en Settings, luego en Device Health, activamos como Require la opción de Require BitLocker y hacemos clic en OK en la parte inferior:

image

7. En la página de Windows 10 complicance policy, hacemos clic en System Settings para expandir otras configuraciones, activamos Firewall y Antivirus y luego clic en OK:

image

En este artículo solo referencié algunas directivas, pero cada organización debe acomodarse a sus necesidades.

8. En la página de Windows 10 compliance policy, hacemos clic en OK

9. En la página de Create policy, hacemos clic en el botón de Create en la parte inferior:

image

10. En la página de la directiva creada, en mi caso Windows Compliance, hacemos clic en el botón izquierdo de Assignments, luego en el botón central de Select groups to include y agregamos el grupo al que pertenezcan los usuarios que están iniciando sesión en los dispositivos a evaluar. Después de esto, hacemos clic en el botón de Save para guardar:

image

Intune hará la evaluación cada 8 horas aproximadamente después de los primeros 30 minutos de haberlo unido al MDM. Mientras eso pasa, es probable que vean los dispositivos en la categoría de Not Evaluated:

image

Lamentablemente, el cuadro anterior es de los que más se demora para actualizarse, así que yo diría que es poco confiable, a menos que se le de el tiempo adecuado.

Si queremos ver el detalle de lo que cumple, no cumple o no aplica, basta con ir a la consola de Intune y hacemos clic en Setting compliance, debajo de la categoría de Monitor. En  el panel central veremos un desglozado de lo que aplicamos como cumplimiento y sus resultados:

image

Aunque personalmente las directivas de cumplimiento en Intune creo que les falta mucho, se pueden utilizar para hacer cosas mucho más interesantes si se unen con el Acceso condicional, pero eso será probablemente para otras entradas del blog.

Espero les sea de utilidad.

—Checho

Inscribir múltiples dispositivos Windows 10 a Microsoft Intune con un paquete de aprovisionamiento

Con la fuerte apuesta de Microsoft a la seguridad y la nube, Microsoft Intune, su plataforma de administración de dispositivos, ha tomado mucha más fuerza, al punto de entrar en el grupo que lidera el cuadrante de Gartner en temas de Unified Endpoint Management, así que se vuelve bastante conveniente empezar a profundizar en todo lo que la plataforma brinda.

Como cualquier otra plataforma de administración, es necesario registrar o inscribir el dispositivo (PC, tablet o móvil) de alguna forma, Intune no es la excepción. Hablando específicamente de Windows, se puede hacer desde el OOBE (manual o a través de Autopilot) o ya en Windows; sin embargo, con el fin de optimizar el proceso para escenarios de muchos dispositivos, es posible configurar un paquete de aprovisionamiento que sirva para unir múltiples dispositivos utilizando un solo token; es decir, sin necesidad de depender de cada cuenta de usuario.

A continuación, les mostraré, paso a paso, cómo podemos crear y desplegar el paquete de aprovisionamiento.

Requerimientos

  1. Todos los equipos deben estar en Windows 10, versión 1703 o superior
  2. Asignar licencia de Intune a la cuenta que se le asociará el token (ver más adelante)
  3. Habilitar la inscripción automática de dispositivos (ver más adelante)
  4. Instalar en un equipo técnico el ADK para Windows 10, versión 1809

Asignar licencia de Intune

Una vez creado el tenant de Intune o EMS (dependiendo del licenciamiento), navegamos hasta el portal de administración de Office 365 e iniciamos sesión con una cuenta administradora: https://portal.office.com/AdminPortal

Una vez en el portal, expandimos el nodo izquierdo de Users y luego clic en Active users

image

Hacemos clic sobre el usuario que deseamos asignarle la licencia de Intune:

image

En la página de usuario que se abre a la derecha, hacemos clic en el botón Edit que está en la parte derecha de Product licenses:

image

En la página de Product licenses, cambiamos de Off a On Intune o Enterprise Mobility + Security:

image

Por último, clic en el botón inferior de Save:

image

Clic en el botón de Close dos veces y cerramos la página de administración de Office 365.

Este mismo procedimiento lo debemos realizar para cada nuevo usuario cuyo dispositivo se vaya a conectar a Microsoft Intune.

Habilitar inscripción automática

1. Iniciamos sesión en el portal de Azure con la cuenta administrativa: https://portal.azure.com

2. Ubicamos y hacemos clic sobre Azure Active Directory en el panel izquierdo:

image

3. En la página de Azure Active Directory, seleccionamos Mobility (MDM and MAM)

image

4. Seleccionamos en el panel central Microsoft Intune

image

5. En la página de Configure, nos aseguramos de seleccionar All en MDM User scope para que todos los dispositivos de usuarios se puedan inscribir a Microsoft Intune:

image

Adicionalmente, pueden habilitar también MAM User scope para administrar los dispositivos móviles, aunque eso hace parte de otros posibles artículos.

En un escenario ideal, seleccionaríamos Some y ahí pondríamos un primer grupo de usuarios de pruebas antes de poder habilitar a toda la organización.

Con esto estamos listos para que los dispositivos con Windows 10 puedan ser administrados por Microsoft Intune.

Crear el paquete de aprovisionamiento

1. En el equipo técnico donde instalamos el ADK para Windows 10, versión 1809, ejecutamos el Windows Imaging and Configuration Designer como administradores

2. En la ventana de Windows Imaging and Configuration Designer, seleccionamos el nodo de Provision desktop devices:

image

3. En la ventana de New project, asignamos un nombre, una descripción (opcional) y hacemos clic en el botón de Finish:

image

4. En la categoría de Set up device, es obligatorio asignar un nombre de equipo. El paquete soporta un par de formatos: %SERIAL% y %RAND%. El primero pone el serial que toma del hardware de la máquina, el segundo asigna un número aleatorio según la cantidad que le demos. Para este caso, yo le pondré: INSIDO-%RAND:4%

image

Es muy importante no ir a asignar un nombre sin estas variables porque entonces todos tratarían de unirse como si fueran el mismo dispositivo y no funcionará.

5.  Hacemos clic en Account Management, seleccionamos Enroll in Azure AD y luego hacemos clic en el botón de Get Bulk Token:

image

6. Seguimos el asistente para iniciar sesión con la cuenta administrativa y obtener el token:

image

6. Si el equipo técnico no está unido a Azure AD, nos aparecerá otra página en donde debemos indicarle en la parte inferior This app only para terminar:

image

Si todo sale bien, nos debe decir «Bulk Token Fetched Successfully»:

image

7. Hacemos clic en el botón Finish y luego en Create para que el paquete compile:

image

8. Si todo sale bien, tendremos un enlace en la parte inferior para nuestro paquete similar a este:

image

Desplegar el paquete de aprovisionamiento

Aunque hay diferentes formas de implementar el paquete de aprovisionamiento, incluso de forma desatendida con PowerShell, lo haré de la forma más simple: copiar el paquete localmente a cada máquina.

1. Una vez copiado en cada equipo, hacemos doble clic sobre el paquete

2. Si nos sale la ventana del UAC, hacemos clic en el botón (Yes)

image

3. En la ventana del paquete de aprovisionamiento, confirmamos que se trate del que creamos y hacemos clic en el botón Sí, agregarlo:

image

Si todo sale bien, el equipo debería reiniciarse solo al momento de aplicarlo (1 min.):

image

4. Al reiniciar el equipo, estará conectado a Azure Active Directory e inscrito a Microsoft Intune. Cada nuevo usuario ya podrá iniciar normalmente con su cuenta profesional:

image

Como dije antes, es necesario que el usuario no tenga restricciones para iniciar sesión con su cuenta de Azure AD y que además tenga su respectiva licencia de Microsoft Intune asignada para poder recibir directivas desde la nube.

Visualizar los equipos inscritos en la consola de Intune

Para estar seguros de que todo salió bien, podemos visualizar los dispositivos inscritos directamente en la consola de Intune:

  1. Navegamos hasta https://portal.azure.com e iniciamos sesión con una cuenta de administrador

  2. En la barra de búsqueda superior, digitamos Intune y hacemos clic en Intune para abrir la consola:

image

  1. En la consola de Intune, hacemos clic en Devices en el panel izquierdo:

image

  1. En la página de Devices, hacemos clic en All devices, debajo de la categoría de Manage

image

  1. Aquí podremos ver todos los dispositivos inscritos correctamente a Intune:

image

Como pueden ver, tengo dos dispositivos con el formato de nombre que puse en el Configuration Designer al momento de crear el paquete.

De aquí en adelante ya podemos empezar a gestionar los dispositivos:  directivas, líneas base, etc. Espero compartir algo de esto en futuros artículos.

Cabe aclarar que con este método de inscripción no funciona el Acceso condicional (Conditional Access) sobre los dispositivos.

Espero sea de utilidad.

—Checho

La pantalla blanca al iniciar PES 2019, Process Explorer, Procdump, Windbg y su solución

Desde los tiempos de Winning Eleven, he sido fiel seguidor de Pro Evolution Soccer (PES), primero en la consola de Play Station y luego en el PC hasta el son de hoy. Aunque ya no lo hago todos los días, con regularidad entro en las noches para jugar un rato después de trabajo. Para mi fortuna, casi nunca tengo problemas con la plataforma de Steam, sin importar que estoy instalando todas las compilaciones que salen del programa de Windows Insider; sin embargo, ayer iba a jugar en la noche y me di cuenta de que el juego no estaba entrando, solo aparecía la pantalla blanca y se cerraba:

image

Después de revisar actualizaciones de Windows y hacer un reinicio del equipo, probé yendo a las propiedades del juego en Steam, pestaña de Local Files y utilicé la opción de Verify itegrity of ame files:

SNAGHTML12e95ca

En principio parece que iba a funcionar porque hace reparaciones si encuentra algo raro, pero la pantalla blanca solo se prolongó por unos segundos más antes de cerrarse inesperadamente otra vez. Como no estaba dispuesto a ponerme a descargar otra vez un juego tan pesado sin saber si solucionaría el inconveniente, decidí ponerme a diagnosticar para intentar encontrar la forma de volver a jugar.

Lo primero que hice fue verificar si el juego se estaba cerrando completamente, para eso abrí Process Explorer, fui al menú de Options, luego Difference Highlighting Duration y lo establecí a lo máximo, es decir, 9 segundos, para poder alcanzar a ver cuáles procesos se cerraban mientras cambiaba entre aplicaciones.

Efectivamente, me encontré con que el juego se estaba cerrando abruptamente después de que desaparecía la ventana en blanco:

image

El otro detalle importante es que también se estaba activando el reporte de errores de Windows, WerFault.exe, que me indicaba que estaba sucediendo un crash de la aplicación:

image

¿Qué estaba impidiendo la ejecución del juego? Pues bien, existen muchos motivos por los que una aplicación puede hacer crash al ejecutarse, incluso diferentes soluciones; una de las formas más productivas para encontrar la causa es obtener un volcado de memoria del proceso en el momento del fallo y proceder a analizarlo con un depurador como Windbg. No es una tarea muy sencilla por lo técnico que puede volverse, pero generalmente solo se necesitan algunos conocimientos básicos para dar con la pista del problema.

Procdump, al rescate

Procdump es una herramienta que hace parte de la suite de Sysinternals y que permite generar volcado de memoria según los parámetros que le indiquemos al proceso que debe de monitorear: excepciones, hangs, etc. Para no complicarme tanto organizando los parámetros, en parte porque no soy muy bueno con la herramienta, opté por utilizar el parámetro –i para instalar el controlador de Procdump indicando la ruta donde quería los volcados para que él mismo me escribiera uno cada que hubiese una excepción en Windows. El comando completo es:

procdump.exe –i C:\Dumps

image

La ruta final puede ser cualquiera, yo traté de mantenerlo simple.

Tan pronto intenté jugar nuevamente, la pantalla se puso blanca, la aplicación se cerró y Procdump hizo lo suyo: crear el volcado de memoria que necesitaba.

image

Windbg

Con el volcado de memoria ya creado, procedí a ejecutar Windbg, abrir el .DMP que había generado el Procdump y finalmente corrí el comando de !analyze –v para que hiciera un análisis automático:

image

Normalmente el análisis que hace Windbg se acerca mucho al controlador o módulo que ocasiona la falla, aunque puede llegar a reportar varios que no están dentro de los símbolos:

image

Lo malo de esto es que muchas veces salen falsos positivos porque indica controladores o componentes propios del sistema operativo como desconocidos.

La forma más fácil de identificar el posible causante es mostrar la pila de ejecución que había al momento del crash y empezar desde la función que le indica a Windows que debe detenerse hacia abajo hasta encontrar controladores o módulos de terceros para analizar con más detalles. En mi caso, encontré dos: NvCamera64 y nvwgf2umx.

image

Windbg permite utilizar el comando lmvm para obtener detalles de cada controlador o módulo. Al ejecutarlo con cada uno, me di cuenta de que pertenecían a NVIDIA:

image

Aunque el primero no tenía la descripción, el segundo, nvwgf2umx, indicaba que era del controlador de D3D10.

Imagino yo que no funcionaba alguna actualización de PES 2019 o la última compilación de Windows, así que mi camino fue ir al GeForce Experience y buscar a ver si existía un nuevo controlador; efectivamente, no hace mucho habían liberado otra versión:

image

Después de hacer una instalación limpia desde el asistente y reiniciar Windows, ejecuté nuevamente el juego y, para mi tranquilidad, todo había vuelto a la normalidad:

image

Una vez más, todo salvado gracias a estas maravillosas herramientas y un poco de investigación.

Saludos,

—Checho

Empaquetar una aplicación de 16 bits a 32 bits con Advanced Installer

Si alguno de ustedes trabaja con implementación masiva de sistemas operativos Windows o ha estado en algún proyecto de migración, seguramente se habrán topado con un escenario inevitable de compatibilidad de aplicaciones, pues suelen ser aplicaciones necesarias para el negocio pero demasiado viejas. Como además las migraciones se hacen a Windows en arquitectura de 64 bits por el aprovechamiento de recursos, se van a encontrar con aplicaciones que funcionan bien en 32 bits, pero que al momento de ejecutarlas en un sistema de 64 bits reciben este tipo de mensajes:

image

Como probablemente sepan, Windows en arquitectura de 32 bits puede ejecutar aplicaciones de 16 bits, pero un sistema a 64 bits solo puede llegar a ejecutar aplicaciones de 32 bits, por lo que las que estén en 16 bits no serán compatibles. Ahora, una aplicación puede tener sus binarios después de la instalación nativamente en 16 bits o bien pueden estar en 32 bits y solamente el paquete de instalación en 16 bits; en el primer caso la única solución es compilar toda la aplicación desde el código en una nueva arquitectura, aunque eso casi nunca se puede hacer por falta de tener el código original. Si es el segundo caso, el camino, como lo voy a mostrar aquí, es construir un nuevo paquete de instalación que esté en 32 bits y pueda ser ejecutado en un sistema de 64 bits con la ayuda de Advanced Installer.

Hay un proceso de mucho más nivel para hacer esto descrito por Aaron Margosis de Microsoft en este artículo, mas no lo seguiré aquí

Requerimientos

1. Tener instalado Advanced Installer en un equipo técnico

Nota: Advanced Installer es un producto licenciado, aunque tiene período de prueba.

2. Tener instalado VMWare Workstation. Se puede hacer con Hyper-V, pero la experiencia no es tan transparente, lamentablemente

3. Instalar una máquina virtual de Windows 10 a 32 bits desde Advanced Installer. Pueden ver el detalle en su página oficial

4. Crear un snapshot de la instalación de Windows de 32 bits en limpio. Si no saben hacerlo en VMWare, pueden ver el procedimiento oficial en su página

Nota: les recomiendo que antes de tomar el snapshot descarguen todas las actualizaciones, deshabiliten internet, notificaciones, antivirus, actualización de aplicaciones, notificaciones y cualquier otra interrupción en el proceso de empaquetamiento

3. Guardar el instalador de la aplicación de 16 bits en el equipo técnico

<

p align=”justify”>4. Descargar Sigcheck de Sysinternals en el equipo técnico

1.0. Instalación manual de la aplicación en equipo de 32 bits

¡Empecemos! Lo primero que tenemos que hacer es instalar la aplicación de 16 bits en el equipo virtual que creamos en el tercer requerimiento para asegurarnos de que el binario que se ejecuta en Windows es, efectivamente, de 32 bits. Como aquí la aplicación será diferente en cada escenario, no mostraré procedimiento de instalación.

1.1. Comprobación de arquitectura con Sigcheck

Una vez instalada, debemos ejecutar Sigcheck e indicarle como único parámetro la ruta completa del ejecutable. Sigcheck nos dirá el MachineType, que corresponde a la arquitectura en la que corre la aplicación:

image

En mi caso, el resultado es 32-bit, así que no es el binario el que está en 16 bits, sino el instalador, tal como lo puedo comprobar corriendo Sigheck con el nombre del instalador:

image

Noten que el MachineType es 16-bit.

Opcionalmente, pueden utilizar la función GetBinaryType de la API de Windows para obtener la misma información, por ejemplo:

SNAGHTML626df8a

Con esto confirmado, ya sabemos que simplemente debemos construir un nuevo instalador que soporte la arquitectura de 32 bits mínimamente para que funcione en ambos, 32 y 64 bits.

2.0. Empaquetamiento de la aplicación utilizando el Repackager de Advanced Installer

2.1. Sobre el Repackaging

El proceso de empaquetamiento es uno de los más interesantes de Advanced Installer: consiste básicamente en monitorear el proceso completo de instalación de una aplicación en conjunto con las configuraciones posteriores para luego empaquetar todos los cambios que hizo en el sistema operativo y, con base en eso, construir un nuevo instalador que hace las mismas operaciones.

Esta característica no está pensada necesariamente para tema de compatibilidad de aplicaciones, sino más bien para mejorar el proceso de instalación de alguna aplicación; sin embargo, sirve muy bien para el propósito de pasar de instaladores de 16 bits a 32 bits sin tener que obtener acceso al código fuente, así que me parece perfecto.

Pueden obtener más información sobre el proceso técnico del Repackager en la web oficial de Advanced Installer.

2.2. Empaquetando

Para empaquetar nuestra aplicación, realizamos los siguientes pasos:

Para poder realizar estos pasos es necesario haber cumplido los requerimientos 3 y 4

Prendemos la máquina virtual que instalamos en el requerimiento 3:

image

Ejecutamos Advanced Installer con privilegios administrativos, vamos a NewConvert y luego doble clic en Repackage Installation:

image

En la ventana de Welcome to the Repackager Wizard, clic en Next

image

En la página de Repackaging Scenario, seleccionamos la segunda opción, Repackage an application in an existing virtual machine, nos aseguramos de que la máquina virtual sea la que creamos en el requerimiento 3 y hacemos clic en Next

image

En la página de Package Information, ubicamos el instalador de nuestra aplicación en el campo de Setup Path como obligatorio y, opcionalmente, modificamos los demás campos como el nombre, versión y empresa para luego dar clic en Next

image

En la página de Customize Settings, dejamos la selección predeterminada y clic en Next para iniciar el empaquetamiento.

image

En la ventana de alerta que nos informa que estamos a punto de empezar, le damos a OK.

image

Veremos que el asistente empieza a informar de varios pasos mientras en la máquina virtual se ejecuta el asistente de instalación de la aplicación con una consola en segundo plano:

SNAGHTML652bebe

Aquí lo único que debemos de hacer es instalar manualmente la aplicación y, si es necesario, ejecutarla para que todos los componentes que debe instalar y registrarse se apliquen correctamente. A parte de eso, si requerimos hacer cambios en Windows o en la aplicación, podemos hacerlos también, pues Advanced Installer capturará casi todo.

Cuando terminemos todo, volvemos al símbolo del sistema, nos aseguramos de que la consola esté capturando nuestro teclado (poniéndola en primer plano) y presionamos INTRO para que termine:

image

Al terminar, la máquina virtual se pausará y volveremos al asistente del Repackager. Ahí hacemos clic en Next para continuar.

image

En la pagína de You have successfully completed the Repackager Wizard, hacemos clic en Finish para abrir el proyecto en Advanced Installer.

image

En la ventana de Advanced Installer de Filter Repackager result, podemos modificar todos los recursos que el asistente capturó para luego darle Import.

image

En la ventana de Repackager, dejamos la primera opción y hacemos clic en Next para poder entrar al proyecto y hacer modificaciones adicionales, si es que lo necesitamos.

image

Nota: pueden darle a Build Package si ya están seguros, pero a mi personalmente me gusta siempre revisar y agregar cosas dentro del proyecto.

image

No entraré en detalles sobre todo lo que se puede hacer dentro de la herramienta porque no es el objetivo del artículo y se haría demasiado extenso (¡más de lo que está!), pero es importante saber que aquí se pueden modificar permisos NTFS, crear accesos directos, modificar archivos y registro, agregar scripts, aplicaciones adicionales a ejecutar antes, durante o después, entre otras.

Al terminar de hacer cualquier modificación, hacemos clic en el botón de Build en el panel superior de herramientas:

image

En el cuadro que nos aparece de Guardar como, escogemos el directorio en donde deseamos que se cree nuestro instalador y clic en Save.

image

En la ventana de Build Project podremos ver el log de la compilación y el acceso directo al .MSI que predeterminadamente se crea:

image

3.0. Prueba de instalación

¡Todo listo! Lo único que nos queda es pasar el instalador a un equipo de 64 bits y proceder a probar la instalación completa de la aplicación:

image

Habrá veces en que diferentes archivos no quedaron en el paquete de instalación, así que habrá que agregarlos (si se saben cuáles son) o bien hacer el proceso nuevamente teniendo cuidado con ejecutar todo lo que se necesite. Afortunadamente, Advanced Installe hace muy bien el trabajo, así que pocas veces tendremos que realizar cambios.

Espero que sea de ayuda.

Saludos,

—Checho

Ransomware y el Acceso controlado a carpetas en Windows 10

Hace unos días escribí un artículo uno de los tipos de ataques relacionados con el robo de credenciales y cómo Windows Defender Credential Guard podía evitarlo. En esta ocasión haré el mismo ejercicio de mostrar una característica nueva de seguridad en Windows 10, pero esta vez enfocado a un tipo de peligro mucho más común: ransomware.

Windows 10 Fall Creators Update introdujo una serie de características de seguridad agrupadas en una categoría llamada Windows Defender Exploit Guard, que a su vez viene siendo el remplazo mejorado de lo que antes se conocía como EMET, pero ya integrado en Windows. Una de las categorías de Exploit Guard es Controlled Folder Access o Controla el acceso a la carpeta, como está traducido al español (algo rara esa traducción, por cierto). Cada aplicación que se ejecute es evaluada por Windows Defender; si determina que es maliciosa o no confiable, es decir, sospechosa, impide que haga modificaciones a cualquier archivo que esté dentro de las carpetas protegidas. Aunque está pensado para cualquier aplicación maliciosa que intente escribir, es especialmente útil para combatir el ransomware, pues si las aplicaciones no pueden modificar nuestros archivos, tampoco podrán, obviamente, proceder a cifrarlos para pedir recompensas.

Predeterminadamente, Controla el acceso a la carpeta agrega las carpetas más comunes en donde el usuario puede almacenar información a las carpetas protegida; estos directorios no se pueden modificar:

image

Antes de entrar en detalle sobre cómo habilitar la característica y configurar las opciones que Windows nos provee a través de directivas de grupo, hagamos una simulación sobre lo que podría pasar en las carpetas con datos importantes.

Jugando a ser ransomware: MalFile.exe

Para poder probar con calma Controla el acceso a carpeta, decidí escribir una pequeña aplicación en C utilizando algunas API de Windows para crear y cifrar archivos. El cifrado está basado en Cryptography API: Next Generation (CNG), de Microsoft, por si están interesados.

Pueden ver el código fuente y la versión 1.0 de esta aplicación en caso de que quieran hacer las mismas pruebas: https://github.com/SergioCalderonR/MalFile/releases 

Si utilizamos el parámetro –ef, la aplicación tomará un archivo de texto plano como primer argumento, leerá el contenido, cifrará el contenido y lo guardará en el archivo que indiquemos como segundo argumento con cualquier extensión. Además de esto, la aplicación eliminará el archivo fuente, así que solo quedará el que está cifrado. En otras palabras, estoy tratando de jugar a ser ransomware.

Ahora, en mi escenario tengo una carpeta llamada C:\Info y allí, un archivo Confidential.txt que tiene texto plato:

image

MalFile.exe necesita tres parámetros para cifrar: –ef, la ruta del archivo a cifrar y la ruta del archivo cifrado con cualquier extensión o bien en texto plano (.txt).

Suponiendo que la aplicación fuera un ransomware, el ataque se podría efectuar sin ningún problema, pues para hacer cifrado ni siquiera se necesitan privilegios administrativos. Yo voy a simular el ataque enviándole los parámetros y cifrando el archivo con extensión .neu, así:

MalFile.exe –ef C:\Info\Confidential.txt C:\Info\Encrypted.neu

image

Noten que la aplicación indica, paso a paso, todo lo que se hizo sobre el contenido del archivo y que elimina el archivo original (para fines de demo, pues no sería lo que haría un ransomware).

Si abrimos el archivo con un bloc de notas, vamos a ver todo el contenido cifrado y una pequeña descripción que aparecerá en texto plano:

image

El texto que no aparece cifrado es porque la función CryptProtectData de la API de Windows permite agregarlo para que viaje con el contenido, pero no lo cifra.

Siendo un verdadero ransomware, no sería un solo archivo, sino múltiples y estaríamos ya preocupados por no poder tener la información.

Protegiendo las carpetas importantes activando Controla el acceso a carpeta

Como mencioné al principio, Controla el acceso a carpeta o Controlled Folder Acces en inglés permite restringir las operaciones de escritura sobre archivos que estén en las carpetas protegidas, así que el ransomware o cualquier otro archivo malicioso no podría actuar, a menos que logre ser confiable dentro de la base de datos de Microsoft. Veamos qué pasa cuando tratamos de hacer el ataque anterior con la característica activada.

Primero, abrimos el Centro de seguridad de Windows Defender desde el menú de inicio:

image

En el Centro de seguridad de Windows, hacemos clic en Protección antivirus y contra amenazas:

image

En la página de Protección antivirus y contra amenazas, clic en Configuración de antivirus y protección contra amenazas:

image

Luego bajamos y activamos deslizando a la derecha para activar Controla el acceso a la carpeta:

image

A menos que el directorio que deseamos proteger esté en alguna ubicación predeterminada de usuario (documentos, imágenes, etc), hacemos clic en Carpetas protegidas:

image

Finalmente, hacemos clic en Agregar una carpeta protegida, navegamos hasta el directorio raíz y aceptamos para que quede dentro de la lista de Controla el acceso a la carpeta:

image

Aceptamos el UAC y listo, nuestra carpeta estará protegida.

Como dato adicional, también pueden agregar la carpeta desde PowerShell así:

Add-MpPreference –ControlledFolderAccessProtectedFolders [CarpetaProtegida]

Donde [CarpetaProtegida] hace referencia al directorio que va a protegeer Controla el acceso a la carpeta de Windows 10. En mi caso, quedaría así:

 Add-MpPreference –ControlledFolderAccessProtectedFolders C:\Info

image

De cualquiera de las dos formas deberíamos ver nuestra carpeta en la lista:

image

Aunque no lo indicaré en este artículo, también se puede habilitar la característica a través de directivas de grupo, incluso podemos usar un modo de auditoría para no afectar a las aplicaciones sin estar seguros de que todo funcionará.

¿Qué pasa ahora cuando una aplicación malitencionada intente hacer algo?

Jugando a ser ransomware: revancha

Utilizando MalFile, voy a probar dos escenarios: creación de archivos y cifrado de archivos. La diferencia es que ahora los archivos están protegidos.

Para crear un simple archivo de texto plano basta con usar el parámetro –nf junto con la ruta y extensión. Si intento crear un archivo en la carpeta C:\Info, esto es lo que pasa:

image

El manejador de errores de Windows está devolviendo un código de error 2, que es cuando no puede encontrar el archivo especificado. Esto es porque en el código estoy utilizando la función de CreateFile, que sirve para abrir o crear archivos. En un funcionamiento normal, independiente de que el archivo exista o no, debería crearlo desde cero, pues eso es lo que explícitamente le pedí cuando la escribí:

image

Ignoro por qué no devuelve un error diferente, pero puede indicar que solo permite hacer las operaciones de lectura. A parte de devolver el error y no permitir hacer la escritura, Windows Defender muestra una notificación al usuario del bloqueo similar a la siguiente:

image

Supongamos que tenemos nuestro archivo Confidential.txt con información importante y hasta ahora sano y salvo en la carpeta segura y lo intento cifrar usando de nuevo el parámetro de –ef, así:

MalFile.exe –ef C:\Info\Confidential.txt C:\Info\Encrypted.tulpep

image

La aplicación puede leer los datos, pasarlos a otro buffer para cifrarlos, pero no puede escribir en la misma carpeta otra vez, así que el archivo continuará intacto. También veremos la notificación por parte del Centro de seguridad de Windows Defender.

También podríamos suponer que dejando leer los datos, podríamos cifrarlos y luego escribirlos nuevamente, esto sería posible si como segundo parámetro le indicamos el mismo archivo fuente, así:

MalFile.exe –ef C:\Info\Confidential.txt C:\Info\Confidential.txt

Sin embargo, Controla el acceso a la carpeta también evita que un proceso no confiable pueda escribir sobre el mismo archivo:

image

Como pueden ver, Windows devuelve Acceso denegado. Interesante, ¿no?

Permitir acceso a aplicaciones manualmente

Desde que sea una aplicación comercial o esté firmada digitalmente, no deberían tener problemas para modificar archivos en la carpetas protegidas; sin embargo, habrá excepciones que encontrarán en el camino. Afortunadamente Windows Defender permite solventar esto, basta con devolvernos a la pantalla de Protección antivirus y contra amenazas y en vez de hacer clic en Carpetas protegidas, hacemos clic en Permitir que una aplicación acceda a una de las carpetas controladas:

image

Luego hacemos clic en Agregar una aplicación permitida, buscamos el ejecutable y aceptamos:

image

Después de esto, así esté habilitado Controla el acceso a carpeta permitirá la escritura sin problemas:

image

Hay un poco más de contenido sobre este tema, pero con esto es suficiente para conocer la característica y experimentarla.

Espero sea de utilidad.

Saludos,

—Checho
Follow me on Twitter

Pass-The-Hash y Windows Defender Credential Guard en Windows 10

Desde el lanzamiento de Windows 10, Microsoft ha hecho enormes esfuerzos por mejorar la seguridad de la plataforma en diferentes frentes agregando más y más características en cada compilación, trabajo que va teniendo frutos, pues se ha convertido el sistema operativo Microsoft más seguro de todos.

Como vale la pena ir conociendo cómo implementar estas nuevas características, iré escribiendo, conforme pueda y sepa, lo que aprendo por aquí por si alguien más desea hacer pruebas en sus respectivas empresas. Por supuesto, todas las correcciones serán más que bienvenidas.

Una de las nuevas características de seguridad se llama Credential Guard, que básicamente utiliza seguridad basada en virtualización para aislar secretos que puedan llevar a ataques de robo de credenciales. Los secretos se protegen y almacenan en un nuevo componente llamado Insolated LSA; la comunicación con el proceso de LSA se hace a través de RPC. Básicamente previene los ataques protegiendo los hashes de las contraseñas NTLM, Kerberos y las contraseñas de dominio almacenadas en el Credential Manager. Pueden obtener más información del sitio oficial.

Pass-The-Hash es un ataque que utiliza una técnica para obtener los hashes de las contraseñas y reutilizarlos para autenticarse a través de la red en otros equipos hasta lograr ganar privilegios con una cuenta de Active Directory.

Veamos qué tan fácil puede llegar a ejecutarse un Pass-The-Hash en Windows 10 y cómo Windows Defender Credential Guard nos puede ayudar a prevenirlo.

Ejecutando un ataque de Pass-The-Hash

Antes que nada, por si desean seguir el ataque, esto es lo que necesitamos:

1. Mimikatz. Lo pueden descargar desde aquí: https://github.com/gentilkiwi/mimikatz/releases

2. PsExec. Lo pueden descargar desde aquí:
https://docs.microsoft.com/en-us/sysinternals/downloads/psexec

3. Entorno de directorio activo

4. Equipo cliente unido al dominio para probar

Notas:

  • Cabe aclarar que obviamente necesitaremos cuentas de dominio con diferentes privilegios para probar.
  • Es probable que deban darle permisos desde el antivirus al Mimikatz, pues normalmente lo bloquean.

Primer paso: obtener el hash NTLM de las contraseñas con Mimikatz

Para poder extraer el hash de las contraseñas de un equipo, cada cuenta de dominio tuvo que haberse conectado de alguna forma, pues al cerrar sesión ya no es posible que Mimikatz cree el hash, así que no lo mostraría en la consola.

No sé si sea diferente con otra aplicación; en mi caso, aunque pude extraer el NTLM hash después de cerrar sesión con otras cuentas, el ataque de Pass-The-Hash no funcionaba correctamente.

Ahora, para mi escenario tengo dos cuentas con las que voy a jugar: Sergio y Andy; la primera, Sergio, es una cuenta de dominio que solo es administradora en el equipo local (no estoy teniendo en cuenta aquí lo de ganar privilegios locales), mientras que la segunda, Andy, es una cuenta que tiene privilegios locales sobre todas las máquinas, incluyendo el controlador de dominio.

Si yo intento hacer conexión utilizando PsExec desde mi cuenta de Sergio, no podré hacerlo por ser una cuenta estándar, más allá de tener privilegios administrativos locales:

SNAGHTML14d1dec7

Afortunadamente, Andy está conectando al equipo, pero necesitamos obtener y reutilizar ese hash para nuestro ataque.

Desde una cuenta local o de dominio con privilegios administrativos en la máquina ejecutamos Mimikatz como administrador:

image

Lo primero es solicitar privilegios a Windows de depuración ejecutando:

privilege::debug

image

Una vez adquiridos los privilegios, es decir, que la consola responda con un OK, vamos a extraer toda la información sobre las contraseñas que están en memoria con el módulo de sekurlsa:

sekurlsa::logonpasswords

image

Inmediatamente veremos datos para todas las cuentas que estén conectadas, incluyendo el más importante para este dato que sería el hash NTLM:

image

Por supuesto, nosotros no estamos interesados el usuario de Sergio, sino en el de Andy. Mimikatz, como dije, me da también el hash de la contraseña correspondiente, siempre y cuando tenga una sesión abierta:

image

Noten que el campo de contraseña lo muestra en nulo porque la forma en que se almacenan en Windows 10 difiere de Windows 7 y anteriores, así que no la podemos ver. Si estuviésemos en un Windows 7, habríamos obtenido la contraseña sin problemas.

Como pueden ver, ya tenemos el hash NTLM y eso es todo lo que necesitamos para autenticarnos a través de la red como Andy.

Segundo paso: realizar el ataque de Pass-The-Hash con el hash obtenido

Desde Mimikatz, lanzamos nuestro ataque de Pass-The-Hash con los datos que ya tenemos:

sekurlsa::pth /user:andy /domain:winside.local /ntlm:a87f3a337d73085c45f9416be5787d86

image

Nota: obviamente los datos en usuario, dominio y NTLM van a ser diferentes en cada escenario, pero dejo el comando de forma ilustrativa.

Lo que va a pasar aquí es que Mimikatz va a lanzar el cmd con una identidad falsa, Windows va a creer que era el usuario actual, es decir, Sergio en este caso, pero va a utilizar el hash de la contraseña del usuario de Andy:

image

Nuestro último paso es simplemente utilizar la consola que se nos abrió para autenticarnos en las próximas máquinas como Andy. Por ejemplo, utilizando PsExec nuevamente sobre el controlador de dominio:

PsExec \\LEO cmd.exe

Si le doy un whoami, van a ver que estoy conectando como Andy, gracias a que reutilicé el hash de la contraseña almacenada en memoria de mi equipo:

SNAGHTML14e3f7a6

Suponiendo que logre burlar la seguridad para ejecutar Mimikatz, yo podría, por supuesto, seguir obteniendo el hash NTLM de las credenciales locales hasta llegar a un usuario que tenga realmente poderes sobre el dominio:

image

Implementando Windows Defender Credential Guard

La implementación de Credential Guard es relativamente sencilla, basta con cumplir los requerimientos en las máquinas físicas o virtuales y proceder a desplegarlo a través de una directiva de grupo, manualmente (Registro de Windows) o con un script de PowerShell liberado por Microsoft.

Para mayor claridad, crearemos la GPO para Credential Guard desde cero.

Nos conectamos a la consola de administración de directivas de grupo y creamos la GPO en la OU que corresponda:

image

Yo la llamaré Credential Guard Policies.

image

Hacemos clic derecho sobre la GPO, editamos y navegamos hasta:

Computer Configuration\Policies\Administrative Templates\System\Device Guard

Allí hacemos doble clic sobre la plantilla de Turn On Virtualization Based Security

image

En la plantilla, clic en Enabled, y debajo de Credential Guard Configuration seleccionamos la opción de Enabled with UEFI Lock, esto es para que remotamente no se pueda deshabilitar, pues está protegido por UEFI.

image

Nota: para fines de prueba pueden utilizar la de Enabled Without Lock.

Actualizamos directivas de grupo en el equipo cliente y reiniciamos.

Después de reiniciar, ejecutamos Msinfo32 y verificamos que en la parte inferior la característica de Virtualization Based Security esté en ejecución y lo demás haga referencia a Credential Guard:

image

En caso de que esté habilitado pero no en ejecución, es necesario habilitar manualmente la característica de Hyper-V Hypervisor desde Activar o desactivar características de Windows y reiniciar nuevamente:

image

Obteniendo el hash de las contraseñas con Credential Guard habilitado

Después de que Windows Defender Credential Guard esté habilitado y funcionando, podemos intentar nuevamente utilizar Mimikatz o cualquier otra herramienta que obtenga el hash NTLM de las cuentas y nos encontraremos con algo completamente diferente:

image

Como pueden ver, ya no tengo forma de obtener el hash porque ahora Windows, utilizando la tecnología de seguridad basada en virtualización, más específicamente la de Insolated User Mode, está protegiendo los secretos (credenciales) para que solo unos binarios autorizados puedan llegar a ellos. Si no tengo el hash NTLM, naturalmente, no puedo hacer el ataque de Pass-The-Hash en las máquinas.

Credential Guard está disponible solo en ediciones Enterprise y Education de Windows 10.

Espero sea de utilidad y pueda seguir compartiendo otras tecnologías nuevas de seguridad en Windows 10.

Saludos,

—Checho

La pantalla verde de la muerte (GSOD) al iniciar sesión, Windbg, Windows PE, Autoruns y su solución

Aunque he tenido algunos problemas resueltos en mi día a día laboral, no había vuelto a sacar tiempo para compartirlos; sin embargo, recién pude recuperar mi propio equipo de uno interesante, así que decidí sentarme un rato y escribirlo como en viejos tiempos.

El problema

Recién había actualizado mi Windows 10 a la compilación 17063 y necesitaba reinstalar el VMWare Workstation por un problema que hay con Advanced Installer, herramienta indispensable en mi trabajo, así que procedí a hacerlo, pero cuando reinicié el equipo para terminar la desinstalación, justo después de iniciar sesión, mi equipo empezó a arrojar pantalla verde de la muerte (GSOD):

«Your Windows Insider Build ran into a problem and needs to restart. We’re just collecting some error info, and then we’ll restart for you.»

GSOD

Nota: el color verde es solo para las compilaciones del programa Windows Insider.

A pesar de que el reinicio del equipo era correcto, incluso el inicio de sesión parecía funcionar, siempre terminaba por obtener el GSOD y se reiniciaba otra vez.

La causa

¿Cómo solucionar el problema cuando no puedes ingresar a Windows? Para pensar en eso, tenía que encontrar primero qué controlador me estaba causando la pantalla verde.

Recordemos que cuando ocurren una pantalla azul/verde de la muerte, mientras nos muestra el aterrador mensaje, Windows escribe un archivo que contiene el volcado de memoria de lo que ocurría al momento del fallo; normalmente escribe uno completo, MEMORY.dmp, ubicado en la raíz del directorio de Windows y otro más pequeño, escrito en el directorio Minidumps.
Si logramos obtener alguno de estos archivos desde el equipo con el fallo, es muy probable que podamos identificar la causa raíz.

Windows PE

Como no podía extraer el volcado de memoria desde el equipo en línea, opté por recurrir al buen amigo Windows PE e iniciar desde ahí el equipo, de esta forma me aseguraba no sufrir más reinicios inesperados y poder navegar desde la consola libremente por mis archivos.

Una vez en el Windows PE, busqué en qué unidad se encontraban los archivos del sistema operativo sin conexión, en mi caso la E:\, y copié el archivo MEMORY.dmp para poder analizarlo en otro equipo con xcopy a mi memoria USB, con letra H:\, así:

xcopy E:\Windows\MEMORY.dmp H:\DumpFile

image

El siguiente paso fue ejecutar la última versión del Windbg en otro equipo, conectar la memoria con el volcado de memoria y abrirlo para el análisis:

2017-12-21_16-21-53

El Windbg tarda unos segundos mientras prepara el ambiente y luego deja a disposición la consola de comandos. El paso básico aquí es proceder con el !analyze –v para que nos dé un resultado de cuál puede ser el controlador que falla y bastante información más, pero en este caso decidí utilizar solamente el comando kc para ver los nombres de todos los módulos y funciones que cargaron antes de que se produjera el bugcheck. Afortunádamente me encontré con algo interesante:

2017-12-21_16-29-46

Aquí cabe recordar que debemos buscar de primero siempre lo que no corresponda a Windows, es decir, que no inicie con nt! Para mi caso, como pueden ver, solo había algo diferente a todo lo demás: gdrv.

Luego, desde el mismo Windbg, utilicé lmvm gdrv para ver qué información podía extraer de ese controlador, aunque no tuve demasiada:

2017-12-21_16-32-09

Hasta aquí pude confirmar que efectivamente había un controlador implicado, pero con estos detalles del Windbg no podía saber a qué programa pertenecía (o no sabía cómo). ¿Qué hacer, entonces?

Autoruns y Windows PE

Como lo he mostrado en varias ocasiones durante toda la vida de este blog, Autoruns, de Sysinternals, tiene una fantástica característica que consiste en cargar todo lo que hay en un sistema operativo sin conexión para hacer análisis desde un Windows PE, por ejemplo. De esta forma podemos saber todo lo que carga con Windows y buscar posibles causas de problemas como una pantalla azul/verde que no deja arrancar.

Lo que hice fue copiar el Autoruns64.exe desde la página de Sysinternals al Windows PE, inicié nuevamente mi equipo desde ahí, ejecuté Autoruns y activé la característica desde el menú de File, Analyze Offline System. 

En la ventana de Offline System solo debemos indicar el directorio en donde está Windows, en mi caso la E:\Windows, y el perfil a cargar, en mi caso E:\Users\Checho:

image

Una vez hecho eso, ya estaba viendo todo lo que cargaba en mi sistema operativo. ¡Todo listo para encontrar a quién le pertenecía el controlador!

Desde el cuadro de texto de Filter, ubicado en la parte superior, debajo de la barra de menú, escribí el nombre del controlador, gdrv, y para mi fortuna, encontré lo que buscaba:

image

Según la descripción, el controlador pertenecía a GIGABYTE Tools, es decir, a la aplicación de App Center del fabricante.

La solución

Naturalmente, si Windows no tiene activo en el inicio el controlador que falla, el problema no va a ocurrir. Desde Autoruns, deshabilité la carga de ese controlador quitando la selección, así:

image

Cerré Autoruns, Windows PE y reinicié mi máquina. Como era de esperarse, no tuve más la pantalla verde, aunque sí un mensaje de error del App Center por no poder cargar su controlador:

image

Intenté buscar una versión más actualizada del App Center, pero no la encontré en la página de Gigabyte, así que tuve que quitar la aplicación de mi equipo mientras logro reportar el problema o sale alguna versión nueva.

Saludos,

—Checho
https://twitter.com/secalderonr

DelVol: cambia fácilmente letra de unidades en Windows

Lo pensé mucho para publicar este artículo, pues no me parece que la herramienta que voy a describir llegue a ser de utilidad para mucha gente; sin embargo, decidí hacerlo por algunas razones: primero, haré mención de su uso en un artículo que escribiré para Implementa Windows. Segundo, es una buena oportunidad para documentar su funcionamiento, y tercero, quizá a otras personas les pueda solucionar el mismo problema que yo tuve.

El problema

Parte de mi rol en el trabajo es realizar ingeniería de imágenes en las empresas, tratando siempre de automatizar todo lo que más pueda en el proceso de instalación de Windows. Como es de esperarse, todas las empresas son muy diferentes, así que siempre me encuentro con nuevos requerimientos, unos más sencillos que otros.

En este caso, necesitaba una forma de automatizar el proceso para quitarle la letra de unidad a una partición; más específicamente, necesitaba liberar la letra D y cambiarla por cualquier otra letra en tiempo de implementación desde MDT.

Las opciones

La primera opción, como suele ser normal, es ver una forma soportada para hacer el cambio de unidad con alguna herramienta integrada de Windows, así que opté por Diskpart. Lo único que debemos saber es el número de volumen que tiene asignada la partición con la letra a cambiar y la nueva letra que vamos a asignarle.

En mi caso, para cambiar de la D a la Z, suponiendo que el volumen es el 0, tendría que utilizar los siguientes comandos:

> Diskpart
> List Volume
> Select Volume 0
> Assign Letter=Z

image

Lo malo con Diskpart es que siempre debía saber el número de volumen y la nueva letra de unidad; si me equivocaba en alguno de los dos o la letra de unidad estaba tomada, no tenía como manejarlo.

La segunda opción era, por supuesto, PowerShell. Soy un entusiasta, pero aún muy malo para construir scripts profesionales, así que traté de encontrar la mejor opción para hacer el cambio de forma automatizada. El script que manejé durante algunas pruebas era así:

$drive = Get-WmiObject -Class win32_volume -Filter “DriveLetter = ‘D:'”

Set-WmiInstance
-input $drive -Arguments @{DriveLetter=”Q:”}

A diferencia de Diskpart, PowerShell utilizaba el módulo de WMI para consultar el volumen que estaba montado con la letra D y luego le asignaba la letra Q.

Aunque me liberé del primer problema, saber el volumen, aún estaba condicionado por la disponibilidad de la letra que le iba a asignar; no obstante, es probable que haya podido encontrar la forma de buscar con PowerShell qué unidades estaban tomadas, pero eso le habría dado más duración al script, además de subir la probabilidad de error. Por otro lado, la ejecución de scripts de PowerShell desde MDT me parece algo lenta y propensa a fallar, pues hay dependencias de que se habilite correctamente la ejecución y de versiones de PowerShell para soportar los módulos.

Podía dejar cualquiera de las dos, pero, como última opción, opté por tratar de entender un poco más cómo funciona la asignación de particiones con la API de Windows y construir mi propia herramienta: DelVol.

Un poco de teoría

Normalmente nosotros reconocemos los volúmenes que tenemos activos en el equipo por su etiqueta (Datos, Windows, Backup, OSDisk, etc.) o por la letra que les fueron asignados, sea por Windows o por nosotros (D:\, E:\, J:\, etc.); pero Windows no puede utilizar la misma estrategia porque, por ejemplo, un volumen puede tener asignado una letra y una etiqueta, solo la letra, solo la etiqueta o ninguna de las dos. Otro ejemplo claro es que la letra puede variar cada que se desconecta y reconecta, puesto que Windows asigna por disponibilidad.

El sistema operativo, entonces, reconoce cada volumen con algo llamado Volume GUID Path, que está compuesto por un prefijo, «\\?\», la palabra «Volume» y un identificador único asignado por Windows. Por ejemplo, el volume GUID path  de la unidad Z:\ en mi equipo quedaría así:

\\?\Volume{45c09333-0000-0000-0000-100000000000}\

Si están interesados en saber el volume GUID path de sus particiones, Windows tiene una herramienta integrada llamada MountVol:

image

Windows Sysinternals también ofrece una herramienta un poco mejor llamada DiskExt que muestra, además del GUID, otros detalles relevantes como la unidad y disco al que pertenece:

image

Yo también hice un pequeño ejecutable que utiliza las funciones GetVolumeInformation y GetVolumeNameForVolumeMountPoint para obtener el volume GUID path, letra de unidad, tipo de sistema de archivos y serial asignado por Windows. El uso es muy sencillo, si yo quiero saber el detalle para la letra Z, solo debo indicársela como argumento agregando los dos puntos y el backslash, así:

VolInfo.exe Z:\

image

Pueden descargar los archivos fuente desde el repositorio de GitHub. El ejecutable está en la carpeta de Exefile: https://github.com/SergioCalderonR/VolInfo 

La solución: DelVol

DelVol es una sencilla herramienta de línea de comandos que me permite especificar la letra de unidad a la que le quiero cambiar la letra y ella se encargará de buscar internamente cuál es la siguiente letra disponible para asignársela, liberando la anterior para nuevo uso. La herramienta utiliza varias funciones de la API de Windows, de esta forma elimino la necesidad de versiones de framework y proporciono compatibilidad desde Windows 7 en adelante.

Gracias a que la herramienta se encarga de buscar la siguiente letra disponible, también elimino la preocupación de que la letra esté ocupada, tal cual me sucedía con Diskpart y PowerShell.

¿Cómo funciona?

Solo es necesario indicarle como argumento la letra de unidad y la herramienta hará el resto. Por ejemplo, si deseo liberar la letra Z, el comando sería:

DelVol.exe Z:\

image

Es necesario indicar la letra de unidad con los dos puntos y el backslash, de lo contrario la herramienta devolverá un error, esto es porque las funciones requieren este formato para funcionar, aunque espero hacer esto más fácil en el futuro.

En caso de equivocación o de lanzar solo el ejecutable sin argumentos, la aplicación mostrará una pequeña ayuda con ejemplo:

image

Como pueden ver, la ventaja de interactuar directamente con la API de Windows es el rendimiento al ejecutar, además de tener un poco más de control sobre lo que estoy haciendo.

¿Dónde descargar?

La solución está disponible también en mi repositorio de Github, por si alguien está interesado en conocer el código y, por qué no, aportar:

https://github.com/SergioCalderonR/DelVol 

Si solo desean el ejecutable, pueden obtenerlo al descargar la solución, en la carpeta Exefile.

SNAGHTML87a094[5]

image

Espero sea de utilidad.

Saludos,

<

p align=”justify”>—Checho