Offphish - Phishing revisited in 2023

Update 14.02.20223 Another one down: Microsoft has patched Publisher (.pub) documents to use the mark of the web (MOTW) to block VBA macros from untrusted sources with CVE-2023-21715.

Intro

What is the state of the art with phishing in 2023? What techniques do exist, which do still work and what is know-how worth revisiting? From time to time, I like to revisit certain topics to reiterate what tools we have in our toolbox, if there is anything new and to renew references. Our latest Red Team exercise triggered this revisiting process for my phishing toolbox, which also offered the opportunity to share my thought process and results through this post.

I usually start drawing the lines of a blog post right away when and while diving into a topic to keep my thought and development process close to my output channel. In this case I noticed right away that phishing is a huge topic with tons and tons of different vectors, tricks and shapes, but for our Red Team exercise I have a specific boundary, which was e-mail based phishing via common Microsoft Office documents, and by "common" I'm referring to the default Microsoft Office set of applications that our target likely had installed (Word, Excel, PowerPoint, OneNote, Publisher, etc.). Therefore, I will focus this post on Phishing through e-mail with Microsoft Office documents (hence the title "Offphish"), but the roadmap and structure of my approach should be applicable to other phishing scenarios as well.

Moreover, I want my background research to result in a cleaned toolbox, which provides me an overview and references to weaponize a campaign. Therefore, I will also attempt to keep this post concise and toolbox-friendly. The downside here is that I can't drill down into specifics on how to implement or weaponize certain components, but I'll add the references from my toolbox to compensate that.

At the end of this blog post I want to have answers to the following questions, that I considered worth revisiting when doing this background-research:

• What is the state of the art with regards to phishing? [With e-mail phishing based on Microsoft Office documents in this case]
• What are the take aways from the latest changes in this area?
• What take aways are there for offensive (red) teams?
• What take aways are there for defensive (blue) teams?

If you like to get the TL;DR version, skip to the end of this post to find my answers.

Setting the stage

Before we dive into the text-heavy based run-down: If you - like me - enjoy a playlist of talks to get into the topic, here's a list of ordered talks that I can recommend to dive into the topic (I do not have a YouTube channel to add these into, but maybe someone will). If you binge watch them, you're looking at roughly 4 hours of knowledge sharing. Feel free to dive into these now (and hopefully return here) or watch them after reading this post...

• 10/18: The MS Office Magic Show by @ptrpieter & @stanhacked, DerbyCon 2018
• 03/19: Office in Wonderland by @ptrpieter & @stanhacked, Black Hat Asia 2019
• 11/20: Phishing in a Macro-less World by @hotnops, SO-CON 2020
• 10/22: LOLDocs: Sideloading in Signed Office files by @ptrpieter & @DaWouw, BruCON 2022
• 07/22: Evasion in Depth - Techniques Across the Kill-Chain by @mariuszbit, x33fcon 2022

