In an era where our critical infrastructures increasingly rely on precise time and space, security implications of GPS systems have become a concerning aspect of their stability.

GNSS: Exploring Vulnerabilities and Attack Surfaces

Global Navigation Satellite System (GNSS) signals, of which Global Positioning System (GPS) is one of the “constellations”, are widely used to determine the position of a receiving antenna, as well as the time to the nearest nanosecond, which is more precise than Network Time Protocol (NTP).

Although the majority of systems dependent on GNSS signals may not experience critical impacts in the event of an attack, the consequences on certain systems can be potentially catastrophic. For example, the war in Ukraine is affected by massive jamming attacks, affecting military logistics and the use of drones, both relying on a precise localization to work. Also, impersonation (commonly called spoofing) attacks can reroute ships or airplanes, causing delays and increasing the probability of collisions.

This article being part of a series on the topic, the aim of this one is to give the reader the knowledge I wish I had at the beginning while testing such devices. This basic knowledge subdivides into the attack surface of GNSS systems and the signal peculiarities making GNSS constellations so unique.

The Attack Surface

First, to understand how a system relying on GNSS signals can be attacked and protected, it is important to clarify the elements that constitute its system. To do so, each elements presented below have a role to play in protecting the system and work in a similar way as the Open Systems (OSI) model, from the physical to the application layer. This means that even if you buy a solution, you are still responsible for its configuration as well as the way you integrate it to your infrastructure.

1) Antenna

The antenna is the first node of the system and can already detect or prevent attacks. Thanks to geometric peculiarities, it can detect if signals are coming from the sky or from the land and even attenuate signals coming from the land to prevent jamming attacks.

2) GNSS demodulation and decoding module

The GNSS module is responsible to demodulate and decode the GNSS data and to make the appropriate calculations in order to give the position and time of the receiver. At this level, signal characteristics like signal to noise ratio or signal phase are gathered and can be used for raw analysis on the hardware with various masks. This signal metadata can also be analyzed at the next levels. An example of decoding module is Ublox MAX-M10S or bu353-s4.

3) GNSS interpretation service

The data is then sent to a service or software through a digital protocol. Most of the time, this protocol is National Marine Electronics Association (NMEA), which is not encrypted. This layer can also analyze various characteristics of the signal along with the processed data and detect spoofing attacks with the help of algorithms. GPSD on Linus would be an example of an interpretation service.

4) Service relying on GNSS data

Finally, the last node of the system is the service relying on the information of position or time. It could be a geolocation service like Google maps, or a NTP server. At this level, fallback mitigations are important to understand and implement, according to the criticality and the level of access needed for that final node. In other words, it will determine if there is another source of positioning or timing information that the system should use if GNSS data is momentarily unusable.

Understanding the role of these layers helps tailoring a successful attack against a whole system or, from the defensive perspective, understand the responsibility of each layer in mitigating such attacks.

Figure 1 : Simple GNSS system

Signal Peculiarities

Even if GNSS signals are not encrypted nor authenticated, it can still be a challenge to impersonate them. For this reason, orbital positioning and availability of constellations are two signal peculiarities important to understand from an offensive standpoint. For defense and risk analysis, it gives an overview of constraints malicious actors must deal with when targeting GNSS systems.

Orbital Positioning

The first peculiarity of GNSS signals to understand for intrusion testing is that it needs orbital positioning of available satellites (called ephemeris data or almanac). The incoming signal at the receiver level is weak and several signals are carried on the same frequency. This means that, without signal processing, the GNSS signals appear to be below the noise floor and cannot be read directly. To successfully retrieve GNSS data, a signal processing technique called Cross-Correlation is used. The outcome of this technique is to make the data of one satellite appear above the noise floor after signal processing. For such a method to work, a signal sent by the satellites must be played at the same time inside the receiver. This signal, called Pseudo Random Noise or Golden Code, is unique to each satellite. Note that even if called Pseudo Random Noise, it doesn’t have any cryptographic meaning, it is a synchronization mechanism. Both the sender and receiver must know this code beforehand, which is made possible by the almanac.

Figure 1 below illustrates the technique at a high level. At the top of the figure, there is no correlation between the receiver that plays the signal internally and the signal received from the satellite. Therefore, it is impossible to capture the GNSS signal. But the bottom of the image illustrates the correlation of the signal from the satellite and the receiver, which makes the signal stand out from the noise.

