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 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:
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.
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.
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:
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.
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.
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:
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.
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
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。