What is DMARC?
DMARC, or Domain-based Message Authentication, Reporting, and Conformance is an email security protocol that helps validate the sender of an e-mail message. It relies on other protocol implementations (SPF and DKIM) to be present along with a DMARC record to be published as a TXT entry in the DNS of the domain.
Why DMARC?
DMARC prevents email spoofing. For example, if DMARC policy is not enabled, an attacker could potentially "impersonate" the unprotected domain and make it seem like the emails being sent originate from the unprotected domain. This adds a layer of perceived "legitimacy" from the recipient perspective (as opposed to the message coming directly from attacker[.]com) and increases the likelihood of interaction leading to compromise.
Spoofing in Action
Enumeration using MxToolbox
First, see if the domain is an email domain and has DMARC configurations using a tool like MxToolbox. In the screenshot below, we can see that the redacted domain I have provided does not have a DMARC policy enabled but is an email domain as indicated by the email provider statement beneath the results.
Enumeration using Spoofy
Spoofy is a tool developed by Matt Keely at BishopFox. You can read more about how the tool came to be on his blog post here. The tool can be downloaded here.
To use Spoofy, install it as indicated on the GitHub README and simply pass it the domain using the -d parameter.
Here, Spoofy output shows that spoofing might be possible for the target domain.
Email Spoofing Testing
The most effective method I've found to test this is using a website called Emkei's Fake Mailer (emkei.cz).
After populating the information as pictured, drafting a convincing and urgent message, and supplying either a link or an attachment to facilitate payload delivery, the draft is set. Complete the CAPTCHA and click send.
You've Got Mail
For testing purposes, I sent this e-mail to an address I manage. In the screenshots below, you can see that the delivery was successful.
Do take note that there is a flag when the user opens the email, indicating that it may be "spoofed." In this situation, an attacker would bank on the fact that the user may not understand what that means and would deem the email to be benign since it wasn't considered "spam" and reached the inbox. Furthermore, in the event the attacker researched and was able to identify that the recipient has an account with the entity tied to the spoofed domain, the added legitimacy would tip the probability scales in favor of a user click.
This banner/flag doesn't always show; other spoofing attempts I've performed against different domains have resulted in emails that did not display this banner.
To help drive additional understanding of possible scenarios, a brief written walkthrough. An attacker identifies that banana-wagons-r-us[.]net is vulnerable to spoofing. The attacker is able to research and determine that Larry has an account with banana-wagons-r-us and finds an email tied to Larry after some OSINT. Subsequently, the attacker drafts an e-mail as pictured above, and sends the e-mail to Larry impersonating banana-wagons-r-us. The e-mail bypasses the spam bin, as the one in our walkthrough did, and lands in Larry's inbox. Being that Larry has an account with banana-wagons-r-us, he doesn't find the e-mail very suspicious and believes it is legitimate. Larry clicks on the link, logs in to the fake portal the attacker has postured, and has now had his credentials compromised.
Yorumlar