Figure 2 : Cross-Correlation signal processing technique (

Figure 2 below shows the impact of the correlation. The B chart slides on the A chart until there is alignment, which produces the peak that stands out from the noise, as observed on the cross correlation of incoming SV signal (third diagram of Figure 2).

Figure 3 : The Correlation (

To decode GNSS signals, a receiver needs to know where and which satellite signal to parse from the noise with the right Pseudo Random Noise. To do so, the GNSS receiver module get this information from the almanac, which is either downloaded from a server or transmitted by all satellites.

The implication of this on an intrusion test is two-fold. The first impact is that when simulating GNSS signal, you need the almanac data to properly generate your signal.

The second impact is that in some cases, a tester might want to provoke a state change of the GNSS receiver module to successfully spoof a signal. This can be done with a jamming signal. This state change will alter the GNSS fixing process and gives the tester a window of opportunity in which he can spoof and even bypass some defense mechanisms.

Choosing the Signals to Trust

The second peculiarity of GNSS signals is that there are many satellite “constellations”. GPS, GALILEO or GLONAS are one of them. This enables for error correction, redundancy, and resiliency to various attacks. To provide an accurate time and position, the receiver must consider a set of valid signals to trust among all available ones. These are composed of various groups like GPS for the United States or Galileo for the European Union, among a few others. These groups of satellites transmit on and with various length and speed of pseudo random noise. These characteristics make them more or less resistant to jamming and spoofing. With GPS for example, these frequencies are categorized by L1, L2 and… L5. L3 and L4 are simply not used for civilian and positioning purposes. Since L1 contains most legacy GPS technologies and L2 to L5 are the most recent, the L1 signals may be more interesting to target.

The implication of this on an intrusion test is that depending on what link (L1, L2 or L5) and constellations your target receiver is configured to follow (GPS, GALILEO or others), to make a successful attack, you might have to jam the frequencies and constellations you will not spoof. In fact, if you don’t, the receiver will probably not trust your signal, but it also raises the chances to trigger defense mechanisms like spoofing detection.


Understanding how GPS (and by extension GNSS) communication work is crucial for both defense and offence. This knowledge let an organization understand what layer of this subsystem it has control on, leading to an efficient risk assessment of the whole systems relying on GNSS signals. Note that the use of software defined radios (SDR) are increasingly common and accessible, both in terms of technology and know-how. Even though it is lowering the barrier on entry for simple jamming and spoofing attacks from malicious hackers, it also enables professionals to contribute to the development of more resilient systems.

In this article, we have seen that on a system relying on GNSS signals there are multiple layers of responsibility for which defense mechanisms can be implemented. This is analogous to the OSI model in traditional networking. As such, this represents the whole attack surface of GNSS systems. Security must be carefully evaluated at all layers and mitigation, or monitoring applied to minimize risks which are context dependent.

Additionally, we have seen two fundamental peculiarities of GNSS signals that are crucial to understand from an attacker’s perspective. The first one is how the signal can be seen above the noise floor and trusted, thanks to the almanac. The second one being how more than one constellation operates on more than one carrier frequency gives resiliency to the system and makes it harder for an attacker to successfully spoof a signal.

In a follow-up blog article, examples of spoofing attacks with signal isolation will be shown and defense strategies will be discussed. Stay tuned!

GoSecure Titan® Managed Extended Detection & Response (MXDR)​

GoSecure Titan® Managed Extended Detection & Response (MXDR)​ Foundation

GoSecure Titan® Vulnerability Management as a Service (VMaaS)

GoSecure Titan® Managed Security Information & Event Monitoring (SIEM)

GoSecure Titan® Managed Perimeter Defense​ (MPD)

GoSecure Titan® Inbox Detection and Response (IDR)

GoSecure Titan® Secure Email Gateway (SEG)

GoSecure Titan® Threat Modeler

GoSecure Titan® Identity

GoSecure Titan® Platform

GoSecure Professional Security Services

Incident Response Services

Security Maturity Assessment

Privacy Services

PCI DSS Services

Penetration Testing Services​

Security Operations


GoSecure MXDR for Microsoft

Comprehensive visibility and response within your Microsoft security environment


Cyber Risks

Risk-Based Security Measures

Sensitive Data Security

Safeguard sensitive information

Private Equity Firms

Make informed decisions

Cybersecurity Compliance

Fulfill regulatory obligations

Cyber Insurance

A valuable risk management strategy


Combat ransomware with innovative security

Zero-Day Attacks

Halt zero-day exploits with advanced protection

Consolidate, Evolve & Thrive

Get ahead and win the race with the GoSecure Titan® Platform


GoSecure Titan® Endpoint Detection and Response (EDR)

GoSecure Titan® Next Generation Antivirus (NGAV)

GoSecure Titan® Network Detection and Response (NDR)

GoSecure Titan® Inbox Detection and Reponse (IDR)

GoSecure Titan® Intelligence


GoSecure is a recognized cybersecurity leader and innovator, pioneering the integration of endpoint, network, and email threat detection into a single Managed Extended Detection and Response (MXDR) service. For over 20 years, GoSecure has been helping customers better understand their security gaps and improve their organizational risk and security maturity through MXDR and Professional Services solutions delivered by one of the most trusted and skilled teams in the industry.


May 21 ITSec




 24/7 Emergency – (888)-287-5858