Service Account Spoofing
This attack exploits legitimate service accounts or third-party services that are authorized to send emails on behalf of a domain. By compromising or abusing these services, attackers can send spoofed emails that pass authentication checks.
Attack Summary: Exploiting legitimate service accounts or third-party services to send spoofed emails that pass authentication checks.
Background: Service Accounts and Third-Party Services
Many organizations use service accounts or third-party services to send emails on their behalf:
- Marketing platforms: Services like Mailchimp, SendGrid, or HubSpot
- CRM systems: Services like Salesforce or Zoho
- Support platforms: Services like Zendesk or Freshdesk
- Internal service accounts: Accounts used for automated notifications or alerts
These services are typically authorized to send emails on behalf of the organization through SPF, DKIM, or both. This authorization creates potential attack vectors if these services or accounts are compromised or misconfigured.
Attack Methodology
This attack involves identifying and exploiting legitimate service accounts or third-party services that are authorized to send emails on behalf of a target domain.
Third-Party Service Exploitation
Exploiting authorized third-party services
This variant involves identifying and exploiting third-party services that are authorized to send emails on behalf of the target domain.
Reconnaissance Example
Identifying authorized third-party services
# Check SPF record for authorized services dig +short TXT example.com # Example output v=spf1 include:_spf.google.com include:sendgrid.net include:mailchimp.com -all
Explanation: In this example, the attacker identifies that example.com has authorized Google, SendGrid, and Mailchimp to send emails on its behalf through SPF. These services become potential targets for exploitation.
Service Account Compromise Example
Exploiting a compromised service account
# After compromising a SendGrid account authorized for example.com # Use the SendGrid API to send a spoofed email curl -X POST https://api.sendgrid.com/v3/mail/send \ -H Authorization: Bearer COMPROMISED_API_KEY \ -H Content-Type: application/json \ -d '{ personalizations: [{to: [{email: victim@target.com}]}], from: {email: ceo@example.com}, subject: Urgent Wire Transfer, content: [{type: text/plain, value: Please process this wire transfer immediately.}] }'
Explanation: In this example, the attacker has compromised a SendGrid account that is authorized to send emails on behalf of example.com. The attacker uses the SendGrid API to send a spoofed email that appears to be from the CEO of example.com.
How It Works
- Attacker identifies third-party services authorized to send emails for the target domain
- Attacker compromises one of these services (e.g., through credential theft, API key exposure)
- Attacker uses the compromised service to send spoofed emails
- The emails pass SPF checks because the service is authorized in the SPF record
- The emails pass DKIM checks because the service signs them with its legitimate DKIM key
- The emails pass DMARC alignment checks because the service is authorized
- Recipients see the emails as coming from the target domain
Service Account Misconfiguration
Exploiting misconfigured service accounts
This variant involves identifying and exploiting misconfigured service accounts that allow unauthorized users to send emails.
Open Relay Example
Exploiting an open relay
# Testing for an open relay telnet mail.example.com 25 HELO attacker.com MAIL FROM: attacker@attacker.com RCPT TO: victim@target.com DATA From: ceo@example.com To: victim@target.com Subject: Urgent Wire Transfer Please process this wire transfer immediately. . QUIT
Explanation: In this example, the attacker discovers that mail.example.com is an open relay, meaning it will forward emails from any sender to any recipient. The attacker uses this misconfiguration to send a spoofed email that appears to be from the CEO of example.com.
Misconfigured Service Account Example
Exploiting a misconfigured service account
# After discovering credentials for a service account # Use SMTP authentication to send a spoofed email telnet mail.example.com 587 HELO attacker.com AUTH LOGIN [Base64-encoded username] [Base64-encoded password] MAIL FROM: notifications@example.com RCPT TO: victim@target.com DATA From: ceo@example.com To: victim@target.com Subject: Urgent Wire Transfer Please process this wire transfer immediately. . QUIT
Explanation: In this example, the attacker has discovered credentials for a service account (notifications@example.com) that is authorized to send emails through mail.example.com. The attacker uses these credentials to authenticate to the SMTP server and send a spoofed email that appears to be from the CEO of example.com.
Common Misconfigurations
Several types of misconfigurations can enable service account spoofing:
- Open relays: SMTP servers that forward emails from any sender to any recipient
- Weak authentication: Service accounts with weak or default passwords
- Exposed credentials: Service account credentials exposed in code repositories or logs
- Overly permissive policies: Service accounts with permission to send as any user
- Lack of sender verification: Systems that don't verify the From header matches the authenticated user
Subdomain Takeover
Exploiting abandoned subdomains
This variant involves taking over abandoned subdomains that are still authorized to send emails for the main domain.
Subdomain Takeover Example
Exploiting an abandoned subdomain
# Check SPF record for authorized subdomains dig +short TXT example.com # Example output v=spf1 include:_spf.google.com include:mail.example.com -all # Check if the subdomain is properly configured dig +short mail.example.com # If the subdomain is abandoned, register it or point it to your server # Then use it to send spoofed emails
Explanation: In this example, the attacker identifies that mail.example.com is authorized in the SPF record of example.com but is no longer in use. The attacker takes over this subdomain and uses it to send spoofed emails that pass SPF checks.
Subdomain Takeover Process
- Attacker identifies subdomains authorized in the SPF record
- Attacker checks if any of these subdomains are abandoned or misconfigured
- If a subdomain is abandoned, the attacker attempts to take it over
- This could involve registering the subdomain if it's available
- Or exploiting DNS misconfigurations to point the subdomain to the attacker's server
- Once the subdomain is under the attacker's control, they can use it to send spoofed emails
- These emails will pass SPF checks because the subdomain is authorized in the SPF record
Impact
This attack allows attackers to:
- Send spoofed emails that pass SPF, DKIM, and DMARC checks
- Impersonate legitimate users or services within the organization
- Conduct highly convincing phishing attacks
- Potentially access sensitive information or systems
Detection
Organizations can detect these attacks by:
- Monitoring for unusual activity from service accounts or third-party services
- Implementing logging and alerting for all email-sending services
- Regularly auditing authorized services and subdomains
- Using email security solutions that can detect anomalous sending patterns
Mitigation
To protect against these attacks, organizations should:
- Limit authorized services: Only authorize necessary services in SPF records
- Implement strict authentication: Require strong authentication for all service accounts
- Verify sender addresses: Ensure the From header matches the authenticated user
- Monitor service accounts: Implement logging and alerting for all email-sending services
- Audit regularly: Regularly audit authorized services and subdomains
- Implement DMARC: Use strict DMARC policies to prevent spoofing
- Use sender verification: Implement additional sender verification mechanisms
Testing
Security professionals can test for this vulnerability using the following approach:
- Identify all authorized services and subdomains in SPF records
- Check for misconfigurations or vulnerabilities in these services
- Test for open relays or weak authentication
- Check for abandoned or misconfigured subdomains
- Attempt to send test emails through authorized services
- Verify if the emails pass authentication checks
References
- RFC 7208: "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email."https://tools.ietf.org/html/rfc7208
- RFC 6376: "DomainKeys Identified Mail (DKIM) Signatures."https://tools.ietf.org/html/rfc6376
- RFC 7489: "Domain-based Message Authentication, Reporting, and Conformance (DMARC)."https://tools.ietf.org/html/rfc7489
- Chen, J., Duan, H., Weaver, N., Paxson, V., & Jiang, J. (2021). "Measuring and Mitigating Email Sender Spoofing Attacks." In Proceedings of the 30th USENIX Security Symposium.
- Foster, I. D., Larson, J., Masich, M., Snoeren, A. C., Savage, S., & Levchenko, K. (2015). "Security by Any Other Name: On the Effectiveness of Provider Based Email Security." In Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security.