Okay, back on track now... When speaking of phishing with Microsoft Office documents often times people's minds automatically jump to how attackers abuse (VBA) macros to compromise targets. Therefore, some might expect this post to revisit (VBA) macros - especially given Microsoft's dance last year around disabling these. While this post will certainly cover macros (and we'll get to the back and forth with disabling macros later on), there is more than macros that a toolbox should contain and moreover before getting our hands on how to compromise a target, the document first has to reach the target. Therefore, this post contains the following sections to step through the process

• Delivery
• Reception & Unboxing
• Execution

To wrap up the journey, there will be an overview of various techniques and a VirusTotal benchmark of some document formats at the end of this post.

Delivery

As this post focuses on e-mail-based phishing techniques, I will only drill down on this delivery channel. However, this in no way implies that this is the only or best channel to get initial access into a targeted environment. Just to name a few others, one could also think of social media channels, "Watering hole"-attacks, mobile/desktop apps, browser plugins, USB-drops, hardware implants and countless other social-engineering maneuvers.

Back to e-mail-based phishing: The delivery stage of mail-based phishing comes with the question of how do you get your phishing document into the victim's mailbox. In summary your efforts in this stage should be driven by the following two questions:

• What (kind of) document do I want to send in?
• What defense mechanisms are there to stop me?

Your choice of document depends on your needs, pretext and strategy to bypass later barriers (which we'll discuss in the following sections). Just to name a few one could choose to utilize:

• Microsoft Office documents (like Word, Excel, PowerPoint, OneNote, Publisher, ...)
• PDFs
• HTML files
• Self-executing files (PE-Files, batch-files)
• Special-purpose files with a specific execution strategy, such as .lnk-, .html-, .js-, .wsh-, .hh-files and others

I will focus solely on malicious Microsoft Office documents here. Looking over to the defense mechanisms of the delivery stage, one should be prepared to overcome multiple layers of defenses, which we'll put in two boxes: Outbound mail filters and Inbound mail filters.

The outbound mail filter box contains all protection mechanisms, that are applied by the mail provider you use to send your message. One could skip this entire box of protections by self-hosting a mail provider (e.g. running a mail server on an internet connected Linux-box), however it must be considered that this could affect successful acceptance on the inbound mail gateway (as we'll discuss in the following). This will also affect your infrastructure decisions, for example (nowadays) you can't just spin up an EC2 instance on AWS, as AWS will block outgoing mail transfer via port 25 on default instances (you could request AWS for an exception though, but this will require justification and an approval process). Choosing well-established mail providers like GMail, ProtonMail, Microsoft Outlook, etc. on the other hand will allow you to piggyback on the reputation of these mail providers, but will also add their defense and size constraints. For example, you might not be allowed to send a 50mb file on a free GMail account, your files might be scanned for malicious content before being allowed to be sent and you will likely be rate-limited when sending mails.

The takeaway here is the following:

One should know the constraints of either choosing a well-known mail provider or hosting your own infrastructure. Both of these approaches have benefits and both approaches are used in the wild. When we do e-mail based campaigns we usually opt for the well-known mail provider, because most of the time the good reputation of a provider outweighs their constraints for our campaigns.

Similarly, the inbound mail filters, meaning the protection mechanisms applied by the mail gateway of your target (e.g. Outlook) must be considered before sending your mail. Especially the following controls should be recognized:

• Spam filters: All major mail gateways try to identify spam-mails based on different criteria, such as reputation of the sending domain or presence of certain words or phrases. @mariuszbit brought up a tool to identify such policies, which can be found here.
• SPF & DMARC checks: If you don't pretend to be someone else, e.g. you're not trying to spoof the SMTP "FROM"-Header, saying that you're the CEO sending a mail, then SPF and DMARC checks should not be a blocker for you. Nevertheless one should know these exists (once again I will not drill down on this to focus on the bigger picture).
• Region exclusions: Some mail providers (like Outlook), also support to block mails originating from manually chosen countries.
• Anti-virus scans: Your mail might be scanned for malicious content before being delivered to a user's inbox, especially if the mail contains an executable attachment. These scans could be simple static analysis scans, as well as sandboxed behavior scans.
• Provider specific protections: For example if you target a Microsoft 365 environment, then it should be noted that these per default include Microsoft's Exchange Online Protection-Feature set, which per default brings customizable Anti-Phishing, Anti-Spam and Anti-Malware policies. Moreover Microsoft customers that paid extra could also benefit from Safe Attachments and Safe Links-Policies. For our topic most notably in this category is that the default Anti-Malware-Policy that comes with EOP (Exchange Online Protection) contains a setting called "Common attachment filter", which - when enabled - filters attachments based on their extensions. This "Common attachment filter" is switched off by default (hint: If you're a defender you might want to enable this). If enabled, the following extension are blocked by default (can also manually be extended): ace, apk, app, appx, ani, arj, bat, cab, cmd,com, deb, dex, dll, docm, elf, exe, hta, img, iso, jar, jnlp, kext, lha, lib,library, lnk, lzh, macho, msc, msi, msix, msp, mst, pif, ppa, ppam, reg,rev, scf, scr, sct, sys, uif, vb, vbe, vbs, vxd, wsc, wsf, wsh, xll, xz, z

Key takeaway:

Consider what (type of campaign) you want to deliver and make test runs against your targeted environment. If you take care of reputation, stick to common attachment files and keep your files on a low profile you should be able to pass the mail gateways.

Reception & Unboxing

If your mail successfully got delivered into a user's inbox, you're in stage two, where your only concern is the following: How do I get the user into the execution stage (following section)?

There are three main defense mechanisms in this stage to overcome:

• The targeted user
• Mark of the web (MOTW)
• Anti-Virus (AV) solutions in place

Tricking the User

First of all you want your targeted user to actually open the mail and the attachment (remember there are also other forms of mail phishing, e.g. using links, but this post focuses on Microsoft Office attachments). Therefore, your pretext should match with the attachment type (e.g. sending a OneNote document to a technical user stating that this is an invoice could raise suspicion). The variety of Microsoft Office file extensions play in your favor here, for example one could abuse the fact that .XLL files (more on this later) do look like Excel (.xls or .xlsx) documents. Moreover Right-to-Left override-techniques might come in handy for certain scenarios.

Preview note concerning macros: It is worth noting that the Outlook preview function will not execute macros. In order to execute macros (if that is your execution strategy), you want the user to save the document to their hard drive and open it from there.

Bypassing MOTW

The Mark of the web (MOTW) is not exactly brand new, therefore I will skip the intro to MOTW, but if you have not encountered it yet, I can recommend Outflank's blog post on the topic: https://outflank.nl/blog/2020/03/30/mark-of-the-web-from-a-red-teams-perspective/.

Preview note concerning macros: The MOTW will also apply if the user downloads or "save as" the document to their hard drive. If the user then opens the document, the user is presented the typical yellow "Protected View" prompt, asking to "Enable editing". After the user accepts that, macros will be blocked, as the source of the file is untrusted (more on this later).

In general, there are 3 strategies for bypassing the MOTW:

• Utilizing software that does not set the MOTW (e.g. git)
• Using containers, where Windows does not propagate the MOTW to files inside the container (e.g. .7z, .cab, ...)
• Tricking the user to remove the MOTW by right clicking on the file, choosing "Properties" from the context menu and check the box that says "unblock"

MOTW bypasses and vulnerabilities come and go, therefore it's worth to reiterate what's still working and what's new from time to time. The ones that crossed my way during this background research are the following:

• Use of archiving software, most notably 7z*. There is also an overview of MOTW support on various archiving tools here
• File attachments, most notably attaching various file types into OneNote documents
• Use of container files like .vhd or .vhdx
  Note: .iso-files propagate the MOTW since November 2022, see note about patches below
• Outflank showcased the abuse of signed Add-Ins to leverage a trusted publisher (more on this in the next section), which bypasses the MOTW by design. Their results can be found here and here

Moreover, in my own testing I found that Microsoft Publisher files do not seem to use the MOTW to disable macros in Publisher files downloaded from the internet (see the overview visualization at the end of this post).

*A side note on 7z:

7z is capable to propagate the MOTW when extracting files, but it depends on how 7z is used. When a file is opened within the 7z UI, e.g. when double clicking the file, then the MOTW is propagated and macros are blocked. However, when a user right clicks the compressed 7z archive, selects to extract the file in the context menu and then opens the file, the MOTW is not propagated and macros can execute.

It is also worth noting that vulnerabilities that allow for MOTW bypasses are taken seriously and are being fixed (at least by Microsoft). Most recent fixes include these:

• CVE-2022-41049 patched November 2022 (Read-only ZIP files)
• CVE-2022-41091 patched November 2022 (Opening file from within ZIP in Windows 11)
• .iso files not propagating the MOTW was patched November 2022 (thanks for the note @badsectorlabs)
• CVE-2022-44698 patched December 2022 (Signed with corrupted authenticate code)
• CVE-2023-21715 patched February 2023 (VBA macros in publisher [.pub] files)

A good read about these vulnerabilities can be found in this Twitter thread by @wdormann.

Withstand AV Scanning

The last barrier to overcome before you finally hit the execution phase is AV/sandbox scanning. As always AV vendors do improve over time and continue to raise the bar of phishing exploitability. On the other side of the house, every Red-Team have their own techniques and ideas to deal with AVs, which should be customized, sharpened and adjusted for each campaign. Once again, there is no single silver bullet here, but there are a few general purpose tricks that you COULD have in your bag:

Payload/Code Design

When developing code for your campaign always try to keep a small footprint and evaluate your "detection" footprint when adding code. For example: You could consider implementing an AMSI bypass attempt in your VBA macro code, but if you can't bring a custom, unknown technique the cost of this will likely not be worth the gain.

File pumping/bloating

These techniques describe the idea to stuff benign content into a file to lower their detection rate. The idea of this is to evade or pass AV scans, based on the observation that some AVs skip files of certain size for performance reasons or lower the detection rate of malicious content if the frequency of "common document content" is high enough.

Obfuscation: Standard, don't make detection rates using static analysis too easy.

Encryption

Note that we should differentiate between container and payload encryption in our campaign. We could use encryption within the container that carries our document, e.g. we could use encrypted ZIP archives, or encrypted Word/Excel/PowerPoint/X documents (which I refer to as container encryption) and we could encrypt our embedded payload(s), e.g. encrypted Shellcode, strings, or code elements (which I refer to as payload encryption).

Container Encryption

While encrypting our container does help a lot against AV detection, it comes with two drawbacks that should be considered. First drawback: The en-/decryption must fit your campaign. Meaning if you encrypt your Office document with a custom password, you have to convince your target that there is a legit reason that a password must be entered. Also keep in mind that encrypting your document will not evade the MOTW. Therefore, if you run a campaign where your target has to extract your document from an unusual container type (to bypass MOTW), only to find out that they now also have to enter a password, might tip them off. Could be a pitfall, doesn't have to be. Second drawback: Detection footprint. Some mail gateways will not allow encrypted ZIPs in the first place (which would return you to stage 1) and just being encrypted might raise the AV score of your document (again don't read this as "you should not use encryption", read it as "consider the costs of encryption"). Extra note: Some Office applications (Excel & PowerPoint) have a "common default password" that will decrypt a document on the fly without showing a prompt. In Excel the password VelvetSweatshop can be used (supported by all Excel formats), in PowerPoint /01Hannes Ruescher/01 (thanks to this tweet) can be used, but this only works with the .pps and .ppt format.

Payload Encryption

Analogous to what I've said before, consider the costs of this. There is no user interaction here, so these costs do not apply, but there is also a detection footprint here. Consider where the decryption key is obtained from (file on disk, environment variable, pulled from webserver, volatile properties like current time, ...) and what is needed for the decryption routine, e.g. are you using Win32 API functions? If yes, could these be hooked? Often times (depending on how custom your payload is) dynamic en-/decryption is very well worth the costs.

VBA Stomping & VBA Purging

For brevity I'll skip the introduction of these, you can read up on VBA Stomping (in no particular order) here, here, here and here. You can read up on VBA Purging (in no particular order) here, here, here and here. In my testing VBA purging seems not too valuable any longer as it's mitigated in Office documents, very well detected and flagged as malicious, therefore I would currently not apply this. VBA Stomping appears to generate a smaller detection rate, but you might want to note that Mandiant fingerprinted their tool OfficePurge, which has therefore a known signature (alternatives exists).

AV/Sandbox detection routines

Another common technique to not get caught is to try to determine if your document/code/implant is run inside a sandbox. A sample VBA detection routine by mariuszbit can be found here. Once again this could make the difference between getting caught or staying under the radar, but also comes with extra footprint. In my testing - where I copy+pasted this code without any changes - adding these sandbox detection routines to benign macros (MessageBox) resulted in AVs flagging the documents (see VirusTotal benchmark at the end of this post), so the least you want is not blindly copy+pasting.

AV Evasion routines

Consider what your document/implant is supposed to do (see "goals in the Execution section"), weigh that against static and "behavior" analysis capabilities of AV/EDR/XDRs of your targeted environment and apply your favorite evasion techniques. If your document contains malicious content that you want to hide from AVs you could consider sandbox evasion techniques that require human interaction, like clicking/accepting a message box or special triggers (see also the section about "triggers" in the following Execution stage) like hovering over an image before your exploit routine starts. If your document has a rather low footprint, but you're looking for evasion techniques for an implant that you plan to download/drop/execute, you could look into techniques like anti-hooking, PPID spoofing, dynamic/sleep obfuscation, spawning of remote process, etc. Need more ideas? Get inspiration from this talk by @mariuszbit.

So, to summarize this section: Getting your document into a target's inbox is a moving target and vendors are doing a good job of catching up and raising the bar. As attackers we need to continue to challenge these. Let me also add in my own observations here from the test cases that I ran:

• Commonly abused containers like .iso,.img,.cab are (currently) filtered by Outlook's inbound mail gateway and flagged by the Windows defender right away. At least in my off-the-shelf default Microsoft 365 playground.
• VBA Stomping appears (to me) not to be too fruitful any longer, as it's well detected.
• When it comes to detection rates file formats can play a big role. I put a simple shellcode loader (Download + VirtualAlloc + CreateThread) into a VBA macro inside of an encrypted office document (Word & Excel) and found that the XML-based Office formats (e.g. .docm, .dotm) were not flag (0 detections), whereas the corresponding compound files (.doc, .dot) were flagged by multiple vendors (see the VirusTotal benchmark at the end of this post).

Execution

Onto the final stage, where you circumvented all of the previous protection layers, got your document in place and ready to execute. This stage is the most interesting and most important part of your campaign as all the other stages depend on decisions made here.

If you thought the final stage of a phishing campaign is just about executing a VBA macro, you might change your mind at the end of this section.

But while we're on that topic, allow me to make a short VBA detour before we get back on track... Early to mid-year 2022 was a wild ride for VBA Macros: In February 2022 Microsoft announced that they were about to block VBA macros in Microsoft Office products, then they rolled back from that in early July of 2022, only to finally push their changes out later in July 2022, which are now in place. This back-and-forth sparked many discussions around the topic and many articles ([1], [2], [3], [4], [5], [6], ...) have been written about how attacker are now changing tactics to execute their campaigns in a "macro-less" world. There is no doubt that Microsoft's step to block VBA Macros from the internet is a huge step against malware campaigns and there is as well no doubt that this already did and will continue to spark creativity to get around this block, but it should also be noted that VBA Macros have not been the single silver bullet up until mid-2022. This is the end of this little detour, which I felt was necessary to capture the events of the last year.

Back on track now: I said the execution stage is the most important one and decisions need to be made here that affect other stages as well. The reason for that being that the following questions need to be answered and implemented in this stage:

Goals: What do you want to achieve? Depending on your campaign (and there could be multiple campaigns in a Red Team exercise) examples of what you might want to achieve could include:

• Reading/Exfiltration of a file or document.
• Exfiltration of host-based applications and settings (installed software, installed AVs, registry keys, joined domain, firewall configurations, ...)
• Credential theft and/or relay (via password prompt, via captured NTLM challenge responses, via coerced NTLM/Kerberos relay)
  [Note: Not all campaigns are executed from the outside]
• Code execution to drop malware, run scans, run ransomware
• C2 connection as persistent initial access vector

Execution Technique: There is always more than one way to achieve your goal, although not every technique might be suitable for every goal. [For brevity I'll skip implementation/execution details, but will link articles covering these]

• VBA macro ([7])
• XLM macro ([8][9][10][11])
• DDE ([12][13][14])
• Field codes ([15][16])
• Embedded files (attachments & OLE elements)
• Add-Ins (XLL [17][18][19][20], VSTO [21][22][23])
• Lazy-loaded components & external references (template injection [24][25][26], CVE-2022-30190 aka Follina [27][28], CustomUI [29])

At this point it should get clearer that there is more than VBA macros and it's also worth noticing that a "macro" does not even have to be a VBA macro, but could also refer to an XML macro. If that sounds unfamiliar check out this part of @ptrpieter's and @StanHacked's BH Asia talk.

If you do however, want to go with VBA macros it should be noted that there are 5 cases, where macros will be explicitly allowed to run:

• If the document is loaded from a trusted site (e.g. the local intranet and SharePoint sites if computer is domain/Azure joined)
• If the document is signed by a trusted publisher
• If the document is loaded from a trusted location. The default trusted locations for Access, Excel, PowerPoint and Word are listed here
• If a document has previously been trusted
• If group policies explicitly allow it

The following diagram created by Microsoft does a great job in visualizing these cases:

Source: https://learn.microsoft.com/en-gb/DeployOffice/security/internet-macros-blocked#how-office-determines-whether-to-run-macros-in-files-from-the-internet

Bonus: If you fancy VBA macros, the MOTW blocks your execution and you're now looking on the list above. The most interesting vectors in this list might be to exploit trusted sites (e.g. if you have guest access or can be invited in an Azure tenant) or to exploit existing documents that are signed by trusted publishers, which Outflank have proven to be fruitful, shown here and here.

Triggers: Some execution techniques come with self-executing files, but others (especially VBA macros) can also be executed by other triggers, for example:

• Common document VBA events (Auto_Open, Document_Open, Document_Close, ...) [30]
• ActiveX control element events
• Document control events (e.g. CustomUI [31])

Payload format: Your payload - if needed for your goal - could come in different forms and shapes:

• Shellcode
• PE-Files
• Scripts for built-in script interpreters (PowerShell, batch files, VBScript, JScript,...)
• Scripts for other interpreters (Python, php, ruby, ...)

Payload storage: While you can place your payload right next to your execution routine, you certainly don't have to. Here are some other options:

• In-line (in VBA script)
• From document (e.g. from ActiveX control element, from excel cell, from document contents, from embedded document)
• From document attributes (e.g. from XML attributes [32])
• From internal or external servers (e.g. http/ftp/smb)

Payload container: Also the container of your payload, which could be the document you send to your target or a file that you attach or embed in your phishing document, can have a variety of formats:

• Common office document formats (.doc, .docx, .xls, .ppt, .one, .pub, ...)
• Un-common office formats (.dot, .rtf, .xlam, .slk [33][34] ...)
• Exotic documents (.chm, .hh, .scf, .url, .library-ms, .settingscontent-ms [35][36], .lnk [37],...)
• Executables (.exe, .cpl, .bat, .cmd,...)

Once again, to conclude this section, here's what I experienced in my testing:

• XLM macros seem to be disabled by default (at least in my Windows 10 VM) and have to be enabled in the Trust Center settings
• As a result of that: SLK files utilizing XLM macros do not execute unless XLM macros are enabled
• DDE usage was flag by Defender right away in my testing

There is lots more to uncover and plenty of options to build and customize tooling. Especially the ability to embed and/or attach files in other Office documents allows for a variety of mix-techniques. One example: PowerPoint seems not to support DDE operations natively, however PowerPoint allows to attach and embed Excel documents, where DDE vectors could be integrated.

Overview & VirusTotal Benchmark

To recap and to summarize, the following figure captures all of the steps and techniques mentioned above.

Additionally, the following visualization might help to get an overview of what the four major Office document applications Word, Excel, PowerPoint, OneNote and Publisher are capable of:

Lastly, I uploaded various samples of different document formats to VirusTotal, here are the results:

Here's what I think is most interesting with this:

• Case ID #02: The use of Document_Open and similar events in itself does not appear to be overly malicious.
• Case ID #04: Adding AV detections could increase the score even though the content itself is malicious. In this case this is likely due to the fact that I did not change anything from the copied and surely heavily signatured code, but nevertheless: You never know how unique your detection techniques are.
• Case ID #05: VBA stomping does not help with detection rates, but makes it worse.
• Case ID #06/#07: VBA purging is no big help either.
• Case ID #10: Using Excel's built-in, default password seems to lower the detection rate compared to having no password (case ID #05), at least for XML-based documents.
  Note: The stated password only auto-decrypts Excel files (at least in my testing), I was still curious how this password would affect detection rates with Word.
• Case ID #09-#11: The detection rates appear quite low for an obvious malicious VBA macro. The important footnote here is that the VBA code downloads the implant from a domain that only resolves in my test network, therefore the AV sandboxes of VirusTotal were not able to pull and inspect what would be downloaded. This could reveal on of two insights: Either the majority of AV vendors aborted because they could not resolve the domain, or these vendors did not consider the download + memory allocation + CreateThread execution to be malicious (enough), but would instead make their decision dependend on what would be downloaded and executed. In either way the key takeaway of these results is that Anti-AV/Anti-headless browser detection is crucial when serving the malicious implant.

Summary

To conclude this post I'd like to get back to those questions that I raised in the beginning:

What is the state of the art with phishing? [With e-mail phishing based on Microsoft Office documents in this case]

• VBA macros from untrusted sources (e.g. downloaded from the internet) are blocked by default.
• Phishing is nevertheless still active and kicking.
• Defensive detections and prevention mechanisms have improved.
• Offensive techniques have evolved, new and old techniques are rewrapped. Especially containered (.cab, .vhd), packed (.zip, .7z) and attached/embedded documents (especially with OneNote) seem to be around lately.

What are the take aways from the latest changes in this area?

• The Mark of the web (MOTW) is a strong defensive layer that attackers try to bypass and/or prevent.
• The bar for successful phishing campaigns is raised by vendors.
• Vendors like Microsoft - who are in the position to control the Office documents, the executing operating system (in most cases) and often also in most cases the mail gateway - care to protect by allowing to narrow down mail gateways, adding default blocks and fixing vulnerabilities in all areas (MOTW, signed Add-Ins, etc.). Shoutout to @Microsoft !
• With all of these efforts, it's possible that the attack surface continues to move/switch to other platforms (like LinkedIn, Twitter, Teams, etc.). Care should also be taken outside of the mailbox.

What take aways are there for offensive (red) teams?

• Attackers need to have a toolbox packed with various techniques and execution strategies.
• All stages of a phishing campaign need to be planned and evaluated.
• The ages of plain VBA macros without any bypass techniques are gone. However, there are still viable options and MOTW bypasses that can be leveraged.
• This (and other) post did not cover all of the default office applications. Microsoft Access, for example, is still an application contained in the default Office package and could be leveraged (although you might need a special pretext for Access).

What take aways are there for defensive (blue) teams?

• Review and narrow down your inbound mail gateways.
• Explicitly block everything that is not needed, even if it might be implicitly blocked by default (like .iso, .cab, etc.). If possible apply a whitelist for allowed attachments.
• Spread awareness with internal, non-technical colleagues that high e-mail barriers could cause attackers to switch to other social media channels (especially LinkedIn)
• If other phishing barriers are too high attackers tend to extend the pretext, engaging in longer, more personal or business-related conversations. Raise awareness about pretext conversations.
• If you're a Microsoft 365 customer, check out your Exchange Online Protection settings. The official documentation for this feature can be found here, the settings in the Security portal can be found here.
• If you're an analyst/threat hunter: Red-Teamers are keeping their bypasses (especially for MOTW) closer to their chests. Continue to burn these techniques on Twitter to raise awareness and add pressure for secure defaults.