Phishing Like a Pro: A Guide for Pentesters to Add SPF, DMARC, DKIM and MX records to Evilginx

In this blog post we will cover an update we did to the Evilginx tool. Specifically, this update introduces the capability to add SPF, DMARC, DKIM and MX records to Evilginx. As a result, you can significantly enhance your sender’s reputation and boost your chances of having your emails reach the recipient’s inbox.

We normally use either the original Evilginx version from Kuba or the forked version from fin3ss3g0d. Unfortunately, currently Evilginx does not support creating your own DNS records such as TXT, CNAME, MX, A, AAAA, yet. Therefore, we have contributed to the original version recently and we are waiting for PR approval. In the meantime you can use our fork from here.

Potential failure points in phishing

Some of the potential failure points in phishing are:

  1. Sender’s reputation – we will be covering this one – how to add SPF, DMARC, DKIM and MX records to Evilginx – in more details below.
  2. Content filtering:
    • Description: This is a security feature of Mail Providers such as Gmail. Essentially it scrutinizes the email’s content for indications of phishing or spam, including suspicious links, language patterns, or attachments.
    • How it Fails: Content filters block or mark emails as spam if they contain common phishing elements like urgent requests, demands for personal information, or suspicious links.
  3. URL reputation:
    • Description: Evaluates the trustworthiness of URLs included in the email. Mail Providers check these URLs against databases of known phishing sites or malicious activity.
    • How it Fails: It fails when Mail Providers identify and act upon emails containing URLs linked to known malicious sites or with poor reputations. Consequently, this action blocks user access to URLs that could potentially harbor harmful content.
  4. User’s Awareness and Training:
    • Description: Trainings equip users to better recognize and report phishing attempts. Regular training can include simulated phishing attacks, informational sessions, and updates on the latest phishing tactics.
    • How it Fails: Well-trained and vigilant users are less likely to fall for phishing scams. Failure from the attacker’s perspective occurs when users identify and report phishing emails, rendering the attack ineffective.
  5. Technical Indicators
    • Description: Technical indicators refer to specific signals within an email that suggest malicious intent. These include discrepancies in the email header where the sender’s address might be spoofed, unusual IP addresses, suspicious attachment types, and inconsistent links that appear legitimate but redirect to harmful sites. Automated processes within Mail Providers often assess these indicators, scanning for anomalies that deviate from normal communication patterns.
    • How it Fails: Technical indicators fail when phishing attempts use sophisticated techniques that mimic legitimate emails so closely that they pass through automated checks.
  6. Mail Security Solutions
    • Description: Tools and services designed to protect email systems from phishing and other threats. These can include spam filters, anti-virus scanners, and advanced threat protection solutions.
    • How it Fails: Phishing emails may bypass defenses and reach the recipient if the administrators do not properly configure or maintain these solutions, or if the solutions fail to detect new or sophisticated phishing techniques.
  7. Browser Security Protections
    • Explanation: Built-in browser features that protect users from phishing and malware. For example, Chrome’s “Phishing and malware detection” warns users about dangerous sites.
    • How it Fails: Users may inadvertently access malicious sites if they disable the browser’s security features or fail to recognize a phishing site. Moreover, the protection may be bypassed if users ignore the warnings.

Now let’s discuss “Sender’s reputation” and how we can improve it.

Sender’s reputation

Sender’s reputation refers to the perceived trustworthiness of the email sender’s domain or IP address. Email service providers (ESPs) and spam filters use sender reputation to determine if an email is likely to be spam or malicious.

If the sender’s domain or IP address has a poor reputation, the email may be blocked or flagged as spam before reaching the recipient’s inbox. The sender can improve his domain’s reputation by implementing the following mechanisms:

  1. SPF
  2. DKIM
  3. DMARC
  4. MX

SPF

SPF (Sender Policy Framework) ensures that emails are sent from authorized IP addresses. Consequently, failure occurs when an email is sent from an unauthorized IP address, causing it to be flagged or rejected.

We will use the following SPF value and add it as TXT record in Evilginx:
“v=spf1 include:spf.protection.outlook.com ip4:148.163.0.0/16 ip4:67.231.0.0/16 ~all”

