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

Establecer la ubicación predeterminada de la carpeta OneDrive a través de directivas de grupo

Hace unos días, como parte de mi trabajo, estaba apoyando un compañero en un proyecto de ingeniería de imágenes en Windows 10 y nos encontramos con que uno de los requerimientos que tenía el cliente sobre la imagen era cambiar la ubicación predeterminada de la carpeta OneDrive a otra partición de forma predeterminada, así el usuario que iniciara sesión solo tendría que indicar la cuenta y no hacer el cambio manualmente.

Predeterminadamente no se puede hacer el cambio hasta después de configurada la cuenta, además de que aplica por usuario; así que nos dimos en la tarea de buscar y encontramos un artículo técnico de la base de conocimientos de Office donde describía una serie de directivas de grupo asociadas a unos archivos ADMX disponibles para descargar:
https://support.office.com/en-us/article/Use-Group-Policy-to-control-OneDrive-sync-client-settings-0ecb2cf5-8882-42b3-a6e9-be6bda30899c

Lamentablemente me encontré con que para para algunas personalizaciones como la que yo buscaba, establecer la ubicación predeterminada de la carpeta OneDrive, había que hacer personalizaciones manuales sobre los archivos, pero la plantilla que uno descarga no tiene ni siquiera el XML con todos los valores base que requiere para funcionar y la ayuda está pésimamente documentada.

Con el ánimo de dejar algo de documentación para futuras ocasiones en que lo necesite y para el que le pueda servir, escribiré a continuación cómo deben de quedar configurados los archivos para que la directiva se pueda aplicar correctamente.

Requerimientos

1. Debemos saber cuál es el Tenant ID de nuestro Azure AD. Si necesitan saber cómo encontrar el Tenant ID, pueden ver este artículo

2. Aunque podemos hacer las modificaciones con el Bloc de notas, yo les recomiendo utilizar un editor como Notepad++ para los siguientes pasos. Pueden descargarlo desde aquí:
https://notepad-plus-plus.org/

Descarga de archivos

Aunque hay dos partes desde la web oficial que se pueden descargar, la mejor es la que está en la misma KB que compartí arriba: download the OneDrive Deployment Package

Configuración del ADMX y ADML

Una vez descarguemos el paquete de implementación, debemos descomprimir el contenido para poder empezar a modificar los dos archivos importantes, OneDrive.admx y OneDrive.adml:

image

Procedemos a hacer clic derecho sobre el archivo OneDrive.admx y lo editamos con Notepad++

image

Lo primero que debemos hacer es ubicarnos en las directivas DefaultRootDir y DisableCustomRoot para remplazar nuestro tenant ID por la cadena que veremos en el XML, así: {INSERT YOUR TENANT’S GUID HERE}

image

image

Naturalmente todos tendremos un identificador diferente.

Es importante aclarar que debemos tener cuidado de no incluir comillas adicionales ni corchetes, por ejemplo:

image

La directiva que nos va a permitir modificar la ubicación predeterminada de la carpeta de OneDrive es la que está con el nombre de DefaultRootDir, así que debemos hacerle algunas correcciones sobre lo que trae predeterminadamente la plantilla para que funcione.

Después de la etiqueta de supportedOn y antes de elements, vamos a agregar esto:

<enabledValue>
     <string>D:\ODUsers\%UserName%</string>
</enabledValue>
<disabledValue>
     <string></string>
</disabledValue>

Lo anterior es para que la plantilla aplique el cambio en el registro y aparezca como Enabled en la consola de directivas de grupo.

Noten que en la etiqueta de string yo agregué una ruta predeterminada; esto es de vital importancia para que pueda funcionar. La ruta puede ser cualquiera, pero debemos asegurarnos de que sea la misma tanto en este archivo .admx como en el .adml más adelante.

Todo quedaría así:


<policy name=”DefaultRootDir” class=”User” displayName=”$(string.DefaultRootDir)” explainText=”$(string.DefaultRootDir_help)” presentation=”$(presentation.DefaultRootDir_Pres)” key=”SOFTWARE\Microsoft\OneDrive\Tenants\81e570c6-569e-4b33-8ef5-8574e89d545b” valueName=”DefaultRootDir”>
       <parentCategory ref=”OneDriveNGSC” />
       <supportedOn ref=”windows:SUPPORTED_Windows7″ />
     <enabledValue>
        <string>D:\ODUsers\%UserName%</string>
     </enabledValue>
     <disabledValue>
         <string></string>
     </disabledValue>
       <elements>
         <text id=”OneDriveSyncFolder” valueName=”DefaultRootDir” required= “true” expandable=”true” />
       </elements>
     </policy>


image

Guardamos los cambios desde nuestro editor y cerramos el OneDrive.admx.

Hacemos clic derecho sobre el archivo OneDrive.adml y procedemos a editarlo también.

image

Al principio del archivo, debajo de  <stringTable>, vamos a agregar lo siguiente:

<!– OneDrive Sync Folder –>
<string id=”OneDriveSyncFolder”>OneDrive Sync Folder</string>

Nos quedaría así:


<resources>
     <stringTable>
    
       <!– OneDrive Sync Folder –>
       <string id=”OneDriveSyncFolder”>OneDrive Sync Folder</string>


image

Después de esta modificación, bajamos del todo en el archivo hasta la etiqueta llamada <presentationTable>; allí ubicamos la etiqueta de <defaultValue> y cambiamos su contenido por la ruta que deseamos mostrar predeterminadamente al abrir la plantilla en el Administrador de directivas de grupo. En mi caso, pondré la ubicación a:

D:\ODUsers\%UserName%


<presentationTable>
    <presentation id=”AutomaticUploadBandwidthPercentage_Pres”>
    <text>Select the maximum amount of bandwidth to take up when uploading files.</text>
         <text>Valid values are from 10 – 90.</text>
         <decimalTextBox refId=”BandwidthSpinBox” defaultValue=”70″ spinStep=”1″>Bandwidth:</decimalTextBox>
       </presentation>
       <presentation id=”DefaultRootDir_Pres”>
        <textBox refId=”OneDriveSyncFolder”>
         <label>OneDrive Sync Folder</label>
        <defaultValue>D:\ODUsers\%UserName%</defaultValue>
       </textBox>
      </presentation>
   </presentationTable>


image

Guardamos el archivo desde el editor y cerramos.

Importar los archivos al repositorio central del Directorio activo

En este punto voy a asumir que ya tienen creado un repositorio central en el controlador de dominio; si no es así, los invito a seguir este artículo para crearlo:

https://support.microsoft.com/en-us/help/3087759/how-to-create-and-manage-the-central-store-for-group-policy-administra

Para registrar los archivos correctamente, seguimos estos pasos:

1. Cerramos cualquier instancia del Administrador de directivas de grupo que tengamos abierta

2. Copiamos el archivo OneDrive.admx a la carpeta raíz de PolicyDefinitios del repositorio central:

image

3. Copiamos el archivo OneDrive.adml en la subcarpeta en-US de PolicyDefinitios:

image

Crear la directiva de grupo

Por último, procedemos a abrir el Administrador de directivas de grupo, creamos o editamos la plantilla desde donde queremos configurar la carpeta de OneDrive y navegamos hasta:

User Configuration\Policies\Administrative Templates\OneDrive

Doble clic sobre la plantilla Set the default location for the OneDrive folder

image

En la ventana de la plantilla, seleccionamos Enabled y, si es necesario, modificamos la ruta en la que OneDrive hará la sincronización, debajo de OneDrive Sync Folder:

image

Como nosotros modificamos la ruta en el archivo OneDrive.admx y OneDrive.adml, será la que aparezca predeterminadamente. Si necesitamos que sea otra, basta con cambiarla y ya.

Hacemos clic en el botón OK para habilitar la directiva. Debemos asegurarnos de que en la ventana del Administrador de directivas se quede viendo como Enabled:

