Putting DNS Abuse into context.

We are currently working on a project to provide abuse monitoring information to our customers.
Giving our customers just the raw data is not helpful, so our goal is to contextualize the data.
We still have long ways to go, but the basics are there.

So what do I see right now on our platform?

 

  • Malware (67%)
  • Phishing (23%)
  • The rest falls into somewhat general buckets like BEC fraud, DGA, botnets, dark lists, crypto mining, etc. Very low incidental percentages.

The above-mentioned data is from two years of monitoring.

On the left is displayed the overall abuse percentage since 2018. And yes, the abuse levels are low, certainly if you compare them with the registrar statistics from Spamhaus.

Malware is the biggest problem.
The number of domains used in malware is low (2.71%).
However, the number of URL’s is high (94.24).

When I dive into information, it becomes clear that Emotet a “Crime As A Service” is the biggest threat actor (operational since 2014).

Emotet does not get noticed much by registrars. Due to tactics, techniques, and procedures (TTP) used by these criminals, they do not require domain names. Meaning there is no registration data; there is no money trail; there is simply nothing at the registrar level.

Emotet hacks web and hosting services to deploy their malicious payload and essentially operates a botnet through these hacked services.

I think, however, that when we release contextual information, things will change. I suspect that situational awareness will provide enough info for our customers to harden security.

Currently, we are fine-tuning the data we download from https://pulsedive.com.
Pulsedive will provide our customers with a more granular level of detail. The data provided at Pulsedive is usually used by Security Operation Center Analysts to turn information into actionable intelligence.

 

 

Streamlining domain name abuse reports and disclosure requests

We released a few new features, one of them, RDAP reseller Vcard. 

To further streamline abuse reports & disclosure requests, Realtime Register introduces the Abuse Vcard. This Vcard will display your (reseller role) abuse contact details through RDAP. 

Showing your (external) abuse contact information will increase the speed of abuse reporting. 

Internal abuse email address/information. 

Resellers can also enter abuse contact information for our abuse & support staff. 

We are not setting requirements here for our resellers, but it would be good if this email address is monitored 24/7. We intend to use this info for emergency communications when dealing with security threats. 

Abuse Domain Manager

 

External abuse reporting address (RDAP). 

RDAP, the replacement of WHOIS, is role-based and supports Vcards. The general idea is that resellers supply their public abuse email address and Company name and telephone number. 

Once this information is present in our system, we will display the info through RDAP. We are confident that the use of this extra contact will streamline abuse reporting.  

Resellers can also assign an abuse contact information for sub-resellers or different labels using the branding management tool within the reseller account. 

At a later stage, we will incorporate such public abuse email addresses in our reseller lookup tool. 

Reseller lookup tool? Yes, just before the GDPR enforcement back in 2018, we introduced a reseller lookup tool to assist LEA’s and other third parties. 

https://www.realtimeregister.com/resources/locate-your-provider/

Reseller Lookup tool

For the reader who knows RDAP very well, yes, we are using the reseller role to display abuse contact information. 

We think that this a better use for now as we already have a reseller lookup tool. 

While RDAP supports many more roles, there is currently no standard for other roles. Once more roles are defined, we can add more info to RDAP. 

Data Protection Officer 

If your company has a DPO, please enter their contact information. While this would satisfy GDPR compliance requirements, there are multiple practical reasons: 

  • Registrant disclosure requests
  • More streamlined communication if there is a data breach. 
  • Improved communication if a data subject wants to exercise his or her rights provided by the GDPR. 

RDAP Output with Abuse Vcard

ICANN SSAD.

The ICANN community is still working on the Standardized System for Access and Disclosure (SSAD).

The details of how this is going to work are still being discussed.

 But we imagine that at some point, we want to automate disclosure requests as much as possible. 

The DPO contact role may, at some point, be used within the SSAD to send disclosure requests.

GDPR Art 27

For those of our resellers who need to comply with Art 27, you can now enter an email address of such a GDPR Representative.

Again this is to ensure better coordination between requestors and other third parties. 

The GDPR Representative data is not public in the WHOIS or RDAP. 

Please check our knowledge base on how to add this information to your into the Realtime Register Domain Manager.

Using Spiderfoot to combat domain name abuse/security threats

“Behavior reflects personality. The best indicator of future violence is past violence. To understand the “artist,” you must study his “art.” The crime must be evaluated in its totality. There is no substitute for experience, and if you want to understand the criminal mind, you must go directly to the source and learn to decipher what he tells you. And, above all: Why + How = Who.”
― John E. Douglas, Mindhunter: Inside the FBI’s Elite Serial Crime Unit

