Features (EN)
_ _ Yoann Jonard

NTP spoofing

How to exploit NTP to conceal traces in a switch?

Introduction

The Network Time Protocol (NTP) allows the synchronization of the clocks of different computing devices on a network. Very important in the worlds of finance and broadcasting, having all devices set to the same time, and the correct time, is also crucial for security reasons. However, this protocol and its implementation are often neglected, and its importance is underestimated.

Let’s explore how to exploit a basic NTP configuration on a switch to conceal our logs, compromise certificates, and make audits impossible.

Environment

For this project, we will use a virtual Extreme Networks switch as well as two virtual machines running Debian, all within GNS3. The first machine will act as the legitimate NTP server (NTP-Server-Legit), while the second will be the attacker (NTP-Server-Rogue). Our target is the switch (ntp-target).

  1. NTP-Server-Legit: 192.168.234.47
  2. NTP-Server-Rogue: 192.168.234.48
  3. ntp-target: 192.168.234.46

The legitimate NTP server will use chronyd with the default configuration, except for the local stratum 8 parameter, which indicates that the server itself is not synchronized with a reference clock, but it is still considered trustworthy.

NTP lab diagram

Nominal Situation

Our switch is using the machine 192.168.234.47 as its NTP server, the legitimate NTP server. The clocks are synchronized, and communication is operational.

A show ntp statistics command confirms that the server is reachable (Reachable) and synchronized (System Peer).

A packet capture on the switch’s uplink clearly shows the exchanges between the two machines: the request from the switch at 192.168.234.46 and the response from the server at 192.168.234.47.

The structure of an NTP response is as follows, and we will focus on the last 4 fields in this article. For more information on other fields, I recommend checking RFC 5905.

As we can see, the nominal situation is quite simple, maybe even too simple. Let’s now introduce our rogue NTP server into the equation.

NTP spoofing

Our target, the switch, only supports unicast NTP and expects to receive an update from the server only if it has requested one. This means we cannot simply flood erroneous NTP responses onto the network and expect the switch to accept them. We need to impersonate the legitimate NTP server to the switch, and impersonate the switch to the NTP server. And for this, we’ll use ARP spoofing.

In Wireshark, the spoofing looks like this: we inform our two targets that the MAC address of their counterpart is ours.

We intercept the traffic, modify the packets by shifting the time back by one month and advancing it by an hour, and respond to our target.

In the first response, it’s interesting to note the value of the “origin timestamp,” which is the NTP client’s timestamp when it made the request. We can see that our switch was “on time” on April 4, 2024, when it requested an update from the NTP server, and we responded by saying it was now March and one hour ahead.

Our switch now believes it is in March 2025, and the CLI confirms this.

The same principle applies if you want to get ahead of time. Let’s modify our script to set it to March 2026 instead.

Great, but... why do this?

Now that our switch is set to the time we want to give it, what can we do with it?

We can conceal our actions in the logs and make the event chronology difficult to understand.

If you check the logs on the switch itself, the chronological order of commands will be preserved because the logs are written one after another in the files. So, you’ll see the commands in the order they were typed, with the “false” dates associated. Below are the commands in chronological order with several NTP updates in between: April 4, 2025, March 4, 2025, March 4, 2026, and March 4, 2024.

2025-04-04T12:23:14.529Z ntp-target CP1 [...] rwa show clock                     
2025-03-04T13:25:15.021Z ntp-target CP1 [...] rwa show clock                     
2026-03-04T13:37:40.853Z ntp-target CP1 [...] rwa show clock                     
2026-03-04T13:39:41.580Z ntp-target CP1 [...] rwa a very dangerous command in 2026
2024-03-04T13:41:14.454Z ntp-target CP1 [...] rwa show clock                     
2024-03-04T13:41:18.062Z ntp-target CP1 [...] rwa a very dangerous command in 2024
2024-03-04T13:41:22.246Z ntp-target CP1 [...] rwa show logging file module CLILOG

In a SIEM, the situation gets more complicated because logs will likely be reclassified based on their timestamp rather than their arrival order. So, you lose the chronological order of actions, and searching through logs will be nearly impossible, with the typical impacts on audits.

Is logging NTP logs useful and would it help reconstruct the order of actions? Yes… and no.

  • Yes: Logging NTP logs is useful, and you should pay attention to events like “NTP synchronization failed” because they can indicate a compromise of your NTP servers or a desynchronization of your devices.

  • No: Logging NTP logs will not help you reconstruct the order of events. The problem is that the timestamp of the log will be the timestamp of the switch once it is updated by NTP. If it’s April 4, 2025, and a rogue NTP server changes your switch’s time to March 4, 2025, your “NTP synchronization succeeded” log will be dated March 4, 2025.