image

Probar la directiva de grupo

Iniciamos en un equipo que tenga Windows 7 o Windows 10 y el último cliente de OneDrive instalado con un usuario de dominio que le aplique la directiva, ejecutamos OneDrive y procedemos a realizar la configuración:

1. Iniciar sesión con la cuenta:

image

2. Ingreso de contraseña:

image

3. Confirmación de la carpeta predeterminada:

image

Noten que, predeterminadamente, la carpeta de OneDrive está apuntando a la misma ubicación que definimos en la directiva de grupo.

4. Sincronización de archivos:

image

5. Confirmación:

image

6. Por último, confirmamos que la carpeta se haya creado físicamente en la ruta que indicamos en la directiva de grupo:

image

Espero les sea de utilidad.

Saludos,

<

p align=”justify”>Checho

Establecer un fondo personalizado para la Pantalla de bloqueo en Windows 10, versión 1703, con un paquete de aprovisionamiento

Una de las características que introdujo Windows 8 a nivel de interfaz gráfica fue la pantalla de bloqueo, que permitía tener una imagen personalizada mostrándose justo antes del inicio de sesión en Windows. Desde ese entonces y hasta la la compilación 1511 de Windows 10 las organizaciones podían establecer una imagen corporativa en todas las ediciones de Windows a través de directivas de grupo; sin embargo, desde Windows 10, versión 1607, solo es posible en ediciones Education y Enterprise, así que todas las empresas que tenían Windows 10 Pro perdieron esta opción, por lo menos de forma soportada.

Con la reciente liberación de Windows 10 Creators Update (versión 1703), Microsoft habilitó un nuevo CSP, más concretamente Personalization CSP, que permite configurar tanto el fondo de pantalla de escritorio como el de la Pantalla de bloqueo utilizando directivas MDM en las ediciones empresariales de Windows 10. Gracias a que los paquetes de aprovisionamiento se basan principalmente en directivas MDM, las empresas con Windows 10 Pro no necesitan tener Windows Intune para empezar a aprovechar estas nuevas características.

A continuación, mostraré cómo podemos utilizar la última versión del Windows Imaging and Configuration Designer (Windows ICD) para construir un paquete de aprovisionamiento que despliegue un fondo de pantalla de bloqueo personalizado y evite que el usuario lo pueda cambiar.

Requerimientos

1. Instalar todas las herramientas de implementación desde la última versión del ADK, la cual pueden descargar desde el sitio oficial:
https://developer.microsoft.com/en-us/windows/hardware/windows-assessment-deployment-kit

image

2. Un equipo cliente que tenga instalado Windows 10 Pro, versión 1703; es decir, Creators Update

Nota: este proceso funciona perfectamente en las ediciones Enterprise y Education también, pero ahí es más fácil por directivas de grupo.

Creación del paquete de aprovisionamiento

Lo primero que vamos a hacer es crear y configurar el paquete de aprovisionamiento con las directivas MDM que deseamos aplicar.

1. Desde nuestro equipo técnico en donde instalamos el ADK ejecutamos el Windows Imaging and Configuration Designer

2. En la página de inicio, hacemos clic en Advanced provisioning para crear un paquete completamente personalizado

image

3. En la ventana de New project, indicamos un nombre para el paquete debajo de Name y hacemos clic en el botón Next

image

  1. En la página de Choose which settings to view and configure, seleccionamos All Windows desktop editions y clic en Next

image

5. En la página de Import a provisioning package (optional), dejamos en blanco y clic en el botón de Finish

image

Windows Configuration Designer abrirá nuestro paquete de aprovisionamiento con todas las configuraciones disponibles debajo de Runtime settings:

image

Personalización del paquete

Aunque un solo paquete de aprovisionamiento puede contener múltiples configuraciones, nos enfocaremos solo en establecer nuestro fondo para la Pantalla de bloqueo.

1. Expandimos Runtime settings, luego el nodo de Personalization y clic en DeployLockScreenImage

