Microsoft Office wscript usage [D0812]

[Mohsen Ghaffari 0]

I would really appreciate it if you could help me further investigating the attached alert. The Excel file does contain any macros. 

Cheers.

[itman 1,755]

1 hour ago, Mohsen Ghaffari said:

The Excel file does contain any macros. 

Did you mean does not contain any macros?

If the Excel file contains macros, Eset is warning that a macro is launching wscript.exe which could allow for malicious activities to occur.

[Mohsen Ghaffari 0]

oh sorry for the typo. I meant does not contain any macros.  

[itman 1,755]

A MS Office file does not need a macro to contain malicious code. Refer to this article for the latest malware techniques: https://www.bleepingcomputer.com/news/security/as-microsoft-blocks-office-macros-hackers-find-new-attack-vectors/ .

[Mohsen Ghaffari 0]

Thank you for your reply.

problem is I cannot find out any child process spawned by the excel in this case as it can be seen on the attached image. I was wondering, if I could find out more information as to what actually was executed consequently. There are no other alerts which I could associate with the alert as an extra indicator. 

[itman 1,755]

1 hour ago, Mohsen Ghaffari said:

problem is I cannot find out any child process spawned by the excel in this case as it can be seen on the attached image.

It appears Eset blocked the execution of wscript.exe. As such, no child process; if applicable, was created.

You can check Eset Detection log for related entries to see if those yield any further details on what was blocked.

 

Edited September 28, 2022 by itman

[Marcos 5,288]

Could you please provide me the document in question? If it contains sensitive information, you could provide another test file that triggers the rule.

[JamesR 58]

The rule "Microsoft Office Wscript Usage [D0812]" is purely looking for any office application to load the wshom.ocx library.  This library allows for the usage of the Windows Script Host directly without the need to use wscript.exe or cscript.exe.  Sometimes users will use an office plugin that will lead to this detection and this will cause every use of an an MS Office application to trigger this detection.

My recommended actions would be:

1. If possible, supply a copy of the office document as a sample to Marcos or I (zipped up and password protected).  We can help verify there are no normal macros, XLM macros, or Stomped (hidden) macros.
2. Check the computer for any other dangerous detections by the EDR or by the Endpoint product itself
   1. Inside EI, open the details of the computer that triggered detection
   2. Then locate the tab at the top labeled "Detections" and review this for any other dangerous detections
3. If you have not done so already, enable AMSI logging of MS Office documents (MS Office 2016 or newer only).  This can add more details in EI to verify no macros were logged by AMSI (will post some steps for doing this via GPO below)
   1. you would need to click on the triggering process in the process tree "excel.exe (13000)", and then locate the tab at the top labeled "Scripts"
4. If you do not find any other dangerous detections in EI, and the detection is not re-occurring, resolve the detection and move along.
5. If you do not find any other detections in EI, and the detection keeps re-occurring, create an exclusion for the specific computer

Lastly, you may want to touch base with the end user.  They could have opened up Excel, opened the Macro editor, typed in a test macro and pressed F5 to run the macro causing the wshom.ocx library to be loaded.

If I had to purely decide off what I see here for "is it malicious" it looks benign to me.  No child processes.  No WMI Execution EI Detections.  Only oddity is the "winlogon.exe > userinit.exe > pfwsmgr.exe > Explorer.exe" for the ancestor processes.  That pfwsmgr.exe is a bit odd to me, but I assume it may be some user management software you are using.  Normal user logon process trees would simply look like  "winlogon.exe > userinit.exe > Explorer.exe".

 

 

Steps to enable AMSI logging via GPO

(if needed) Download ADMX GPO Templates

1. Download and extract ADMX file to DC
   1. Administrative Template files (ADMX/ADML) for Microsoft 365 Apps for enterprise/Office LTSC 2021/Office 2019/Office 2016 and the Office Customization Tool for Office 2016
      1. https://www.microsoft.com/en-us/download/details.aspx?id=49030
         1. There are both x86 and x64 versions.  You will need the version to match the computer you will be managing GPOs from.  Thus if you are on a x86 computer and managing GPOs, you would use the x86 version (does not need to match the arch of the MS Office on network)
   2. Run the EXE and follow its steps to extract them.  Extract them to a temp location like "C:\CCSupport\ADMX_TEMP\"
      1. Next, from the "C:\CCSupport\ADMX_TEMP\admx\" directory, copy all .admx files from your temp folder, and place them in "C:\Windows\PolicyDefinitions\"
      2. Lastly, from the "C:\CCSupport\ADMX_TEMP\admx\" copy the "en-US" contents (.adml files) to the "C:\Windows\PolicyDefinitions\en-US\" directory.
         1. If other languages are needed, you can copy those to their corresponding locations
2. Now, close any open Group Policy Management editors, and reopen one (you simply need to start editing or creating a new GPO), and check the following 2 locations for Microsoft Office branches.
   1. Computer Configuration > Policies > Administrative Templates
      1. Microsoft Office 2016 (Machine)
      2. Microsoft Office PowerPoint 2016 (Machine)
   2. User Configuration > Policies > Administrative Templates
      1. Microsoft Access 2016
      2. Microsoft Excel 2016
      3. Microsoft Office 2016
      4. Microsoft OneNote 2016
      5. Microsoft Outlook 2016
      6. Microsoft PowerPoint 2016
      7. Microsoft Project 2016
      8. Microsoft Publisher 2016
      9. Microsoft Teams
      10. Microsoft Visio 2016
      11. Microsoft Word 2016

 

Set Group Policy to enable AMSI logging/scanning of MS Office VBA Macros:

1. Edit or create a new policy that will be linked/applied to computers.
2. In the Group Policy Editor, navigate to: User Configuration > Policies > Administrative Templates > Microsoft Office 2016 > Security Settings
3. Locate "Macro Runtime Scan Scope" and Edit it.
4. Set the policy to "Enabled" and then set the options to one of the following 2 items:
   1. "Enable for low trust documents" - AMSI scanning/logging of documents which are NOT any of the following:
      1. Opened while macro security settings are set to "Enable All Macros"
      2. Opened from a "Trusted Location"
      3. Trusted Documents
      4. Files that contain VBA that is digitally signed by a Trusted Publisher
   2. "Enable for all documents" - AMSI scanning is done for all documents regardless of where they came from.  This is perfect for test environments, or for environments where a SOC is present to analyze all macros in an environment.
5. Click OK/Apply, close any open windows.  Go to a workstation and run "gpupdate /force"
   1. The following registry key should be set after the policy is applied:
      1. Key: HKCU\software\policies\microsoft\office\16.0\common\security
      2. Value: macroruntimescanscope
      3. Type: REG_DWORD
      4. Data: 0 = Off, 1 = Enable for Low Trust Docs, 2 = Enable for all docs

 

[Mohsen Ghaffari 0]

wow, thank you for the awesome explanation. It was due to an office plugin. Appreciate the eset community support.