For the purpose of securing Microsoft Office installs we see many of our customers moving to a macro signing strategy. Furthermore, Microsoft is trying to battle macro malware by enforcing Mark-of-the-Web (MotW) control on macro-enabled documents. In this blog we will dive into some of the quirks of Microsoft Office macro security, various commonly used configuration options and their bypasses.

• In the first part of the blog we will discuss various Microsoft Office security controls on macros and add-ins, including their subtleties, pitfalls and offensive bypasses.
• In the second part of this blog the concept of LOLdocs is further explained, detailing how vulnerabilities in signed MS Office content might be abused to bypass even strictly configured MS Office installs.

This blog is related to our BruCON talk on LOLdocs: legitimately signed Office documents where control flows can be hijacked for malicious purposes.

Attempt 1: Enforce macro signing

As an enterprise planning to block macros you first run an inventory of macros in use, then start designing mitigation strategies for these exceptions (e.g. sign them, configure a trusted location or design a policy for a couple of ‘special users’). After quite some work, discussions on risks etc, finally the big day is there. Time to block those pesky macros! The sysadmin changes the GUI options to disable VBA macros except digitally signed macros, as displayed below.

Bypass – Self-signed macros still render a yellow bar!

However, there is a big caveat for this configuration: any self-signed macro will just end up in the same GUI as before. So all the work done before did not really affect attackers or block those pesky macros.

Even when configuring a set of ‘trusted publishers’ any self-signed document will still render this yellow bar. Time for something more powerful.

Attempt 2: Block the message bar

The issue with self-signed macros is that the message bar is shown. Luckily, we can control the message bar feature via policies and settings. So combining the macro signing enforcement and removing the message bar is our next step in blocking macro attacks.

End-users are no longer prompted for a warning when opening a signed Office file from a non-trusted publisher and we can safely sleep right?

Bypass – macro-based add-ins still render a prompt!

Well… there is an exception. Let’s test macro-based add-ins (XLA/XLAM file-format).

Oops, this file format still renders a prompt. The previous setting that related to the ‘message bar’ does not apply to this ‘dialogue’ (yes, for real…). Thus further configuration is needed.

Attempt 3: MS Office configuration options to block add-ins

When digging deeper into the settings, an option can be found to disable add-ins (COM, VSTO and others).

But despite this setting, still the XLA/XLAM add-in warning dialogue is still shown to end-users. My guess is that this setting applies to various add-in types, but certainly not to XLAM/XLA add-ins… Leaving add-ins disabled may have its value, but appears not to relate to macros.

Attempt 4: There is a way to block XLA/XLAM

To block XLAM and XLA add-ins you can use the ‘file block settings’, combine that with the steps from attempt 1 and 2 and you are blocking quite some macro attack surface. However, this does have a drawback, even legit (signed) XLA/XLAMs no longer work.

Now all macro-related settings have been securely configured, we must be safe, right? Not completely, as we were securing settings mostly at the end of Microsoft Office’s security decision tree.

Block macro documents from the Internet decision tree

Microsoft provided a nice writeup with details on how the security flow works in modern Office versions.

The red block is drawn by Microsoft as the blog relates to the the new feature ‘Macros from the internet will be blocked by default in Office’. The diagram tells us that trusted locations or files signed by a trusted publisher could pose a risk. Based on our experience, misconfigurations in trusted locations still occur quite often in enterprises (e.g. home drive or downloads folder of a user configured as a trusted location).

After configuring the Trusted Locations, Trusted Publishers and all above mentioned macro and filetype settings correctly, we must be safe, right?

Digitally Signed macro from Trusted Publisher

In the remainder of this blog we will dive into the purple block of the decision tree and dive into abusing signed files.

Based on the flow, any ‘signed file from a trusted publisher’ will automatically be executed, no need to worry on Mark-of-the-Web and as it is trusted and it bypasses AMSI by default. In our previous blogs we demonstrated that there are some legitimately Microsoft signed macros that can be abused to run arbitrary code. If Microsoft was marked as a trusted publisher in Office, then this could be the perfect phishing vector.

Generalizing our previous attacks

After reporting vulnerabilities towards Microsoft (write-ups here and here), we reflected on what we are actually doing. We summarized it as:

“Taking signed files ‘out of context’, manipulate the environment of the file to influence the execution flow”.

If we can find other files that are signed by a trusted publisher of our target we immediately bypass 3 layers of security controls:

1. Controls blocking macros in downloaded files and MOTW, as these are ignored for trusted publishers.
2. Macro security control settings (even when setting VBA macros to “blocked without notification”!), as these are ignored for trusted publishers.
3. AMSI, as trusted files are exempt from inspection.

