Tendemos a pensar que el Shadow IT son los .dmg, .exe o .pkg que un usuario instala fuera del catálogo corporativo. No siempre. Esta semana, una extensión maliciosa instalada en el IDE del endpoint de un empleado le ha costado a uno de los proveedores más críticos del ecosistema de código colaborativo el acceso indebido a miles de repositorios internos.
El Shadow IT más invisible, y el que tu EDR no ve, es el que entra por el marketplace del navegador o del IDE: se instala en treinta segundos, hereda los permisos del usuario, y nunca pasa por compliance.
No siempre se puede impedir que el atacante publique una extensión. Sí se puede impedir que esa extensión termine instalada en un endpoint corporativo. Publicamos hoy una política Apple lista para desplegar que cierra el vector más amplio y más fácil de cerrar, el del navegador, en Chrome, Edge, Firefox y Safari, desde un único perfil .mobileconfig que se importa directamente en Applivery.
El patrón: extensiones como Supply Chain
Las extensiones de navegador y de IDE comparten un modelo de permisos que las convierte en el eslabón más débil del endpoint moderno. Se instalan desde un marketplace público, sin involucrar a IT, con permisos heredados del usuario activo. El EDR clásico no las detecta porque, en el momento de la instalación, no son malware: lo son después.
| Vector | Permisos heredados | Cobertura clásica | Control UEM |
|---|---|---|---|
|
Extensiones VS Code / Cursor |
Proceso usuario, acceso completo a $HOME, ~/.ssh, ~/.aws, .env |
Ninguna |
Inventario + allow-list (custom) |
|
Extensiones Chrome / Edge |
Proceso navegador, acceso DOM y storage de todas las páginas |
EPP variable |
Configuration profile nativo |
|
Extensiones Firefox |
Proceso navegador, acceso DOM, cookies, history |
EPP variable |
Configuration profile nativo |
|
Extensiones Safari |
Sandbox parcial, acceso a navegación y datos de páginas |
Parcial |
Configuration profile nativo |
El Shadow IT clásico era una app instalada saltándose IT. El Shadow IT 2026 es una extensión instalada en treinta segundos desde un marketplace público, con permisos del usuario y sin paso por compliance. Mismo problema, superficie distinta.
La politíca: un perfil, cuatro navegadores
Política Apple MDM unificada que bloquea cualquier intento de instalación de extensiones en los cuatro navegadores principales. Mensaje informativo en castellano para el usuario final. Postura conservadora: bloquea todas las extensiones por defecto, ideal para flotas en entornos regulados o como punto de partida antes de definir una allow-list corporativa por publisher.
Esto es lo que ve un usuario cuando intenta instalar una extensión que ha caído fuera de la política, el navegador la bloquea antes de descargarla y el usuario recibe un mensaje informativo:
Y así se ve la política en la consola, dos payloads personalizados + dos apps en instalación forzosa:
La política es un único archivo Apple .mobileconfig (XML plist) que combina dos PayloadContent dentro de un Configuration profile estándar. Esto es exactamente lo que pegas en el textarea del modal Importar perfil, Applivery valida la estructura y lo convierte en los dos Personalizado que aparecen en la consola:
PayloadType Configuration
PayloadVersion 1
PayloadIdentifier com.applivery.extensionblock
PayloadUUID F0E1D2C3-B4A5-9687-7890-1A2B3C4D5E6F
PayloadDisplayName Bloqueo de extensiones — Browsers (macOS)
PayloadContent
<!-- ───── Payload #1: Chrome / Edge / Firefox ───── -->
PayloadType com.apple.ManagedClient.preferences
PayloadUUID A5B6C7D8-E9F0-1A2B-3C4D-5E6F7A8B9C0D
PayloadIdentifier com.applivery.extensionblock.browsers
PayloadDisplayName Bloqueo extensiones — Chrome / Edge / Firefox
PayloadContent
com.google.Chrome
Forced
mcx_preference_settings
ExtensionSettings
*
installation_mode blocked
blocked_install_message Las extensiones estan desactivadas por la politica de seguridad de tu organizacion.
com.microsoft.Edge
Forced
mcx_preference_settings
ExtensionSettings
*
installation_mode blocked
blocked_install_message Las extensiones estan desactivadas por la politica de seguridad de tu organizacion.
org.mozilla.firefox
Forced
mcx_preference_settings
EnterprisePoliciesEnabled
ExtensionSettings
*
installation_mode blocked
blocked_install_message Las extensiones estan desactivadas por la politica de seguridad de tu organizacion.
<!-- ───── Payload #2: Safari ───── -->
PayloadType com.apple.Safari
PayloadUUID C4F7E77A-9238-4BD5-A538-C12B577DE302
PayloadIdentifier com.applivery.extensionblock.safari
PayloadDisplayName Safari Restricciones
ExtensionsEnabled
DidDisableIndividualExtensionsAfterRemovingOnOffSwitchIfNecessary
Anatomía del perfil
Envoltorio configuration profile (el raíz)
Es el contenedor estándar Apple. PayloadType: Configuration lo identifica como perfil agregador, no aplica configuración por sí mismo, agrupa otros payloads. PayloadIdentifier y PayloadUUID son los identificadores únicos: cámbialos si vas a desplegar variantes del perfil para distintos grupos de dispositivos.
Payload #1 — com.apple.ManagedClient.preferences (Chrome / Edge / Firefox)
Este payload nativo de macOS inyecta Managed Preferences en aplicaciones de terceros. Lo usamos para alimentar los policy schemas que Chrome, Edge y Firefox leen como dispositivos gestionados por organización:
- Cada navegador se identifica por su bundle ID (com.google.Chrome, com.microsoft.Edge, org.mozilla.firefox).
- Bajo Forced > mcx_preference_settings, se declara la clave ExtensionSettings con un wildcard * que matchea cualquier extensión.
- installation_mode: blocked impide la instalación; blocked_install_message define el texto que el usuario ve.
- Firefox requiere además EnterprisePoliciesEnabled: true — sin ese flag, Firefox ignora cualquier managed preference.
Payload #2 — com.apple.Safari
Safari es una app Apple del sistema, no usa el esquema Chromium. Su payload propio expone dos claves clave:
- ExtensionsEnabled: false desactiva el subsistema de extensiones de Safari.
- DidDisableIndividualExtensionsAfterRemovingOnOffSwitchIfNecessary: true cubre el caso esquinado: si el usuario consigue reactivar el switch general, cada extensión individual queda desactivada por separado.
Personalización rápida
| Capacidad | Qué hace |
|---|---|
|
Personalizar el mensaje al usuario |
El valor de blocked_install_message en cada payload de navegador. |
|
Permitir extensiones puntuales (gestor de contraseñas, etc.) |
Añade entradas por ID-de-extensión con installation_mode: allowed dentro de ExtensionSettings, manteniendo el * en blocked como default. |
|
Desplegar en varios grupos con configs distintas |
Duplica el perfil cambiando PayloadIdentifier y PayloadUUID. |
Cómo se importa en Applivery
No hace falta construir el perfil clave a clave en el editor: Applivery acepta el .mobileconfig (o el XML equivalente) directamente. El flujo desde la consola tiene tres clics.
1. En Políticas, abre la pestaña Añadir configuración y haz click en Importar.
2. Pega el XML del perfil o súbelo como archivo desde Cargar XML. Applivery valida la estructura y muestra el preview.
3. Tras Previsualizar y confirmar, el perfil aparece como Personalizado #N en la policy, listo para asignarse al grupo de dispositivos.
Las apps que vienen con la política (Chrome + Applivery Agent) se ven en la pestaña Apps:
Extensiones de IDE: la segunda capa
El navegador es el vector más amplio, pero no el único. Las extensiones de VS Code, Cursor y JetBrains comparten exactamente el mismo modelo de permisos y, justamente, esa es la superficie por la que ha entrado el atacante del incidente de esta semana. La cubrimos con una segunda capa también desplegada desde Applivery, un script de auditoría que enumera las extensiones instaladas en el endpoint, las normaliza al formato publisher.extensionName, y las compara contra la allow-list corporativa.
En macOS el script va en Bash: recorre ~/.vscode/extensions/, ~/.cursor/extensions/ y ~/Library/Application Support/JetBrains/<producto>/plugins/, calcula el SHA-256 de cada paquete, y deja un log auditable en /var/log/applivery-extension-audit.log.
En Windows el equivalente vive en PowerShell, enumera %USERPROFILE%\.vscode\extensions y aplica la misma lógica de comparación contra allow-list.
El despliegue en Applivery es directo: el .sh y el .ps1 se suben a Recursos del workspace, y desde la sección Scripts de la policy Apple o Windows correspondiente se adjuntan para ejecución periódica en los dispositivos del grupo. Desde ese momento, el resultado queda registrado en el histórico de la politica.
El código completo de los scripts y la plantilla de allow-list por sector irán en una entrega dedicada.
Las extensiones de navegador ya son un control auditable
El control de software en endpoint ha pasado de «buena práctica» a control auditable explícito.
| Estándar | Control aplicable | Qué exige |
|---|---|---|
|
ISO 27001:2022 |
A.8.7 — Protección contra malware |
Mecanismos de prevención, detección y recuperación frente a software malicioso |
|
ISO 27001:2022 |
A.8.19 — Instalación de software en sistemas operativos |
Procedimientos para gestionar la instalación de software en sistemas en producción |
|
ENS (RD 311/2022) |
op.exp.2 — Configuración de seguridad |
Configuración endurecida en función de la categoría del sistema |
|
ENS (RD 311/2022) |
mp.sw.2 — Aceptación y puesta en servicio |
Validación previa del software antes de su despliegue en producción |
Tener extensiones de navegador sin control documentado es uno de los hallazgos más frecuentes en auditorías de endpoint en 2026 y uno de los más fáciles de cerrar con un perfil de configuración bien escrito.
Este perfil no sustituye al EDR ni al SIEM. Cierra la puerta antes de que el atacante llegue al endpoint.
El perfil está listo, ¿tu flota también?
Si tu flota macOS o Windows todavía no tiene una policy de extensiones, este perfil es el punto de partida más rápido que puedes desplegar hoy.
Para entornos con ENS o ISO 27001 en el horizonte, nuestro equipo de consultores puede ayudarte a mapear los controles que faltan antes de la auditoría, contactanos.
Preguntas Frecuentes (FAQ)
¿Qué es el vector de extensiones y por qué es un riesgo para la seguridad del endpoint?
El vector de extensiones es la superficie de ataque que se abre cuando los empleados pueden instalar extensiones de navegador o de IDE sin pasar por un proceso de validación de IT. A diferencia del software tradicional, las extensiones se instalan en segundos desde un marketplace público, heredan los permisos del usuario activo, y no son detectadas por los EDR clásicos en el momento de la instalación.
En 2026, este vector es uno de los más explotados en ataques de supply chain: una extensión aparentemente legítima puede convertirse en malware después de una actualización silenciosa.
¿Se puede bloquear el vector de extensiones en macOS sin instalar agentes adicionales?
Sí. macOS permite gestionar extensiones de Chrome, Edge, Firefox y Safari a través de Configuration Profiles estándar (.mobileconfig), que cualquier solución MDM puede desplegar sin agentes adicionales en el endpoint. Un único perfil con dos payloads cubre los cuatro navegadores principales.
¿Qué diferencia hay entre bloquear extensiones en Chrome/Edge/Firefox y en Safari?
Chrome, Edge y Firefox usan el esquema de Managed Preferences de macOS (com.apple.ManagedClient.preferences) con la clave ExtensionSettings y un wildcard que bloquea cualquier extensión por defecto.
Firefox requiere además activar explícitamente EnterprisePoliciesEnabled: true, o ignorará cualquier managed preference. Safari, al ser una app del sistema Apple, usa su propio payload nativo (com.apple.Safari) con la clave ExtensionsEnabled: false.
¿Es posible permitir extensiones concretas mientras se bloquean las demás?
Sí. Dentro de ExtensionSettings se pueden añadir entradas por ID de extensión con installation_mode: allowed, manteniendo el wildcard * en blocked como comportamiento por defecto. Esto permite construir una allow-list corporativa sin eliminar el bloqueo general.
¿Cubre este enfoque también las extensiones de VS Code, Cursor o JetBrains?
El perfil .mobileconfig cubre exclusivamente extensiones de navegador. Las extensiones de IDE — VS Code, Cursor, JetBrains — comparten el mismo modelo de riesgo pero requieren una segunda capa: un script de auditoría que enumera las extensiones instaladas y las compara contra una allow-list corporativa. En macOS el script va en Bash; en Windows, en PowerShell. Ambos se pueden desplegar desde Applivery como scripts periódicos asociados a la policy del grupo de dispositivos.
¿Qué marcos de cumplimiento exigen controlar el vector de extensiones?
ISO 27001:2022 lo cubre bajo A.8.7 (protección contra malware) y A.8.19 (instalación de software en sistemas operativos). El Esquema Nacional de Seguridad (RD 311/2022) lo exige bajo op.exp.2 (configuración de seguridad) y mp.sw.2 (aceptación y puesta en servicio). Tener extensiones de navegador sin control documentado es uno de los hallazgos más frecuentes en auditorías de endpoint en entornos regulados.
