Augmenting Security Testing and Analysis Activities with Microsoft 365 Products
Use of Microsoft 365 products in security testing is not a new concept. For a long time, I’ve incorporated various activities using Office products into my testing regimen. In the early days, we used to frequently use malicious Office documents for initial access, embedding malware in a macro-laden document to be executed when the user opened the file.
Sadly, direct payload execution using VBA macro logic has become increasingly more difficult and organizations may block inbound macros altogether. All is not lost though, there’s plenty of opportunity to use macros during testing (and for analysis as a defender). Over time, my macro use has evolved from direct execution to focusing on other capabilities that might be useful in the context of security testing. I will cover some of those concepts in this blog post. For expanded treatment on the subject, watch my webcast on the same subject at https://www.youtube.com/watch?v=cfKDnxeoTuQ.
Resources discussed in this blog post can be found at https://github.com/aut0m8r/FunWithMacros.
Microsoft Office Product Choices
Microsoft Office products are just another LOLbin at our disposal. In incorporating Microsoft Office products into your testing methodology, it might be useful to consider which product to start with. In my case, I most frequently tend to use Microsoft Excel for the following reasons:
- Data is presented in a simple tabular format – this makes it easy to analyze, visualize, and present information in bulk. Rather than having to investigate each object in Bloodhound to see the value of a given attribute, I can just look at the table itself and use integrated features.
- Hiding (and unhiding) elements – Columns and tables can be hidden in Microsoft Excel workbooks. This provides the opportunity to collect information into elements that are not immediately accessible to the user. This is extremely valuable when poisoning existing macro-enabled documents.
- Integrated features – Sorting, filtering, conditional formatting and formula support make Excel an attractive product for collection of raw data that may require manipulation and analysis after the fact.
- External data collection – Excel supports a ton of features for collecting information from the local environment, LDAP (Active Directory), databases, and other sources that might be useful in the context of testing and security analysis. Often, collection of data using these features goes undetected within an environment.
At the end of the day, I recommend using the product that makes the most sense in the context of your given conditions. You may need to adapt the strategies identified here, but in doing so, you’re likely to be expanding the tooling options available to the greater community.
With the advent of Microsoft 365, the Office suite has added some additional features that might help us in our testing efforts along the way. Consider the scenario where you gain access to an organization’s Microsoft 365 environment, but don’t establish remote C2. Commonly, this typically occurs when using a reverse proxy, pilfering the browser credential store, or just analyzing stealer malware dumps.
Office products now include the notion of presence: when a user opens a document, a presence indicator appears in the ribbon for any other user that has the same document open. As a consequence, one of my favorite activities is to search for existing macro-enabled documents that appear to be frequently used in SharePoint, OneDrive, or SMB shares and wait for the presence information to appear.
After I’m convinced that the documents are going to be useful for my nefarious purposes, I add my own macro logic to the existing document. The wonderful thing about this technique is that we don’t have to really worry about the “enable macros” prompt because we know that users are ALREADY using our target document.
Obviously, before you go poisoning documents all willy-nilly, you should take some time to understand how your surrogate code will affect the operation of the legitimate document. Also… ALWAYS make a backup of the original document.
Common Activities
So, what can we do this these documents that won’t cause endpoint protection to trigger on a given device? I often approach document poisoning in several stages.
Reconnaissance
In the initial stage, my approach is usually guided by the following question. “What would I want to know prior to sending a phishing email to this user?” The answer usually includes:
- What kind of endpoint protection is on my target host? – We can interrogate processes and investigate the contents of the local filesystem to at least get a rough approximation.
- What permissions does my target user have in the environment? – We can definitely ask Active Directory and then target our payload to execute in context of a specific user if we desire.
- Are there any useful applications I might want to try to impersonate to avoid detection? – Usually, this involves investigating the file system for entries that might indicate custom developed applications.
I usually look for the name of my organization in the Program Files folders, then, when I do try to deliver a payload, I mimic characteristics of those applications. Why would I do this? Because these applications are commonly allowlisted in application control and endpoint protection solutions and may be ignored by the security team.
After gathering details from the remote system, I might want to perform analysis on Active Directory. Gathering details about the password policy, a list of users, groups, and computers often helps me better understand the target environment and will increase the effectiveness of any external attacks I’m executing. Password spraying effectiveness will certainly be increased by having a full list of internal users and knowledge of the internal password policy. In addition, Active Directory attribute analysis may expose additional credentials. An excerpt of commonly useful output is shown below.
Initial Access
With sufficient knowledge about the internal environment, I might attempt to establish remote command and control (C2) on the target system. An interesting method of doing this involves abuse of the SSH client that is installed on modern Microsoft Windows clients by default. Typically, I’ll set up a restricted SSH users on a Virtual Private Server (VPS) instance, and then use SSH to either deliver a payload to the endpoint or establish a reverse SSH tunnel connection. Often, I find that I can establish outbound SSH connectivity using TCP port 443.
My approach to establishing this access often involves using the macro to do two things. First, I drop the SSH private key for my restricted user (on the VPS) to the compromised user’s profile directory. Next, I drop an LNK file to somewhere that will cause user-induced execution. Examples include the startup folder or the users’ desktop for hotkey persistence.
The LNK file contains the SSH command used to do my bidding. This could include downloading and executing a payload, downloading the payload directly to a dll hijack or dll sideload location, or establishing a reverse SSH tunnel. SSH file transfer has the benefit of not receiving Mark of the Web.
Post Compromise
After establishing a foothold in the environment, I often use Microsoft Excel for post compromise activities as well. The product has native support for connecting to various resources. Features that I’ve already implemented include:
- Analysis of the SYSVOL/Policies share – This feature will gather details about interesting artifacts, like drive mappings, scripts, URLs, and nonstandard policy files. The results can provide a stealthier alternative to full SMB share analysis and scanning for internal web applications.
- SQL database access – This feature identifies computers with Service Principal Names (SPNs) containing MSSQLSvc then attempts to connect to each one, providing a database listing for any accessible database servers.
- LAPS password access – LAPS analysis is tricky because, if the product is not deployed, then the associated attribute (ms-mcs-AdmPwd) may not exist in the directory. This module will check for readable LAPS passwords under the context of the executing user.
These features are just the tip of the iceberg. The Data tab in the Microsoft Excel ribbon has a ton of functionality that attackers may be able to use to perform interesting operations. Did you know that you can use Microsoft Excel as a SQL client for various data sources. You should definitely check it out.
Another technique I have used in post-compromise situations is to hunt for commonly used macro enabled documents INTERNALLY. Then I reengage with document poisoning, only this time I drop a payload on an internal writeable file share and use an LNK file to execute that payload using the same techniques described above.
Conclusion
Hopefully this blog post has gotten your creative juices flowing. Microsoft Office is a tool that is just as ripe for abuse as any other. As you’re exploring environments, consider how you might use native features to enhance your testing methodology. At the very least, you will provide your customers with food for thought to consider hardening deployments of common tools like the Microsoft Office suite.
One last note for defenders, consider how gathering information from Active Directory might help you bolster your internal security. If you can’t get permission to run tools like BloodHound or PingCastle in your environments, use of the Office suite may be a good starting point for understanding where weaknesses might exist in your environments.
If you feel like you might want to collect this type of information from Active Directory, please check out the resources available at https://github.com/aut0m8r/FunWithMacros.
Ready to learn more?
Level up your skills with affordable classes from Antisyphon!
Available live/virtual and on-demand