When generalizing this attack type, we are looking for: Execution flows that relate to ‘external file loads’.

Via various means we composed a dataset of signed files and code snippets and structured our research.

We identified 4 classes of coding patterns that can be abused.

Abuse pattern 1: Execution flow depending on cell contents

As explained in a previous blog post, CVE-2021-28449 is rooted in the fact that the VBA execution flow depended on cell contents. The cell content is not part of the signed data. By editing the cell content, malicious code could be loaded by legitimately signed files.

Abuse pattern 2: Declares & DLL references

Another bad coding pattern was identified by Microsoft themselves after they investigated our bug report. When studying the patch for CVE-2021-28449, we noticed changes to Solver.xlam. The original Microsoft signed Solver could be abused because of an insecure DLL reference.

When looking at this specific code sample, the issue becomes apparent. When using a declare in VBA, a reference is made to an external module. In regular VBA, upon the first call of the referenced function, the referenced DLL is loaded with a standard LoadLibrary call.

In the Solver.xlam, the function Solv is referenced from Solver32.dll, and prior to calling the Solv function, the VBA code performs a ChDir and Chdrive to the path of the current workbook. This allows for a very simple attack: In case an attacker would send Solver.xlam and a rogue Solver32.dll together (e.g. in a zip, in an ISO container or on a WebDAV share), then the Microsoft signed XLAM would load the rogue code.

Identifying the abuse patterns in this code sample was relatively simple, so we tried to abuse other signed code that relied on external declares, and that did not have any chdir function calls in the code. We noticed that LoadLibrary would always attempt to load the external content from the Documents folder instead of the folder where the Office document was located.

Upon further analyzing this, this loading behaviour is related to Office configurations. The ‘Default File location’ is used as current directory of the Office path when loading VBA references.

Default file location configuration in MS Office

A simple attack plan from an offensive/red team viewpoint:

1. Locate a signed file that is most likely a trusted publisher for your victim that relies on any external declare.
2. Inform the user that the document only works from his ‘My Documents’ folder.
3. Watch your malware beacons coming in!

Abuse pattern 3: Loading other documents

In case VBA code is used to open another Office document, we can abuse the fact that the macros in the document being opened are auto-executed. Some Excel macros import other Excel add-ins or even Word macros. So locating a signed Excel macro that opens a Word file (e.g. a mail-merge macro) could be your way in!

Abuse pattern 4: Beyond VBA – XLL ghosting hijack

Lastly, there is an attack class that goed beyond VBA. XLL files (which adhere to macro security settings!) can contain references to other DLL files, including DLL files that are custom and not available on a default Windows installation. As an attacker you can distribute the signed XLL file together with the ‘missing DLL’ and the signed XLL subsequently loads the DLL. We found various signed XLL files in the wild that suffer from this vulnerability.

Mitigations

The most important mitigation: be really restrictive on configuring trusted publishers. One should understand that a vulnerability in content within a signed MS Office file from a trusted publisher can be abused to circumvent most MS Office security settings, including macro security and MOTW controls.

For those involved in signing files or developing VBA and XLLs, consider the idea that your code may be abused to run other MS Office content or DLLs. It would be good to include a source-code security review in the development lifecycle prior to signing a new release.

Conclusion

This blog showed how to harden your Office environment against macro based threats and some common pitfalls for popular settings.

However, even a strongly hardened Office environment could be vulnerable for various attacks:

• Blocking a user prompt for XLA/XLAMs is hard, and can only be achieved by completely disabling the filetype. Additional monitoring on these filetypes is recommended.
• There are some fundamental weaknesses and risks when working with signed office files. Mitigation is complex, but organisations can consider:
  • Code review prior to signing MS Office files.
  • Evaluate previously signed files for security weaknesses.
  • Compensating controls for revocation, such as processes for replacing the signing certificate in case a vulnerable file has been signed in the past.
  • Only allow a minimal required set of trusted publishers.
  • Be particularly careful when you develop software for Microsoft Office, especially when end-users should trust your code signing certificate.

Just “blindly signing” all internal legacy macros without proper analysis is a bad strategy. There is still a VBA/macro risk looming over your shoulder and in fact this may have made an attacker’s life easier, since signed content bypasses many MS Office security controls…

Signing can be a powerful tool to secure Office documents and to prevent maldoc phishing. However, creating secure signed macros is way more complex than we anticipated: legacy features, Operating System dependencies, and limited documentation are making it hard to identify weaknesses.

For further questions and discussions on this, reach out to us via twitter @DaWouw and @ptrpieter

The post So you think you can block Macros? appeared first on Outflank.

