Folks,

I have been asked by several people to dust off a few of the use cases I worked up for the EWG and submit them to the current conversation.  I have the three below that are activities I’m intimately familiar with, having built systems, processes, controls, and an entire business around performing many of them, and am exposed to other operators in this space daily.  These are closely related but have different applications and requirements for handling.  Note that these are written up in the context of assuming an RDS system that would handle all manner of things like credentialing, access rights, purpose-driven access to data, etc. that are not present in the current whois system but are present to some extent in external databases of domain information.  So these are more describing a system as it could/should be while also describing current usage - important that you read these with that context in mind.

The three areas covered are:

Investigations of Abusive Domains
Finding domains that are registered and/or controlled by a particular miscreant or organization that are being used maliciously
Creating domain reputation scores

I will also note that while I point out that people in both LEA’s (Law Enforcement Agencies) and Ops-Sec (Private Sector Operational Security Personnel) utilize these techniques, by far, the most prevalent actors and volume “users” in these investigative roles are private sector investigators - security researchers, incident response teams, security companies, anti-spam services, etc. and not LEA’s.  This is an important part of how we shut down bonnets, keep your e-mail boxes from overflowing with the 95% of e-mail you don’t see due to anti-spam, and try to keep folks safe online.

I was reminded of this over the weekend as I was catching up on an investigation my own team has open tracking one of the most prevalent threats on the Internet today - the infrastructure that leads to people and companies being hit with ransomeware that encrypts their computers and holds their personal data ransom. I’ve quoted one of my team member’s use of whois data to track a miscreant that is giving all sorts of tells in their use of fraudulent domain registrations.  Of course I’ve redacted the particulars to protect the investigation, but by doing this work, we are anticipating the next generation of domains used in their attacks, blocking that for our own customers, sharing that with others so they can protect their customers or in the case of LE, advance their cases.  Almost every cybersecurity company with a decent research team uses similar techniques to stay on top of e-crime and protect their customers and the greater public.

Cheers,

Rod

Redacted excerpt of current Infoblox threat intel investigation:

I've decided to record what I've learned during my efforts to predict <Malware>’s movements. Here's what I've gathered so far:
# While the <Malware> operator regularly cycles the registrant names and email addresses used to register their fraudulent domains, they are less diligent in cycling the rest of their registrant information. For example, the domains {{REDACTED\[.\]REDACTED NEW GTLD}} and {{REDACTED2\[.\]REDACTED NEW GTLD}} both use identical address information (“REDACTED ADDRESS” in REDACTED CITY, REDACTED COUNTRY) despite having different information for the other fields. This behavior allows us to pivot from one identity to another by using the REDACTED SERVICE NAME reverse whois API.
# The domains are frequently (if not exclusively) registered with <ABUSED REGISTRAR> and remain on that registrar's nameservers until the actor is ready to use them for their attack. Once <Malware> is deployed to a domain, its nameservers switch to ones that are hosted on the same domain as the attack.
# The operator rotates the dictionaries used to generate their domain names on a fairly regular basis.
# In the event that we lose track of the operator's current dictionary and/or registration information, we can use our knowledge of their infrastructure (which is reasonably static) to generate a list of active threats. Analyzing these threats allows us to update our profile to match the actor's current behavior.
We can use this information to predict future <Malware> domains in the following ways:
# Searching the zone files for all domains that point to <ABUSED REGISTRAR>  nameservers and narrowing that list down by using our list of known <Malware> dictionary words and/or registrant information.
# Searching the zone files for nameservers that point to known <Malware> IPs, then taking registrant information from those domains to find domains that have been registered but aren't currently hosting <Malware>.
# Searching the zone files for domains that match our known <Malware> dictionaries, then comparing their infrastructure and registrant details with the same information from known <Malware> threats.
# Monitoring the zone files over time, watching for domains that are first recorded on <ABUSED REGISTRAR>  nameservers and later switch to hosting their own nameservers.
# Taking registrant information from confirmed <Malware> threats and making reverse whois queries to unearth additional registrant identities along with their associated domains.