Explanation of the Policy

  • v=spf1: Specifies that this is an SPF version 1 record.
  • include:spf.protection.outlook.com: Authorizes the servers specified by spf.protection.outlook.com to send emails on behalf of the domain.
  • ip4:148.163.0.0/16 ip4:67.231.0.0/16: This part is optional. Authorizes the IP address range 148.163.0.0 to 148.163.255.255 and 67.231.0.0 to 67.231.255.255 to send emails on behalf of the domain.
  • ~all: Soft fail. Emails from servers not listed in the SPF record should be accepted but marked as suspicious. This is less strict than -all, which indicates a hard fail.

DKIM

DKIM (DomainKeys Identified Mail): Enables the sending server to add a digital signature to the email headers. This signature helps the receiving server verify the integrity of the email and confirm that the email is authorized to use the domain in its sender’s address, as per the domain owner’s policies. If the DKIM signature fails verification, it may indicate potential tampering or that the email does not legitimately originate from the claimed sender’s domain.

We can enable DKIM in 2 ways when using Outlook (Microsoft 365) as Mail Provider:

  1. through CNAME records when using Microsoft 365 (free)
  2. through TXT records when using Microsoft 365 with Advanced Email Security powered by Proofpoint (yearly subscription)

In Evilginx we can now add both CNAME and TXT records.

Enable DKIM through ‘CNAME’ records using Microsoft 365

To enable DKIM using the option #1, free, you go to Microsoft Defender – Policies & rules – Threat policies – Email authentication settings – Click your custom domain – and click ‘Enable’. It will return to you 2 CNAME values (selector1 and selector2) to add in your DNS config file, such as the following:

  selector1._domainkey.<yourdomain>.com.: "selector1-<yourdomain>-com._domainkey.NETORGFT15995168.onmicrosoft.com."
  selector2._domainkey.<yourdomain>.com.: "selector2-<yourdomain>-com._domainkey.NETORGFT15995168.onmicrosoft.com."
Enabling DKIM in Microsoft Defender
Enabling DKIM in Microsoft Defender and getting in return the CNAMEs to be added as DNS records.

The Problem with the above CNAME implementation is that most online tools do not query the CNAME record values and only query the TXT record values to check for SPF, DKIM or DMARC. Thus I have used dig to do TXT queries on the above 2 CNAME values and added for each CNAME the result as TXT value in the now supported Evilginx’s DNS config yaml file instead of as CNAME:

Using 'dig' to query the CNAMEs, get the results and add them as TXT records in the DNS record in Evilginx.
Using ‘dig’ to query the CNAMEs, get the results and add them as TXT records in the DNS record in Evilginx.

Note: If you ever ‘Rotate DKIM keys’, you will have to redo the dig queries and update again your DNS config yaml file with the new values/keys as now they are hard-coded.

Enable DKIM through ‘TXT’ records using Advanced Email Security from Proofpoint

To enable DKIM using the option #2, go to Account Management – Domains (to see this menu you have to contact the Support team for permission to enable DKIM) – ‘the 3 dots’ next to your domain – Enable DKIM. This will return a TXT record value to add in your DNS config file such as the following:

  selector-1715066775._domainkey.<yourdomain>.com.:
    - ttl: 1
      value: >
        v=DKIM1; k=rsa; t=s; n=core; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArHsf8VkiIyxhVdaSRto9hKrI656uw1t6dglrRbpX0EQcHhOi/w+WRYlHL3dbso1+OlAKTECiQrYRsNgsQgGP2ajVpNjAUNMBItiHsPlldQb9wodOIWmWDoVV/C536ia6wujqGCnwrS3CTWwa/lfXdw77d5YFxbCvyO+8USlvF0LnNYF0zMjEzlRCaTRRqXVkjGjsnUMCnpCz2AHrMNLCcAUREONjy05KNNEWpmAb6j3ea0wfw3svNlFG8E7+9C8pE2GiyUtVImqZFbE8V80w95Pwd593Vb2fFhSQNLNAHGvoFvnfO3wQ6Zr4lZVa0+W918jaQhOq22LvmWwRelcBYQIDAQAB
