Guía de auditoría de VBA y herramientas internas para prepararse ante la baja de VBScript

Resumen ejecutivo

En este artículo, «herramientas internas» no se refiere solo a macros de Excel o archivos .vbs. Incluye los scripts de inicio de sesión de GPO, las tareas registradas en el Programador de tareas, los scripts distribuidos mediante Intune y las Custom Action de VBScript en paquetes MSI. Aunque usted no recuerde haber escrito VBScript por su cuenta, si alguno de estos elementos tiene un .vbs incrustado, entra dentro del alcance.

A fecha de abril de 2026, Microsoft ha publicado su política de baja escalonada de VBScript: en Windows 11 versión 24H2 primero estará habilitado de forma predeterminada como Feature on Demand, en la siguiente fase pasará a estar deshabilitado de forma predeterminada, y en la fase final se eliminará en una futura versión de Windows. En otras palabras, lo que realmente conviene hacer ahora, antes de la «reescritura total», es «visualizar dónde existe dependencia de VBScript».

En cuanto al calendario, no se ha publicado una fecha definitiva. La guía de Microsoft dirigida a VBA sitúa la Fase 2 (deshabilitar el FOD de forma predeterminada) «hacia 2026-2027» y la Fase 3 (eliminación) como «TBD (por determinar)». Es decir, en este asunto no se puede calcular hacia atrás «para cuándo hay que terminarlo» a partir de una fecha. Bajo la premisa de que el plazo se acerca a medida que aumentan los equipos con Windows 11 24H2 o posterior, conviene al menos completar el inventario cuanto antes.

En VBA y las macros de Excel, los puntos prácticos se reducen a dos grandes casos. Uno es la ejecución externa de .vbs, y el otro son las referencias a bibliotecas de tipo VBScript, como VBScript.RegExp. Sobre este segundo caso, a partir de Office versión 2508 (compilación 19127.20154) la clase RegExp se incorporó de forma estándar en el VBE, lo que ha facilitado migrar al menos una parte de la dependencia de RegExp. Por otro lado, en entornos mixtos donde quedan clientes de Office antiguos, es habitual que el mismo código VBA funcione en unos equipos y no en otros.

Lo que dificulta la migración no es tanto VBScript en sí como «la operación que lo rodea». Por ejemplo, aunque se reemplace el código para que Excel invoque powershell.exe, si el resultado choca con reglas de reducción de la superficie de ataque (ASR) como «bloquear la creación de procesos secundarios por aplicaciones de Office» o «bloquear las llamadas a la API de Win32 desde macros de Office», con AppLocker, con App Control for Business, con la directiva de ejecución de PowerShell, con la gestión de firmas o con el control de macros en archivos con marca MOTW, no funcionará en producción. El plan de migración debe diseñarse incluyendo no solo la conversión de código, sino también las directivas, las firmas y la auditoría de registros.

La ruta más corta es inventario → detección estática → recopilación de registros de ejecución → selección de la alternativa → pruebas → despliegue gradual. En este artículo lo organizamos en ese orden, orientado a la práctica.

Además, el código que aparece en este artículo está publicado en GitHub como un conjunto de ejemplos ejecutables y comprobables (scripts de auditoría de PowerShell, ejemplos de reemplazo, código de referencia para VBA y Office Scripts, y pruebas Pester).

vbscript-deprecation-vba-excel-macro-internal-tools-audit-guide - komurasoft-blog-samples (GitHub)

Mini diccionario de términos

En los apartados siguientes aparecen, uno tras otro, acrónimos de funciones de seguridad de Windows. Si repasa primero esta sección, el resto se lee con más facilidad.

Panorama del cambio

Lo primero que hay que tener claro es que el punto en cuestión no es que «VBA se vaya a retirar». Lo que Microsoft ha publicado es únicamente la baja escalonada de VBScript, y el impacto sobre los proyectos VBA se concentra principalmente en la ejecución de .vbs externos y en las referencias a bibliotecas de tipo VBScript. El Microsoft 365 Developer Blog también identifica la ejecución de .vbs desde VBA y el uso de VBScript.RegExp como los puntos de impacto representativos.

