Attacker Playbook: Turning BIMI's Trust Signal Into a Phishing Weapon

An email arrives from your bank. Next to the sender's name is the familiar, crisp logo you see on your debit card. The message urges you to review a new security policy. Everything looks right. Except it isn't. This isn't a simple display name spoof from a consumer mailbox. The underlying email passed every technical check. This is a DMARC-validated, BIMI-powered phish, and it represents a sophisticated subversion of email's newest trust signal.

Brand Indicators for Message Identification, or BIMI, aims to solve a real problem. It allows brands to display a verified logo in the user's inbox, but only for emails that are authenticated through DMARC at a policy of `p=quarantine` or `p=reject`. For years, we've told users to 'check for the lock' in their browser's address bar. BIMI is meant to be the email equivalent—a visual shortcut for 'this is legitimate.'

But what if an attacker could manufacture that legitimacy? From a red team perspective, BIMI introduces a fascinating new attack surface. We're going to walk through exactly how a threat actor can register a lookalike domain, achieve full DMARC compliance, and weaponize a logo to craft a phish that bypasses both technical filters and human intuition. This isn't theoretical. The components are available, and the path is clear.

Recon & Setup: The Hunt for a Digital Doppelgänger

Every targeted attack begins with reconnaissance. For this play, the attacker isn't hunting for open RDP ports or unpatched web servers. They're hunting for digital real estate: an unregistered, convincing lookalike domain. This is the foundation of the entire operation.

Finding the Typo-Squat Goldmine

An attacker will generate hundreds of variations of a target domain like `acmecorp.com`. Think `acme-corp.co`, `acmecorpsupport.com`, or homoglyph attacks that swap letters with similar-looking Unicode characters. Tools like dnstwist automate this process, creating a list of potential typo-squats, bit-flips, and other permutations. The goal is to find a domain that looks plausible in a user's inbox, especially on a mobile device where the full domain might be truncated.

The critical filtering step is checking the DNS records for these candidates. The ideal target is a domain that has never been registered or has expired and is now available. A domain with no existing DMARC record (RFC 7489) is a clean slate. An attacker can build their entire authentication infrastructure from scratch without worrying about tripping over a pre-existing, restrictive policy. A quick `dig txt _dmarc.potential-target.com` tells them everything they need to know.

Forging DMARC Compliance

This is the part that often surprises IT teams. Achieving DMARC `p=reject` on a domain you fully control is trivial. There's no magic to it. Since the attacker owns `attacker-acme.co`, they control its entire mail ecosystem. There are no legacy applications or misconfigured third-party senders to worry about—the exact issues that make DMARC deployment a headache for legitimate enterprises.

First, they publish an SPF record (RFC 7208) authorizing their own sending mail server. Then, they generate a DKIM key pair (RFC 6376), publish the public key in DNS, and configure their mail server to sign every outgoing message. With SPF and DKIM aligned, they can publish a DMARC record telling receivers to reject any mail that fails these checks. Since they control the only mail server sending for this domain, nothing will ever fail. They can confidently set `v=DMARC1; p=reject; rua=mailto:reports@attacker-acme.co` and know that 100% of their mail will pass DMARC, satisfying the core prerequisite for BIMI.

The Deceptive Logo: Weaponizing the SVG and VMC

With the domain and DMARC policy established, the attacker moves to the visual payload. BIMI requires the logo to be a specific type of SVG file, hosted at a public URL. The attacker creates a BIMI DNS record pointing to this file, effectively telling mail clients, 'If my email passes DMARC, display this logo.'

default._bimi.attacker-acme.co. IN TXT "v=BIMI1; l=https://media.attacker-acme.co/logo.svg; a=;" — Example attacker BIMI record

In this record, `l=` points to the logo's location. The `a=` field, for the authority evidence (the Verified Mark Certificate, or VMC), is left empty for now. We'll get to that.

Crafting a Pixel-Perfect Fake

The attacker simply downloads the target company's real logo and recreates it as an SVG. The BIMI specification (RFC 8461 is a good reference, though it's now BCP 228) has strict technical requirements for the SVG file—it must be a specific profile, known as the SVG Tiny P/S profile. This disallows scripts, external links, and animations, which is a sensible security measure to prevent the logo itself from becoming an attack vector. But creating a static, visually identical image that conforms to these rules is easy work. An attacker can even slightly alter a color value or move a vector point by a sub-pixel amount to ensure the file hash doesn't match the legitimate company's logo, evading simple detection.