2. En el panel central, hacemos clic en el botón de Browse y buscamos la imagen que deseamos establecer con extensión .jpeg o .jpg (se pueden más formatos, pero no viene al caso)

image

3. Después de escoger la imagen, hacemos clic en LockScreenImageUrl y en el campo de texto del centro escribimos el nombre de la imagen que seleccionamos en el paso 2. Para mi caso, por ejemplo, sería balls.jpg

image

4. Expandimos el nodo de SharedPC, luego PolicyCustomization, clic en SetEduPolicies y cambiamos el valor en el panel central de FALSE a TRUE

image

Nota: el paso 4 solo es necesario si vamos a configurar el fondo para la Pantalla de bloqueo en Windows 10 Pro, versión 1703.

Compilación del paquete

Finalmente, seguimos estos pasos para compilar nuestro paquete de aprovisionamiento:

1. Hacemos clic en el botón de Export, ubicado en la parte superior izquierda, y luego en Provisioning Package

image

2. En la primera ventana de Build, cambiamos el owner de OEM a IT Admin y clic en Next

image

Nota: el owner determina la prioridad en que Windows realizará configuraciones en el equipo, en caso de que hayan dos paquetes tratando de establecer las mismas directivas con distintas configuraciones.

3. En la página de Select security details for the provisioning package, hacemos clic en Next

image

4. En la página de Select where to save the provisioning package, dejamos el directorio predeterminado y hacemos clic en Next

image

5. En la página de Build the provisioning package, hacemos clic en el botón de Build para crear nuestro paquete de aprovisionamiento

image

6. En la página de All done, hacemos clic en el enlace que nos da el Output location para acceder al paquete de aprovisionamiento y clic en el botón de Finish

image

¡Todo listo! Lo único que nos queda es copiar nuestro CusttomLockScreen.ppkg o como lo hayan nombrado al equipo en donde aplicaremos la directiva para probar.

Prueba del paquete en Windows 10 Pro, versión 1703

Así luce la Pantalla de bloqueo en un escenario no administrado:

image

Como ven, la selección predeterminada es la de Windows spotlight, aunque el usuario lo puede cambiar por una imagen fija.

Lo que haremos será copiar el paquete de aprovisionamiento creado anteriormente y hacer doble clic para lanzarlo.

Normalmente el paquete nos da una leve descripción de tareas generales que hará y las opciones de aceptar o cancelar:

image

Lo único que tenemos que hacer es darle a Yes, add it y Windows se encargará de toda la configuración.

Una vez se cierre la ventana del paquete de aprovisionamiento, abrimos nuevamente la aplicación de Configuraciones, Personalización, Pantalla de bloqueo para ver cómo luce ahora:

image

Windows indica que algunas de las opciones están siendo administradas por la organización, por ende deshabilita toda personalización que pueda hacer el usuario.

Para comprobar que todo quedó aplicado, basta con bloquear el equipo y ver que nuestro fondo corporativo fue aplicado en la Pantalla de bloqueo.

image

Espero sea de utilidad.

—Checho

SetWall: cambia el fondo de pantalla aplicado por directivas de grupo

El mes pasado escribí un artículo sobre cómo cambiar el fondo de pantalla establecido a través de directivas de grupo, además de mostrar algunos detalles técnicos sobre las operaciones en registro que se llevan a cabo en el proceso. Como mencioné en ese momento, realizo este cambio manualmente cada que mi equipo actualiza las directivas de grupo, así que decidí construir una pequeña aplicación que realizará este procedimiento cada que lo necesitara y la compartiré por aquí.

SetWall

SetWall es una aplicación de consola que utiliza varias funciones de la API de Windows para modificar el fondo de pantalla y notificarle al sistema operativo para que lo pueda visualizar. No hice modificaciones de seguridad, así que el cambio de fondo durará lo que demoren las directivas de grupo para volverse a forzar en el equipo, pero igual siempre puede volverse a ejecutar la aplicación.

¿Cómo funciona?