The above quote is also applicable when you deal with cybercrime investigations. Though registrars usually do not deal with serial killers, we do deal with a lot of security threats.
And security threats require a holistic approach to get to the Why + How = Who.
Lucky for cyber threat intelligence analysts, there is Spiderfoot created by Steve Micallef. Spiderfoot automates a lot of research and combines the data.

Spiderfoot Tree map

So let me run you through a typical abuse report and how I used to approach such a report.
Assume the domain name account-login.tld is reported for malware activities. The experienced investigator understands that such a domain name can be used for a lot of different things.

  • apple.com.account-login.icu
  • BankName.account-login.tld
  • YourCompany.URLaccount-login.tld

With just a few of the above examples, the potential scope of criminal possibilities has expanded from malware to spam to phishing and or account theft. BEC/VEC fraud is also associated with such domain names.

I also could be dealing with a poorly chosen domain name of a company that uses the domain name to let employees log in to a CRM. Here at Realtime Register, we also have a few domain names that, at first glance, reveal nothing about our business but are essential in our daily operations. Suspending such domain names even if there is a report of malware could be very tricky.
Not to mention the legal liabilities.
If the domain name is suspended and hundreds of employees cannot do their work, well, again tricky.

So what I lack here is actionable info.
The first action is to inform the reseller of the security threat report. Making sure the uptime is as low as possible is essential. The reseller might be dealing with an unmanaged VPS, which also complicates the matter.
I mention the unmanaged VPS with a reason. Often wholesale registrars are powerless to address the issue.
Wholesale registrars might not host anything or do not provide email services. But with some research, things might become actionable.

Weapons of choice.
So there are many tools out there that you can use for your investigation.
Virustotal.com can be used for a second opinion when dealing with malware or phishing. It has many more features, so check it out.

Do you want to check if subdomains are present for malicious practices? Well, try Sublist3r.

If you want to check co-hosted sites, DGA domains, or cybersquatting domain names on a server, check out RiskIQ community edition.
RiskIQ is also great for some first OSINT research and is just awesome when doing reverse domain name lookups through a Google or FB id.

You also want to check some threat exchanges like Pulsedive. Getting some info on past breaches and leak sites is also handy to known.
Doing a little research on the dark web through Intelligence X on the domain name could reveal actionable info also.

The need for speed
Checking all the mentioned sources would take a lot of time, most likely a full day to gather the information.
Not to mention, you need to analyze all the information.

So here is where Spiderfoot comes in.
Spiderfoot connects to all these databases and pulls that info for you.
One interface, one scan, and within 30 minutes, you usually have actionable information.
Through the report section, you correlate the data and collected evidence.
The evidence can be exported, which is a great plus if an officer of the law contacts you about a malicious domain name.
Usually, LE’s officers are somewhat surprised by the amount of data you have on a target.

Spiderfoot short overview

Reconnaissance, the first scan
The scan setting I use is always set to passive, and there are a few reasons for that.
-I do not want to alert the criminals that they are being investigated.
-The scan is a lot quicker, and it gives me enough results to understand the threat level.
-As I am not sure about what kind of technical infrastructure I am dealing with, I like to make sure I do not break something by accident. Having a reseller go berzerk on you is something you want to avoid for many good reasons.

By now, I have confirmation that either passing the security threat report to the reseller was enough.
Or I need to suspend the domain name?

I also might have evidence now that I am dealing with a criminal reseller.
Or criminals are abusing the services of our resellers. Either way, I need to act.
What action is required depends on many factors. In the past, we dealt with criminal resellers who registered a bunch of sleeper domain names.
Usually, it is best to take all those domain names offline before they become active. But again, there might be a situation where this is not the best course of action. For example, you do not want to alert the criminal just yet.
Or there is conflicting info that requires more investigation focus.

Versions of Spiderfoot.
There are several versions out there of Spiderfoot. My advice if you are going to use Spiderfoot go for the HX, aka cloud version. Visit the website here.

  • You have a centralized solution and reports for you and your team members in one place
  • Always the latest version
  • Instant access to new modules
  • No need to tinker around with Linux or Python

Overkill?
The above use of OSINT techniques and the use of Spiderfoot as part of a set procedure when dealing with domain names that are engaged in abuse might seem like overkill.
But too often, the reality is that we quickly detect patterns and can avoid future security threats and prevent fraud for our customers.
Usually, these fraudulent domain names are registered with stolen credit cards or stolen Paypal accounts.
As you can imagine, there is a monetary loss, not to mention there is paperwork involved.