This is a joint blog written by the Cobalt Strike and Outflank teams. It is also available on the Cobalt Strike site.

Over the past few months there has been increasing collaboration and knowledge sharing internally between the Cobalt Strike and Outflank R&D teams. We are excited about the innovation opportunities made possible by this teamwork and have decided to align Cobalt Strike and Outflank Security Tooling (OST) closely going forward. Although we are actively collaborating, Cobalt Strike will continue to be the industry standard Command & Control (C2) framework, while OST will continue to offer a red team toolbox for all environments containing custom tradecraft that is OPSEC safe, evasive by design, and simple to use. Our vision is that Cobalt Strike and OST together will provide the best red team offering on the planet. 
 
This blog will provide an update of the technical strategy of each product individually before giving a glimpse into the future of the two combined. 

Cobalt Strike 

Cobalt Strike is the industry standard Command & Control framework. Following the acquisition of Cobalt Strike by Fortra in 2020, a conscious decision was taken to follow the technical strategy employed by founder Raphael Mudge in taking Cobalt Strike to the next level. The core tenets of this strategy are: 

• Stability: Cobalt Strike must remain reliable and stable; nobody wants to lose their Beacons. 
• Evasion through flexibility: Since its inception, Cobalt Strike has always been an adversary emulation tool. It is designed to enable operators to mimic other malware and the TTPs they desire. Hence, in its default state, Beacon is pretty trivial to detect. This however has never been the point; Cobalt Strike has flexibility built into key aspects of its offensive chain. You can tinker with how Beacon is loaded into memory, how process injection is done, what your C2 traffic looks like etc. We don’t want to bake TTPs into Beacon which become signatured over time (Cobalt Strike’s implementation of module stomping is a good example of this). We want to enable operators to customise Beacon to use their own original TTPs.  Our R&D effort will continue to focus on building in flexibility into all aspects of the offensive chain and to give operators as much control as possible over the TTPs they employ. 

Outflank & OST 

In September last year we were acquired by Fortra. Outflank is a security consultancy based in Amsterdam with deep expertise in red teaming and a proven track record of world class research. Our team is best known for our work on Direct Sys Calls in Beacon Object Files,  various public tools, Microsoft Office tradecraft (derbycon, troopers, Blackhat Asia, brucon, x33fcon), or on the red team SIEM Redelk. 

In recent years, we have taken our internal research & development and created Outflank Security Tooling (OST).  

OST is not a C2 product but a collection of offensive tools and tradecraft, offering: 

• A broad arsenal of offensive tools for different stages of red teaming. 

• Tools that are designed to be OPSEC safe and evade existing security controls (AV/EDR). 
• Advanced tradecraft via understandable interfaces, instead of an operator needing to write or compile custom low-level code. 
• A knowledge sharing hub where trusted & vetted red teamers discuss tradecraft, evasion, and R&D. 
• An innovative cloud delivery platform which enables fast release cycles, and complex products such as ‘compilation as a service’, while still allowing any customer to run and manage their own offensive infrastructure. Although OST is offered as a cloud model, it is possible to use the offensive tools and features offline and in air gapped environments.  

Hence, it is a toolbox for red teamers made by red teamers, enabling operators to work more efficiently and focus on their job at hand. It contains features such as: a payload generator to build sophisticated artifacts and evade anti-virus / EDR products, a custom .NET obfuscator, credential dumpers, kernel level capabilities, and custom BOF implementations of offensive tools (such as KerberosAsk as an alternative to Rubeus). 

Going forward, OST will continue to provide a full suite of bleeding-edge tools to solve the main challenges facing security consultants today (i.e., on prem/workstation attacks, recon, cloud etc.). Our R&D team remain active in red teaming engagements and so all these tools are being continually battle tested on live red team operations. Furthermore, OST will continue to grow as a vetted knowledge hub and an offensive R&D powerhouse that brings novel evasion, tradecraft, and tooling for its customers. 

Combining forces: Cobalt Strike and Outflank Security Tooling 

Having outlined the technical strategies of Cobalt Strike and OST above, it is clear that both products naturally complement each other. Therefore, we have decided to align the two products closely going forward. 

In our joint roadmap, both products will stay true to their visions as outlined above. Cobalt Strike will continue to push the boundaries of building flexibility into every stage of the offensive chain, e.g. via technologies such as BOFs, and OST will continue to leverage this flexibility to deploy novel tradecraft, as well as continuously releasing stand-alone tools. 

