{"id":55626,"date":"2024-03-19T16:52:54","date_gmt":"2024-03-19T16:52:54","guid":{"rendered":"https:\/\/packetstormsecurity.com\/news\/view\/35673\/How-Rogue-ISPs-Tamper-With-Geofeeds.html"},"modified":"2024-03-19T16:52:54","modified_gmt":"2024-03-19T16:52:54","slug":"how-rogue-isps-tamper-with-geofeeds","status":"publish","type":"post","link":"https:\/\/www.threatshub.org\/blog\/how-rogue-isps-tamper-with-geofeeds\/","title":{"rendered":"How Rogue ISPs Tamper With Geofeeds"},"content":{"rendered":"
\n
\n
\n
\n
\n
\n
<\/p>\n
\n
\n
\n
\"DCSO<\/div>\n<\/div>\n<\/div>\n<\/div>\n

<\/a><\/div>\n<\/div>\n

\n
<\/p>\n
<\/p>\n
11 min read<\/span><\/p>\n

\u00b7<\/span><\/span><\/p>\n

2 hours ago<\/p><\/div>\n

<\/span><\/div>\n

<\/span><\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n

Precise geolocation information for IP addresses has emerged from a niche requirement to a ubiquitous demand. While the country an IP address is (allegedly) related to has long been used for applications such as network traffic distribution and coarse geoblocking, today, state-, city- and sometimes even district-level geolocation information is crucial for modern security measures, such as fraud detection. Data brokers, advertisers, defenders, and investigators alike are interested in having precise and up-to-date information on the physical<\/em> location of an IP address at their disposal. The demand for such information has nurtured an entire industry, with US-based vendor MaxMind<\/a> probably being the most commonly referred to source for geolocation information.<\/p>\n

\n
\n
<\/picture><\/div>\n<\/div>
Photo by GeoJango Maps<\/a> on Unsplash<\/a><\/figcaption><\/figure>\n

However, a steady demand in geolocation information beyond a country-level has incentivized efforts to allow ISPs to propagate such information independently, perhaps further driven by MaxMind\u2019s EULA changes for its free GeoLite2 databases in 2019<\/a>, which has caused problems particularly<\/a> among<\/a> the open-source community.<\/p>\n

A result of this development is IP Geolocation Feeds, commonly abbreviated as \u201cgeofeeds.\u201d By publishing these, ISPs can ensure that geolocation database vendors, among others, are more likely to learn about and subsequently return correct information for the IP networks under an ISP\u2019s control.<\/p>\n

Unfortunately, threat actors are leveraging geofeeds as well, and have been observed publishing forged information, presumably with the objective of circumventing access control measures (such as country-level geoblocking) and hampering investigations. This blog post strives to shed light on a particularly noteworthy example, which also serves as a case study for discussing the viability of geofeeds as OSINT pivot points. Furthermore, countermeasures for defenders and investigators are suggested.<\/p>\n

Blog post authored by <\/em>DCSO CSIRT\/Threat Research Team<\/em><\/a>.<\/em><\/p>\n

A Primer On Geofeeds<\/h2>\n

Specified in RFC 8805<\/a>, IP Geolocation Feeds \u2014 commonly abbreviated as \u201cgeofeeds\u201d \u2014 allow ISPs to distribute information on the physical location of IP networks, consisting of country, region\/state, city, and ZIP code. Such information can then be parsed and (comparatively) easily included in geolocation databases for improved accuracy. A separate internet standard, RFC 9092<\/a>, discusses how to discover and verify geofeeds at scale in a structured fashion, such as in Regional Internet Registry (RIR) databases.<\/p>\n

It is worth noting that RIR databases have long allowed the allocation of a country to IP network and Autonomous System (AS) objects, as the following example from the RIPE<\/a> database shows:<\/p>\n

inetnum: 185.183.126.0 - 185.183.126.255
netname: Infrastructure
country: DE
admin-c: DCSO-RIPE
tech-c: DCSO-RIPE
status: LIR-PARTITIONED PA
mnt-by: DCSO-MNT
created: 2020-08-28T08:45:53Z
last-modified: 2020-08-28T08:45:53Z
source: RIPE<\/span><\/pre>\n
However, it may not always be clear whether the \u201ccountry\u201d database field refers to the country a network is physically<\/em> located in, or the jurisdiction<\/em> that applies to it. (Both are Germany in the above example.) Consequently, many geolocation database vendors who incorporate country-level information from RIR databases abstain from clarifying this aspect as well, which often causes geolocation database users to be overly confident in the understanding of database outputs.<\/p>\n
Aside from that, RIR database schemes commonly do not allow for the machine-digestible publication of more precise geolocation information, such as the involved state or city. Assessing these by examining routing information, network latency triangulation, and other technical measures is often, but not always, feasible and is considerably more resource-intensive than parsing geofeeds and alike databases. While advertising and tracking networks may be able to correlate IPs with precise geolocation information made available from end-user devices (i.e., through GPS sensors and WiFi network mapping), collecting such information is a rather privacy-invasive measure.<\/p>\n
An arbitrary example of a geofeed reference in RIR databases may look like this (note the \u201cgeoloc\u201d field<\/a>, which \u2014 unrelated to geofeeds \u2014 contains geographic coordinates on the physical location of this IP network):<\/p>\n
inetnum: 5.149.224.0 - 5.149.239.255
netname: DE-R-KOM-20120717
country: DE
geoloc: 49.014042 12.127519
geofeed: https:\/\/geofeed.r-kom.de\/geofeed.csv
org: ORG-RA3-RIPE
admin-c: RKOM-RIPE
tech-c: RKOM-RIPE
status: ALLOCATED PA
mnt-by: RKOM-MNT
mnt-by: RIPE-NCC-HM-MNT
created: 2019-12-20T12:47:47Z
last-modified: 2022-10-20T06:04:14Z
source: RIPE<\/span><\/pre>\n
The CSV file will then contain further information, such as in this case:<\/p>\n
5.149.224.0\/20,DE,DE-BY,Regensburg,<\/span><\/pre>\n
This allows geolocation database vendors to easily locate 5.149.224.0\/20 in the city of Regensburg, Bavaria, Germany. At the time of writing, DCSO has no reason to question this particular geolocation information.<\/p>\n
Eygelshoven, Edison, or Paris? \u2014 A Case Study<\/h2>\n
However, not all geofeed use-cases are this benign, as the case of AS203168 (allocated to \u201cConstant MOULIN\u201d) shows: at the time of writing, five out of six IPv4 prefixes announced by this AS contain geofeed information, such as:<\/p>\n
inetnum: 45.88.90.0 - 45.88.90.255
netname: CONSTANTMOULIN
descr: Constantmoulin
org: ORG-CM304-RIPE
country: FR
geofeed: https:\/\/raw.githubusercontent.com\/geofeeds\/geofeed\/main\/geofeed.csv
admin-c: ACRO54823-RIPE
tech-c: ACRO54823-RIPE
abuse-c: ACRO54823-RIPE
mnt-lower: personal-ip-mnt
mnt-routes: personal-ip-mnt
mnt-domains: personal-ip-mnt
status: ASSIGNED PA
mnt-by: MNT-NETERRA
created: 2024-02-09T14:35:37Z
last-modified: 2024-03-05T10:17:23Z
source: RIPE<\/span><\/pre>\n
This geofeed URL, at the time of writing, returns:<\/p>\n
193.222.96.0\/24,NL,NL-LI,Eygelshoven,
87.120.84.0\/24,US,US-NJ,Edison,
45.128.96.0\/24,US,US-NJ,Edison,
45.88.90.0\/24,FR,FR-75,Paris,
194.48.251.0\/24,FR,FR-75,Paris,<\/span><\/pre>\n
This suggests that 45.88.90[.]0\/24 is physically located in or near Paris, France. Indeed, global routing information and network latency triangulation efforts carried out by DCSO corroborate this information.<\/p>\n
However, this assessment does not hold true for all entries of this geofeed, particularly not for 45.128.96[.]0\/24 and 87.120.84[.]0\/24, both allegedly located in or near Edison, New Jersey, USA. Firstly, it is noteworthy that the RIPE database objects for both networks list \u201cFR\u201d (France) as the country code (both output have been trimmed for brevity reasons):<\/p>\n
inetnum: 45.128.96.0 - 45.128.96.255
netname: CONSTANTMOULIN
descr: Constantmoulin
geofeed: https:\/\/raw.githubusercontent.com\/geofeeds\/geofeed\/main\/geofeed.csv
country: FR
<snip><\/span><\/pre>\n
inetnum: 87.120.84.0 - 87.120.84.255
netname: BG-NETERRAIP-20050712
country: FR
org: ORG-NL38-RIPE
admin-c: ACRO54823-RIPE
tech-c: ACRO54823-RIPE
abuse-c: ACRO54823-RIPE
status: ALLOCATED PA
geofeed: https:\/\/raw.githubusercontent.com\/geofeeds\/geofeed\/main\/geofeed.csv
<snip><\/span><\/pre>\n
However, as mentioned above, the \u201ccountry\u201d could also refer to the jurisdiction that applies to these networks\u2014which would prompt questions as well, given that the postal addresses provided for AS203168 in general and both networks in particular refer to Dinant, a Belgian province.<\/p>\n
At the time of writing, 45.128.96[.]0\/24 is routed via AS49581 (\u201cFerdinand Zink trading as Tube-Hosting,\u201d according to the RIPE database), an ISP offering<\/a> VPS, VDS, and colocation services in the SkyLink datacenter<\/a>, located in Eygelshoven, the Netherlands. DCSO was unable to discover any presence of this ISP in the USA; indeed, the following router appearing in traceroute outputs for this network corroborates the hypothesis of this \/24 being located in Eygelshoven. However, it is worth noting that \u201cEGH\u201d does not appear to be the IATA<\/a> or UN\/LOCODE<\/a> code allocated to Eygelshoven (both IATA and UN\/LOCODE are frequently used for referring to physical locations).<\/p>\n
ae4.1129-1.cr1.egh.as49581.net (80.91.223.18)<\/span><\/pre>\n
BGP routing information for this \/24 also contain SkyLink\u2019s AS (AS44592), further corroborating DCSO\u2019s aforementioned hypothesis that this network is neither physically located in France (according to its RIPE database record) nor in the USA (according to its geofeed):<\/p>\n
45.128.96.0\/24 4608 7575 199524 44592 49581 203168 203168<\/span><\/pre>\n
As far as 87.120.84[.]0\/24 is concerned, it appears to be routed via AS399486 (12651980 CANADA INC.) at the time of writing. According to its website<\/a>, this ISP offers dedicated server and colocation offerings in data center facilities in Montreal, Canada, as well as Edison, USA. However, DCSO was unable to conclusively assess in which of these facilities 87.120.84[.]0\/24 is physically located, and it remains unclear why the network\u2019s RIPE database object lists France in its \u201ccountry\u201d attribute.<\/p>\n
It is worth mentioning that all prefixes announced by AS203168, as well as the Autonomous System itself, are listed in Spamhaus DROP lists<\/a> at the time of writing, suggesting a poor reputation of this ISP:<\/p>\n
\n
The Spamhaus DROP lists consist of netblocks that are leased or stolen by professional spam or cyber-crime operations, and used for dissemination of malware, trojan downloaders, botnet controllers, or other kinds of malicious activity.<\/p>\n<\/blockquote>\n
DCSO was unable to discover a website publicly mentioning services hosted by AS203168, which leads to the suspicion that this ISP does not advertise and sell its services through public-facing websites. 194.33.191[.]0\/24, a prefix currently announced by this Autonomous System, was previously in use by AS211252, allocated to Delis LLC<\/a>, a now-defunct bulletproof<\/a> hoster<\/a> operating out of a data center owned by Dutch ISP Serverion BV.<\/p>\n
According to news<\/a> reporting<\/a>, the aforementioned SkyLink data center has previously come under scrutiny by Dutch law enforcement authorities in conjunction with illegal IPTV streaming, culminating in a raid carried out by the Netherlands\u2019 fiscal intelligence unit (FIOD) on March 23, 2023.<\/p>\n
OSINT Pivot Potential of Geofeeds<\/h2>\n
It is well understood that, from an OSINT perspective, any kind of database whose edit history can be publicly retrieved \u2014 which often is the case for RIR databases \u2014 has the potential of holding a wealth of information suitable for enabling or proliferating investigations.<\/p>\n
In the case of geofeeds, this may also apply to the content of the geofeed itself, particularly if it is provided via a source code repository. In the case of AS203168, combining both historical RIPE database information and metadata retrieved from the involved Git repositories unveils further information on entities associated with or controlling AS203168.<\/p>\n
First, historical versions of RIPE database objects of the involved prefixes contain different geofeed URLs (output trimmed for brevity):<\/p>\n
inetnum: 45.88.90.0 - 45.88.90.255
netname: CONSTANTMOULIN
descr: Constantmoulin
org: ORG-CM304-RIPE
country: FR
geofeed: https:\/\/raw.githubusercontent.com\/pfcloud-io\/geofeed\/main\/geofeed.csv
<snip><\/span><\/pre>\n
This suggests a certain degree of involvement by German Pfcloud UG<\/a> in the operation of AS203168. On the same day when the RIPE database object for 45.88.90[.]0\/24 was last updated to include aforementioned, more unobtrusive geofeed URL (March 5, 2024), a variety of networks were deleted via a Git commit<\/a> in the geofeed GitHub repository<\/a> that Pfcloud maintains.<\/p>\n
commit 22722a610a1ecc6548cb0b539aca5c5d77fe9e72 (HEAD -> main, origin\/main, origin\/HEAD)
Author: TeamAggro (~Steve) <49125036+TeamAggroDEV@users.noreply.github.com>
Date: Tue Mar 5 09:56:26 2024 +0100
Update geofeed.csv<\/p>
diff --git a\/geofeed.csv b\/geofeed.csv
index 7de625e..d6aaf67 100644
--- a\/geofeed.csv
+++ b\/geofeed.csv
@@ -8,10 +8,6 @@
147.78.102.0\/24,NL,NL-LI,Eygelshoven,
87.121.69.0\/24,GB,GB-LND,London,
87.121.58.0\/24,NL,NL-LI,Eygelshoven,
-193.222.96.0\/24,NL,NL-LI,Eygelshoven,
-87.120.84.0\/24,US,US-NJ,Edison,
-45.128.96.0\/24,US,US-NJ,Edison,
-45.88.90.0\/24,FR,FR-75,Paris,
2a05:b0c6:a000::\/39,US,US-AZ,Phoenix,
2a05:b0c6:a200::\/39,DE,DE-BE,Berlin,
2a05:b0c6:a400::\/39,GB,GB-LND,London,<\/p><\/span><\/pre>\n
A Git commit<\/a> made to the \u201cgeofeeds\u201d GitHub repository<\/a> only 34 seconds prior not only includes all four IPv4 networks that were deleted from Pfcloud\u2019s GitHub repository, but also lists the same author, \u201cTeamAggro (~Steve)\u201d. DCSO assesses that this likely is a reference to a Hull, UK-based company named Aggros Operations Ltd.<\/a>, which surfaced in historical RIPE database records for prefixes announced by AS203168, as does a RIPE handle allocated to Pfcloud (\u201cpfcloud-mnt\u201d).<\/p>\n
Noteworthy, the timestamp of both Git commits lists \u201c+0100\u201d as a timezone, which (weakly) indicates the involved computer\u2019s clock being aligned to Central European Time (CET) rather than Greenwich Mean Time (GMT), which would be used by UK-based systems. The British Summer Time (BST), which would also result in \u201c+0100\u201d, only commences on March 31 in 2024, several weeks after the Git commits have taken place.<\/p>\n
commit 358614d3c919471d8bba6ce31f9f9583bda3adba (HEAD -> main, origin\/main, origin\/HEAD)
Author: TeamAggro (~Steve) <49125036+TeamAggroDEV@users.noreply.github.com>
Date: Tue Mar 5 09:55:52 2024 +0100
Create geofeed.csv<\/p>
diff --git a\/geofeed.csv b\/geofeed.csv
new file mode 100644
index 0000000..63ec36f
--- \/dev\/null
+++ b\/geofeed.csv
@@ -0,0 +1,5 @@
+193.222.96.0\/24,NL,NL-LI,Eygelshoven,
+87.120.84.0\/24,US,US-NJ,Edison,
+45.128.96.0\/24,US,US-NJ,Edison,
+45.88.90.0\/24,FR,FR-75,Paris,
+194.48.251.0\/24,FR,FR-75,Paris,<\/p><\/span><\/pre>\n

inetnum: 45.88.90.0 - 45.88.90.255
netname: CONSTANTMOULIN
descr: Constantmoulin
org: ORG-CM304-RIPE
country: FR
geofeed: https:\/\/raw.githubusercontent.com\/pfcloud-io\/geofeed\/main\/geofeed.csv
admin-c: AA39986-RIPE
tech-c: AA39986-RIPE
mnt-lower: aggrosoperations-mnt
mnt-routes: aggrosoperations-mnt
mnt-domains: aggrosoperations-mnt
status: ASSIGNED PA
mnt-by: MNT-NETERRA
created: 2024-02-09T14:35:37Z
last-modified: 2024-02-09T14:35:37Z
source: RIPE
organisation: ORG-CM304-RIPE
org-name: Constant MOULIN
country: BE
org-type: OTHER
address: RUE SAINT-JACQUES 108\/3 5500 DINANT
abuse-c: ACRO54823-RIPE
mnt-ref: mnt-fr-scalynet-1
mnt-ref: mnt-neterra
created: 2022-08-23T16:10:16Z
last-modified: 2023-12-19T10:27:14Z
source: RIPE # Filtered
mnt-by: mnt-fr-scalynet-1
mnt-by: be-constantmoulin-mnt<\/p>
role: Administration
address: Aggros Operations Ltd, c\/o COCENTER, Koppoldstr. 1, 86551 Aichach, Germany
nic-hdl: AA39986-RIPE
mnt-by: aggrosoperations-mnt
created: 2022-09-25T15:51:13Z
last-modified: 2023-01-27T17:05:24Z
source: RIPE # Filtered<\/p>
% Information related to '45.88.90.0\/24AS203168'<\/p>
route: 45.88.90.0\/24
origin: AS203168
created: 2024-02-10T12:33:50Z
last-modified: 2024-02-10T12:33:50Z
source: RIPE
mnt-by: pfcloud-mnt<\/p><\/span><\/pre>\n
In this case, the geofeed URL is suitable for usage as an OSINT pivot point and resembles a crucial information breadcrumb for linking Pfcloud UG and Aggros Operations Ltd. to each other and to the operational aspects of AS203168.<\/p>\n
Similar to other investigative use-cases, GitHub repositories used for geofeed URL hosting may allow detailed insights into the history of an ISP, (alleged) physical facilities used by it, related personas or GitHub accounts, OpSec mistakes made by involved entities, and attempts to cover up such mistakes.<\/p>\n
Potential Risks Induced By Geofeed Processing<\/h2>\n
In contrast to RIR databases, geofeed URLs carry several potential risks that geolocation database vendors and investigators alike may wish to keep in mind:<\/p>\n