No reports.
I want to highlight the fact that a lot of abuse goes unreported.
My first thought that the correct parties were contacted by skipping the registrar.
But often, I had to hear back that a hosting company wasn’t informed about the security threat.
Where the disconnect is located is unknown to me at this moment.
But perhaps the issue of the disconnect could be a discussion item for ICANN 66, as it appears there is a lot of low hanging fruit.

More Spiderfoot modules

For more information about Spiderfoot, check the website.
A word of advice for my registrar/registry colleagues.
While Spiderfoot automates a lot of tasks for you, it does not substitute experience.
Experience in cyber threat intelligence is required in your decision making. Again Why + How = Who.

.

Privacy by default account setting.

Today we introduce a new account setting called:”Default Privacy Protect setting”, which you can access by clicking here.

Setting disabled.

When selected, domain name registrations and transfers will not use our privacy service automatically. This is how it used to work for years.

Setting enabled when free (and available)

When enabled all domain name registrations and transfers will automatically use our privacy service. Regardless if you use WHMCS, our API or the domain name manager.

A list of available TLDs that can be used for this service is located here.

We keep recommending this service as it is unknown if gTLD registries will continue to publish the data in the WHOIS or not. Several large gTLDs will no longer publish the WHOIS, similar to how we will operate our WHOIS server. But some of them most likely will keep publishing registrant data.

Enabled (when available)

Same as above but also will use privacy services that are not free of charge. Please check the price list in your account if that is the case.

Registration

When you register a domain name you can override your account settings if required. Select the desired action from the drop-down menu.

Current Customers.

At the moment the default setting is not active, as mentioned earlier. Due to the new ICANN contractual regulations that have been rushed out of the door on 17-05-2018 this week, we are reviewing the option to turn this on for all customers. I apologize in advance for any inconvenience this may cause.

Post GDPR gTLD Transfers

Update: 25-05-2018

The procedure below is now live as per the ICANN temporary spec. I observe that not every Registrar was aware of the below situation. If you cannot transfer out your domain name(s) advise the gaining registrar to stop parsing WHOIS data and trying to send FOA emails to the registrant or admin contact, this will no longer work.

 

The new procedure has been communicated last week by ICANN to all registrars. To view this communication click here,

 

 

As mentioned in a previous blog the WHOIS will change drastically over the next few weeks.

At the moment when you start a transfer through the API or domain manager, our system sends an FOA to the registrant or the admin contact based on our contractual ICANN requirements. Once the FOA has been approved by one of the above contacts the transfer is requested at the registry,

 

Transfer solution post-GDPR

We will no longer send the incoming FOA, the auth code is sufficient to request the transfer on a registry level.

The losing registrar will still be required to send the outgoing FOA, the registrant can agree or decline the request. If there is no response from the registrant the transfer will be processed automatically after 5-7 days unless the losing registrar not acknowledges the transfer and cancel the transfer on their side.

Domain names that are set to transfer prohibited will not be transferred, if your customer wishes to transfer in or out, the transfer lock needs to be removed prior to the transfer. We recommend setting your domain names to transfer prohibited and regularly change the auth-codes for the domain names under your management for security reasons.

The above-described transfer process should not be to complex for most resellers, as it works somewhat similar how the larger ccTLD registries operate.

Recommended domain name security reading

A Registrant’s Guide to Protecting Domain Name Registration Accounts a report from the ICANN Security and Stability Advisory Committee (SSAC)

SSAC Advisory on Registrant Protection: Best Practices for Preserving Security and Stability in the Credential Management Lifecycle

Domain theft?

Though at first glance it seems the above changes might lead to more domain theft. This is counter mitigated due to the fact that the WHOIS info will no longer contain registrant data and email addresses. This info is usually an attack vector for hackers who steal domain names, with this attack factor no longer in play we expect to see fewer cases of domain theft.

Key transfer changes post GDPR summary.

  • Transfers will continue to require a valid authorization code; just like EU ccTLDs
  • The gaining registrar will no longer be required to send a Form of Authorisation (FOA) to the registrant, again most likely there is no WHOIS info to create one.
  • The losing registrar will continue to send an FOA (aka outgoing FOA) that allows the registrant or admin contact to ACK (acknowledge) or NACK (not acknowledge) the transfer;
  • If there is no action/response, the transfer will auto-ACK by the registry after five days from initiation of transfer;
  • Registration information will not be transferred as part of the IRTP-C, registrants will independently re-enter transfer information with the gaining registrar. This will include entering into a registration agreement with the new registrar as it is now.