# Exploit Title: Microsoft Office365 Remote Code Execution Vulnerability # Date: 2/11/19 # Exploit Author: Social Engineering Neo - @EngineeringNeo # Vendor Homepage: https://microsoft.com # Software Link: https://office.com # Version: Office365/ProPlus (build 16.0.11727.20222, 16.0.11901.20170, 16.0.11901.20204 & 16.0.11929.202.88) # Tested on: Windows 10 (build 17763.253, 18362.295 & 18362.356) Microsoft Office .docx to .docm Protection Bypass Allowing Remote Code Execution by Social Engineering Neo. Affected Platforms: - Microsoft Windows ≤10 Office365 & ProPlus Products ≤2019 Tested On: - Windows 10 (build 17763.253, 18362.295 & 18362.356) Office365/ProPlus (build 16.0.11727.20222, 16.0.11901.20170, 16.0.11901.20204 & 16.0.11929.202.88) Most up to-date version of Microsoft Windows & Office365/ProPlus Products are affected. Base: - CWE-325 - Missing Required Cryptographic Step. The software does not implement a required step in a cryptographic algorithm used to validate the original integrity of documents. Summary: - Overwriting Registry Keys on a Machine Allows Full Protection Bypass, allowing .docx document to execute macro-enabled code. Although Similar to https://github.com/SocialEngineeringNeo/Exploits/blob/master/Our%20Exploits/ Microsoft/Office/PrdctRCE_Report.txt, not the same. This is Due to Improper Integrity Validation of Office Documents Resulting in Multiple Microsoft Office Products Suffering from a Protection Bypass Vulnerability. Allowing Auto-Execution of Macro Code Inside Macro-Enabled Office Documents. Short Description: - Overwriting an original .docx document with a malicious .docx document will bypass the built-in protections. Long Description: - A user creates a .docx MS Word document and saves the document with macro code inside. When a single registry key is modified/added, this could allow execution of code within documents which do not support macro code execution. Proof of Concept: - ===== Tested on Latest Versions of Access, Excel, InfoPath, OneNote, Outlook, PowerPoint, Project, Publisher, Visio, Word. Affects Access, Excel, InfoPath, PowerPoint, Visio, Word. Does not affect OneNote, Outlook, Project, Publisher. ATTACKER: - Step 1.) - Craft .reg or .psh file to modify registry keys. Step 2.) - Open original document on ATTACKER machine, note the binary values of 'HKCU\Software\Microsoft\Office\16.0\Word\Security\Trusted Documents\Trust Records\[FILENAME]' Step 2.1.) - Inject malicious VBA macro code & payload into .docx Office document. *preferably AV evasive, don’t save as .docm* Step 3.) - Send malicious .reg and .docx document to VICTIM through internet. Step 4.) - Setup bind/reverse connection. VICTIM: - Step 1.) - Download document sent by ATTACKER. Step 2.) - Run .reg or .psh *without admin privileges* Step 2.1) - Open .docx Document. [CODE EXECUTION SUCCESSFUL] Reg key '%USERPROFILE%/Documents/PoC.docx' value modified from '933A80188373 D5010028A153C5FFFFFF92348F01 01000000' => '4E82A24F8876 D5010028A153C5FFFFFF92348F01 FFFFFF7F' The beginning 7 bytes (933A80188373) of the binary registry value seems to be computer/file/network specific, meaning as long as you are within the same system or network this bypass would work out-of-the-box from copying the middle 15 bytes of the original document and overwriting the final 4 bytes (FFFFFF7F) with the mentioned values. Ending with: 01000000 = Open without Protected view. FFFFFF7F = Allow document execution. PowerShell: reg add "HKCU\Software\Microsoft\Office\16.0\Word\Security\Trusted Documents\TrustRecords" /v %USERPROFILE%/Documents/PoC.docx /t REG_BINARY /d 4E82A24F8876D5010028A153C5FFFFFF92348F01FFFFFF7F *Manual adjustment of /d will be required* VIDEO: - https://youtu.be/-yfjdHOgNT8 Video demo uses .docx and .docm for simplicity. Essentially, we are giving macro-enabled auto execute permissions to the .docx file, allowing remote code execution. ===== Expected Result: - It shouldn't be possible to automatically execute macro code within a .docx document. (Clean Install) Observed Result: - Office .docx document auto-executes macro code upon loading document without any user consent, in our case leading to remote code execution. (User Level Access) Our Recommendation: - Generating a hash value of the document once changes have been made will greatly reduce the exploitability. Once file is reopened by user, check whether the hash of the filename is the same as last changes. If the current hash value and filename do not match the previous modification of document, open in protected view and prevent scripts from running. Additional registry key hardening would be possible.