Para decidir las prioridades prácticas, resulta más fácil pensarlas con la siguiente tabla.

Este orden de prioridades es un juicio práctico basado en el plan de baja de VBScript por parte de Windows, la estrategia oficial de detección y las especificaciones de ASR, AppLocker y App Control.

Solo RegExp tiene una situación algo distinta. A partir de Office versión 2508, la clase RegExp se incluye de forma estándar en el VBE, por lo que, si el uso se limita a RegExp, ahora es posible «resolver parte de la dependencia de VBScript con la actualización de Office». Sin embargo, esto no se resuelve automáticamente en organizaciones con Office antiguo, canales de actualización lentos, entornos mixtos o imágenes de equipo obsoletas. Es importante incluir en el inventario tanto «la actualización de Office» como «el cambio de fase de Windows».

Cómo llevar a cabo el inventario

El inventario no basta con buscar por nombre de archivo. Se recomienda mantener, como mínimo, las siguientes 10 perspectivas como columnas, por caso, por herramienta y por proceso de negocio.

• ① Método de detección de dependencias de VBScript Registre por separado la búsqueda de archivos, el análisis de código y el análisis de registros.
• ② Uso de CreateObject / GetObject / Execute / ExecuteGlobal, etc. dentro de VBA El destino de la dependencia queda oculto en una cadena de texto, por lo que es fácil que se escape de una búsqueda estática.
• ③ Llamadas a scripts externos desde macros de Excel Mantenga por separado WScript.Shell, la función Shell, wscript.exe / cscript.exe, y .vbs / .js / .ps1.
• ④ Dependencias de scripts en lotes y herramientas internas Incluya las tareas programadas, GPO, Intune, los scripts de operación en carpetas compartidas y los instaladores.
• ⑤ Seguridad, permisos, firmas y directivas AppLocker, App Control for Business, ASR, la directiva de ejecución de PowerShell, la firma digital y la necesidad o no de permisos de administrador.
• ⑥ Comparación de tecnologías alternativas y coste de migración Compare VBA nativo, PowerShell, .NET/VSTO, Office Scripts y Power Automate.
• ⑦ Plan de pruebas Separe las pruebas unitarias, de integración, de aceptación de usuario y las repeticiones tras aplicar la directiva.
• ⑧ Procedimiento operativo y reversión (rollback) Deje por escrito qué hay que revertir para recuperar el servicio y hasta qué punto se automatiza.
• ⑨ Compatibilidad y rendimiento Diferencias de versión de Office, 32/64 bits, rendimiento del equipo, carga de la recopilación de registros y tiempos de espera de los flujos en la nube.
• ⑩ Caso de estudio de migración de ejemplo Prepare de antemano un caso representativo que pueda usarse para explicarlo sobre el terreno.

De estos 10 puntos, la guía oficial de Microsoft señala expresamente como áreas prioritarias, en particular, la GPO, las tareas programadas, los scripts distribuidos por Intune, las Custom Action de MSI y la detección mediante Sysmon, AppLocker y App Control.

Pensar en el flujo completo de la migración como se muestra en el diagrama evita desviaciones.

flowchart TD
    accTitle: Flujo de migración desde el inventario hasta la desactivación gradual de VBScript
    accDescr: Diagrama que muestra cómo el inventario de activos se clasifica según el tipo de dependencia y avanza a través de pruebas unitarias, de integración y un despliegue piloto en modo de auditoría hasta la desactivación gradual del FOD de VBScript
    A[Inventario de activos] --> B{Tipo de dependencia}
    B -->|Ejecución externa de .vbs| C[Reemplazar por PowerShell o VBA nativo]
    B -->|VBScript.RegExp| D[Migrar al RegExp integrado de Office 2508+]
    B -->|GPO / tarea / MSI| E[Corregir la configuración centralizada y los paquetes de distribución]
    B -->|Dependencia desconocida u oculta| F[Recopilar registros de ejecución con Sysmon / AppLocker / App Control]
    C --> G[Pruebas unitarias]
    D --> G
    E --> H[Pruebas de integración]
    F --> H
    H --> I[Despliegue piloto en modo de auditoría]
    I --> J[Desactivación gradual del FOD de VBScript]