Para ejecutar SetWall, basta con abrir un símbolo del sistema con privilegios elevados y lanzar como parámetro la ruta del JPG o PNG:

SetWall.exe [RutaImagen]

Donde [RutaImage] debe contener la extensión del archivo, por ejemplo:

SetWall.exe C:\Imagen.jpg

La aplicación verificará que el archivo exista en la ruta utilizando la función GetFileAttributes y si no hay problemas, procederá a aplicar el fondo de forma local para luego abrir la subclave en donde se almacena la directiva y escribir el nuevo contenido con la ruta de la imagen. Finalmente, llama a la función SystemParametersInfo para notificarle al sistema operativo del cambio y que se pueda ver inmediatamente.

Así es como se ve mi equipo con el fondo corporativo:

image

Para cambiar el fondo por una imagen ubicada en D:\WALL, basta con ejecutar SetWall con el nombre de archivo completo:

SetWall.exe “D:\WALL\img10.jpg”

La aplicación debe notificar el cambio en local y dominio:

SNAGHTML6087a79

En caso de intentar establecer algún TXT u otro tipo de archivo diferente a JPG y PNG, la aplicación nos dará un error:

SNAGHTML6099afc

El resultado final será el fondo de pantalla que queríamos, en vez del corporativo:

image

Descarga

Para los que estén interesados, la aplicación se puede descargar desde aquí:

https://1fichier.com/?mvw7d6fqgp

Si en algún momento logro que el cambio sea permanente, actualizaré la aplicación en el mismo servidor.

Saludos,

—Checho

Monitorear la creación de archivos en Windows utilizando Sysmon

Hace unos días recibí, por fin, mi copia del libro Troubleshooting with the Windows Sysinternals tools de Mark Russinovich y Aaron Margosis, copia que estaba esperando desde principios de año, pero que había tenido retrasos de publicación. Mi pensado es pasar por todas las herramientas lo más detallado posible; sin embargo, después del capítulo introductorio, me concentré en la aplicación más nueva de todas, System Monitor (Sysmon), pues quiero aprovechar este espacio para describir un escenario en el que puede ser de mucha ayuda y aprender por ahí derecho.

Sysmon es una herramienta escrita por Mark Russinovich y Thomas Garnier, basada en los mismos mecanismos que Process Monitor, pero enfocada completamente a rastrear actividad maliciosa en los equipos de la red. Sysmon, a diferencia de casi todas las herramientas de Sysinternals, debe ser instalada para empezar a monitorear, solo se concentra en una serie de eventos y puede utilizarse un archivo XML de configuración para realizar filtros específicos sobre estos eventos. Por otra parte, toda la actividad que Sysmon rastrea queda escrita en el Visor de eventos de Windows para un posterior análisis.

Aunque podría escribir un artículo de uso general de la herramienta, quiero enfocar esta entrada explícitamente a uno de los eventos: creación de archivos. Describiré cómo podemos instalar y configurar Sysmon para que podamos ver en el Visor de eventos todos los archivos que se crean, además de datos importantes como el proceso implicado en la creación, hora exacta, etc.

 

Instalación y configuración de Sysmon

Lo primero que debemos hacer es descargar, instalar y configurar Sysmon en el sistema operativo. A continuación, pasaré a describir cómo realizar todos estos procedimientos.

  1. Descargamos el paquete de Sysmon desde la web de Sysinternals: https://technet.microsoft.com/en-us/sysinternals/sysmon
  2. Creamos una carpeta llamada Sysmon en la unidad de Windows y guardamos el instalador, descomprimido, ahí:

    image

  3. Ejecutamos el símbolo del sistema con privilegios elevados y navegamos hasta la carpeta C:\Sysmon
  4. Creamos y configuramos el archivo de configuración de Sysmon:

Creación del archivo de configuración

El archivo de configuración consiste en un XML que contiene un elemento root, Sysmon,  y varios elementos hijos, con sus respectivos filtros para estos eventos que Sysmon leerá y aplicará. Es necesario indicarle explícitamente qué excluirá y qué incluirá porque si no, Sysmon empezará a escribir en el visor de evento todos los eventos.

