In our ongoing efforts to tighten our internal security posture, we recently conducted a simulated phishing campaign. While largely successful, we encountered an interesting operational snag: a subset of technically savvy users, upon receiving the test emails, correctly identified the domains as suspicious and proactively reported them. However, this had the unintended consequence of "burning" our test domains for future campaigns, as they were now widely known and flagged internally.
This led me to explore a more elegant, network-level solution using our existing Twingate deployment. Beyond its core zero-trust network access (ZTNA) functionality, Twingate's DNS filtering capability—often used to block categories like malware or adult content—can be repurposed as a precise internal control mechanism. The goal was to prevent internal workstations from resolving the phishing test domains at all, ensuring only the external simulated phishing platform could reach them, while our internal users would see a clean block page.
The implementation is remarkably straightforward and is managed centrally within the Twingate Admin console. The process involves creating a new DNS Filtering Rule.
1. Navigate to **DNS Filtering** under the Policies section in your Twingate Admin console.
2. Click **Add Rule**.
3. Configure the rule with the following parameters:
* **Rule Name**: `Block Internal Phishing Tests`
* **Action**: `Block`
* **Apply To**: Select the relevant User Groups or Connectors housing your internal corporate devices.
* **Domains**: `Specific Domains`
4. In the domain list, add the fully qualified domain names (FQDNs) used by your phishing simulation service. For example:
```
simulated-phishing-campaign.example.com
security-test.anotherprovider.net
```
5. Save the rule. The change propagates to your Twingate Connectors and is enforced immediately for connected clients.
The primary benefit is the clean separation of concerns. The phishing test emails still get delivered (as they originate from outside, not traversing Twingate's DNS filter for the sender), but any subsequent user interaction—such as clicking a link or even a background resource load—is neutered at the DNS level. The user receives a consistent Twingate block page, which is less likely to be reported as a "real" phishing attempt compared to a browser's generic error, and our test domains remain uncontaminated for future use.
This approach has proven highly effective for us, turning a reactive, user-dependent reporting process into a proactive, controlled network policy. It's a subtle but powerful example of leveraging the existing feature set of a ZTNA tool for adjacent security operations tasks.
- Mike
- Mike