The Email That Asked for Your Cell Number Was Sent from a Domain Registered Yesterday

The email had five words in the subject line ("Want to Connect With You") and a single sentence in the body: "Hello [name], I may need your help with something. Please share your cell phone number so I can text you."

No link. No attachment. No urgency. Just a polite, first-name-familiar ask from someone who appeared to be a senior colleague.

The sending domain, yorkshiregroups[.]com, had been registered 24 hours earlier.

A Forensics Professional Targeted by a One-Sentence Social Engineering Ask

The recipient was a Digital Forensics Technician at a digital forensics firm. She received the message on a Friday morning. The display name on the email matched a real senior colleague in her organization by a plausible first-name variation: "Robert" for the internal "Bob." The difference is easy to miss in a busy inbox, especially in the Microsoft Outlook reading pane where the display name takes center stage and the sending address is one click away.

The goal was not credential theft. It was channel migration. If she replied with her cell number, the conversation would move off corporate email entirely, beyond the reach of Microsoft Defender, any secure email gateway (SEG), and the firm's SOC. From there, the attacker could follow the established business email compromise playbook: pose as the colleague, manufacture urgency, and request a wire transfer, gift card, or payroll diversion via text.

The FBI IC3 2024 report puts adjusted BEC losses above $2.9 billion for the year. The attacks that do the most damage rarely start with a malicious link. They start with a question.

Domain Registration to Inbox in Under 24 Hours

yorkshiregroups[.]com was registered on June 4, 2026, at 16:02 UTC via Squarespace Domains LLC. The email arrived on June 5 at 15:21 UTC (less than 24 hours later). The registrant information is fully privacy-redacted.

The attacker configured the domain on Google Workspace and sent through Google's mail infrastructure. That decision was tactical: Google's outbound servers carry strong IP reputation, and the DKIM signature (yorkshiregroups-com.20251104.gappssmtp.com) is cryptographically valid. As a result, the message cleared every authentication check.

• SPF: pass (authorized Google IPv6 2607:f8b0:4864:20::132b)
• DKIM: pass (Google-signed, relaxed/relaxed canonicalization)
• DMARC: pass (header.from=yorkshiregroups.com)
• Microsoft compauth: 100

This is a deliberate evasion pattern documented in MITRE ATT&CK T1585.001 (Establish Accounts: Social Media Accounts, here adapted to domain + cloud mail infrastructure). The attacker invests roughly $15 in a domain and a few minutes in Workspace setup to buy a clean authentication record for a single targeted campaign.

Authentication standards confirm the message came from yorkshiregroups[.]com. They say nothing about whether that domain has any legitimate connection to the impersonated employee.

What Themis Caught That the Gateway Missed

Microsoft Defender classified the message as CAT:PHISH with an SCL of 5 and routed it to the quarantine folder, so it never reached the inbox. That is the right outcome. But the detection path matters.

The Forefront antispam engine assigned the PHISH category and SCL:5 based on content signals (the request pattern and the new sender combination). Those same signals did not trigger a reject or a block on the DKIM-authenticated path. The message passed through the Exchange Online Protection (EOP) front end and was classified only after transit.

See Your Risk: Calculate how many threats your SEG is missing

IRONSCALES Themis resolved the incident at 89% confidence with labels of "Business Email Compromise" and "Fraudulent Request." The signal stack that drove that verdict is worth unpacking:

First, sender-organization relationship analysis: the sender gabriel@yorkshiregroups[.]com had never sent to the organization, to the recipient's mailbox, or to any mailbox in the tenant. Zero prior correspondence is a strong baseline anomaly for a message that addresses the recipient by first name and frames itself as a familiar colleague check-in.

Second, display name proximity scoring: Themis matched the sender display name against the internal directory and flagged the close similarity to a real employee as a "Similar Display Name Impersonation" signal. This was not a substring match on a generic name, but a targeted similarity hit against a specific internal record.

Third, community pattern matching: similar short-form, zero-payload social engineering messages resolved across the IRONSCALES platform fed the 89% confidence score. This is the value of crowdsourced threat intelligence at scale: the attacker's template had been seen before, even if the domain was brand new.

The combination of behavioral signals (new domain, first-time sender, display name anomaly, out-of-character personal-data request) is exactly what IRONSCALES Adaptive AI is built to correlate. No single signal would close the case. The ensemble does.

How One Cell Number Request Becomes a Wire Transfer

The attack chain in MITRE ATT&CK T1566 maps this as a phishing-for-initial-access attempt, but the more precise framing is T1598 (phishing for information). The attacker is not trying to steal credentials. She is building a communication channel.

Step one: register a convincing domain the day before the attack to minimize threat intel exposure. Step two: configure cloud mail to pass all authentication checks, neutralizing header-based detection. Step three: impersonate a familiar internal name at the display layer, where most recipients focus attention. Step four: ask for personal contact data with a plausible but vague framing ("I may need your help with something"). Step five (if the reply comes): move to SMS or a personal call, where corporate controls cannot see the conversation. Step six: execute the fraud request off-channel.

The Verizon DBIR 2026 notes that 62% of breaches involve the human element, and BEC specifically accounts for a substantial share of the financial losses in that category. The reason is structural: BEC attacks target the human decision layer that sits between the email and the bank account, not a technical vulnerability that a patch can close.

Why a 24-Hour-Old Domain Should Trigger a Hard Stop

The single most actionable detection control for this attack class is domain age enforcement. A domain registered within 30 days sending a first-ever message to your organization and addressing an employee by first name should not land in the inbox pending user judgment. It should be quarantined for analyst review or rejected outright.

Most SEGs will score a clean-authentication, zero-link, zero-attachment message as low risk. The content surface is minimal. There is nothing to sandbox, no redirect chain to unwind, no payload to execute. The gap between "authenticated and benign-looking" and "actively targeting your employees" is exactly where business email compromise protection needs to operate: at the behavioral and contextual layer, not just the artifact layer.

Domain age, sender-organization relationship history, and display name proximity are not features that legacy gateways inspect. They are signals that require a platform with memory across the entire organization's mail history, not a per-message content scan.

The ask in this email was five words. The domain was one day old. The authentication was perfect. All three facts were visible in the headers. Zero-payload BEC recon is not hard to build, and it is not hard to catch if you are looking at the right signals.

---

The Domain and Sender Address Behind the Request