Enable DKIM through 'TXT' records using Advanced Email Security from Proofpoint
Enable DKIM through ‘TXT’ records using Advanced Email Security from Proofpoint

DMARC

DMARC (Domain-based Message Authentication, Reporting, and Conformance): Specifies how to handle emails that fail SPF and DKIM checks. Therefore, the Mail Provider identifies these emails when they violate the domain’s SPF or DKIM policies and then applies the DMARC policy specified for the domain: ‘none’, ‘quarantine’ or ‘reject’.

Example: “v=DMARC1; p=quarantine; pct=100; rua=mailto:administrator@yourdomain.com;”

Explanation of the Policy:

  • v=DMARC1: This tag identifies the record as a DMARC record.
  • p=quarantine: This is the policy tag, and setting it to “quarantine” instructs receiving servers to move emails that fail DMARC checks into the spam or junk folder, rather than delivering them directly to the recipient’s inbox or rejecting them entirely.
  • pct=100: This tag is optional. It specifies to Mail Providers the percentage of mails to which the DMARC policy is applied. If you do not specify pct, the default is 100%, meaning the DMARC policy applies to all messages. You can set this value lower if you are just starting with DMARC and want to test its impact without affecting all your email traffic.
  • rua=mailto:postmaster@domain.com: This tag is optional and specifies an email address to receive reports about messages that pass and fail DMARC evaluation. These reports enable administrators to actively monitor and adjust their email authentication practices based on how receiving servers handle their emails.

MX Records

MX (Mail Exchange) Records: These records identify the mail servers responsible for receiving emails on behalf of a domain. Thus, when properly configured, MX records ensure that incoming emails are routed through legitimate and secure mail servers. This not only secures email reception for the domain but also indirectly enhances the sender’s reputation by associating them with reliable mail providers.

Example: “yourdomain.com. 3600 IN MX 10 mail1.yourdomain.com.”

Explanation of the Policy

  • yourdomain.com.: The domain name for which this MX record is specified.
  • 3600: This is the TTL (Time to Live), which indicates how long (in seconds) this record should be cached by resolving name servers before it needs to be refreshed. During testing is better to use a lower value.
  • IN: Specifies the class of the record, where “IN” stands for Internet.
  • MX: Indicates that this is a Mail Exchange record.
  • 10: The priority of the mail server. Lower numbers represent higher priority. This tells receiving mail servers which server to try first.
  • mail1.example.com.: The hostname of the mail server that will receive the emails on behalf of the domain.

Add SPF, DMARC, DKIM and MX records to Evilginx

You can enable and add the above DNS records in the dns_records.yaml file. Each time you start Evilginx, it will load this DNS config yaml file. For every change to this DNS config file you will have to restart Evilginx to apply the changes.

My dns_records.yaml file looks like this:

txt_records:
  <yourdomain>.com.:
    - ttl: 360
      value: "v=spf1 include:spf.protection.outlook.com ip4:148.163.0.0/16 ip4:67.231.0.0/16 ~all"
  _dmarc.<yourdomain>.com.:
    - ttl: 1
      value: "v=DMARC1; p=none"
  selector1._domainkey.<yourdomain>.com.:    #extracted the value from the cname  
    - ttl: 1
      value: >
        v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3fMuLsest6PUWWRMgkdJfyqPXYByC+806Buq7zI1AQqhuMdBhMUfCHgIqmrmUgPXgLRmiFKs5vM3882qXauKCIS2vPaBZiBCJ21IykFXHknnMC6NFpkK3q0FD+r0gVxuuyuo/VCI5ZhigbLOlhjabG05LnWvfuXRlk9E7g8jgSfjQvaET8FamGBvZLuFsci69zM0dUPcy6/SK18q4QF/UNlByMVLiNbeS1byH1Es0oToCLIC3v+vX2X24Q2PymoCu0E6aPs1IWtNQt19L3/4Bvymz8x+ytGnbgmsYj87/TP2QyGGsk+PLewAQ9c3fJ5eMXGRg6AAddNx442JZkC6rQIDAQAB;
  selector2._domainkey.<yourdomain>.com.:    #extracted the value from the cname  
    - ttl: 1
      value: >
        v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2BtLMzp7iuEpdFh+f4A7ajY0WqEEzeIDZlQVfmsO8t61Yti1lldXIf/o+VG4FBCvrC71nR4upW9eUDhIk4MHDLLXA0vQ4BERKiET6TVhKtCGwrMXqALRngvjmOwdG8hhZkdh3pPLl4v9Gjv9NkgT9XqdBYHksWy7keIMIngrH3WZXNEpMUkcoguZDUe8P90uwilpyN2apvOoXPW9wxx4vkhy7SKuV7VXmW7V8I01Qx3sjLhH8vh1vlxzMZusjsKFLz3IyAAx71FmJWtnernS1a6u9YQcEayoubzwJEPcaUNJF6S8EVeJb8SXyPMn/HmNfRX/gs12LCGox7U9snPN5QIDAQAB;

