This paper investigates whether large-scale GNSS spoofing activity can be inferred from maritime Automatic Identification System (AIS) position reports. A data-processing framework, called SeaSpoofFinder, available here: seaspooffinder.github.io/ais_data, was developed to ingest and post-process global AIS streams and to detect candidate anomalies through a two-stage procedure. In Stage 1, implausible position jumps are identified using kinematic and data-quality filters; in Stage 2, events are retained only when multiple vessels exhibit spatially consistent source and target clustering, thereby reducing false positives from single-vessel artifacts. The resulting final potential spoofing events (FPSEs) reveal recurrent patterns in several regions, including the Baltic Sea, the Black Sea, Murmansk, Moscow, and the Haifa area, with affected footprints that can span large maritime areas. The analysis also highlights recurring non-spoofing artifacts (e.g., back-to-port jumps and data gaps) that can still pass heuristic filters in dense traffic regions. These results indicate that AIS-based monitoring can provide useful evidence for identifying and characterizing potential spoofing activity at scale, while emphasizing that AIS-only evidence does not provide definitive attribution.
The spoofing threat has been recognized in the GNSS community for more than two decades [1], [2], and operational manifestations have increased in recent years [3]. A number of large scale monitoring applications have previously been published that utilize the widely available ADS-B data used in the aviation sector [4]- [6].
For maritime users, a comparable source is the Automatic Identification System (AIS), which distributes vessel reports in near real time through terrestrial receiving stations and satellite links.
This work analyzes AIS position reports to identify patterns consistent with potential GNSS spoofing. AIS data alone cannot provide definitive attribution; however, characteristic spatial and temporal signatures can still be detected. In some regions, independent field observations have also been reported e.g., in the Kaliningrad area [7]- [9].
To support this analysis, a prototype software tool was developed to collect, store, and post-process AIS network data.
The results indicate recurrent patterns consistent with large-scale spoofing activity in several regions, including the Baltic Sea (Kaliningrad and St. Petersburg), Murmansk, the Black Sea, and the eastern Mediterranean.
The presented results remain preliminary and include events that are difficult to classify. For example, in and around Amsterdam, Stockholm and Fort Lauderdale, FL, and other locations, the heuristics also flag events that may correspond to non-spoofing data artifacts.
A software tool, SeaSpoofFinder, was developed to capture and log AIS data (see Fig. 1). Subsequently, the heuristics described below are applied to identify potential spoofing events. AIS data have been collected continuously since mid-December 2025 until the time of this writing (mid February 2026). The data are processed in user-selectable batches of 1 or 3 days, and a date selector enables temporal navigation. Detected potential spoofing events are visualized in a 3D global view. The interface displays both potential spoofing events (PSEs) and final potential spoofing events (FPSEs). For vessels associated with FPSE detections, full trajectories are recorded and displayed. In predefined areas of interest (red rectangles in Fig. 1), heatmaps of overall vessel traffic are generated.
SeaSpoofFinder is publicly available at seaspooffinder. github.io/ais data and is planned to remain accessible at least through June 2026. During this period, the data are updated daily. The tool is provided as-is and was developed as part of a small informal study; accordingly, it should not be considered a commercial-grade system.
The primary dynamic information broadcast by AISequipped vessels is conveyed in the position report messages (Messages 1, 2, and 3) as specified in Recommendation ITU-R M.1371-5, § 3.1 [10]. These reports are transmitted periodically and provide, among others, the vessel identifier or the Maritime Mobile Service Identity (MMSI), navigation status, speed and course over ground, as well as the GNSS-derived position (latitude/longitude) with associated integrity and timing indicators. The payload for Messages 1-3 comprises 168 bits, where the key fields used in our analysis are summarized in Table I.
The UTC time-stamp field provides only the second within the minute (0-59). Values up to 63 are reserved for special conditions. This field is primarily used by the TDMA access scheme between vessels and receiving stations and does not represent a precise reception-time reference for this study.
AIS data is typically received by shore stations, aggregated, and redistributed through commercial and open providers. Some providers apply plausibility filtering, which can remove anomalies of interest. For this study, an as-unfiltered-as-possible feed was preferred.
The provider used for our study is aisstream.io [11]. After applying for an API key, the data stream can be accessed via TCP/IP. The AIS data provided by aisstream.io is obtained from a network of global landbased stations with a typical signal range of approximately 200 km. Coverage varies with environmental conditions and topography, and global coverage is not
Inferring spoofing from large AIS position streams is non-trivial and inherently uncertain. A simple pairwise jump detector between consecutive positions yields a large number of apparent “jumping” vessels in raw data.
Closer inspection indicates that some records use nonunique or placeholder MMSIs, although MMSI is nominally unique. These values frequently end with “000000” or “999999” and may be associated with generic labels (e.g., “FRENCH WARSHIP” or “NATO SHIP”). Such records are excluded.
We also observe jumps that are almost entirely aligned with longitude or latitude. These may arise from bitlevel decoding or transmission errors in one coordinate component; therefore, they are filtered conservatively.
The detection logic is implemented in two stages. Stage 1 applies a set of necessary tests; all must be satisfied for
This content is AI-processed based on open access ArXiv data.