Para los entornos donde no se muestre el diagrama, lo resumimos en tres líneas.

1. Clasifique las dependencias encontradas en el inventario en cuatro grupos: ejecución externa de .vbs, VBScript.RegExp, configuración centralizada (GPO, tareas, MSI) y desconocida.
2. Para cada grupo, decida el destino del reemplazo, supérelo con pruebas unitarias y, a partir de ahí, únalo a las pruebas de integración.
3. Realice un despliegue piloto en modo de auditoría y, si no hay problemas, desactive el FOD de VBScript de forma gradual.

Seguir este orden reduce considerablemente el típico retrabajo de «reescribir primero y descubrir después que falla por culpa de GPO o ASR».

Detección práctica y ejemplos de código

Búsqueda de archivos e inventario de la configuración

La guía de detección de Microsoft recomienda hacer una búsqueda recursiva de .vbs priorizando rutas con un propósito claro, como C:\Users, C:\ProgramData o C:\Scripts, y comprobar por separado también GPO, tareas programadas, scripts distribuidos por Intune y paquetes MSI. Supervisar vbscript.dll con Sysmon es útil, pero la supervisión de carga de imágenes (Image Load) genera mucho volumen de registros y carga operativa, por lo que conviene validarla primero en un piloto de pequeña escala.

# Revisión aproximada de dependencias de scripts en equipos y carpetas compartidas
$paths = @("C:\Users", "C:\ProgramData", "C:\Scripts")
$patterns = @(
  'wscript\.exe',
  'cscript\.exe',
  '\.vbs(\s|$)',
  'VBScript\.RegExp',
  'WScript\.Shell',
  'CreateObject\("VBScript\.RegExp"\)',
  'ExecuteGlobal'
)

$hits = foreach ($path in $paths) {
  if (Test-Path $path) {
    Get-ChildItem -Path $path -Recurse -File `
      -Include *.vbs,*.ps1,*.bat,*.cmd,*.wsf,*.hta,*.txt `
      -ErrorAction SilentlyContinue |
      Select-String -Pattern $patterns -AllMatches |
      Select-Object Path, LineNumber, Line
  }
}

$hits | Export-Csv .\vbscript-dependency-hits.csv -NoTypeInformation -Encoding UTF8

A continuación, revisamos el Programador de tareas. Esto se debe a que, en las herramientas internas, es más frecuente que wscript.exe / cscript.exe / .vbs estén incrustados dentro de la definición de la tarea que en un archivo suelto.

# Extraer llamadas a VBScript desde las tareas programadas
Get-ScheduledTask | ForEach-Object {
  foreach ($a in $_.Actions) {
    if ($a.Execute -match 'wscript|cscript|mshta' -or $a.Arguments -match '\.vbs\b') {
      [pscustomobject]@{
        TaskName  = $_.TaskName
        TaskPath  = $_.TaskPath
        Execute   = $a.Execute
        Arguments = $a.Arguments
      }
    }
  }
} | Export-Csv .\task-vbscript-dependencies.csv -NoTypeInformation -Encoding UTF8

Análisis del código VBA

En el lado de VBA, no basta con mirar solo las referencias configuradas. CreateObject y GetObject pueden iniciar un objeto COM a partir de una cadena de texto, así que puede existir una dependencia aunque no aparezca nada en las referencias. La documentación de VBA/Office de Microsoft también describe CreateObject como el mecanismo básico para crear objetos COM, y tanto FileSystemObject como Scripting.Dictionary se usan de esa forma. Además, para leer un proyecto VBA de forma programática es necesario habilitar «Confiar en el acceso al modelo de objetos de proyectos de VBA».

