[BGP Hijack] AS202734 hijacked multiple Chinese Ca rriers on May 16-17 – Full evidence and attribution

Dear NANOG community,

I am sharing a fully-attributed BGP hijacking incident that occurred on May 16-17, 2026.

**What happened:**

Between May 16-17, 2026, AS202734 announced 3,948 IPv4 prefixes that it does not legally own, targeting major Chinese carriers and infrastructure, including:
- China Telecom (125.104.0.0/13)
- China Unicom (123.144.0.0/12)
- China Mobile
- China Education and Research Network (CERNET)
- China Postal Bureau (120.72.160.0/24)
- Alibaba Cloud, Tencent Cloud, Huawei Cloud

The same ASN also announced China Telecom's IPv6 backbone (240e::/20). 

**Key technical evidence:**
- Attacker's own BIRD config shows manual injection of hijacked routes on May 1 (premeditation).
- Attacker's own Looking Glass shows the hijacked routes were active in his routing table.
- Attacker's GitHub shows he submitted a new ASN (AS402333) on May 16, the day of the hijack.
- Sponsoring org (MoeDove)'s official website shows they operate 36 global PoPs, including nodes in mainland China (Shanghai, Hangzhou, Zhengzhou, Chengdu).

**Who is behind it:**
AS202734 is registered to Junqi Tian (Jacob Tian), a graduate student at McGill University and researcher at Mila - Quebec AI Institute. His RIPE WHOIS address is: 1103-2100 Rue de Bleury, Montreal, Canada.

**The sponsoring org:**
MoeDove LLC (ORG-ML942-RIPE) is the sponsoring organization. Their network engineer responded to my abuse report by calling me an "idiot" and refused to investigate.

**What I have done:**
- Reported to RIPE NCC, Vultr, HE, Cloudflare, Mila, and his academic supervisor.
- Vultr has cut IPv4 peering and is "working with the customer" on IPv6.
- RIPE NCC opened tickets #1042641 and #1043090, but stated they "do not have the scope to act."

**Attached原始邮件 (.eml) 供验证：**
- `moedove_abuse_reply_idiot.eml` (MoeDove engineer's response)
- `ripe_carl_guderian_1042641.eml` (RIPE NCC first reply)
- `ripe_carl_guderian_1043090.eml` (RIPE NCC second reply)

**Questions for the community:**
1. Has anyone else observed unusual prefixes from AS202734 / AS402333 / AS44324?
2. What operational steps can the community take to filter bogons from these ASNs?
3. Are there best practices for dealing with a sponsoring LIR that refuses to act?

**Public evidence:**
- HE BGP Toolkit: https://bgp.he.net/AS202734
- RIPE WHOIS: https://apps.db.ripe.net/db-web-ui/query?searchtext=AS202734

Thank you for reading. I welcome any technical scrutiny or advice. Full evidence archive (with PII redacted) is available upon request.

---
zhong miao
[email protected]
Independent Security Researcher

_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/[email protected]/message/MI6VWOX7XOCDIS244RLJSMS2ITZWTGED/