Antes de construir el XML, debemos consultar la versión del schema ejecutando el siguiente comando:

sysmon –? config

Veremos, entre bastante información, un formato XML en la consola con la versión del schema.

image

Para el momento de escribir este artículo, la versión es 3.20, pero podría variar cuando lo ejecuten, así que más vale verificar antes de crear el archivo de configuración.

El secreto del archivo de configuración consiste en saber indicarle los filtros para todo lo que deseamos. Para este caso, es necesario deshabilitar todos los eventos adicionales y solo dejar el de FileCreate, correspondiente a la creación de archivos. Así quedaría el archivo:


<Sysmon schemaversion=”3.20″>
<!–Captures only FileCreate events–>
    <EventFiltering>
    <!–Let’s disable all events but FileCreate–>
        <FileCreate onmatch=”exclude”/>
        <ProcessCreate onmatch=”include”/>
        <FileCreateTime onmatch=”include”/>
        <NetworkConnect onmatch=”include”/>
        <ProcessTerminate onmatch=”include”/>
        <DriverLoad onmatch=”include”/>
        <ImageLoad onmatch=”include”/>
        <CreateRemoteThread onmatch=”include”/>
        <RawAccessRead onmatch=”include”/>
        <ProcessAccess onmatch=”include”/>
        <RegistryEvent onmatch=”include”/>               
        <FileCreateStreamHash onmatch=”include”/>   
    </EventFiltering>
</Sysmon>


Noten que el único evento que tiene el atributo onmatch como exclude es el de FileCreate; esto indica que Sysmon va a monitorear toda la actividad que tengan los eventos de creación de archivos. Todos los demás eventos, al estar con el atributo de include y sin ninguna regla de condición, quedarán deshabilitados.

Nota:

Aquí hay que tener cuidado, pues como veremos más adelante, al empezar a jugar con las reglas de condición los atributos varían.

Debemos guardar este archivo con cualquier nombre y extensión .XML. Preferiblemente, almacenarlo en la misma ruta que el ejecutable de Sysmon para que sea fácil referenciarlo. En mi caso le puse el nombre de Config.xml.

image

 

Para proceder, finalmente, con la instalación, ejecutamos desde el símbolo del sistema:

Sysmon.exe –accepteula -i C:\Sysmon\Config.xml

Debemos tener un resultado similar al siguiente:

image

Para verificar cuáles reglas quedaron aplicadas para los filtros, ejecutamos Sysmon –c

image

Revisión del los logs creados por Sysmon

De aquí en adelante basta con abrir el Visor de eventos y navegar hasta Applications and Services logs\Microsoft\Windows\Sysmon\Operational para poder ver todos los eventos que se están generando con respecto a la creación de archivos en nuestro sistema:

image

El evento 11 corresponderá siempre a la creación de archivos, aunque en la categoría lo describe también. Cada fila de información (Information) nos entregará los detalles precisos sobre el evento:

image

Cada evento tiene unos nombres de etiquetas que entregan diferente información. Por ejemplo, en la creación de archivo podemos ver el proceso que lo hizo con la etiqueta de Image; el archivo creado con la etiqueta de TargetFilename y la hora exacta con la etiqueta de CreationUtcTime.

Como está la configuración, vamos a ver todos los eventos de creación de archivos, independiente de que en unos confiemos y en otros no. Esta información es perfecta para auditoría o análisis forense, pero llegará un punto en el que deseemos concentrarnos en uno o más archivos específicamente y ahí Sysmon también nos puede ayudar.

Ahora, supongamos que entre todos los eventos encontramos uno que parece ser malicioso:

image 

Opciones avanzadas

Para poder concentrarnos específicamente en la creación del archivo MalwareFile.txt creado en la unidad de Windows, podemos indicarle fácilmente a Sysmon que solo monitoree las ocurrencias de ese nombre, sin importar en dónde lo escriba.