' Requisitos previos:
'  - Habilitar en el [Centro de confianza] la opción "Confiar en el acceso al modelo de objetos de proyectos de VBA"
'  - Los proyectos protegidos requieren además exportar el origen por separado o confirmarlo con el responsable
Sub ScanProjectForVbScriptRisks()

    Dim comp As Object
    Dim cm As Object
    Dim ws As Worksheet
    Dim nextRow As Long
    Dim patterns As Variant
    Dim p As Variant
    Dim i As Long
    Dim lineText As String

    patterns = Array( _
        "CreateObject(""VBScript.RegExp"")", _
        "VBScript.RegExp", _
        "WScript.Shell", _
        "Shell(", _
        ".vbs", _
        "wscript.exe", _
        "cscript.exe", _
        "ExecuteGlobal", _
        "Execute(" _
    )

    Set ws = ThisWorkbook.Worksheets.Add
    ws.Range("A1:D1").Value = Array("Module", "Line", "Pattern", "Code")
    nextRow = 2

    For Each comp In ThisWorkbook.VBProject.VBComponents
        Set cm = comp.CodeModule

        For i = 1 To cm.CountOfLines
            lineText = cm.Lines(i, 1)
            For Each p In patterns
                If InStr(1, lineText, CStr(p), vbTextCompare) > 0 Then
                    ws.Cells(nextRow, 1).Value = comp.Name
                    ws.Cells(nextRow, 2).Value = i
                    ws.Cells(nextRow, 3).Value = p
                    ws.Cells(nextRow, 4).Value = lineText
                    nextRow = nextRow + 1
                End If
            Next p
        Next i
    Next comp

    ws.Columns.AutoFit
    MsgBox "Scan finished: " & (nextRow - 2) & " hits"

End Sub