mx_records:
  <yourdomain>.com.:
    - preference: 0
      value: "<yourdomain>-com.mail.protection.outlook.com."

We will use mail-tester and Gmail for showing us the improvements once we implemented these 4 mechanisms: SPF, DMARC, DKIM and MX.

Before improving the sender’s reputation

For the original Evilginx tool:

The mail score before we add the SPF, DKIM, DMARC, and MX records to Evilginx
The mail score before we add the SPF, DKIM, DMARC, and MX records to Evilginx
The mail score before we add the SPF, DKIM, DMARC, and MX records to Evilginx
The mail score before we add the SPF, DKIM, DMARC, and MX records to Evilginx

For the Evilginx fork from fin3ss3g0d:

The mail score before we add the SPF, DKIM, DMARC, and MX records to the Evilginx fork tool
The mail score before we add the SPF, DKIM, DMARC, and MX records to the Evilginx fork tool

After improving the sender’s reputation

For the original Evilginx tool:

The mail score after we add the SPF, DKIM, DMARC, and MX records in the Evilginx tool
The mail score after we add the SPF, DKIM, DMARC, and MX records in the Evilginx tool
The results after we add SPF, DKIM, DMARC, and MX records in  Evilginx
The results after we add SPF, DKIM, DMARC, and MX records in Evilginx

For the Evilginx fork:

The mail score after we add the SPF, DKIM, DMARC, and MX records to the Evilginx fork tool
The mail score after we add the SPF, DKIM, DMARC, and MX records to the Evilginx fork tool
The results after we add of the SPF, DKIM, DMARC, and MX records in the Evilginx fork tool
The results after we add of the SPF, DKIM, DMARC, and MX records in the Evilginx fork tool

Before and After, as shown in Gmail for Evilginx:

The mail before we add the SPF, DKIM, DMARC, and MX records in the Evilginx tool
The mail before we add the SPF, DKIM, DMARC, and MX records in the Evilginx tool
After we add the SPF, DKIM, DMARC, and MX records to Evilginx, the email now displays a new 'signed-by' header.
After we add the SPF, DKIM, DMARC, and MX records to Evilginx, the email now displays a new ‘signed-by’ header.

Before and after, as shown in Gmail for the Evilginx Fork:

The mail before we add the SPF, DKIM, DMARC, and MX records to the Evilginx fork tool
The mail before we add the SPF, DKIM, DMARC, and MX records to the Evilginx fork tool
After we add the SPF, DKIM, DMARC, and MX records in the Evilginx fork tool, the email now displays a new 'signed-by' header.
After we add the SPF, DKIM, DMARC, and MX records in the Evilginx fork tool, the email now displays a new ‘signed-by’ header.

Debug

Lastly, you can run evilginx in the debug mode (with the -debug flag) and investigate at start the loading of your DNS yaml config file. Moreover, you can see when you receive DNS records from 3rd parties or yourself using a tool such as ‘dig’:

The loading of the dns_records.yaml file at start time in evilginx in debug mode.
The loading of the dns_records.yaml file at start time in evilginx in debug mode.
Evilginx in debug mode showing the DNS MX and A queries made with the 'dig' tool from a terminal: "dig +short MX <yourdomain>.com"
Evilginx in debug mode showing the DNS MX and A queries made with the ‘dig’ tool from a terminal: “dig +short MX <yourdomain>.com”

