vba2clr

TLDR:

Solo experimentando con diferentes formas de cargar ensamblados CLR (.NET) en VBA local y remotamente usando AppDomain.ExecuteAssembly o cualquier otro método útil después de sortear AccessVBOM (el acceso programático al proyecto de Visual Basic no es de confianza) desde VBA.

• vba2clr.*.vba:
  • Establece la clave de registro AccessVBOM a 1
  • Instancia un objeto COM Word.Application. (podría ser Excel.Application, MS PowerPoint, Access, etc.).
  • Añade una macro desde una cadena (la macro corresponde a ExecuteAssembly.vba codificado en b64/hex)
  • Ejecuta la macro ExecuteAssembly.vba usando wordObj.Application.Run...

.NET desde VBA:

• ExecuteAssembly.clr.2.0.vba: Hasta .NET 3.5

  • Añade las referencias requeridas de mscordlib
  • Instancia los objetos requeridos (IDomain, ICRHost)
  • Empaqueta los argumentos requeridos de AppDomain.ExecuteAssembly en dos matrices separadas (variables, tipos).
  • Usa DispCallFunc para llamar a AppDomain.ExecuteAssembly(Arg1, Arg2) (desplazamiento 51 del VFTable) donde Arg1 es la "URL del ensamblado .NET" o "ruta local" y Arg2 es el valor de retorno.
  • Los desplazamientos del VFTable de los métodos de AppDomain se pueden consultar en el IDL de AppDomain _AppDomain.idl, solo ten en cuenta que la interfaz AppDomain hereda de la interfaz IUnknown, por lo que los desplazamientos del VTable de las funciones/métodos comienzan desde el tercer desplazamiento en adelante, esto se debe a que las interfaces que heredan de IUnknown tienen las primeras 3 entradas de su vtable establecidas en los métodos QueryInterface, AddRef, Release.
  • WinDbg o IDA también se pueden usar como alternativas para extraer los desplazamientos del VTable de funciones/métodos.

• ExecuteAssembly.clr.x.vba: soporta .NET 2, 3.5 y 4.x

Notas de OPSEC:

• Crear un objeto COM para Word.Application (o Excel.Application, etc.), dará como resultado el inicio de un WinWord.exe adicional como proceso hijo de svchost.exe en lugar del proceso principal WinWord.exe.
• La clave de registro AccessVBOM se modifica/restaura mediante COM usando WScript.Shell; usar APIs de win32 podría ser una mejor alternativa.
• Alojar el CLR usando APIs de win32 en VBA es obviamente más seguro que actualizar la clave de registro AccessVBOM; lo dejaré para otro día...
• Otras APIs de .NET como System.CodeDom.Compiler se pueden usar para compilar/ejecutar código c# desde VBA; consulta la referencia a continuación;

Referencias:

• https://github.com/jet2jet/vb2clr
• https://github.com/med0x2e/NET-Assembly-Inject-Remote