Este análisis recoge, como mínimo, CreateObject("VBScript.RegExp"), WScript.Shell, Shell(, .vbs y ExecuteGlobal. En particular, la ejecución mediante cadenas de texto, como Execute / ExecuteGlobal, es un foco habitual de omisiones en el inventario, porque el destino de la dependencia y el código que se ejecuta se construyen de forma dinámica.

Análisis de registros

En la fase de revisión de registros de ejecución, la combinación Sysmon + AppLocker/App Control es muy eficaz. Con Sysmon se puede rastrear la carga de vbscript.dll mediante el Event ID 7, y con AppLocker se pueden consultar en el Visor de eventos los eventos de permiso y auditoría para scripts y MSI. Si App Control for Business se ejecuta en modo de auditoría, los scripts y los MSI quedan registrados en el registro AppLocker\MSI and Script.

# Sysmon: comprobar los procesos que cargaron vbscript.dll
Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvents 2000 |
  Where-Object { $_.Id -eq 7 -and $_.Message -match 'vbscript\.dll' } |
  Select-Object TimeCreated, MachineName, Message

# AppLocker / App Control: comprobar los registros de auditoría relacionados con scripts y MSI
Get-WinEvent -LogName "Microsoft-Windows-AppLocker/MSI and Script" -MaxEvents 2000 |
  Where-Object { $_.Id -in 8005, 8006 } |
  Select-Object TimeCreated, Id, Message

Lo importante aquí es recopilar no solo los registros de «lo que está funcionando», sino también los de «lo que se habría bloqueado en modo de auditoría». Los eventos de auditoría de AppLocker y el modo de auditoría de App Control son adecuados para verificar la seguridad antes de bloquear en producción.

Ejemplo mínimo de reemplazo

Si el proceso se limita a algo como llamar a un .vbs externo para generar un CSV, la vía más rápida es reemplazarlo primero por VBA nativo.

Sub ExportCsvNativeVba()

    Dim f As Integer
    Dim outPath As String

    outPath = ThisWorkbook.Path & "\out.csv"
    f = FreeFile

    Open outPath For Output As #f
    Print #f, "Code,Name"
    Print #f, "1001,Tokyo"
    Print #f, "1002,Osaka"
    Close #f

    MsgBox "CSV exported: " & outPath

End Sub

Si es necesario invocar procesamiento externo desde Excel, incluyendo el sistema operativo, carpetas compartidas, Active Directory, instaladores o recopilación de registros, es más realista inclinarse hacia PowerShell. Microsoft recomienda PowerShell como alternativa a VBScript, y del lado de PowerShell existen mecanismos oficiales de directiva de ejecución, firma y verificación Authenticode. Cabe señalar que la función Shell de VBA es asíncrona de forma predeterminada, por lo que, en procesos que requieren control de orden, hay que diseñar el flujo o considerar por separado un mecanismo de espera.

Sub RunModernPs()

    Dim cmd As String
    cmd = "powershell.exe -NoProfile -File """ & ThisWorkbook.Path & "\Normalize.ps1""" & _
          " -InputFile """ & ThisWorkbook.Path & "\in.csv""" & _
          " -OutputFile """ & ThisWorkbook.Path & "\out.csv"""

    Shell cmd, vbNormalFocus

End Sub

param(
  [string]$InputFile,
  [string]$OutputFile
)

Import-Csv $InputFile |
  Sort-Object Code |
  Export-Csv $OutputFile -NoTypeInformation -Encoding UTF8

# Aplicar y comprobar la firma
$cert = Get-ChildItem -Path Cert:\CurrentUser\My -CodeSigningCert | Select-Object -First 1
Set-AuthenticodeSignature -FilePath .\Normalize.ps1 -Certificate $cert
Get-AuthenticodeSignature -FilePath .\Normalize.ps1

Si el procesamiento de Excel se completa únicamente con formateo, agregación o transformación dentro del propio libro, Office Scripts también es una opción sólida. Office Scripts está orientado a Excel y es adecuado para ejecución en la nube, multiplataforma e integración con Power Automate.

function main(workbook: ExcelScript.Workbook) {
  const sheet = workbook.getActiveWorksheet();
  const used = sheet.getUsedRange();
  used.getFormat().autofitColumns();

  const tables = workbook.getTables();
  if (tables.length > 0) {
    tables[0].getSort().apply([{ key: 0, ascending: true }], true);
  }
}

Selección de la tecnología alternativa

La alternativa no debe elegirse por «con qué se puede escribir», sino por hasta qué punto de responsabilidad se le va a asignar. PowerShell está orientado a Windows, archivos, tareas e instaladores; VBA nativo, al interior de Office; Office Scripts, al procesamiento de libros de Excel; VSTO/.NET, a integraciones de escritorio complejas; y Power Automate, a la orquestación. La siguiente tabla es una estimación práctica basada en las características de cada método tal como las publica oficialmente Microsoft. El esfuerzo estimado es una referencia del autor.

Interprete la escala del esfuerzo estimado como la referencia para migrar una sola herramienta (una macro o un script): bajo = unos pocos días, medio = varias semanas, alto = de uno a varios meses. Si hay 10 objetos, el esfuerzo se acumula en esa misma proporción.

Si se representa de forma más intuitiva el criterio de selección, queda así.

flowchart TD
    accTitle: Criterio de selección de la tecnología alternativa a VBScript
    accDescr: Árbol de decisión que, a partir de una dependencia de VBScript encontrada, guía hacia VBA nativo, Office Scripts, PowerShell, .NET/VSTO o Power Automate según el ámbito del procesamiento
    A[Dependencia de VBScript encontrada] --> B{Se completa dentro del libro de Excel}
    B -->|Sí| C[VBA nativo]
    B -->|Sí, y prioriza lo compartido/la nube| D[Office Scripts]
    B -->|No| E{Toca el SO, archivos, tareas o AD}
    E -->|Sí| F[PowerShell]
    E -->|No| G{Integración de UI intensiva o complemento de larga vida}
    G -->|Sí| H[.NET / VSTO]
    G -->|Origen en un flujo o centrado en aprobaciones| I[Power Automate]

Esto también se puede resumir en tres líneas.

1. Si se completa dentro del libro de Excel, use VBA nativo. Si prioriza compartir o la ejecución en la nube, use Office Scripts.
2. Si toca el sistema operativo, archivos, tareas o Active Directory, use PowerShell.
3. Si necesita integración de UI intensiva o un complemento de larga vida, use .NET/VSTO. Si el origen es un flujo o se centra en aprobaciones, use Power Automate.

Como añadido solo sobre RegExp: en un entorno donde todos los equipos tienen Office versión 2508 o posterior, migrar a Dim re As RegExp / Set re = New RegExp resulta bastante eficaz. Sin embargo, si queda aunque sea un solo equipo con Office antiguo, ese código choca con un muro de incompatibilidad de compilación. En entornos mixtos, conviene decidir de antemano si la estrategia de migración será «sintaxis nueva», «sintaxis antigua» o «envoltorio condicional (wrapper)».

Pruebas y operación

Plan de pruebas

La migración de VBScript no se resuelve solo con pruebas unitarias. Si no se vuelve a probar en condiciones equivalentes a producción con las directivas de seguridad activas, el PowerShell o el script .NET del reemplazo se detendrá por otro motivo. La documentación de Microsoft también trata la directiva de ejecución de PowerShell, AppLocker, el modo de auditoría de App Control, ASR y el control de macros en archivos con MOTW como reglas independientes entre sí.

Lo que se pasa por alto con más frecuencia es lo siguiente.

• El reemplazo que hace que Excel invoque PowerShell puede chocar con la regla ASR de «bloquear la creación de procesos secundarios por aplicaciones de Office».
• Si se conservan declaraciones o llamadas a la API en VBA, puede chocar con la regla ASR de «bloquear las llamadas a la API de Win32 desde macros de Office».
• Los archivos .xlsm / .ps1 de prueba distribuidos por descarga o adjunto de correo cambian de comportamiento según el estado de MOTW y de la firma.
• La combinación de Office Scripts y Power Automate es cómoda, pero con CSV grandes o gran cantidad de celdas hay que tener presentes los tiempos de espera y los límites de transferencia de datos.
• La supervisión de carga de imágenes (Image Load) de Sysmon es útil, pero si se extiende sin cuidado a toda la empresa, tiende a aumentar mucho el volumen de registros.

Lista de verificación del procedimiento de migración

• Se realizó una búsqueda estática de .vbs, wscript.exe, cscript.exe, VBScript.RegExp, WScript.Shell, Shell( y ExecuteGlobal
• Se hizo el inventario por separado de GPO, tareas programadas, Intune, operación en carpetas compartidas y MSI
• Se inventarió la versión de Office y el canal de actualización, y se conoce el remanente por debajo de 2508
• Se decidió el destino del reemplazo entre «VBA nativo / PowerShell / .NET / Office Scripts / Power Automate»
• Se decidió la política de firma y de distribución de certificados
• Se probó el impacto de AppLocker / App Control / ASR / la directiva de ejecución
• Se recopilaron registros de auditoría en el departamento piloto
• Se documentó el procedimiento de reversión (rollback)
• Se dejó constancia de la justificación de «no utilizado» antes de desactivar el FOD de VBScript

Riesgos y medidas

Las medidas de esta tabla trasladan a la operación interna las restricciones de diseño que figuran en la documentación oficial de Microsoft.

La reversión no basta con «devolver el código». Como mínimo, considere en conjunto restaurar la versión anterior del paquete de distribución, revertir las directivas, el margen para volver a habilitar la función opcional y la continuidad de la recopilación de registros. Mientras VBScript siga existiendo como FOD, tal como indica la guía de la Fase 2 existe margen para volver a habilitarlo como función opcional, pero una vez eliminado en la Fase 3 esa vía de escape desaparece.

Caso de estudio de migración de ejemplo

Como ejemplo típico, imaginemos una macro de agregación mensual del departamento de Contabilidad. Supongamos que, en su estado actual, la macro de Excel inicia cleanup.vbs a través de WScript.Shell, valida los códigos con VBScript.RegExp tras dar formato al CSV y, por último, envía la salida a una carpeta compartida. Esta configuración recibe de lleno el impacto de la baja de VBScript y, además, es una configuración que, aunque se sustituya de forma sencilla por PowerShell, tiende a volver a bloquearse por ASR o por la gestión de firmas.

Sin una idea del tamaño del proyecto resulta difícil incluirlo en una solicitud de aprobación interna, así que también incluimos cifras hipotéticas colocadas solo con fines ilustrativos. Los valores reales se determinan según el resultado del inventario, pero si se reescriben con este mismo nivel de detalle, sirven directamente como base para la tabla de planificación.

La duración es más larga que el esfuerzo porque se trata de un proceso mensual. Aunque las pruebas unitarias terminen en un día, no se puede confirmar si «da el mismo resultado que el mes anterior» sin cruzar al menos un fin de mes. Si la herramienta incluye procesos anuales, esta espera se alarga todavía más. Al planificar, calcule hacia atrás no a partir del esfuerzo, sino a partir de el momento en que se puede verificar.

En este caso, lo correcto es dividir el problema. Las validaciones, el formato y la agregación que se completan dentro de Excel se llevan a VBA nativo o al RegExp integrado de Office 2508+. La conversión de archivos y la entrada/salida hacia la carpeta compartida se lleva a PowerShell. Si el origen de la ejecución es «la llegada de un archivo» o «una hora fija cada día», se lleva a Power Automate. De esta forma se puede ordenar la responsabilidad que antes estaba comprimida en un único .vbs.

Un ejemplo de configuración tras la migración sería el siguiente.

• Macro de Excel: comprobación de entradas, operación de pantalla, mensajes dirigidos al usuario
• PowerShell: normalización de CSV, E/S de la carpeta compartida, salida de registros
• Gestión de firmas: firma Authenticode en los scripts de PowerShell
• Seguridad: verificación previa de AppLocker/App Control en modo de auditoría, y decisión sobre la necesidad de excepciones de ASR
• Ampliación futura: migración gradual del procesamiento estándar interno de Excel hacia Office Scripts

La ventaja de este enfoque es que permite desacoplar pronto la dependencia del runtime de VBScript sin tener que reconstruir todo de una sola vez. Al dividir por responsabilidad —absorber RegExp con la actualización de Office, llevar los scripts operativos a PowerShell y el flujo de negocio a Power Automate—, también se reduce el alcance de cualquier incidencia.

Herramientas recomendadas y referencias

• El conjunto de código de ejemplo de este artículo (scripts de auditoría de PowerShell y pruebas Pester) https://github.com/gomurin0428/komurasoft-blog-samples/tree/main/vbscript-deprecation-vba-excel-macro-internal-tools-audit-guide

Se recomienda leer la documentación oficial en este orden.

• VBScript deprecation: Timelines and next steps Punto de partida para confirmar la hoja de ruta general y el significado de cada fase.
• VBScript deprecation: Detection strategies for Windows Guía práctica de detección que incluye Sysmon, GPO, tareas programadas, Intune y Custom Action de MSI.
• Prepare your VBA projects for VBScript deprecation in Windows El más importante desde el punto de vista de VBA. Organiza la incorporación de RegExp, el tratamiento de Office 2508 en adelante y la tabla de compatibilidad.
• Diferencias entre Office Scripts y las macros de VBA Documento útil para decidir si conviene llevar el procesamiento centrado en Excel hacia Office Scripts.
• about_Execution_Policies / about_Signing / Set-AuthenticodeSignature / Get-AuthenticodeSignature Conjunto básico para gestionar la firma y la directiva de ejecución al migrar a PowerShell.
• Using Event Viewer with AppLocker / Use audit events to create App Control policy rules / Aplicación de scripts mediante App Control for Business Necesario para entender el diseño del modo de auditoría, la recopilación de eventos y el comportamiento de aplicación de scripts.
• Referencia de las reglas de reducción de la superficie de ataque Documento para comprobar las reglas de bloqueo de procesos secundarios de Office, de la API de Win32 y de la ejecución de descargas JS/VBS.
• Las macros procedentes de Internet se bloquean de forma predeterminada en Office Lectura obligada para entender el problema de MOTW al distribuir pruebas o al desplegar en producción.

Como herramientas de apoyo, en la práctica se usan con frecuencia las siguientes.

• Sysmon La base para supervisar la carga de vbscript.dll y recopilar eventos relacionados con procesos.
• Plantillas de configuración de Sysmon en GitHub sysmon-config de SwiftOnSecurity es una plantilla inicial de alta calidad, y sysmon-modular de Olaf Hartong es un punto de partida modular y fácil de operar.
• oletools / olevba Adecuado como apoyo para extraer el código fuente de VBA de archivos de Office y detectar palabras clave sospechosas o macros de ejecución automática.

En conclusión, prepararse para la baja de VBScript no basta con «buscar VBScript y sustituirlo por PowerShell». Gestionar en un único inventario la actualización de Office, el análisis de código, la configuración operativa, la firma, ASR/AppLocker/App Control y las pruebas de aceptación de usuario (UAT) es la vía más corta y segura. Recupere cuanto antes las áreas que, como RegExp, se pueden resolver con la actualización de Office, y separe con prioridad las áreas propensas a romperse por el cambio de fase de Windows, como la ejecución de .vbs o las dependencias de GPO, tareas o MSI.

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Cuándo se va a retirar VBScript?

A fecha de abril de 2026, Microsoft ha publicado su política para retirar VBScript de forma escalonada. En Windows 11 versión 24H2, VBScript primero está habilitado de forma predeterminada como Feature on Demand (FOD); en la siguiente fase pasará a estar deshabilitado de forma predeterminada, y en la fase final se eliminará en una futura versión de Windows. En otras palabras, lo que realmente conviene hacer ahora, antes de reescribir todo, es visualizar dónde existen dependencias de VBScript. Mientras VBScript siga existiendo como FOD, todavía existe margen para volver a habilitarlo como función opcional, pero una vez eliminado esa vía de escape desaparece.

Si se retira VBScript, ¿dejarán de funcionar también VBA y las macros de Excel?

No. El punto en cuestión no es que «VBA se vaya a retirar». Lo que Microsoft ha publicado es únicamente la baja escalonada de VBScript, y el impacto sobre los proyectos VBA se concentra principalmente en dos puntos: la ejecución de archivos .vbs externos y las referencias a bibliotecas de tipo VBScript, como VBScript.RegExp. Los procesos que ejecutan .vbs directamente desde VBA o Excel tienen un riesgo alto de dejar de funcionar a partir del cambio de fase, por lo que deben identificarse con prioridad. Los scripts de inicio de sesión de GPO, las tareas programadas (Scheduled Task), los scripts distribuidos por Intune y las Custom Action de VBScript en paquetes MSI son también áreas críticas propensas a fallos generalizados.

¿Qué se debe usar como alternativa a VBScript?

La alternativa no se elige por «con qué se puede escribir», sino por hasta qué punto de responsabilidad debe asumir. Para los procesos que tocan el sistema operativo, archivos, carpetas compartidas, Active Directory, tareas o instaladores, la opción principal es PowerShell, que es la que recomienda Microsoft, y que además cuenta con mecanismos oficiales de firma y de directiva de ejecución. Para operaciones de celdas o informes que se completan dentro del propio libro de Excel, la opción es VBA nativo; si se prioriza la ejecución en la nube o la integración con Power Automate, Office Scripts es candidato; para integraciones de escritorio complejas o complementos internos de larga vida, .NET/VSTO; y para ejecuciones programadas o flujos que arrancan con una aprobación, Power Automate. Tras el reemplazo, es necesario probar, incluyendo las directivas, si la solución no queda bloqueada por ASR o AppLocker.

¿Qué se debe hacer si en VBA se usa VBScript.RegExp?

A partir de Office versión 2508 (compilación 19127.20154), la clase RegExp se incorporó de forma estándar en el VBE, de modo que, si el uso se limita a RegExp, ahora es posible resolver parte de la dependencia de VBScript simplemente con la actualización de Office. Sin embargo, en entornos mixtos donde quedan clientes de Office antiguos, es habitual que el mismo código VBA funcione en unos equipos y no en otros. Si queda aunque sea un solo equipo por debajo de la versión 2508, la nueva sintaxis choca con un muro de incompatibilidad de compilación, por lo que conviene primero inventariar la versión de Office y el canal de actualización de cada equipo para conocer los remanentes, y decidir de antemano si la estrategia de migración será «sintaxis nueva», «sintaxis antigua» o «envoltorio condicional (wrapper)».

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.