Furthermore, both teams are already cooperating extensively, which is further advancing innovation and product development. Outflank’s experience in red teaming is providing valuable insight and feedback into new Cobalt Strike features, while joint research projects between the Cobalt Strike and Outflank R&D teams is already generating new TTPs. Together, we are regularly evaluating offensive innovation and adjusting the roadmap of both products accordingly. This ensures that both Cobalt Strike and OST remain cutting edge and that any new features are designed to integrate seamlessly between the two. 

This approach is already bearing fruit; we recently released a feature focusing on Cobalt Strike Integrations, specifically custom User Defined Reflective Loaders, which we will explore in more detail below. 

Case Study : User Defined Reflective Loaders 

Cobalt Strike has relied on reflective loading for a number of years now and the team has endeavoured to give users as much control over the reflective loading process as possible via Malleable C2 options. However, they always want to push the boundaries in terms of building flexibility into Cobalt Strike so that users can customize Beacon to their liking. This was why they introduced User Defined Reflective Loaders (UDRLs). This enables operators to write their own reflective loader and bake their own tradecraft into this stage of the offensive chain. Furthermore, the team recognises that UDRLs can be challenging to develop, which is why they started their own blog series on UDRL development (with a second post on implementing custom obfuscation dropping soon). 
 
As long-term Cobalt Strike users, we also recognised the complexities and time constraints that red teams face when developing custom UDRLs. Hence, we decided to put our own experience and R&D into developing novel UDRLs as part of their Cobalt Strike Integrations feature on OST, as shown below: 

With this feature, it is now possible in OST to stomp a custom UDRL developed by Outflank onto a given Beacon payload. There are currently two custom loaders available and more are in the pipeline. Most pertinently, operators do not need to get into the weeds with Visual Studio/compilers, while still being able to use advanced UDRLs that are OPSEC safe and packed with Outflank R&D. 

Bypassing YARA signatures 

Furthermore, OST will also check the stomped Beacon payload against a number of public YARA signatures and automatically modify Beacon to bypass any triggering rules, as demonstrated below: 

Cobalt Strike has previously blogged about YARA signatures targeting Beacon and so this is an important ‘evasion in depth’ step built into payload generation within OST. 

Once Beacon has been equipped with a custom UDRL, and YARA bypasses have been applied, the payload can be seamlessly integrated with other OST features. For example, we can import the new payload into OST’s payload generator to create advanced artifacts which can be used for phishing, lateral movement, or persistence. This whole workflow is demonstrated below: 

Video 1: Recording of the User Defined Reflective Loader feature as available in OST 

This feature is a great example of the joint roadmap in action; both the UDRL stomper and the YARA module originated from collaboration and shared knowledge between the Cobalt Strike and Outflank teams. 

The Road Ahead 

• Novel tradecraft: The UDRL and YARA integration is just the first step. OST’s Cobalt Strike integrations will be further extended with new features, such as custom sleep masks and additional YARA and OPSEC checks. This allows customers of both OST and Cobalt Strike to utilise advanced tradecraft and the flexibility of Cobalt Strike without needing to write low level code. 
• Better user workflows: Instead of manually downloading custom BOFs/tools from OST, we are working on implementing a ‘bridge’ between OST and Cobalt Strike. This bridge would also allow users to upload Beacons to OST and generate advanced payloads quickly; allowing for smoother and more efficient workflows. 

• New approaches of software delivery: OST has taken a unique approach in offensive software compilation & distribution, utilising just-in-time compilation and anti-piracy via its cloud delivery model. In due course Cobalt Strike will start leveraging a similar approach as OST; enabling new possibilities and evasion techniques within Beacon. The first step of this will be to migrate Cobalt Strike to a new download portal.  
• Team collaboration: Lastly, the OST and Cobalt Strike teams are increasingly collaborating on a number of low-level areas. These deep technical discussions on evasion and novel TTPs between hands-on red teamers, offensive R&D members, and the Cobalt Strike developers provides valuable feedback and accelerates product development.  

Closing Thoughts 

We hope that this blog provides an informative update to the technical strategy of both products going forward. In summary: 

The Outflank and Cobalt Strike teams are cooperating to get the most value for our customers. Both Cobalt Strike and OST will stay close to their roots: Cobalt Strike will remain focused on stability and flexibility while OST offers a broad arsenal of offensive tradecraft. Furthermore, the collaboration between the two teams will enable enhanced product innovation and ensure that new features for both products are designed to work seamlessly together. 
 
If you are interested in either Cobalt Strike or OST, please refer to Cobalt strike’s product info and demo video, or OST’s product info and demo videos for more info. Cobalt Strike and OST bundles are available now and you can request a quote here.

The post Cobalt Strike and Outflank Security Tooling: Friends in Evasive Places appeared first on Outflank.