What about certificates ?

Certificates can expire prematurely if your attacker has decided to place your switch in the future. Or they may not be valid yet if they’ve placed it in the past before the certificate’s validity date.

Even better, by modifying the time to the past, you can “revalidate” an expired certificate and continue using it.

Other impacts?

There can be many impacts on servers, particularly for Kerberos and DNSSEC, which will also stop working.

Regarding DNS, although it’s convenient to use domain names for NTP servers, be cautious about name resolution with unsynchronized devices. If your device is not on time, DNSSEC will not work, so you won’t be able to resolve the DNS to get the IP address of your NTP server, thus you won’t be able to reach it for an update, and your DNSSEC will fail, and you won’t be able to update…

I recommend not having dependencies between your critical services.

I recommend not having dependencies between your critical services.

Your NTP should work at all times, even without DNS. Just like your Radius, TACACS, OCSP servers, etc.

How to Protect Yourself?

The attack above was possible under certain conditions: we were in the same subnet as the target, ARP spoofing was possible, and there was no NTP authentication. The first two points are general security concerns beyond the scope of this article, so we will focus only on NTP authentication.

NTP Authentication

You can authenticate your NTP packets using a symmetric key between the client and the server. This key will be used to calculate the “digest” of the NTP packets (the Message Authentication Code or MAC), which will be added to the end of each packet. When an NTP packet is received, both on the server and on the switch, the MAC is recalculated using the local key. If it matches the one in the packet, it means the same key was used when the packet was sent, so the packet is authenticated.

In our example, let’s implement NTP packet authentication with SHA1.

In chronyd, you simply need to create a chrony.keys file with our key, specifying the hash algorithm used, and restart the chronyd daemon. In our example, we use key ID 100, the SHA1 hash algorithm, and the key “ntp.”

echo "100 SHA1 ntp" >> /etc/chrony/chrony.keys
systemctl restart chronyd

On the switch, you need to create the key and bind it to the NTP server. You can have different keys for different servers.

ntp authentication-key 100 type sha1
ntp
ntp
ntp server 192.168.234.47 authentication-key 100
ntp server 192.168.234.47 auth-enable

A show ntp statistics command now indicates that authentication is enabled (Auth Enabled: Enabled).

In Wireshark, we now see that the NTP packets are 114 bytes long instead of 90 without authentication.

The key ID (100 in decimal, 64 in hexadecimal) and the MAC are present at the end of each packet.

If we try to spoof our NTP server, our responses will not be accepted by the switch. Indeed, we don’t know the key on our attacking server. Even if we intercept the requests and responses, the MAC is calculated based on the key and the fields of the packet. Since we modify the packets to change the time but cannot modify the MAC, when the switch receives a tampered packet, it recalculates the MAC and sees that it does not match. Therefore, the response will be ignored, and the switch will not update its clock.

Below is the legitimate response from the NTP server that we intercepted.

And here’s the response we send back to the client.

The MAC is the same (last field of the packet), while the timestamps have changed. Since we cannot recalculate the MAC without the key, we retain the one sent by the server and send this response to the client.

On the client side, this packet is simply ignored because the MAC doesn’t match. Therefore, our spoofing has no impact.

What not to do ?

Synchronize directly to external servers

You don’t control these servers or their security, and if all your devices sync externally, you unnecessarily increase your Internet bandwidth usage. Using different external servers may result in slight time differences across your devices.

Synchronize with multiple internal sources...

…without making sure they are synchronized with each other! You risk having log correlation issues if your devices are synced with servers that have slight time discrepancies.

What to do ?

Ensure the security of your servers

  1. Sync your servers with each other and from reliable external sources, or from your own reference clocks if possible.
  2. Configure NTP authentication, or better yet, NTS.Set a maximum drift on your servers to prevent them from deviating too far from the initial time.
  3. Only accept NTP requests from your devices.

ARP inspection

This attack would have been impossible if the switch had been properly configured with ARP inspection.

Check your logs

 Don’t neglect an “NTP synchronization failed” log.

Conclusion

NTP alone is no longer sufficient. If certain prerequisites are met, an attacker can alter your equipment’s clock to conceal their tracks or make them inaccessible. In a financial context, a desynchronized device can be used for fraud, and in an industrial context, production lines can be affected by desynchronized equipment.

The minimum requirement is to add authentication to NTP as we’ve seen above, or use NTS on compatible devices (currently, only Juniper switches seem to be compatible) which fully encrypt NTP communications using asymmetric keys.

Finally, if NTP is not accurate enough for your needs, PTP (Precision Time Protocol) is an alternative supported by most switch manufacturers, offering nanosecond-level precision.

Contact us to find out how to implement these features.

Follow us on LinkedIn to see our next videos.

Sources