HelloSign's Reputation, Attacker's Domain: How a 9-Day-Old HR Portal Hijacked a Trusted E-Signature Platform

The email passed every authentication check. Every link in it resolved to a domain owned by Dropbox. The sending IP belonged to HelloSign's production mail infrastructure. And the attacker's only contribution to the entire delivery chain was a domain registered nine days earlier.

A recipient at a mid-size organization received an HR payroll notice delivered through HelloSign (Dropbox Sign), the widely used e-signature platform. The from address displayed as hr@filesignportal[.]com. The actual sending infrastructure was HelloSign's outbound mail host, 242.static.mail.hellosign.com, with SPF, DKIM, and DMARC all passing for mail.hellosign.com. The return path was a legitimate HelloSign bounce address. HelloSign's X-Mailgun-Variables header exposed the on-behalf-of field: hr@filesignportal[.]com. That was the attacker's address, and filesignportal[.]com had been registered nine days before the email was sent.

The signing links embedded in the message pointed to app.hellosign.com. The "Get Started" button resolved to app.hellosign.com/t/d39a08a9382f50671447e7f321e8d791237098d1. A secondary signing URL pointed to app.hellosign.com/sign/43b002cb280a0848e1fb668995d02fbd80278e1a. Both are HelloSign's legitimate document-signing domain. Scanner verdicts for those URLs returned clean.

The Attacker Artifact Hiding in Plain Sight

ESP abuse works because the authentication story attackers need is not theirs to provide. It belongs to the platform. HelloSign signs the mail with its own DKIM key, records its own SPF, and its own DMARC policy governs the from header. An attacker who registers a fresh domain and provisions a HelloSign customer account inherits that authentication posture immediately, without DNS aging, without IP reputation building, without waiting for their own domain to stop looking new.

filesignportal[.]com was registered on 2026-05-22 via NameCheap with full privacy protection. The domain had no public record tying it to any HR services provider, staffing agency, or internal department. The signing request was framed as an "HR Internal Team" payroll notice with a generic call to action and no recipient name in the body. For an employee expecting routine HR communications during a payroll cycle, this message would be visually indistinguishable from a legitimate HelloSign workflow from their own HR department.

MITRE ATT&CK T1566.001 covers the spearphishing delivery mechanism. T1656 (impersonation) maps to the HR identity claim paired with the "Internal Team" framing. T1585.001 (establish accounts) describes the registration of a new customer account on a trusted platform specifically to enable the delivery.

Why Signing Links Pointing to Legitimate Domains Do Not Make This Safe

The signing session at app.hellosign.com was created by whoever controls the filesignportal[.]com HelloSign account. That session could contain any document: a fabricated payroll authorization, a consent form requesting personal details, or a document designed to establish fraudulent agreement. The victim who clicks through to the legitimate app.hellosign.com domain and sees HelloSign's interface has no platform-level signal that the requesting party is not their actual employer.

This is the structural risk in impersonation campaigns that route through trusted platforms: the platform's interface provides positive trust signals (valid TLS, known domain, familiar UI) that the victim may interpret as validating the requester's identity. They do not. They validate only that HelloSign delivered the message, not that HR sent it.

The absence of recipient personalization is meaningful. A genuine HR payroll request from an organization's HR system would include the employee's name, employee ID, or document reference number. This message addressed no one by name. Combined with a first-time sender status for the filesignportal[.]com domain, this produced a behavioral profile that matched an outbound bulk lure rather than an internal HR workflow.

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

The Detection Surface in a Zero-Payload Attack

No attachments were present. No credential-harvest page appeared in the email body. Every link was to a real platform. This is the challenge phishing campaigns through trusted platforms present: the attack surface visible to a signature-based or URL-reputation scanner is nearly zero, because the attacker has intentionally delegated every visible artifact to a legitimate service provider.

The detection signal here is behavioral and relational, not content-based. The on-behalf-of domain (filesignportal[.]com) is nine days old, privacy-shielded, and has no organizational relationship to the recipient's employer. The sender identity ("HR Internal Team") does not match any known internal HR contact. The message claims to initiate a payroll signing flow, a high-value lure, with no personalization and no prior communication history.

IRONSCALES assessed the combination: a newly registered, opaque domain using a trusted e-signature platform to deliver an HR-themed signing request to a recipient with no relationship to the sending domain, and no personalization to suggest the request was expected. That cluster of behavioral signals identified the campaign without requiring a malicious URL or attachment to evaluate.

For organizations relying on e-signature platforms for legitimate HR, legal, and onboarding workflows, the control implication is that authentication pass-through from those platforms is not sufficient to clear a message. What matters is whether the customer account initiating the request has a verifiable relationship to the recipient's organization.

Indicators of Compromise