Nosotros podemos crear unas reglas de condiciones incluyentes o excluyentes con los elementos hijos, es decir, los nombres de etiqueta que aparecen en el evento, para poder suplir diferentes necesidades. Cuando el atributo del elemento es include, todo lo que esté dentro de la etiqueta FileCreate es lo que se escribirá en el Visor de eventos, dependiendo de la condición con la etiqueta.

En el siguiente ejemplo, estoy utilizando la etiqueta TargetFilename para decirle que me muestre siempre los resultados que contengan el nombre de MalwareFile.txt; para conseguir este filtro, utilizo la condición “contains” dentro del nombre de etiqueta, así:

image

De esta forma, no importa en qué unidad se cree el archivo, voy a poder verlo en el Visor de eventos.

La modificación en la configuración de Sysmon no requiere reinicio y se aplica inmeditamente; basta con ejecutar desde el símbolo del sistema con privilegios elevados:

Sysmon –c C:\Sysmon\Config

image

Si utilizamos nuevamente Sysmon –c, veremos que el filtro está aplicado:

image

 

Ahora supongamos que deseamos tener registro de todos los archivos creados que contengan la palabra «Malware» y se copien en la partición del sistema operativo. La regla de condición, teniendo en cuenta las etiquetas de Image y de TargetFilename quedarían expresadas en el XML así:

<FileCreate onmatch=”include”>
            <TargetFilename condition=”image”>C:\</TargetFilename>
            <TargetFilename condition=”contains”>Malware</TargetFilename>
</FileCreate>

Aquí estoy utilizando la etiqueta TargetFilename, que contiene el nombre completo, incluyendo la ruta, para establecer dos reglas de condición:

1. La imagen debe ser el la unidad del sistema operativo, C
2. El archivo debe contener el nombre de «Malware» para que lo escriba en el Visor de eventos

Siempre se debe correr el comando de Sysmon –c con el XML de configuración para que los filtros queden aplicados; es decir:

Sysmon –c C:\Sysmon\Config.xml

De esta forma podríamos ver toda ocurrencia de la palabra «Malware» en los archivos creados en la unidad de Windows:

image

Como pueden ver en el ejemplo, el archivo contiene la palabra clave en la mitad.

Entre mejor implementemos los filtros en Sysmon, más fructífero será nuestro análisis. Es una herramienta sorprendente.

Limitaciones

Si el código de la aplicación tiene como disposición CREATE_ALWAYS, es decir, que el archivo se escriba si no estaba o se sobreescriba si ya estaba, Sysmon solo registrará en el Visor de eventos la primera vez que se escribió, no cuando se haya sobreescrito. Dicho esto, una aplicación podría sobreescribir datos maliciosos sobre un archivo ya creado y no quedaría nada en el Visor de eventos.

Pude contactar a Mark Russinovich sobre esto y él me dijo que estaban considerando agregar la sobreescritura también para una futura actualización.

Espero escribir más adelante sobre el monitoreo de operaciones en registro también.

Saludos,

—Checho

Cambiar el fondo de pantalla establecido por directivas de grupo en Windows 10

En mi empresa, como en todas las organizaciones, hay una directiva de grupo que establece un fondo de pantalla corporativo en todas las estaciones Windows. Si bien es algo normal y los encargados de TI suelen cambiarlo con cierta frecuencia, se vuelve muy aburridor estar viendo el mismo fondo de pantalla todos los días; por este motivo, decidí explorar un poco cómo reconoce Windows la directiva para cambiarlo por uno que sea de mi gusto y compartirlo por aquí.

Nota: es necesario contar con privilegios administrativos para poder realizar los procedimientos que voy a describir aquí.

Explorando la directiva del fondo de pantalla

Para poder seguir lo que pasa al activar una directiva de grupo, es necesario forzar la configuración con la herramienta de gpupdate, con el parámetro de /force, y seguirla con Process Monitor mientras hace el procedimiento.

image

