Hi Folks, This is a new one for me. One of my AS numbers (AS27421) appears to be being used by someone in Brazil. We haven't seen any actual effects of the hijack -- that is, we don't appear to be losing any traffic. The only reason we noticed is because it's being reported on HE's BGP monitoring site. I've reached out to the abuse contact for the AS's the hijacker is peering with (AS1000, AS271253 - same abuse contact for both) several times and gotten no response. Though, looking at which prefixes AS271253 is originating, it doesn't appear this AS cares much about proper behavior. If anyone has any advice on next steps, it would be appreciated. Thanks, Matt
The u-del folk (as2?) have some fun stories about this sort of problem :( I think they've even done at least 1 nanog talk about this? There's also a long history of 'bad actors' using ASN at IX's (amsix and u-new-mexico I recall for us in the past) in order to make it seem like legit sources were sending traffic to places. "Gosh, I don't THINK UNM has a network out to AMS do they? that seems sus (as the kids say these days)" The impact you might see is non-reachability to things they announce? and/or them not being able to access your announced resources :( Also, people on the intertubes are going to be made about your 'bad behaviors' coming out of brazil :( Its likely that the 2/1 abuse contacts you reached out to are the part of the problem here, escalate perhaps? :) On Fri, Sep 11, 2026 at 10:26 AM Matt Brennan via NANOG <nanog@lists.nanog.org> wrote:
Hi Folks,
This is a new one for me. One of my AS numbers (AS27421) appears to be being used by someone in Brazil. We haven't seen any actual effects of the hijack -- that is, we don't appear to be losing any traffic. The only reason we noticed is because it's being reported on HE's BGP monitoring site.
I've reached out to the abuse contact for the AS's the hijacker is peering with (AS1000, AS271253 - same abuse contact for both) several times and gotten no response. Though, looking at which prefixes AS271253 is originating, it doesn't appear this AS cares much about proper behavior.
If anyone has any advice on next steps, it would be appreciated.
Thanks, Matt _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/63VQ3WKN...
I would look at creating ASPAs objects with $rir in the first instance. Would help combat these sorts of issues :) Ask your upstream to create objects, then ask them to ask their upstreams, and so on… You get the picture. Regards, Christopher Hawker Sent from my iPhone
On 11 Sep 2026, at 7:57 pm, Matt Brennan via NANOG <nanog@lists.nanog.org> wrote:
Hi Folks,
This is a new one for me. One of my AS numbers (AS27421) appears to be being used by someone in Brazil. We haven't seen any actual effects of the hijack -- that is, we don't appear to be losing any traffic. The only reason we noticed is because it's being reported on HE's BGP monitoring site.
I've reached out to the abuse contact for the AS's the hijacker is peering with (AS1000, AS271253 - same abuse contact for both) several times and gotten no response. Though, looking at which prefixes AS271253 is originating, it doesn't appear this AS cares much about proper behavior.
If anyone has any advice on next steps, it would be appreciated.
Thanks, Matt _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/63VQ3WKN...
Hi Matt, If AS27421 is being originated from an unexpected network in Brazil, I would recommend first confirming the exact prefixes and BGP paths being advertised by the suspected ASN. You can check the announcements and AS paths using tools such as BGPStream, RIPEstat, or HE BGP Toolkit. It would also be worth checking whether the affected prefixes are covered by valid RPKI ROAs. If they are, and the Brazilian announcement is RPKI Invalid, that provides strong evidence of an unauthorized origin. Since you have already contacted the upstream abuse contacts without a response, I would suggest escalating through their upstream/transit providers and the relevant RIR (ARIN for AS27421, and LACNIC for networks involved in Brazil). You can also report the incident to the NOC/security contacts listed in the relevant WHOIS/RDAP records. If there is no traffic impact at the moment, it may be a route leak or limited hijack rather than a full traffic interception. However, I would still recommend documenting the observed prefixes, timestamps, AS paths, and collectors reporting the announcement so you have a clear record for escalation. Hope this helps. Regards, Althaf On Fri, Sep 11, 2026 at 7:56 PM Matt Brennan via NANOG < nanog@lists.nanog.org> wrote:
Hi Folks,
This is a new one for me. One of my AS numbers (AS27421) appears to be being used by someone in Brazil. We haven't seen any actual effects of the hijack -- that is, we don't appear to be losing any traffic. The only reason we noticed is because it's being reported on HE's BGP monitoring site.
I've reached out to the abuse contact for the AS's the hijacker is peering with (AS1000, AS271253 - same abuse contact for both) several times and gotten no response. Though, looking at which prefixes AS271253 is originating, it doesn't appear this AS cares much about proper behavior.
If anyone has any advice on next steps, it would be appreciated.
Thanks, Matt _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/63VQ3WKN...
Maybe this is a bigger problem (loop or intentional)? This happened to a newly managed ASN for me as well: https://bgp.he.net/AS21752#_peers Ryan On Fri, Sep 11, 2026 at 10:54 AM Christopher Morrow via NANOG < nanog@lists.nanog.org> wrote:
The u-del folk (as2?) have some fun stories about this sort of problem :( I think they've even done at least 1 nanog talk about this?
There's also a long history of 'bad actors' using ASN at IX's (amsix and u-new-mexico I recall for us in the past) in order to make it seem like legit sources were sending traffic to places.
"Gosh, I don't THINK UNM has a network out to AMS do they? that seems sus (as the kids say these days)"
The impact you might see is non-reachability to things they announce? and/or them not being able to access your announced resources :( Also, people on the intertubes are going to be made about your 'bad behaviors' coming out of brazil :(
Its likely that the 2/1 abuse contacts you reached out to are the part of the problem here, escalate perhaps? :)
On Fri, Sep 11, 2026 at 10:26 AM Matt Brennan via NANOG <nanog@lists.nanog.org> wrote:
Hi Folks,
This is a new one for me. One of my AS numbers (AS27421) appears to be being used by someone in Brazil. We haven't seen any actual effects of
the
hijack -- that is, we don't appear to be losing any traffic. The only reason we noticed is because it's being reported on HE's BGP monitoring site.
I've reached out to the abuse contact for the AS's the hijacker is peering with (AS1000, AS271253 - same abuse contact for both) several times and gotten no response. Though, looking at which prefixes AS271253 is originating, it doesn't appear this AS cares much about proper behavior.
If anyone has any advice on next steps, it would be appreciated.
Thanks, Matt _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/63VQ3WKN... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/76THYD7L...
oopsie, I realize I wasn't super clear below... see below. On Fri, Sep 11, 2026 at 10:53 AM Christopher Morrow <morrowc.lists@gmail.com> wrote:
The u-del folk (as2?) have some fun stories about this sort of problem :( I think they've even done at least 1 nanog talk about this?
There's also a long history of 'bad actors' using ASN at IX's (amsix and u-new-mexico I recall for
I don't think there was anything AMSIX could have actually done here. Why? becuse the actor showed AMSIX RS the 'correct' asn... the peerings in question were not via the RS though:( I believe this was also seen at several other IX's :( it's one of the reasons focus was brought on filtering and RPKI by us at the time. My larger point is really that: "This happens, because people are people... and your best path is to escalate up the peering fabric with logs and evidence of the behavior."
But our AS2 "hijacks" and MIT, etc. are usually the result of router syntax errors trying to prepend, I really hope someone isn't trying to prepend 27421 times... 🙂 On 9/11/26 10:53 AM, Christopher Morrow via NANOG wrote:
The u-del folk (as2?) have some fun stories about this sort of problem :( I think they've even done at least 1 nanog talk about this?
There's also a long history of 'bad actors' using ASN at IX's (amsix and u-new-mexico I recall for us in the past) in order to make it seem like legit sources were sending traffic to places.
"Gosh, I don't THINK UNM has a network out to AMS do they? that seems sus (as the kids say these days)"
The impact you might see is non-reachability to things they announce? and/or them not being able to access your announced resources :( Also, people on the intertubes are going to be made about your 'bad behaviors' coming out of brazil :(
Its likely that the 2/1 abuse contacts you reached out to are the part of the problem here, escalate perhaps? :)
On Fri, Sep 11, 2026 at 10:26 AM Matt Brennan via NANOG <nanog@lists.nanog.org> wrote:
Hi Folks,
This is a new one for me. One of my AS numbers (AS27421) appears to be being used by someone in Brazil. We haven't seen any actual effects of the hijack -- that is, we don't appear to be losing any traffic. The only reason we noticed is because it's being reported on HE's BGP monitoring site.
I've reached out to the abuse contact for the AS's the hijacker is peering with (AS1000, AS271253 - same abuse contact for both) several times and gotten no response. Though, looking at which prefixes AS271253 is originating, it doesn't appear this AS cares much about proper behavior.
If anyone has any advice on next steps, it would be appreciated.
Thanks, Matt _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/nanog@list...
Matt- This is semi common occurrence. Your best option is what you have done, reach out to the networks they are advertising to, and keep going upstream until you reach someone who is responsive and can take action. Getting your as_paths in ASPA is nice, but ASPA is not widely implemented, and it's still pretty trivial to bypass. Good luck. On Fri, Sep 11, 2026 at 10:27 AM Matt Brennan via NANOG < nanog@lists.nanog.org> wrote:
Hi Folks,
This is a new one for me. One of my AS numbers (AS27421) appears to be being used by someone in Brazil. We haven't seen any actual effects of the hijack -- that is, we don't appear to be losing any traffic. The only reason we noticed is because it's being reported on HE's BGP monitoring site.
I've reached out to the abuse contact for the AS's the hijacker is peering with (AS1000, AS271253 - same abuse contact for both) several times and gotten no response. Though, looking at which prefixes AS271253 is originating, it doesn't appear this AS cares much about proper behavior.
If anyone has any advice on next steps, it would be appreciated.
Thanks, Matt _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/63VQ3WKN...
On Fri, 11 Sept 2026 at 18:04, Christopher Hawker via NANOG <nanog@lists.nanog.org> wrote:
I would look at creating ASPAs objects with $rir in the first instance. Would help combat these sorts of issues :) Ask your upstream to create objects, then ask them to ask their upstreams, and so on… You get the picture.
If someone feels like vibing, may I suggest. a) recover AS-SET <-> ASN relation - look at RIR data, check if (mp-)export has exactly one AS-SET -> match - look at peeringDB b) resolve AS-SET into an ASN tree c) prune from the tree ASPA violating branches d) return prefix-list, and origin ASN list This way anyone already doing RIR prefix-list generation, without any ASPA support in NOS, could get a significant amount of ASPA benefits without changing anything in the NOS side, just changing command they call to translate customer AS-SET into prefix-list or AS origin list or both. -- ++ytti
b) resolve AS-SET into an ASN tree
c) prune from the tree ASPA violating branches
I've discussed this with a few people with the same ideas, and I can think of few reasons not to ship it as long as it's done right. It is appealing to get some value from the ASPAs as early as possible, and pruning bad members from an expanded AS-SET tree could offer that. -- Bryton Herdes Principal Network Engineer AS13335 - Cloudflare On Fri, Sep 11, 2026 at 11:58 AM Saku Ytti via NANOG <nanog@lists.nanog.org> wrote:
On Fri, 11 Sept 2026 at 18:04, Christopher Hawker via NANOG <nanog@lists.nanog.org> wrote:
I would look at creating ASPAs objects with $rir in the first instance. Would help combat these sorts of issues :) Ask your upstream to create objects, then ask them to ask their upstreams, and so on… You get the picture.
If someone feels like vibing, may I suggest.
a) recover AS-SET <-> ASN relation - look at RIR data, check if (mp-)export has exactly one AS-SET -> match - look at peeringDB
b) resolve AS-SET into an ASN tree
c) prune from the tree ASPA violating branches
d) return prefix-list, and origin ASN list
This way anyone already doing RIR prefix-list generation, without any ASPA support in NOS, could get a significant amount of ASPA benefits without changing anything in the NOS side, just changing command they call to translate customer AS-SET into prefix-list or AS origin list or both.
-- ++ytti _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/UOBGN4KM...
Thanks, everyone, for the feedback. FYI we do have ROA set up for our prefixes, and I set up ASPA earlier this week hoping it might help this ... situation. After reviewing Ryan's note, I reviewed the list of their peers further and I feel like a number of them are likely hijacked. I have now reached out to who I am confident are upstreams of them (HE, Cogent, Level3) and we'll see where that gets me. Of course, with more than 5,000 alleged peers this could easily be a zero sum game. @Bryton -- as a note, both of the upstream ASs are peering with you as well, but your abuse form doesn't really have an option for this type of submission. -Matt On Fri, 11 Sept 2026 at 16:06, Bryton Herdes via NANOG < nanog@lists.nanog.org> wrote:
b) resolve AS-SET into an ASN tree
c) prune from the tree ASPA violating branches
I've discussed this with a few people with the same ideas, and I can think of few reasons not to ship it as long as it's done right.
It is appealing to get some value from the ASPAs as early as possible, and pruning bad members from an expanded AS-SET tree could offer that.
-- Bryton Herdes Principal Network Engineer AS13335 - Cloudflare
On Fri, Sep 11, 2026 at 11:58 AM Saku Ytti via NANOG < nanog@lists.nanog.org> wrote:
On Fri, 11 Sept 2026 at 18:04, Christopher Hawker via NANOG <nanog@lists.nanog.org> wrote:
I would look at creating ASPAs objects with $rir in the first instance. Would help combat these sorts of issues :) Ask your upstream to create objects, then ask them to ask their upstreams, and so on… You get the picture.
If someone feels like vibing, may I suggest.
a) recover AS-SET <-> ASN relation - look at RIR data, check if (mp-)export has exactly one AS-SET -> match - look at peeringDB
b) resolve AS-SET into an ASN tree
c) prune from the tree ASPA violating branches
d) return prefix-list, and origin ASN list
This way anyone already doing RIR prefix-list generation, without any ASPA support in NOS, could get a significant amount of ASPA benefits without changing anything in the NOS side, just changing command they call to translate customer AS-SET into prefix-list or AS origin list or both.
-- ++ytti _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/UOBGN4KM... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/2FQHH6LN...
participants (9)
-
Althaf Navaskhan -
Bryton Herdes -
Christopher Hawker -
Christopher Morrow -
Matt Brennan -
Mike Davis -
Ryan McIntosh -
Saku Ytti -
Tom Beecher