- PowerShell permite automatizar el uso de imágenes de Spotlight y carpetas locales como fondo y pantalla de bloqueo mediante scripts que modifican el registro y fuerzan el refresco del escritorio.
- En entornos gestionados con Intune, los scripts de PowerShell se empaquetan como aplicaciones, permitiendo desplegar wallpapers corporativos y configuraciones homogéneas usando archivos CSV y carpetas de recursos.
- PowerShell es una herramienta esencial para administración y despliegue (IIS, Web Deploy, bases de datos SQL y MySQL), pero su potencia también lo hace atractivo para atacantes, que lo usan en ataques fileless y marcos de postexplotación.
- La clave para aprovechar PowerShell sin aumentar el riesgo está en combinar buenas prácticas de scripting, políticas de ejecución adecuadas y soluciones de seguridad basadas en el análisis de comportamiento.
En este artículo vamos a juntar piezas que suelen aparecer por separado: scripts reales para usar las imágenes de Spotlight como fondo, ejemplos de rotación automática de wallpapers, cómo aplicar todo esto en entornos gestionados con Intune, y una introducción práctica al papel de PowerShell en administración y ciberseguridad. La idea es que salgas con una visión completa tanto de la personalización visual como de los riesgos y buenas prácticas al automatizar tu escritorio.
Spotlight + PowerShell: convertir las imágenes de bloqueo en tu fondo diario
Windows Spotlight muestra a diario imágenes espectaculares en la pantalla de bloqueo, pero de serie no hay una opción clara para usarlas automáticamente como fondo de escritorio. Ahí es donde entra PowerShell: con un pequeño script puedes decirle a Windows que tome siempre la última imagen de Spotlight y la aplique como fondo del usuario actual.
La clave del procedimiento está en el registro de Windows. Las imágenes de Spotlight asociadas al usuario se referencian en una ruta bajo HKEY_LOCAL_MACHINE, concretamente en una rama de configuración de LogonUI y contenido creativo que cambia según el SID (identificador de seguridad) de cada usuario. El truco consiste en detectar el SID activo, construir la ruta adecuada del registro y, a partir de ahí, obtener la imagen más reciente.
Un script típico comienza obteniendo el SID del usuario actual mediante ::GetCurrent(). Ese SID se utiliza para formar la ruta del registro que apunta a la configuración de la pantalla de bloqueo. Después, se enumeran las subclaves que contienen las referencias a las imágenes de Spotlight y se selecciona la última clave, ya que suelen estar ordenadas por fecha de creación, lo que facilita localizar la imagen más reciente.
Una vez localizada la clave de registro correcta, el script lee la propiedad que almacena la ruta de la imagen en formato de archivo (por ejemplo, un valor llamado landscapeImage) y guarda esa ruta en una variable. Esa variable será la que se use más adelante para actualizar el fondo de escritorio del usuario dentro de la rama de registro HKCU:\Control Panel\Desktop, que es donde Windows guarda la configuración del wallpaper.
Para evitar cambios innecesarios, el script suele comparar la ruta de la imagen actual de Spotlight con la ruta que está configurada como fondo en la clave de registro del usuario (WallPaper). Si coinciden, se asume que ya se está usando la última imagen de Spotlight como fondo de escritorio y el script finaliza con éxito sin tocar nada más, lo que reduce parpadeos o refrescos de pantalla innecesarios.
Otro detalle interesante de estos scripts es la calidad del JPEG. Muchos administradores aprovechan para asegurarse de que el valor JPEGImportQuality en HKCU:\Control Panel\Desktop está fijado a 100. Si la clave no existe, se crea como un DWord con valor 100; si existe pero tiene otro número, se actualiza. De esta forma se evita que Windows degrade la calidad de la imagen al convertirla para usarla como fondo.
El paso final es asignar la nueva ruta al valor WallPaper con Set-ItemProperty y forzar a Windows a refrescar el fondo. Para ello, se suele llamar a RUNDLL32.EXE USER32.DLL,UpdatePerUserSystemParameters en un bucle que se ejecuta durante unos segundos, ya que la actualización no siempre se aplica al primer intento. El script hace varias llamadas con pausas de un segundo para asegurarse de que el escritorio se repinta usando la nueva imagen.
Uno de los puntos delicados de este enfoque es que la ruta exacta del registro donde se guardan las imágenes de Spotlight puede variar entre equipos o futuras versiones de Windows. Conviene validar la ruta en tu entorno antes de desplegar nada a gran escala y tener presente que podrían ser necesarios ajustes si Microsoft cambia la forma de almacenar esta información.
Rotar fondos automáticamente desde una carpeta: el caso sencillo
Si no quieres depender de Spotlight y prefieres tu propia selección de imágenes, PowerShell también lo pone muy fácil —por ejemplo, para cambiar el fondo de pantalla automáticamente según la hora del día en Windows—. Puedes crear una carpeta, por ejemplo C:\Wallpapers, llenarla de fotos y dejar que un pequeño script elija y aplique una imagen de forma periódica (por ejemplo, una vez al día) usando el Programador de tareas de Windows.
Un enfoque habitual es listar los archivos de imagen con Get-ChildItem, limitarse a archivos mediante el parámetro -File y luego elegir uno al azar usando Get-Random. Con la propiedad .FullName de ese archivo se obtiene la ruta completa, que se escribe a continuación en el valor Wallpaper del registro del usuario, igual que se hacía con las imágenes de Spotlight.
Tras actualizar el valor de Wallpaper, se fuerza el refresco del fondo de escritorio con la misma técnica: una llamada a RUNDLL32.EXE user32.dll,UpdatePerUserSystemParameters. Aunque el ejemplo más simple lo hace solo una vez, en entornos reales muchos administradores prefieren repetir la llamada varias veces o añadir una pausa breve para asegurarse de que se ve el cambio en todos los escritorios, sobre todo en sistemas con varios monitores.
Este tipo de script resulta ideal para pequeñas automatizaciones personales: basta con programarlo en el Programador de tareas con una periodicidad diaria o incluso cada vez que inicias sesión. No requiere jugar con rutas de Spotlight ni con el SID del usuario, y funciona con cualquier colección de imágenes, desde fotografías corporativas a fondos artísticos descargados de Internet.
Además, estos scripts son una buena puerta de entrada a PowerShell para quien está empezando: permiten practicar con cmdlets como Get-ChildItem, Get-Random, Set-ItemProperty y el uso básico del registro de Windows sin necesidad de código complejo. A partir de aquí, es fácil ir introduciendo mejoras como filtrado por extensiones, registro de errores o integración con servicios externos.
Fondos y pantallas de bloqueo gestionados con Intune
En entornos empresariales la cosa se complica un poco. No basta con que un usuario decida cambiar su wallpaper; muchas organizaciones quieren fondos unificados, pantallas de bloqueo corporativas y, en ocasiones, presentaciones de diapositivas que muestren campañas internas, imágenes de marca o información básica de la compañía. Cuando los equipos están gestionados vía Intune y con los ajustes de productividad de Windows 11, PowerShell vuelve a ser una pieza clave.
Un escenario típico es el de un administrador que recibe un conjunto de imágenes y la petición de convertirlas en un pase de diapositivas para el fondo del escritorio y, a veces, para la pantalla de bloqueo. Suele definirse una carpeta local, por ejemplo C:\temp\slideshowtest como banco de pruebas, donde se copian todas las imágenes que se van a usar. A partir de ahí, se construye un script que configure Windows para usar esa carpeta como origen de diapositivas.
La parte de Intune consiste en empaquetar ese script como una aplicación (por ejemplo, un paquete que ejecute el .ps1) y desplegarlo a los dispositivos o grupos de usuarios deseados. Al ejecutarse en el contexto del usuario, el script tiene acceso a las claves de registro de HKCU, donde puede fijar tanto el fondo de escritorio como la imagen o modo de la pantalla de bloqueo, respetando las políticas de la organización.
Un enfoque más avanzado es el de scripts diseñados específicamente para IntuneApp, una solución de empaquetado y despliegue. Un ejemplo es un script llamado SetDesktop.ps1, acompañado de un archivo CSV (SetDesktop.csv) y una carpeta Wallpaper. El CSV actúa como fichero de configuración con columnas como nombre del archivo de imagen, estilo de colocación (Rellenar, Centrar, Ajustar, etc.) y color de fondo en formato hexadecimal (por ejemplo, #040E4C para un azul oscuro), que solo tendrá efecto si el estilo de presentación lo necesita.
La estructura típica de este tipo de solución puede ser algo como \IntuneApp\Wallpaper\wallpaper1.png, donde la imagen principal se almacena con un nombre estándar. En el CSV se define, por ejemplo, WallpaperStyle=Fill para que Windows rellene toda la pantalla manteniendo la relación de aspecto y recortando lo que sobre y un color de fondo en formato hexadecimal (por ejemplo, #040E4C para un azul oscuro), que solo tendrá efecto si el estilo de presentación lo necesita.
Para probar el comportamiento en local, muchos administradores simplemente ejecutan un archivo SetDesktop.cmd que llama al script en modo interactivo. Una vez verificado que el wallpaper se aplica y respeta el color y el estilo, se utiliza el modo automático -mode auto en el script PowerShell para integrarlo en el proceso de instalación silenciosa que se desplegará con Intune.
En organizaciones que utilizan el sistema IntuneApp, incluso es posible ajustar la audiencia de publicación mediante otro CSV (por ejemplo, intune_settings.csv), definiendo qué grupos de dispositivos o usuarios recibirán el nuevo fondo. De este modo se puede, por ejemplo, aplicar diferentes wallpapers según departamento, país o nivel de acceso, todo centralizado y automatizado.
Configurar fondos y bloqueo con imágenes externas como Unsplash
No todo el mundo está encantado con las imágenes de Spotlight. Hay usuarios que prefieren otros repositorios como Unsplash, que ofrece fotografías de alta calidad con licencia muy flexible. Un patrón común es programar un script que descargue cada día una nueva imagen desde una URL de Unsplash y la guarde siempre con el mismo nombre en disco, sobrescribiendo el archivo anterior.
Una vez que tienes ese archivo actualizado cada día, lo lógico es automatizar que Windows lo use tanto como fondo de escritorio como pantalla de bloqueo. Para el fondo, se recurre de nuevo a modificar HKCU:\Control Panel\Desktop y forzar la actualización con la llamada a RUNDLL32.EXE user32.dll,UpdatePerUserSystemParameters, de manera muy similar a los ejemplos anteriores.
La parte de la pantalla de bloqueo es algo más específica. Windows proporciona una API y configuraciones de registro para definir la imagen de bloqueo, aunque no es tan directa como la del wallpaper clásico. Muchos usuarios se plantean usar esa API o recurrir a ajustes de registro alternativos, aceptando que habrá que experimentar y comprobar qué combinación funciona mejor en su versión de Windows 10 o 11.
En estos escenarios es habitual que el script descargador y el script de aplicación estén separados: uno se encarga de obtener la imagen diaria desde Internet y guardarla con un nombre fijo, y otro, programado poco después, se limita a tomar ese archivo y establecerlo como fondo de escritorio y (si procede) como pantalla de bloqueo. Esto ayuda a depurar problemas: si la descarga falla, el script de aplicación seguirá funcionando con la última imagen válida.
Al apoyarse en servicios externos como Unsplash, hay que considerar también la disponibilidad de red, políticas de proxy y posibles cambios en la API remota. Es buena idea implementar manejo de errores y registros básicos (por ejemplo, anotando en un log local la fecha, URL y resultado de cada descarga) para detectar rápidamente si algo ha dejado de funcionar.
PowerShell como herramienta de automatización y seguridad: lo bueno y lo peligroso
Detrás de todos estos ejemplos de fondos de pantalla hay una realidad más amplia: PowerShell es un lenguaje de scripting y un shell de línea de comandos extremadamente potente para tareas de administración, automatización de configuración y también para operaciones de seguridad. Esa misma potencia es lo que lo convierte en una herramienta muy atractiva para atacantes.
Desde la perspectiva de administración, PowerShell permite listar módulos con Get-Module -ListAvailable, descubrir todos los comandos disponibles con Get-Command, interactuar con el registro, con servicios, con IIS, con bases de datos y prácticamente con cualquier componente del sistema. Esto lo hace indispensable para administradores de sistemas Windows y también para escenarios multiplataforma gracias a PowerShell Core, que se ejecuta en Windows, Linux y macOS.
A nivel de seguridad, sin embargo, hay que tener en cuenta varios riesgos. Atacantes pueden abusar de cmdlets legítimos para desactivar Microsoft Defender a través de Set-MpPreference -DisableRealTimeMonitoring $true o excluir rutas completas del análisis con Add-MpPreference -ExclusionPath "c:". También pueden usar Get-PSDrive para enumerar unidades, Get-EventLog para examinar registros en busca de información sensible o revisar el historial de comandos de PowerShell para intentar recuperar contraseñas utilizadas directamente en la línea de comandos.
PowerShell permite ejecutar scripts tanto desde disco como solo en memoria, lo que facilita los ataques «fileless» (sin archivos) difíciles de detectar por soluciones basadas solo en análisis de ficheros. Con el cmdlet Invoke-Expression (alias iex) es posible descargar scripts desde Internet y ejecutarlos directamente en memoria, a menudo junto a parámetros como -ExecutionPolicy Bypass y -nop (sin perfil) para saltarse restricciones de ejecución.
En los últimos años han aparecido marcos de explotación específicos como PowerSploit o PowerShell Empire, que ofrecen colecciones de scripts para postexplotación, ejecución de keyloggers, extracción de credenciales usando Mimikatz y otras técnicas avanzadas. Estas herramientas se aprovechan precisamente de la flexibilidad de PowerShell y su integración profunda en el sistema operativo.
Para los defensores, bloquear simplemente PowerShell.exe no es una opción. PowerShell forma parte integral de Windows y, además, existen herramientas que pueden ejecutarlo a través de la biblioteca System.Management.Automation.dll sin pasar por el ejecutable habitual. En la práctica, cualquier proceso podría llegar a ejecutar scripts de PowerShell si se abusa de esa DLL, por lo que las soluciones de seguridad modernas tienden a centrarse en el comportamiento y no en el binario concreto que se está usando.
Soluciones como SentinelOne se apoyan en el análisis de comportamiento: monitorizan procesos, argumentos de línea de comandos, acceso al registro, operaciones de red y ficheros, y con ese contexto identifican cuándo un uso de PowerShell es legítimo (por ejemplo, cambiar un fondo de escritorio corporativo) y cuándo forma parte de una cadena de ataque. De esta manera, se puede seguir utilizando PowerShell como herramienta de administración sin dejar la puerta abierta a los abusos.
Scripts de PowerShell para despliegue web e infraestructura
Más allá de los fondos y la personalización visual, PowerShell se usa intensivamente para configurar infraestructuras completas, como servidores IIS y sitios web públicos o internos. Un ejemplo muy representativo es el conjunto de scripts que instala Web Deploy (v2.1), pensados para facilitar la publicación de aplicaciones web y la gestión de bases de datos.
Estos scripts incluyen utilidades como SetupSiteForPublish.ps1, CreateSqlDatabase.ps1, CreateMySqlDatabase.ps1 y AddDelegationRules.ps1. Están diseñados para automatizar desde la creación de sitios en IIS y usuarios de despliegue hasta la provisión de bases de datos SQL o MySQL y la configuración de reglas de delegación necesarias para que los usuarios puedan publicar contenido de forma segura sin ser administradores del servidor.
Para usar este tipo de scripts se requiere un entorno con IIS 7 o superior, es decir, Windows Server 2008 o 2008 R2, y que el usuario que los ejecuta tenga privilegios de administrador. Hay que asegurarse también de que el rol de servidor web está habilitado, que el servicio de administración de IIS está activo, que PowerShell 2 está disponible y que Web Deploy se ha instalado con el componente de integración del servicio de administración.
El script SetupSiteForPublish.ps1, ejecutado sin parámetros, crea un sitio por defecto llamado WDeploySite con raíz física en %systemdrive%\inetpub\WDeploySite, un grupo de aplicaciones asociado WDeployAppPool y un binding en el puerto 8080 (o el siguiente disponible). Además, crea un usuario local no administrador (WDeploySiteuser), le da permisos completos sobre la carpeta del sitio y privilegios de administrador de IIS para ese sitio concreto, y guarda un archivo de configuración (WDeploy.PublishSettings) en el escritorio que puede ser consumido por herramientas como WebMatrix o Visual Studio.
SetupSiteForPublish.ps1 también puede usarse de forma más flexible mediante parámetros como siteName, sitePhysicalPath, siteAppPoolName, sitePort, deploymentUserName, deploymentUserPassword, managedRunTimeVersion, publishSettingSavePath y publishSettingFileName. Esto permite, por ejemplo, habilitar la publicación sobre un sitio ya existente para un usuario concreto o crear un nuevo sitio con nombre, ruta física, puerto y credenciales totalmente personalizados.
Para la parte de base de datos SQL, CreateSqlDatabase.ps1 automatiza la creación de una base de datos, un inicio de sesión, un usuario con permisos db_owner y la correspondiente cadena de conexión que se guarda en el mismo archivo de configuración de publicación. Los parámetros permiten definir el nombre de la base de datos, usuario y contraseña, así como especificar el administrador SQL (por ejemplo, sa) y la instancia (por defecto .\SQLExpress), además de la ruta y el nombre del archivo de configuración.
En entornos que utilizan MySQL, CreateMySqlDatabase.ps1 cumple una función parecida: genera la base de datos, crea un usuario con todos los privilegios sobre ella (por defecto restringidos a localhost) y añade la cadena de conexión a un archivo de configuración de publicación. Se pueden ajustar parámetros como el administrador (root normalmente), el host de MySQL (por defecto localhost) y, si es necesario, modificar la línea de concesión de privilegios para permitir accesos remotos usando '%' en lugar de 'localhost'.
Para terminar de atar la seguridad y los permisos de IIS, se utiliza el script AddDelegationRules.ps1, que configura reglas de delegación en el servidor para permitir que determinadas cuentas puedan escribir en applicationHost.config y realizar acciones como reciclar pools de aplicaciones. Este script puede crear cuentas elevadas específicas para estas tareas y admite parámetros para definir usuarios y contraseñas, además de un modificador para permitir el reseteo de credenciales de cuentas existentes.
Todos estos ejemplos de scripts de despliegue muestran la misma filosofía que hemos visto con la automatización de fondos y Spotlight: aprovechar PowerShell para convertir tareas repetitivas o complejas en procesos reproducibles, estándar y fáciles de desplegar en varios servidores o equipos, reduciendo errores humanos y mejorando la trazabilidad de la configuración.
Combinar PowerShell con las herramientas adecuadas permite tanto personalizar la experiencia visual del usuario (ya sea con Spotlight, Unsplash o wallpapers corporativos) como gestionar infraestructura web y seguridad con control fino. Entender cómo interactúan los scripts con el registro, los servicios del sistema y las políticas de ejecución es lo que marca la diferencia entre un entorno bien automatizado y uno expuesto a riesgos innecesarios.
Redactor apasionado del mundo de los bytes y la tecnología en general. Me encanta compartir mis conocimientos a través de la escritura, y eso es lo que haré en este blog, mostrarte todo lo más interesante sobre gadgets, software, hardware, tendencias tecnológicas, y más. Mi objetivo es ayudarte a navegar por el mundo digital de forma sencilla y entretenida.