Ya que Process Monitor genera bastante bulla con el log, debemos configurar filtro para que nos muestre lo que esté haciendo el proceso de svchost.exe, encargado de replicar las directivas de grupo, que las operaciones sean de escritura en el registro y que no muestre nada de sistema de archivos, procesos o redes.

image

Después de esto, abrí el cuadro de búsqueda (CTRL + F) y procedí a buscar todas las ocurrencias que tuviese la palabra «Wallpaper».

image

El primer resultado, aunque no es exactamente el que buscaba, encontré algunos detalles interesantes:

image

El Path hacía referencia a la subclave de registro que almacena la información correspondiente a las GPO aplicadas tanto en máquina como en usuario. En este caso, al SID correspondiente a mi usuario, S-1-5-21-3916089143-2390449709-3607105231-11656.

Noten que, según me indicaba Process Monitor, Windows estaba escribiendo un valor (RegSetValue) con el nombre de DisplayName y su contenido era GPO Wallpaper, nombre de la GPO que se encargaba de configurar el fondo de pantalla corporativo en mi equipo.

Haciendo clic derecho desde Process Monitor e indicando Jumpt To…, encontré todos los detalles referentes a la directiva de grupo en el registro: nombre, ubicación física, ruta completa de la OU, identificador único de la GPO, entre otras.

image

Toda esta información estaba alojada en la subclave HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\DataStore\SID, mas no era la única GPO, pues en la raíz de DataStore están alojados las GPO tanto para usuario como para máquina. Las que corresponden a la máquina están en la subclave de Machine, y las de usuario, en su respectiva subclave que tiene como nombre el SID.
 

image

Esta información puede llegar a ser muy útil si estamos haciendo diagnóstico de problemas con directivas de grupo que no estén aplicando en los clientes; sin embargo, no me decía desde dónde estaba llamando al fondo de pantalla ni la ubicación de este. Lo que hice fue seguir buscando en Process Monitor con la misma palabra, Wallpaper, y esto fue lo que encontré:

SNAGHTML22c85cd8

Windows creó un valor de registro llamado Wallpaper en la ruta HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\; cabe agregar que normalmente las directivas de grupo, correspondientes a usuario, se agregan en la subclave de Policies.

Abrí el Registro de Windows para explorar de una forma más visual y hallé lo que estaba buscando, la ruta exacta de la directiva de fondo de pantalla.

image

El primer valor, Wallpaper, hace referencia a la ruta física, normalmente de red, en donde está ubicada la imagen a establecer como fondo de pantalla; el segundo valor, WallpaperStyle, le dice a Windows cómo debe posicionar la imagen en el escritorio: centrado, ajustado, etc.

Una vez obtenida la información, el siguiente paso, naturalmente, era proceder a hacer la personalización.

Cambiar el fondo de pantalla por uno personalizado

Para realizar el cambio de fondo corporativo a uno personal, realizamos los siguientes pasos:

1. Asegurarnos de estar en la subclave de registro: HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

2. Doble clic sobre el valor Wallpaper para abrir la ventana de edición

3. Le indicamos una ruta completa, local o de red, en donde esté alojado nuestro fondo de pantalla, en el cuadro de texto:

image

4. Clic en el botón de Aceptar (OK)

5. Reiniciamos el sistema o reiniciamos el proceso de Explorer.exe para que el fondo se aplique y lo veamos en nuestra pantalla

¿Se puede impedir el cambio efectuado por la directiva?

En teoría sí, pero después de intentarlo muchas veces, me encontré con la sorpresa que no. Básicamente, para evitar el cambio habría que quitarle todo tipo de privilegios de escritura al usuario SYSTEM sobre la subclave de System o incluso de Policies; sin embargo, todos los administradores, incluyendo SYSTEM, por supuesto, tienen el privilegio de tomar propiedad (SeTakeOwnershipPrivilege), lo que les permite volver a restablecer todos los permisos de las subclaves.

Trataré de adentrarme más en esto cuando aprenda un poco de Internals.

Saludos,

—Checho