In Blog

After having watched my colleague Michael pay the beer after Daniel’s rubber ducky attack, I wanted in on the fun!

So, our systems at OKIOK are pretty well secured, an outsider, let’s call him Bob, will not be able to spoof an email from, say saying he wishes to pay the next round of beverages. Or will he?

A brief introduction on how SPF works.

SPF, or Sender Policy Framework, is a protocol aimed at preventing abuse of a domain. It won’t prevent your domain from getting spam, but it will prevent spammers from impersonating your domain, or any domain with an SPF policy. The way it achieves this is by specifying which hosts within the DNS record are sanctioned mailers.

If I attempt to send an email from, it is rejected with error 550 since my IP is

550 5.7.1 Sender ID (PRA) Not Permitted

If you wish to quickly see the SPF for a domain, you can do so using dig as follows:

root@bt:/work# dig -t TXT okiokcom | grep spf     3600    IN    TXT    "v=spf1 mx -all"

This specifies that the Mail Server (MX) is allowed to send emails from the; IPs can be used as well but this syntax is more flexible since if the IP changes in the future, the SPF does not need editing.

The value that interests us is the -all. This parameters can be used as a whitelisting mechanism, and has the following meanings:

  • -all All IPs not matching the previous mechanism of mx should be rejected
  • +all All IPs not matching the previous mechanism of mx should be accepted

In our case, since we want to send an email to the Penetration Testing team mailing list from Michael stating that he wishes to buy rounds yet again, I needed a way of circumventing this SPF mechanism, at least for a little while! Then it hit me, why not simply modify the DNS response on the fly, then the mail server will essentially be “open” for a duration of Time-To-Live, (which in this case is one hour, 3600 seconds as show here)?

root@bt:/work# dig ANY | grep MX    3600    IN      MX      10

With this in mind, all I needed was the IP of DNS server, the IP of the gateway, a way to get in the same subnet as the DNS server and then to perform the ARP poisoning and modify the DNS response as needed.

Enter Ettercap

Ettercap is a well know networking tool used by our team while performing penetration tests for clients. It performs ARP poisoning well, and more importantly is stable.

A brief introduction to ARP spoofing.

ARP spoofing is a way of seeing network traffic I would not normally see. In this case, the DNS traffic from our DNS server to the mail server does not go through my laptop, yet I need it to, in order to tweak the DNS response to fit my needs. ARP spoofing is broadcasting ARP information containing FAKE information, where FAKE == MY LAPTOP. ARP, or Address Resolution Protocol, is how computers know where to send a packet to.

Wait, you thought that was what IP addresses are used for? Kind of, an IP is a network layer abstraction, but a computer is located on a network by its MAC address. That is referred to as the Link layer, one level down, and at this level, each computer keeps a mapping of who (the unique MAC address) owns a particular IP.

Computers receive these Ethernet frames, replace the Ethernet Source with their own MAC value, and also replace the Ethernet destination MAC with the destination where the packet needs to go next. This happens on and on for each packet as it travels along the Internet highway. So when a computer doesn’t have a direct mapping for an IP, sends an ARP broadcast to discover the MAC address if the IP is in the same subnet or it forwards the packet to the configured default route otherwise.

In the case of our ARP spoofing, we want to tell the DNS server on the network that the MAC address for the gateway is FAKE-ME, and tell the gateway that the MAC address for the DNS host is also FAKE-ME.

View of network, in red is the traffic we want to intercept and modify:


After successfully performing the ARP spoofing, the traffic now looks as follows, lines in red indicate the redirected flow for BOB:


Once I had this done, all that was left to do was to modify the DNS response to fit our needs: Tell the mail server that any IP can send emails from the domain.

Again, using Ettercap we can specify a filter, which is essentially a script which can be used to modify the traffic being intercepted.

The filter I used for this case was:

if (ip.proto==UDP && udp.src==53 && search(, "v=spf1 mx -all")) {
    replace("v=spf1 mx -all", "v=spf1 mx +all");
    msg("ML is paying the beer, hurry and send the email!");

The filter is compiled using Etterfilter as follows:

etterfilter myfilter.filter –o myfilter.ef

And the attack is put in place with the Ettercap as follows:

ettercap –TqM arp:remote –F myfilter.ef / /

Once the message “ML is paying the beer, hurry and send the email!” appears, it is time to send the fake email. You can telnet to, or even easier, create a new account in Outlook named, and manually configure as the SMTP server, no need to specify a POP3 server, and you can then send the fake email using Outlook instead of having to type out each command in the telnet command line interface.

Conclusion, SPF works well for external attackers, preventing outsiders from sending emails from your domain, but it can be circumvented internally.

Leave a Comment

Start typing and press Enter to search