Re: ]ADC Should Be Triggered by Multiple Signals, Not One Abusive Domain
Hi Nick, just to be clear we are not saying don’t start any kind of investigation. We are saying before you go to ADC check based on one abuse report, check these other signals. In order to do ADC you need to have access to registrar backend or database. These other signals I mentioned don't need access to backend it's public information. are not (I managed to gather the signals without being a registrar, I am only a detective) So in effect, to find out about those signals you don’t have to do ADC as your first action as I demonstrated. Those signals along with abusive domain could establish the trigger for ADC. Farzaneh On Wed, Apr 22, 2026 at 11:02 AM Nick Wenban-Smith < Nick.Wenban-Smith@nominet.uk> wrote:
Hi Detective FB
Thanks for the investigation and report; I think some contextual examples of when ADC can assist with abuse mitigation are really helpful when considering our policy deliberations.
Sharing wider threat intel as between registrars and the wider security and LE community when a widespread attack is spotted could be an important part of a community response bearing in mind that threat actors will spread their attacks across multiple registrars and TLDs, both gTLDs and ccTLDs for that matter (NB not part of this PDP1 Charter but I digress).
Just coming back to the multiple signals point, I think there is a risk of conflating the trigger for ADC, the investigations conducted by the registrar, and then the mitigation action taken by the registrar (if any), which I see as all discrete aspects of the policy work in accordance with the Charter instructions to us.
What I don't follow with the multiple signals argument as part of the trigger test, is how with respect to a single proven maliciously registered abusive domain, the registrar could possibly know prior to doing some basic investigation at least, whether or not it is part of a wider campaign?
In fact I'd go further than that and say that the whole point about the
registrar investigation is to determine whether the trigger domain was a one off abusive registration (in which case nothing to see any further) or whether in fact due to multiple signals (or whatever we want to call them) it is clear that (as per your examples below) it *could be* part of a wider pattern of malicious registrations which therefore need investigation. And if it then found by the registrar that other domains are also abusively registered then they should be actioned by the registrar without separate abuse notifications needing to be filed by anyone. If they aren't abusive then the registrar obviously shouldn't take any mitigation action. But that will only become clear having done the investigation, with no wriggle room for wilful blindness on the part of the registrar.
Given registrar friends on the PDP have already told us that they already conduct ADC it would be nice to understand whether I have understood this practice correctly and my analysis here is fair. If a wheel has already been invented then let's not get into different shapes and sizes and a set of competing standards, but document existing good policies which already work.
Cheers all Nick
------------------------------ *From:* farzaneh badii via Gnso-dnsabuse-pdp <gnso-dnsabuse-pdp@icann.org> *Sent:* Wednesday, April 22, 2026 12:53 *To:* Ching Chiao <ching.chiao@whoisxmlapi.com> *Cc:* anil Jain via Gnso-dnsabuse-pdp <gnso-dnsabuse-pdp@icann.org> *Subject:* [MALICIOUS URLS, FILTERED][Gnso-dnsabuse-pdp] ADC Should Be Triggered by Multiple Signals, Not One Abusive Domain
*Caution:* This is an external email and may be malicious. Please take extra care when replying, clicking links or opening attachments.
Hi all,
I just wanted to show you what we mean by considering other indicators rather than one domain to start ADC. You need multiple signals to trigger ADC, not just one abusive domain. Here's what those signals look like — and how even free agent Detective Badi undertook her analysis with zero equipment or use of intelligence firms (yes yes I know, when it scales it's harder.)
Before diving in, here are the kinds of freely available, contextual indicators I can think of:
1. Is the domain on a blocklist? 2. Has it been reported before? 3. Does it relate to a documented, active campaign? 4. Does it share infrastructure (e.g. nameservers) that host a large number of malicious actors? 5. Was it registered during a period of heightened relevance to a specific attack target? 6. Is the registry going through a period of increased abuse? (check domain metrica) 7. Is the registrar going through a period of increased abuse? (check domain metrica)
These paint a much richer picture than "one domain in a portfolio is bad, therefore ADC should start and every domain should be checked." *This is not a formal NCSG position* , but we've been saying for a while that ADC should be triggered based on a combination of such indicators/signals rather than profiling entire registrant portfolios from a single abusive domain. Ching's ADC examples inspired me to actually do this exercise and show what that looks like in practice.
One caveat before I go further: I am not comfortable with these indicators. But they might be better than profiling domain name registrants and their entire portfolios based on a single abusive domain.
---
THE TELEGRAM-HONG KONG CASE
In Ching's examples I came across telegram-hongkong[.]com. This one is very interesting for me I worked on the use of Telegram in Hong Kong during the 2019 uprising.
Here's the scenario: imagine this domain was registered around the uprising time in Hong Kong. Telegram was the most popular app during the uprising, and people were desperately trying to download and use it. A domain registered in that window, mimicking Telegram, could signal a systematic effort to cause security issues for a specific population at a specific moment. That's a genuinely good contextual indicator for triggering ADC — the timing and the target tell you something that the domain name alone cannot.
But this is not without its complications. During that same period, people also ran apps that helped protesters track police locations, and dear Apple took those down. Now imagine that somewhere in an "abusive" portfolio, a couple of domains exist that were actually helping protesters. Authorities are actively requesting takedowns of such domains. What should the registrar do? *Does their knowledge of those domains create legal or political exposure for them?*
The contextual signal cuts both ways. Which is exactly why context needs to be analyzed.
For the record, Malwarebytes documented a campaign where attackers used malicious Google ads exclusively targeting people in Hong Kong, luring victims into downloading a malicious version of Telegram. So yes — this domain relates to a well-known, documented campaign. That's another signal worth noting.
---
THE CRAIGSLIT / CALUDE CASE
I do DNS abuse reporting as a hobby, partly to understand what doesn't work and what could be better. In one of my hunts I came across Craigslit[.]com. I reported it multiple times through different reporting mechanisms, it got suspended, and then, sigh, it's active again.
What's interesting is that it used to share a nameserver that I have come across too often in abusive domain (like calude(.)ai But the name server can be rapidly changed so this metric should not be used on its own.
Another signal: whether a domain has been reported before. I was excited to see that Domain Metrica claimed to have this kind of data — until it didn't actually tell me whether the domain had ever been reported, despite the fact that I know I reported it myself. This is admittedly a weak signal, but public reporting history is still better than snooping on registrant accounts.
All in all,
You need contextual, situational signals alongside the abusive domain to justify starting ADC — things like blocklist presence, prior reports, shared infrastructure, registration timing, and ties to documented malicious campaigns. These signals are freely available in the world. No special access required. No account surveillance needed. you can use abuse.ch <http://secure-web.cisco.com/1BZB0-EyjFrgCcD-rYQevZwzy2424uO_vDgh2061MI04vLWW...> and a myriad of free tools that can help you with your decision.
Best regards,
Detective FB
Ching's ADC examples inspired me to do this exercise. This is not an NCSG position but we have been saying that the start of ADC should be based on different indicators instead of just if one domain is abusive, then we should trigger ADC. Before I begin, I want to be very clear that I am not comfortable with these indicators. But they are better than profiling domain name registrants and their portfolios based on one abusive domain.
In Ching's examples I came across telegram-hongkong[.]com. This is a very interesting case. It was exciting for me especially because I worked on the use of Telegram in Hong Kong during the 2019 uprising. So the scenario is as follows: imagine if this domain was registered around that time. Telegram was the most popular app around that time and people would want to download it or use it. So perhaps if the domain was registered during that time, it could signal that it's a systematic effort to cause some security issues. So that's actually a good indicator to consider when wanting to trigger ADC. This is not without its shortcomings. During that period they also ran apps that would inform the protestors about the police location. Those apps were taken down by dear Apple. Now imagine if in this abusive portfolio, there are a couple of registered domains that help protestors. There is a clear request from the authorities to take down such apps/domains. What should the registrar do? doesn't their knowledge of existence of such domains create problems? Other factors that should be considered are: is the nameserver ... does the domain relate to a well known campaign (it does, Malwarebytes documented a campaign where attackers used malicious Google ads exclusively targeting people in Hong Kong, luring victims into downloading a malicious version of Telegram.)
Anyway I continue. I do DNS abuse reporting as a hobby to understand what doesn't work, what could be better etc. In one of my hunts, I came across Craigslit[.]com. I reported this domain many times using different reporting mechanisms and it was suspended and now I see it's active again. But interestingly it shares the same name-server with my other hunt and that's calude.ai, They both use NS1.HASTYDNS.COM <http://secure-web.cisco.com/1l15LLs-tuNPu4mQFmRuuLKEET2gefIwRKgZNKXh-vo0A-t9...> (the name server).
Another signal can be if the domain has been reported before. I got excited to see domain metrica said it has such data but it didn't tell me if it was ever reported despite the fact that I know I have reported the domain name! (this is a weak signal, but again public data might be better than snooping on accounts etc).
So what is the moral of the story.
You need to have different signals (contextual situational) as well as the abusive domain to start ADC. Those signals are available for free out in the world and even Detective Badi without any equipment managed to do it.
Farzaneh
On Wed, Apr 15, 2026 at 7:01 AM Ching Chiao via Gnso-dnsabuse-pdp < gnso-dnsabuse-pdp@icann.org> wrote:
Dear all,
Please review the attached 2023 research slides regarding typosquatting groups, which may be relevant to this PDP. In short, the research compares two different datasets -- typo groups vs. confirmed IoC domains .
Feel free to ask any questions or comments via the list or privately.
Best,
Ching
*Ching Chiao 乔敬* *Head of APAC & Corporate Development* Check our latest *Internet Abuse Signal* research: https://main.whoisxmlapi.com/blog/to-cache-a-predator-ilovepoop-toolkit-reac... <https://secure-web.cisco.com/1eTgThDAb10Uv7QOwH8grodWjkEkZ0kdzx4HtV2_ej-kLWG...>
*WhoisXMLAPI.com* <http://secure-web.cisco.com/1rKYUKEeCa6HXYaOgHrUs7mvPuMJkx48OvVkSmGjaOJ_Rtth...> *中文：**https://zh.main.whoisxmlapi.com/* <https://secure-web.cisco.com/1Jg5W7wgvG8hNYDVfPt4h5Hg7EiLVKsKCC-UINN1PR5rX9F...> *日本语 ：**https://ja.main.whoisxmlapi.com/* <https://secure-web.cisco.com/1bhfrIEZMiPghCvJvStGu1OSPrKJKmxVDKlYr2HESvyT86X...>
LinkedIn : https://www.linkedin.com/in/chiao/ Book a meeting now: https://calendar.app.google/9neWrkwvhPHRqGZ86 <https://secure-web.cisco.com/1OG5PtqhWfaTdOV3637C_tKP2GmxnPyjqaEWEqTNefJCd-Y...> _______________________________________________ Gnso-dnsabuse-pdp mailing list -- gnso-dnsabuse-pdp@icann.org To unsubscribe send an email to gnso-dnsabuse-pdp-leave@icann.org
Is Signal Checking not already ADC? el -- Sent from my iPhone On 24. Apr 2026 at 14:02 +0200, farzaneh badii via Gnso-dnsabuse-pdp <gnso-dnsabuse-pdp@icann.org>, wrote:
Hi Nick, just to be clear we are not saying don’t start any kind of investigation. We are saying before you go to ADC check based on one abuse report, check these other signals. In order to do ADC you need to have access to registrar backend or database. These other signals I mentioned don't need access to backend it's public information. are not (I managed to gather the signals without being a registrar, I am only a detective)
So in effect, to find out about those signals you don’t have to do ADC as your first action as I demonstrated. Those signals along with abusive domain could establish the trigger for ADC.
Farzaneh
[…]
To me, all checks qualify as associated domain checks. The only difference is that some of them pivot on open source publicly accessible data (like NS or MX records or public abuse reports) and others pivot on personal data, like the registrant name or email address. As I understand, Farzy has a problem not with the associated domains check itself, but with the datapoints that are used as pivot points. If you pivot on host IP for example, it's ok. If you pivot on registrant email then it is considered more intrusive. Maybe we can explore this specific issue further. Regards, Naoum ΜΕΓΓΟΥΔΗΣ Ναούμ Αστυνόμος Α' Διεύθυνση Δίωξης Κυβερνοεγκλήματος Τμήμα Διαδικτυακής Προστασίας Ανηλίκων Λ. Αλεξάνδρας 173, 115 22, Αθήνα<https://www.google.com/maps/place/%CE%94%CE%B9%CE%B5%CF%8D%CE%B8%CF%85%CE%BD...> MENGOUDIS Naoum Police Major Cyber Crime Directorate Online Child Protection Department Alexandras Avenue 173, 115 22, Athens<https://www.google.com/maps/place/%CE%94%CE%B9%CE%B5%CF%8D%CE%B8%CF%85%CE%BD...> T: (+30) 2106476475 E: n.mengoudis@cybercrimeunit.gov.gr<mailto:n.mengoudis@cybercrimeunit.gr> ------------------- Email Disclaimer This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this email. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system.If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Think green before printing ________________________________ From: Eberhard W Lisse via Gnso-dnsabuse-pdp <gnso-dnsabuse-pdp@icann.org> Sent: Friday, April 24, 2026 15:13 To: Bruna Martins dos Santos via Gnso-dnsabuse-pdp <gnso-dnsabuse-pdp@icann.org> Cc: Dns-techs <dns-techs@na-nic.com.na> Subject: [Gnso-dnsabuse-pdp] Re: ]ADC Should Be Triggered by Multiple Signals, Not One Abusive Domain Is Signal Checking not already ADC? el -- Sent from my iPhone On 24. Apr 2026 at 14:02 +0200, farzaneh badii via Gnso-dnsabuse-pdp <gnso-dnsabuse-pdp@icann.org>, wrote: Hi Nick, just to be clear we are not saying don’t start any kind of investigation. We are saying before you go to ADC check based on one abuse report, check these other signals. In order to do ADC you need to have access to registrar backend or database. These other signals I mentioned don't need access to backend it's public information. are not (I managed to gather the signals without being a registrar, I am only a detective) So in effect, to find out about those signals you don’t have to do ADC as your first action as I demonstrated. Those signals along with abusive domain could establish the trigger for ADC. Farzaneh […]
Using a host IP / A record may give you different results. Not all ADC-linked domain names will have proper DNS record setup, and many are in a whack-a-mole situation. A lot of time the registrar knows what the OSINT community doesn't know simply by checking the internal data which is only available to specific registrar. Let's focus on the registrar account / registrant level solution. Thanks! Best, Ching On Fri, Apr 24, 2026 at 8:39 AM Naoum MENGOUDIS via Gnso-dnsabuse-pdp < gnso-dnsabuse-pdp@icann.org> wrote:
To me, all checks qualify as associated domain checks. The only difference is that some of them pivot on open source publicly accessible data (like NS or MX records or public abuse reports) and others pivot on personal data, like the registrant name or email address.
As I understand, Farzy has a problem not with the associated domains check itself, but with the datapoints that are used as pivot points. If you pivot on host IP for example, it's ok. If you pivot on registrant email then it is considered more intrusive.
Maybe we can explore this specific issue further.
Regards, Naoum
ΜΕΓΓΟΥΔΗΣ Ναούμ Αστυνόμος Α' Διεύθυνση Δίωξης Κυβερνοεγκλήματος Τμήμα Διαδικτυακής Προστασίας Ανηλίκων Λ. Αλεξάνδρας 173, 115 22, Αθήνα <https://www.google.com/maps/place/%CE%94%CE%B9%CE%B5%CF%8D%CE%B8%CF%85%CE%BD...>
MENGOUDIS Naoum Police Major Cyber Crime Directorate Online Child Protection Department Alexandras Avenue 173, 115 22, Athens <https://www.google.com/maps/place/%CE%94%CE%B9%CE%B5%CF%8D%CE%B8%CF%85%CE%BD...>
T: (+30) 2106476475 E: n.mengoudis@cybercrimeunit.gov.gr <n.mengoudis@cybercrimeunit.gr> ------------------- *Email Disclaimer*
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this email. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system.If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
*Think green before printing*
------------------------------ *From:* Eberhard W Lisse via Gnso-dnsabuse-pdp < gnso-dnsabuse-pdp@icann.org> *Sent:* Friday, April 24, 2026 15:13 *To:* Bruna Martins dos Santos via Gnso-dnsabuse-pdp < gnso-dnsabuse-pdp@icann.org> *Cc:* Dns-techs <dns-techs@na-nic.com.na> *Subject:* [Gnso-dnsabuse-pdp] Re: ]ADC Should Be Triggered by Multiple Signals, Not One Abusive Domain
Is *Signal* Checking not already ADC?
el
-- Sent from my iPhone On 24. Apr 2026 at 14:02 +0200, farzaneh badii via Gnso-dnsabuse-pdp < gnso-dnsabuse-pdp@icann.org>, wrote:
Hi Nick, just to be clear we are not saying don’t start any kind of investigation. We are saying before you go to ADC check based on one abuse report, check these other signals. In order to do ADC you need to have access to registrar backend or database. These other signals I mentioned don't need access to backend it's public information. are not (I managed to gather the signals without being a registrar, I am only a detective)
So in effect, to find out about those signals you don’t have to do ADC as your first action as I demonstrated. Those signals along with abusive domain could establish the trigger for ADC.
Farzaneh
[…]
_______________________________________________ Gnso-dnsabuse-pdp mailing list -- gnso-dnsabuse-pdp@icann.org To unsubscribe send an email to gnso-dnsabuse-pdp-leave@icann.org
Hi Farzaneh, I would appreciate some clarification on your point regarding the use of external signals. Are you suggesting that a registrar should rely on third-party or open-source signals to evaluate an ADC rather than using its own internal backend registration data? It seems more efficient for a registrar to use the data immediately available to them once a confirmed abuse report is received. Checking external signals during the triggering phase could potentially slow down the response and may raise additional data privacy concerns (?) . While I support using third-party intelligence for comprehensive studies or multi-registrar investigations, those appear to be out of scope for our current discussion. Furthermore, as Nick mentioned, many registrars already conduct ADC for cybersecurity or business intelligence purposes; we should be careful not to reinvent the wheel for them. Thank you for your time and consideration. Best regards, Ching On Fri, Apr 24, 2026 at 8:02 AM farzaneh badii via Gnso-dnsabuse-pdp < gnso-dnsabuse-pdp@icann.org> wrote:
Hi Nick, just to be clear we are not saying don’t start any kind of investigation. We are saying before you go to ADC check based on one abuse report, check these other signals. In order to do ADC you need to have access to registrar backend or database. These other signals I mentioned don't need access to backend it's public information. are not (I managed to gather the signals without being a registrar, I am only a detective)
So in effect, to find out about those signals you don’t have to do ADC as your first action as I demonstrated. Those signals along with abusive domain could establish the trigger for ADC.
Farzaneh
On Wed, Apr 22, 2026 at 11:02 AM Nick Wenban-Smith < Nick.Wenban-Smith@nominet.uk> wrote:
Hi Detective FB
Thanks for the investigation and report; I think some contextual examples of when ADC can assist with abuse mitigation are really helpful when considering our policy deliberations.
Sharing wider threat intel as between registrars and the wider security and LE community when a widespread attack is spotted could be an important part of a community response bearing in mind that threat actors will spread their attacks across multiple registrars and TLDs, both gTLDs and ccTLDs for that matter (NB not part of this PDP1 Charter but I digress).
Just coming back to the multiple signals point, I think there is a risk of conflating the trigger for ADC, the investigations conducted by the registrar, and then the mitigation action taken by the registrar (if any), which I see as all discrete aspects of the policy work in accordance with the Charter instructions to us.
What I don't follow with the multiple signals argument as part of the trigger test, is how with respect to a single proven maliciously registered abusive domain, the registrar could possibly know prior to doing some basic investigation at least, whether or not it is part of a wider campaign?
In fact I'd go further than that and say that the whole point about the
registrar investigation is to determine whether the trigger domain was a one off abusive registration (in which case nothing to see any further) or whether in fact due to multiple signals (or whatever we want to call them) it is clear that (as per your examples below) it *could be* part of a wider pattern of malicious registrations which therefore need investigation. And if it then found by the registrar that other domains are also abusively registered then they should be actioned by the registrar without separate abuse notifications needing to be filed by anyone. If they aren't abusive then the registrar obviously shouldn't take any mitigation action. But that will only become clear having done the investigation, with no wriggle room for wilful blindness on the part of the registrar.
Given registrar friends on the PDP have already told us that they already conduct ADC it would be nice to understand whether I have understood this practice correctly and my analysis here is fair. If a wheel has already been invented then let's not get into different shapes and sizes and a set of competing standards, but document existing good policies which already work.
Cheers all Nick
------------------------------ *From:* farzaneh badii via Gnso-dnsabuse-pdp <gnso-dnsabuse-pdp@icann.org
*Sent:* Wednesday, April 22, 2026 12:53 *To:* Ching Chiao <ching.chiao@whoisxmlapi.com> *Cc:* anil Jain via Gnso-dnsabuse-pdp <gnso-dnsabuse-pdp@icann.org> *Subject:* [MALICIOUS URLS, FILTERED][Gnso-dnsabuse-pdp] ADC Should Be Triggered by Multiple Signals, Not One Abusive Domain
*Caution:* This is an external email and may be malicious. Please take extra care when replying, clicking links or opening attachments.
Hi all,
I just wanted to show you what we mean by considering other indicators rather than one domain to start ADC. You need multiple signals to trigger ADC, not just one abusive domain. Here's what those signals look like — and how even free agent Detective Badi undertook her analysis with zero equipment or use of intelligence firms (yes yes I know, when it scales it's harder.)
Before diving in, here are the kinds of freely available, contextual indicators I can think of:
1. Is the domain on a blocklist? 2. Has it been reported before? 3. Does it relate to a documented, active campaign? 4. Does it share infrastructure (e.g. nameservers) that host a large number of malicious actors? 5. Was it registered during a period of heightened relevance to a specific attack target? 6. Is the registry going through a period of increased abuse? (check domain metrica) 7. Is the registrar going through a period of increased abuse? (check domain metrica)
These paint a much richer picture than "one domain in a portfolio is bad, therefore ADC should start and every domain should be checked." *This is not a formal NCSG position* , but we've been saying for a while that ADC should be triggered based on a combination of such indicators/signals rather than profiling entire registrant portfolios from a single abusive domain. Ching's ADC examples inspired me to actually do this exercise and show what that looks like in practice.
One caveat before I go further: I am not comfortable with these indicators. But they might be better than profiling domain name registrants and their entire portfolios based on a single abusive domain.
---
THE TELEGRAM-HONG KONG CASE
In Ching's examples I came across telegram-hongkong[.]com. This one is very interesting for me I worked on the use of Telegram in Hong Kong during the 2019 uprising.
Here's the scenario: imagine this domain was registered around the uprising time in Hong Kong. Telegram was the most popular app during the uprising, and people were desperately trying to download and use it. A domain registered in that window, mimicking Telegram, could signal a systematic effort to cause security issues for a specific population at a specific moment. That's a genuinely good contextual indicator for triggering ADC — the timing and the target tell you something that the domain name alone cannot.
But this is not without its complications. During that same period, people also ran apps that helped protesters track police locations, and dear Apple took those down. Now imagine that somewhere in an "abusive" portfolio, a couple of domains exist that were actually helping protesters. Authorities are actively requesting takedowns of such domains. What should the registrar do? *Does their knowledge of those domains create legal or political exposure for them?*
The contextual signal cuts both ways. Which is exactly why context needs to be analyzed.
For the record, Malwarebytes documented a campaign where attackers used malicious Google ads exclusively targeting people in Hong Kong, luring victims into downloading a malicious version of Telegram. So yes — this domain relates to a well-known, documented campaign. That's another signal worth noting.
---
THE CRAIGSLIT / CALUDE CASE
I do DNS abuse reporting as a hobby, partly to understand what doesn't work and what could be better. In one of my hunts I came across Craigslit[.]com. I reported it multiple times through different reporting mechanisms, it got suspended, and then, sigh, it's active again.
What's interesting is that it used to share a nameserver that I have come across too often in abusive domain (like calude(.)ai But the name server can be rapidly changed so this metric should not be used on its own.
Another signal: whether a domain has been reported before. I was excited to see that Domain Metrica claimed to have this kind of data — until it didn't actually tell me whether the domain had ever been reported, despite the fact that I know I reported it myself. This is admittedly a weak signal, but public reporting history is still better than snooping on registrant accounts.
All in all,
You need contextual, situational signals alongside the abusive domain to justify starting ADC — things like blocklist presence, prior reports, shared infrastructure, registration timing, and ties to documented malicious campaigns. These signals are freely available in the world. No special access required. No account surveillance needed. you can use abuse.ch <http://secure-web.cisco.com/1BZB0-EyjFrgCcD-rYQevZwzy2424uO_vDgh2061MI04vLWW...> and a myriad of free tools that can help you with your decision.
Best regards,
Detective FB
Ching's ADC examples inspired me to do this exercise. This is not an NCSG position but we have been saying that the start of ADC should be based on different indicators instead of just if one domain is abusive, then we should trigger ADC. Before I begin, I want to be very clear that I am not comfortable with these indicators. But they are better than profiling domain name registrants and their portfolios based on one abusive domain.
In Ching's examples I came across telegram-hongkong[.]com. This is a very interesting case. It was exciting for me especially because I worked on the use of Telegram in Hong Kong during the 2019 uprising. So the scenario is as follows: imagine if this domain was registered around that time. Telegram was the most popular app around that time and people would want to download it or use it. So perhaps if the domain was registered during that time, it could signal that it's a systematic effort to cause some security issues. So that's actually a good indicator to consider when wanting to trigger ADC. This is not without its shortcomings. During that period they also ran apps that would inform the protestors about the police location. Those apps were taken down by dear Apple. Now imagine if in this abusive portfolio, there are a couple of registered domains that help protestors. There is a clear request from the authorities to take down such apps/domains. What should the registrar do? doesn't their knowledge of existence of such domains create problems? Other factors that should be considered are: is the nameserver ... does the domain relate to a well known campaign (it does, Malwarebytes documented a campaign where attackers used malicious Google ads exclusively targeting people in Hong Kong, luring victims into downloading a malicious version of Telegram.)
Anyway I continue. I do DNS abuse reporting as a hobby to understand what doesn't work, what could be better etc. In one of my hunts, I came across Craigslit[.]com. I reported this domain many times using different reporting mechanisms and it was suspended and now I see it's active again. But interestingly it shares the same name-server with my other hunt and that's calude.ai, They both use NS1.HASTYDNS.COM <http://secure-web.cisco.com/1l15LLs-tuNPu4mQFmRuuLKEET2gefIwRKgZNKXh-vo0A-t9...> (the name server).
Another signal can be if the domain has been reported before. I got excited to see domain metrica said it has such data but it didn't tell me if it was ever reported despite the fact that I know I have reported the domain name! (this is a weak signal, but again public data might be better than snooping on accounts etc).
So what is the moral of the story.
You need to have different signals (contextual situational) as well as the abusive domain to start ADC. Those signals are available for free out in the world and even Detective Badi without any equipment managed to do it.
Farzaneh
On Wed, Apr 15, 2026 at 7:01 AM Ching Chiao via Gnso-dnsabuse-pdp < gnso-dnsabuse-pdp@icann.org> wrote:
Dear all,
Please review the attached 2023 research slides regarding typosquatting groups, which may be relevant to this PDP. In short, the research compares two different datasets -- typo groups vs. confirmed IoC domains .
Feel free to ask any questions or comments via the list or privately.
Best,
Ching
*Ching Chiao 乔敬* *Head of APAC & Corporate Development* Check our latest *Internet Abuse Signal* research: https://main.whoisxmlapi.com/blog/to-cache-a-predator-ilovepoop-toolkit-reac... <https://secure-web.cisco.com/1eTgThDAb10Uv7QOwH8grodWjkEkZ0kdzx4HtV2_ej-kLWG...>
*WhoisXMLAPI.com* <http://secure-web.cisco.com/1rKYUKEeCa6HXYaOgHrUs7mvPuMJkx48OvVkSmGjaOJ_Rtth...> *中文：**https://zh.main.whoisxmlapi.com/* <https://secure-web.cisco.com/1Jg5W7wgvG8hNYDVfPt4h5Hg7EiLVKsKCC-UINN1PR5rX9F...> *日本语 ：**https://ja.main.whoisxmlapi.com/* <https://secure-web.cisco.com/1bhfrIEZMiPghCvJvStGu1OSPrKJKmxVDKlYr2HESvyT86X...>
LinkedIn : https://www.linkedin.com/in/chiao/ Book a meeting now: https://calendar.app.google/9neWrkwvhPHRqGZ86 <https://secure-web.cisco.com/1OG5PtqhWfaTdOV3637C_tKP2GmxnPyjqaEWEqTNefJCd-Y...> _______________________________________________ Gnso-dnsabuse-pdp mailing list -- gnso-dnsabuse-pdp@icann.org To unsubscribe send an email to gnso-dnsabuse-pdp-leave@icann.org
_______________________________________________ Gnso-dnsabuse-pdp mailing list -- gnso-dnsabuse-pdp@icann.org To unsubscribe send an email to gnso-dnsabuse-pdp-leave@icann.org
I feel like we are going around in circles here and would just reiterate that it does not make sense, nor is it scalable, to conduct a full investigation before the ADC occurs, especially if such investigation searches information that is not even within the registrar’s possession. That aside, the requirement of an investigation/use of signals also contradicts the charter of this PDP which seeks to create an obligation for registrars to investigate other domains associated with a customer account or registrant where at least one domain of that registrant is found to be engaged in DNS Abuse, as defined in the RAA, and thus is out of scope for this PDP. For the latter reason, just like we are not discussing compromised domains or ADC across registrars which are outside the scope of this PDP, I would propose that we foreclose further discussion on ADC triggers other than one domain name where there is actionable evidence of DNS Abuse as it just takes up time that could be spent addressing other unresolved questions and points that are within the scope of this PDP. I understand that some may not like the trigger for ADC being actionable evidence of DNS Abuse on one domain name, and don’t seek or mean to denigrate that view in any way – but it just should not be open for debate in this PDP based on the clear language in the charter. The time for those arguments was in the charter creation stage which has passed. Best regards, Marc H. Trachtenberg Shareholder Chair, Internet, Domain Name, e-Commerce and Social Media Practice Greenberg Traurig, LLP Aspen Chicago 411 E. Main Street 360 North Green Street Suite 207 | Aspen, CO 81611 Suite 1300 | Chicago, IL 60607 T +1.970.300.5313 T +1.312.456.1020 M +1.773.677.3305 M +1.773.677.3305 trac@gtlaw.com<mailto:trachtenbergm@gtlaw.com> | www.gtlaw.com<http://www.gtlaw.com/> | View GT Biography <https://www.gtlaw.com/en/professionals/t/trachtenberg-marc-h> [Greenberg Traurig Logo] [Greenberg Traurig Logo] From: farzaneh badii via Gnso-dnsabuse-pdp <gnso-dnsabuse-pdp@icann.org> Sent: Friday, April 24, 2026 7:02 AM To: Nick Wenban-Smith <Nick.Wenban-Smith@nominet.uk> Cc: Ching Chiao <ching.chiao@whoisxmlapi.com>; anil Jain via Gnso-dnsabuse-pdp <gnso-dnsabuse-pdp@icann.org> Subject: [Gnso-dnsabuse-pdp] Re: ]ADC Should Be Triggered by Multiple Signals, Not One Abusive Domain *EXTERNAL TO GT* Hi Nick, just to be clear we are not saying don’t start any kind of investigation. We are saying before you go to ADC check based on one abuse report, check these other signals. In order to do ADC you need to have access to registrar backend or database. These other signals I mentioned don't need access to backend it's public information. are not (I managed to gather the signals without being a registrar, I am only a detective) So in effect, to find out about those signals you don’t have to do ADC as your first action as I demonstrated. Those signals along with abusive domain could establish the trigger for ADC. Farzaneh On Wed, Apr 22, 2026 at 11:02 AM Nick Wenban-Smith <Nick.Wenban-Smith@nominet.uk<mailto:Nick.Wenban-Smith@nominet.uk>> wrote: Hi Detective FB Thanks for the investigation and report; I think some contextual examples of when ADC can assist with abuse mitigation are really helpful when considering our policy deliberations. Sharing wider threat intel as between registrars and the wider security and LE community when a widespread attack is spotted could be an important part of a community response bearing in mind that threat actors will spread their attacks across multiple registrars and TLDs, both gTLDs and ccTLDs for that matter (NB not part of this PDP1 Charter but I digress). Just coming back to the multiple signals point, I think there is a risk of conflating the trigger for ADC, the investigations conducted by the registrar, and then the mitigation action taken by the registrar (if any), which I see as all discrete aspects of the policy work in accordance with the Charter instructions to us. What I don't follow with the multiple signals argument as part of the trigger test, is how with respect to a single proven maliciously registered abusive domain, the registrar could possibly know prior to doing some basic investigation at least, whether or not it is part of a wider campaign? In fact I'd go further than that and say that the whole point about the registrar investigation is to determine whether the trigger domain was a one off abusive registration (in which case nothing to see any further) or whether in fact due to multiple signals (or whatever we want to call them) it is clear that (as per your examples below) it could be part of a wider pattern of malicious registrations which therefore need investigation. And if it then found by the registrar that other domains are also abusively registered then they should be actioned by the registrar without separate abuse notifications needing to be filed by anyone. If they aren't abusive then the registrar obviously shouldn't take any mitigation action. But that will only become clear having done the investigation, with no wriggle room for wilful blindness on the part of the registrar. Given registrar friends on the PDP have already told us that they already conduct ADC it would be nice to understand whether I have understood this practice correctly and my analysis here is fair. If a wheel has already been invented then let's not get into different shapes and sizes and a set of competing standards, but document existing good policies which already work. Cheers all Nick ________________________________ From: farzaneh badii via Gnso-dnsabuse-pdp <gnso-dnsabuse-pdp@icann.org<mailto:gnso-dnsabuse-pdp@icann.org>> Sent: Wednesday, April 22, 2026 12:53 To: Ching Chiao <ching.chiao@whoisxmlapi.com<mailto:ching.chiao@whoisxmlapi.com>> Cc: anil Jain via Gnso-dnsabuse-pdp <gnso-dnsabuse-pdp@icann.org<mailto:gnso-dnsabuse-pdp@icann.org>> Subject: [MALICIOUS URLS, FILTERED][Gnso-dnsabuse-pdp] ADC Should Be Triggered by Multiple Signals, Not One Abusive Domain Caution: This is an external email and may be malicious. Please take extra care when replying, clicking links or opening attachments. Hi all, I just wanted to show you what we mean by considering other indicators rather than one domain to start ADC. You need multiple signals to trigger ADC, not just one abusive domain. Here's what those signals look like — and how even free agent Detective Badi undertook her analysis with zero equipment or use of intelligence firms (yes yes I know, when it scales it's harder.) Before diving in, here are the kinds of freely available, contextual indicators I can think of: 1. Is the domain on a blocklist? 2. Has it been reported before? 3. Does it relate to a documented, active campaign? 4. Does it share infrastructure (e.g. nameservers) that host a large number of malicious actors? 5. Was it registered during a period of heightened relevance to a specific attack target? 6. Is the registry going through a period of increased abuse? (check domain metrica) 7. Is the registrar going through a period of increased abuse? (check domain metrica) These paint a much richer picture than "one domain in a portfolio is bad, therefore ADC should start and every domain should be checked." This is not a formal NCSG position , but we've been saying for a while that ADC should be triggered based on a combination of such indicators/signals rather than profiling entire registrant portfolios from a single abusive domain. Ching's ADC examples inspired me to actually do this exercise and show what that looks like in practice. One caveat before I go further: I am not comfortable with these indicators. But they might be better than profiling domain name registrants and their entire portfolios based on a single abusive domain. --- THE TELEGRAM-HONG KONG CASE In Ching's examples I came across telegram-hongkong[.]com. This one is very interesting for me I worked on the use of Telegram in Hong Kong during the 2019 uprising. Here's the scenario: imagine this domain was registered around the uprising time in Hong Kong. Telegram was the most popular app during the uprising, and people were desperately trying to download and use it. A domain registered in that window, mimicking Telegram, could signal a systematic effort to cause security issues for a specific population at a specific moment. That's a genuinely good contextual indicator for triggering ADC — the timing and the target tell you something that the domain name alone cannot. But this is not without its complications. During that same period, people also ran apps that helped protesters track police locations, and dear Apple took those down. Now imagine that somewhere in an "abusive" portfolio, a couple of domains exist that were actually helping protesters. Authorities are actively requesting takedowns of such domains. What should the registrar do? Does their knowledge of those domains create legal or political exposure for them? The contextual signal cuts both ways. Which is exactly why context needs to be analyzed. For the record, Malwarebytes documented a campaign where attackers used malicious Google ads exclusively targeting people in Hong Kong, luring victims into downloading a malicious version of Telegram. So yes — this domain relates to a well-known, documented campaign. That's another signal worth noting. --- THE CRAIGSLIT / CALUDE CASE I do DNS abuse reporting as a hobby, partly to understand what doesn't work and what could be better. In one of my hunts I came across Craigslit[.]com. I reported it multiple times through different reporting mechanisms, it got suspended, and then, sigh, it's active again. What's interesting is that it used to share a nameserver that I have come across too often in abusive domain (like calude(.)ai But the name server can be rapidly changed so this metric should not be used on its own. Another signal: whether a domain has been reported before. I was excited to see that Domain Metrica claimed to have this kind of data — until it didn't actually tell me whether the domain had ever been reported, despite the fact that I know I reported it myself. This is admittedly a weak signal, but public reporting history is still better than snooping on registrant accounts. All in all, You need contextual, situational signals alongside the abusive domain to justify starting ADC — things like blocklist presence, prior reports, shared infrastructure, registration timing, and ties to documented malicious campaigns. These signals are freely available in the world. No special access required. No account surveillance needed. you can use abuse.ch<https://urldefense.com/v3/__http:/secure-web.cisco.com/1BZB0-EyjFrgCcD-rYQev...> and a myriad of free tools that can help you with your decision. Best regards, Detective FB Ching's ADC examples inspired me to do this exercise. This is not an NCSG position but we have been saying that the start of ADC should be based on different indicators instead of just if one domain is abusive, then we should trigger ADC. Before I begin, I want to be very clear that I am not comfortable with these indicators. But they are better than profiling domain name registrants and their portfolios based on one abusive domain. In Ching's examples I came across telegram-hongkong[.]com. This is a very interesting case. It was exciting for me especially because I worked on the use of Telegram in Hong Kong during the 2019 uprising. So the scenario is as follows: imagine if this domain was registered around that time. Telegram was the most popular app around that time and people would want to download it or use it. So perhaps if the domain was registered during that time, it could signal that it's a systematic effort to cause some security issues. So that's actually a good indicator to consider when wanting to trigger ADC. This is not without its shortcomings. During that period they also ran apps that would inform the protestors about the police location. Those apps were taken down by dear Apple. Now imagine if in this abusive portfolio, there are a couple of registered domains that help protestors. There is a clear request from the authorities to take down such apps/domains. What should the registrar do? doesn't their knowledge of existence of such domains create problems? Other factors that should be considered are: is the nameserver ... does the domain relate to a well known campaign (it does, Malwarebytes documented a campaign where attackers used malicious Google ads exclusively targeting people in Hong Kong, luring victims into downloading a malicious version of Telegram.) Anyway I continue. I do DNS abuse reporting as a hobby to understand what doesn't work, what could be better etc. In one of my hunts, I came across Craigslit[.]com. I reported this domain many times using different reporting mechanisms and it was suspended and now I see it's active again. But interestingly it shares the same name-server with my other hunt and that's calude.ai<https://urldefense.com/v3/__http:/calude.ai__;!!DUT_TFPxUQ!C-82eyzkswvC83wdr...>, They both use NS1.HASTYDNS.COM<https://urldefense.com/v3/__http:/secure-web.cisco.com/1l15LLs-tuNPu4mQFmRuu...> (the name server). Another signal can be if the domain has been reported before. I got excited to see domain metrica said it has such data but it didn't tell me if it was ever reported despite the fact that I know I have reported the domain name! (this is a weak signal, but again public data might be better than snooping on accounts etc). So what is the moral of the story. You need to have different signals (contextual situational) as well as the abusive domain to start ADC. Those signals are available for free out in the world and even Detective Badi without any equipment managed to do it. Farzaneh On Wed, Apr 15, 2026 at 7:01 AM Ching Chiao via Gnso-dnsabuse-pdp <gnso-dnsabuse-pdp@icann.org<mailto:gnso-dnsabuse-pdp@icann.org>> wrote: Dear all, Please review the attached 2023 research slides regarding typosquatting groups, which may be relevant to this PDP. In short, the research compares two different datasets -- typo groups vs. confirmed IoC domains . Feel free to ask any questions or comments via the list or privately. Best, Ching Ching Chiao 乔敬 Head of APAC & Corporate Development [https://secure-web.cisco.com/1c0QGVzG6OoEDdUdydWqsLkp6MF49CAygm3kmKuXOqx4C32...] Check our latest Internet Abuse Signal research: https://main.whoisxmlapi.com/blog/to-cache-a-predator-ilovepoop-toolkit-react2shell-cve-2025-55182<https://urldefense.com/v3/__https:/secure-web.cisco.com/1eTgThDAb10Uv7QOwH8grodWjkEkZ0kdzx4HtV2_ej-kLWG-LtTQcrD3YFD2F369TL163Nw4gfXcqX8y95r02oX_HX0bvdtTTrEQolC9M1hQzFMkz1inFWzOpnXrWPeer29iK0x1tQgscFiXivREP3Z_LxlJQRu-PFKOw5aI_OEkFC2Rr_IBSy9hdPvEvHT-zVB5q3KW2kUHRoiyAOtniTLsSWtS0JZ01DLS5yNlqehYRRdMOuiZz9bW-nAQUwhblmkadUY8Yb-YMuko6C_rbr1s2ZXNivtto-lN2kPWVUzGaeO-5HDgTYkDH2ZXBCUNa/https*3A*2F*2Fmain.whoisxmlapi.com*2Fblog*2Fto-cache-a-predator-ilovepoop-toolkit-react2shell-cve-2025-55182__;JSUlJSU!!DUT_TFPxUQ!C-82eyzkswvC83wdrUzik3inGE4xP4DgXxcPbE6o1Yf8rSiElzu-HvIT9jWOCDDk-rQlL2HoCswrc4xGKdRCCAWIJrg6hQ$> WhoisXMLAPI.com<https://urldefense.com/v3/__http:/secure-web.cisco.com/1rKYUKEeCa6HXYaOgHrUs...> 中文：https://zh.main.whoisxmlapi.com/<https://urldefense.com/v3/__https:/secure-web.cisco.com/1Jg5W7wgvG8hNYDVfPt4h5Hg7EiLVKsKCC-UINN1PR5rX9FgEoN53BPSmY_dk3LimmUCkImPjTs43lssxenZIFYO9tYcjr4gmt3RgV4Bc7LdWZTJuTEcC1FVrUFSWgOKgNLwA5ivtQ05cth_apRDzD0bR6PNlsTNNUGTxI-GJr3_vSfldhBRaNLq-e0eMASutwMQJLx1hB02qa2LAYLxqV4BE70T1JqMlJb9zP1MBpxuze23SXuVOz2kxyShqQ41O6JK4QHq2vo7iHMoAZSO64liKzRUk8XUvhvet6dKDyjcqsswZWmZHiqU19-sgmBuz/https*3A*2F*2Fzh.main.whoisxmlapi.com*2F__;JSUlJQ!!DUT_TFPxUQ!C-82eyzkswvC83wdrUzik3inGE4xP4DgXxcPbE6o1Yf8rSiElzu-HvIT9jWOCDDk-rQlL2HoCswrc4xGKdRCCAWiVOWWLw$> 日本语 ：https://ja.main.whoisxmlapi.com/<https://urldefense.com/v3/__https:/secure-web.cisco.com/1bhfrIEZMiPghCvJvStGu1OSPrKJKmxVDKlYr2HESvyT86XJCkSnk_y43YcrBtOm6-uFMJEdX5our8FN3vjA6_UGgQ_5tVL2t7FCwJhPhEhr8RfNWAiOpK6Sy-Ecz2U7QD0q7jlJa64hzAIvitOgLG17H2-qstkCcBJCdh2YFnFsrFzAEpFY7jm7M38Jv2EDApb9k242kpWiOyQIMg5b98cv0YDBXkkNy0iSOlEfUjP_X-WKyO5i2jlGOK8t5BIkPFr9cMZaUPCMj4dalJ8_cuNDZcP1VkShw8mYA1kbE-oL4vOXpW4EVqa76XRUqshUs/https*3A*2F*2Fja.main.whoisxmlapi.com*2F__;JSUlJQ!!DUT_TFPxUQ!C-82eyzkswvC83wdrUzik3inGE4xP4DgXxcPbE6o1Yf8rSiElzu-HvIT9jWOCDDk-rQlL2HoCswrc4xGKdRCCAXR5wu8tA$> LinkedIn : https://www.linkedin.com/in/chiao/<https://urldefense.com/v3/__https:/www.linkedin.com/in/chiao/__;!!DUT_TFPxUQ!C-82eyzkswvC83wdrUzik3inGE4xP4DgXxcPbE6o1Yf8rSiElzu-HvIT9jWOCDDk-rQlL2HoCswrc4xGKdRCCAWBR-jUNw$> Book a meeting now: https://calendar.app.google/9neWrkwvhPHRqGZ86<https://urldefense.com/v3/__https:/secure-web.cisco.com/1OG5PtqhWfaTdOV3637C_tKP2GmxnPyjqaEWEqTNefJCd-YPxj92znGH44bZESrEO6LzjO30JZYyHfbrkB3Uo5D1nfBnW5x08ZrrxY0MbaAPv-taad2cNz5SldMob0iPkS9K-v8b2hk9bc2hshkeNDhkeyhf5_621Z09kp2L3INHOTsP1kbNpaQJbcYsjWtwHcstmx47zF9eubWAGhPtU7JVjXzfR7d03eVzdDv8l9ey1DRA8i-vse9UnV_pSwf03T7Vt17fPxHfq2fZi73RGLwr-RqBwmiw5BCRsJgFXm2-_kb3i4lJ7oMsMb-1R-PzL/https*3A*2F*2Fcalendar.app.google*2F9neWrkwvhPHRqGZ86__;JSUlJQ!!DUT_TFPxUQ!C-82eyzkswvC83wdrUzik3inGE4xP4DgXxcPbE6o1Yf8rSiElzu-HvIT9jWOCDDk-rQlL2HoCswrc4xGKdRCCAVDZArVLg$> _______________________________________________ Gnso-dnsabuse-pdp mailing list -- gnso-dnsabuse-pdp@icann.org<mailto:gnso-dnsabuse-pdp@icann.org> To unsubscribe send an email to gnso-dnsabuse-pdp-leave@icann.org<mailto:gnso-dnsabuse-pdp-leave@icann.org> ---------------------------------------------------------------------- If you are not an intended recipient of confidential and privileged information in this email, please delete it, notify us immediately at postmaster@gtlaw.com, and do not use or disseminate the information.
participants (5)
-
Ching Chiao -
Eberhard W Lisse -
farzaneh badii -
Naoum MENGOUDIS -
trachtenbergm＠gtlaw.com