Join our Newsletter — 33% off our NHI Course

SilverTerrier

SilverTerrier is a financially motivated threat group that specialises in business email compromise and phishing. It typically uses spoofed or compromised mail accounts to trick victims into paying fraudulent invoices or redirecting funds. Defenders should validate payment changes out of band, enforce strong mail authentication and flag unusual mailbox rules.

What SilverTerrier Represents in the Threat Landscape

SilverTerrier is best understood as a financially motivated email fraud group, not just a generic phishing label. Its activity sits in the intersection of social engineering, mailbox compromise and payment diversion, which makes it especially dangerous in invoice-heavy business processes.

The group’s value to defenders is that it illustrates how cybercrime can bypass technical perimeter controls by abusing trusted business workflows. A fraudulent email that looks routine can still trigger a payment, change bank details or reroute funds if the receiving process is not independently verified.

How SilverTerrier Abuse Usually Works

Operations like SilverTerrier often begin with spoofed or compromised mail accounts, then move into conversational manipulation, fake invoice trails or requests to update account details. The attacker’s goal is to make the request feel normal enough that finance or operations staff do not question it.

Once the attacker is inside a mailbox or can impersonate a trusted sender, they may exploit thread hijacking, lookalike addresses or mailbox rule changes to keep the fraud alive. That is why mailbox visibility matters as much as email filtering: compromise is often hidden inside ordinary-looking correspondence.

For background on how threat groups are named, tracked and compared across vendor ecosystems, see the Threat Actor Groups Guide.

Why Business Email Compromise Is So Effective

Business email compromise works because it targets trust, timing and payment authority rather than malware execution. A convincing invoice or payment-change request can succeed even in organisations with strong endpoint security if the approval path is weak.

The real weakness is often not the message itself, but the business assumption that an email from a known contact is sufficient proof. SilverTerrier-style fraud exploits that assumption by inserting itself into payment workflows where speed and routine reduce scrutiny.

Defenders should treat outbound payment changes, supplier bank updates and urgent settlement requests as high-risk events because the cost of one missed validation can be direct financial loss and follow-on operational disruption.

Defensive Controls That Reduce Exposure

Practical defence starts with payment verification, mail authentication and mailbox monitoring. Out-of-band confirmation for bank detail changes, stronger sender authentication and alerts for unusual inbox rules all help interrupt the fraud chain before money moves.

Technical controls matter, but they work best when paired with process controls. If the organisation cannot tell which supplier details changed, who approved the change and whether the approving mailbox was healthy at the time, the fraud can remain undetected long enough to be effective.

Authoritative baselines for authentication, access control and monitoring are well captured in NIST SP 800-53 Rev 5 Security and Privacy Controls, while mailbox and sender-authentication guidance is reinforced by NIST SP 800-63 Digital Identity Guidelines. For organisations looking for prescriptive hardening and detection mapping, the CIS Benchmarks also support secure configuration discipline.

Risk and Threat Considerations

SilverTerrier-style fraud is dangerous because it combines social engineering with trusted communications and financial process abuse. The threat is not limited to stolen credentials, the more important risk is that a legitimate-looking message can trigger a legitimate-looking payment.

Failure mechanism: An attacker gains access to, or convincingly imitates, a mailbox and then manipulates invoice or payment instructions before normal review steps can stop the transfer.

Impact: Organisations can suffer direct financial loss, delayed supplier payments, invoice disputes and a wider erosion of trust in email-based business approvals.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
NIST SP 800-53 Rev 5 IA-2 — Identification and Authentication (Organizational Users) SilverTerrier abuses trusted user mail access and impersonation.
AU-6 — Audit Review, Analysis, and Reporting Mailbox-rule abuse and fraud require reviewable audit evidence.
SC-23 — Session Authenticity BEC relies on session abuse and trusted-message impersonation.
Recommendation — Enforce strong user authentication and review mailbox access for compromise. Review mail and account logs for rule changes, forwarding, and suspicious access. Validate message and session authenticity before approving payment changes.
CIS Controls v8 CIS-5 — Account Management Compromised or misused mail accounts are central to BEC campaigns.
CIS-8 — Audit Log Management Detection depends on visibility into mailbox and mail-flow abuse.
Recommendation — Harden account lifecycle controls and remove unnecessary mailbox access. Centralise and review logs for forwarding rules, login anomalies, and payment-change activity.

Practitioner Guidance

Why practitioners should care: Treat payment-change fraud as a business control problem, not only an email security problem. The strongest defence is to make high-value payment changes impossible to complete on email alone.

What to watch for: New mailbox forwarding rules, unexpected sender-domain variation, urgent tone shifts and requests to reroute funds are all strong indicators that a routine business thread may be under attack.

Practitioner takeaway: If the request changes money movement, require a second channel, because the attacker is usually betting that no one will.