The VMC Hurdle

Here's the strongest defense BIMI offers, and also its most misunderstood nuance. For major mailbox providers like Google and Apple, having DMARC at enforcement is not enough. To display the logo, the domain must also have a Verified Mark Certificate (VMC) referenced in the BIMI record. A VMC is a special type of certificate issued by a Certificate Authority that proves the owner of the domain also holds a registered trademark for the logo itself. This is a high bar. A random attacker can't get a VMC for the Coca-Cola logo.

But a determined and well-funded threat actor has options. They could attempt to register a trademark for a visually similar but legally distinct logo. This is a slow, expensive process, but not impossible. More importantly, *not all mailbox providers require a VMC.* The BIMI standard allows for it but does not mandate it. An attacker might find that their phish doesn't render a logo in Gmail but works perfectly fine in another widely-used webmail client that has a less stringent implementation. The attacker doesn't need to fool every email client, just a vulnerable subset of the target's ecosystem.

The Attack in Motion: Bypassing the Human Firewall

Let's put the pieces together. An accounts payable clerk receives an email with the subject line 'Invoice Overdue: Immediate Action Required'. The sender is `billing@acme-corp.co`, the attacker's typo-squat domain. In the avatar slot, where there is usually just a generic initial, the clerk sees the official ACME Corp logo.

This visual cue short-circuits their normal suspicion. They've been trained to spot phishing, but the typical warning signs are absent. There are no grammar mistakes. The sender address looks plausible. Most importantly, the logo imbues the message with an authority that a simple text email lacks. The mail client itself seems to be vouching for the sender.

Authentication-Results: mx.google.com; dkim=pass header.i=@attacker-acme.co; spf=pass ... smtp.mailfrom=user@attacker-acme.co; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=attacker-acme.co

A look at the headers would show a clean sheet. SPF, DKIM, and DMARC all return a `pass` verdict. The link in the email directs the clerk to a payment portal hosted on the same `attacker-acme.co` domain, completing the illusion. This isn't just Business Email Compromise; it's Brand and Infrastructure Compromise. The attacker has successfully weaponized the very protocols designed to generate trust.

Defensive Postures: How to Hunt for Your Own Ghost

Defending against this attack vector requires shifting from a reactive posture to proactive hunting. You can't just wait for the malicious email to hit your gateway; you need to look for the attacker's setup long before they launch their campaign. It's about monitoring beyond your perimeter.

Proactive Domain and Certificate Monitoring

First, own your typo-squat landscape. The most effective defense is to register common variations of your domain yourself. It's a land grab; if you own `acme-corp.co`, an attacker can't use it. For domains you don't own, you must monitor them.

This means programmatically checking for newly registered lookalike domains and, more importantly, monitoring their DNS records. A script that checks a list of 200 high-risk typo-squats for new SPF, DKIM, or DMARC records can provide an invaluable early warning. The moment a `p=reject` policy and a BIMI record appear on a domain impersonating you, it's time to launch an incident response.

The VMC requirement is also a detection point. Monitor Certificate Transparency (CT) logs, which are public records of all issued TLS certificates. If a VMC is issued by a CA for a domain that looks like yours but isn't, that's a five-alarm fire. This is an unambiguous signal of a sophisticated adversary preparing an attack.

Continuous Policy Validation

Use the same tools an attacker would use, but for defense. Regularly use BIMI record checkers to validate your own configuration across all your sending domains. This ensures your legitimate logos are displaying correctly and haven't been misconfigured. Simultaneously, run these checks against your monitored-lookalike list. Discovering an attacker's `logo.svg` URL before they even send their first phish gives you the opportunity to block the URL at your web filter and submit takedown requests to the hosting provider.

The takeaway

BIMI is a good-faith effort to improve the email ecosystem, and its role in driving DMARC adoption is undeniably positive. But security standards are not fire-and-forget solutions. They create new surfaces and new assumptions, and attackers are masters at exploiting the gap between a protocol's intent and its real-world implementation.

The lookalike domain attack on BIMI isn't a flaw in the standard itself; it's a reminder that defense in depth remains the only viable strategy. Technical authentication must be paired with proactive intelligence. Assume someone is meticulously building an impersonation of your brand. Your job is to find their infrastructure before they use it. Use tools that can monitor and validate DNS security records in bulk, like the scanners in MailSleuth.AI, and treat a suspicious DMARC or BIMI record on a typo-squatted domain with the same urgency as a critical vulnerability on your web server.