Features

Current Features

Now that Evilginx supports a DNS config yaml file, you can add the following DNS records to improve sender’s reputation:

  1. TXT
  2. MX
  3. CNAME
  4. A
  5. AAAA

Examples of a DNS yaml config file:
Note: Replace ‘yourphishingdomain’ with your domain.

txt_records:
  yourphishingdomain.com.:
    - ttl: 360
      value: "v=spf1 include:spf.protection.outlook.com ip4:148.163.0.0/16 ip4:67.231.0.0/16 ~all"
  _dmarc.yourphishingdomain.com.:
    - ttl: 1
      value: "v=DMARC1; p=none"
  selector1._domainkey.yourphishingdomain.com.:    #from cname  
    - ttl: 1
      value: >
        v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3fMuLsest6PUWWRMgkdJfyqPXYByC+806Buq7zI1AQqhuMdBhMUfCHgIqmrmUgPXgLRmiFKs5vM3882qXauKCIS2vPaBZiBCJ21IykFXHknnMC6NFpkK3q0FD+r0gVxuuyuo/VCI5ZhigbLOlhjabG05LnWvfuXRlk9E7g8jgSfjQvaET8FamGBvZLuFsci69zM0dUPcy6/SK18q4QF/UNlByMVLiNbeS1byH1Es0oToCLIC3v+vX2X24Q2PymoCu0E6aPs1IWtNQt19L3/4Bvymz8x+ytGnbgmsYj87/TP2QyGGsk+PLewAQ9c3fJ5eMXGRg6AAddNx442JZkC6rQIDAQAB;
  selector2._domainkey.yourphishingdomain.com.:    #from cname  
    - ttl: 1
      value: >
        v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2BtLMzp7iuEpdFh+f4A7ajY0WqEEzeIDZlQVfmsO8t61Yti1lldXIf/o+VG4FBCvrC71nR4upW9eUDhIk4MHDLLXA0vQ4BERKiET6TVhKtCGwrMXqALRngvjmOwdG8hhZkdh3pPLl4v9Gjv9NkgT9XqdBYHksWy7keIMIngrH3WZXNEpMUkcoguZDUe8P90uwilpyN2apvOoXPW9wxx4vkhy7SKuV7VXmW7V8I01Qx3sjLhH8vh1vlxzMZusjsKFLz3IyAAx71FmJWtnernS1a6u9YQcEayoubzwJEPcaUNJF6S8EVeJb8SXyPMn/HmNfRX/gs12LCGox7U9snPN5QIDAQAB;

# cname_records:
#  selector1._domainkey.yourphishingdomain.com.: "selector1-yourphishingdomain-com._domainkey.NETORGFT15995168.onmicrosoft.com."
#  selector2._domainkey.yourphishingdomain.com.: "selector2-yourphishingdomain-com._domainkey.NETORGFT15995168.onmicrosoft.com."

mx_records:
  yourphishingdomain.com.:
    - preference: 0
      ttl: 1
      value: "yourphishingdomain-com.mail.protection.outlook.com."

aaaa_records:             
  yourphishingdomain.com.:
    - ttl: 1
      value: "aaaa:bbbb:cccc:dddd::1111:2222"

a_records:            
  yourphishingdomain.com.:
    - ttl: 1
      value: "179.129.1.1"

Possible new features

To add PTR records support too – if there is a need/demand for it. So far I did not find a reason related to improving sender’s reputation. Currently there is a ‘bug’ somewhere in a more upstream function that ‘rejects’ PTR queries from being solved by the same function that does all the other queries such as: TXT, CNAME, A, AAAA, MX.

Explore Our Phishing and Pentesting Services

As we continuously improve our tools and techniques for effective penetration testing, we encourage you to explore our phishing services. Tailored to assist security professionals in adopting the latest and most effective security practices, these services are here to enhance your cybersecurity measures. For more information about our offerings or to discuss personalized pentesting solutions with our team, please visit our services page or contact us today.

About Post Author