Domain Infringement Events

Domain Infringement events are available to External Threats customers subscribed to the Domain Threats module. They alert customers to third party-owned domain and subdomains names that are confusingly similar to branded terms or trademarks. This is a common way for threat actors to spoof your organization’s identity and use that domain to carry out phishing attacks, divert traffic to ads, and/or otherwise deceive Internet users into mistakenly believing that your organization is the source of the content being presented to them via that domain/host.

When such an infringing domain is found, a Domain Infringement event is created in the workspace which can be viewed in the the events dashboard and events list inside the RiskIQ web application, in an email alert, or via the RiskIQ events API.

For a general introduction to events and other parts of the RiskIQ system, please see RiskIQ Platform Architecture.

This article describes :

  1. How to read and interpret the information presented in a Domain Infringement event (field definitions)
  2. Suggested best practices for Domain Infringement event management, including user workflow and tagging
  3. How it works: Domain Threats detection and system overview 

Example: an event showing a domain name related to the RiskIQ brand, but not owned by RiskIQ.

Reading Domain Infringement Events - Field Definitions

This is how Domain Infringement events are represented in the Events section of the RiskIQ web application. Clicking on a list item in the column on the left side of the screen brings up details for that event and user-initiated workflow actions in the panel on the right. 

Event List Item

  • Thumbnail screenshot of the webpage hosted on the domain that generated the event (if there is associated web content).
  • Event-Type: what kind of event it is (e.g. Domain Infringement).
  • Title: the domain/host associated to the event.
  • Status: current status of the event.
  • Created: date the event was generated.
  • Updated: date of the last entry in the event history.
  • Active: Domain Infringement events are considered active as long as the domain contains or is confusingly similar to a configured brand keyword, and is not either owned by the organization (confirmed as an asset in your Inventory) or otherwise whitelisted
  • Email-Capable:  whether the event  has a TXT/SPF record, determining what mail servers are allowed to send email on behalf of this domain name.
  • Tags ("Potential Acquisition Target" pictured above).

Event Header

At the top of each event's details is a header containing workflow actions. See Event User Actions for information on these options. 

This section also contains contains the event title and system tags, including the event-type name, active status, email-capable (if applicable), and classifier names that matched on this event (as of the last time we monitored it, ex. "Parking" is a classifier name pictured above), as well as user-applied tags (shown in orange to differentiate from system ones),

Summary Tab

The Summary page provides information for initially assessing the event and deciding how to act on it, including screenshots from the first and most recent crawls for the page (if the event domain has live web content associated to it, otherwise blank). 

ATTRIBUTES

  • Domain: infringing domain name.
  • Initial URL: the URL used as the starting point of the crawl
  • Final URL: the final destination where the crawl ended (i.e. if there was a redirect sequence, this would be different than the initial URL)
  • Domain Created: what date the first whois record for the domain was ever registered.
  • Domain Expires: what date the domain's current registration expires, or “Not Registered” if the domain is not currently registered.
  • Live Website: whether the domain has live website content associated to it (a non-zero http response code).
  • Parked Website: whether the domain is parked (as opposed to having a live website that is something other than a parking page).
  • Alexa: degree of web traffic indicated by the site’s Alexa rank (High = Top 1,000, Medium = Top 10,000, Low = 10,000+).
  • IP: the IP address this domain/host resolves to or redirects to (null if there is no http or https response)
  • ASN: autonomous system number (ASN) associated to the IP address for this event with the country of origin, and company (if applicable).

HISTORY

  • Timeline of changes made to the event with the date, time, and name of the user who took each action, including:
    • Status changes 
    • Emails sent (with recipients)
    • Notes added
    • Tags added/removed
    • Changes in ownership or priority

Whois

This tab displays current and historical Whois information associated to the domain. You can view historical records by selecting the date in the Change History list on the left side of the table. The icons next to the date indicate what values were changed in each new record. The right side of the table shows the values for each field contained in the record as well as the raw record in its entirety, with colors and + or - icons noting whether the value was newly added in this record (green +), removed in this record but present in the prior one (red -), or unchanged since the last record. You can choose to hide either the raw record or the changes if preferred. 

  • Record Updated: the date the last new record for the domain was found.
  • Last Scanned: the last time RiskIQ queried to find if there is a new record for this domain available.
  • Expired: when the registration of the selected record (if there are multiple) expires
  • Created: when the domain was originally registered (note: even if the original record is not available in full, this date often will be)
  • Registrar: name of registrar for the domain associated to this event.
  • Email: email address(es) to contact the registrant, admin, technical or billing contacts for the domain.
  • Name: name(s) of the registrant, admin, technical or billing contacts for the domain.
  • Organization: Org name(s) listed for the registrant, admin, technical or billing contacts for the domain.
  • Street / City / State / Postal Code / Country: Mailing address info / geographic location(s) listed for the registrant, admin, technical or billing contacts for the domain.
  • Phone: phone number(s) to contact the registrant, admin, technical or billing contacts for the domain.
  • Name Servers: name servers for the domain associated to this event

DNS

  • MX Records: mail exchanger records specifying mail servers that can be used to receive email on behalf of this domain name
  • TXT Records: Other text records associated to this domain's DNS entry--typically this is an SPF record, which determines what mail servers are allowed to send email on behalf of this domain name (if there is an TXT record, then the event will contain a flag in the event header and list item noting that the domain is "Email-Capable")

Site Details

If more detail is needed beyond what is shown in the summary tab, Whois, or DNS tab, this section provides any more information about the website associated to this event that is available, including:

  • CName
  • Additional ASN Information
  • Alexa Category and Exact Rank
  • Full IP WhoIs Record (includes raw response)
  • SSL Information
  • File Information

Classify Tab

This section details what about the page was flagged by the RiskIQ system in relation to your business logic. In the case of Domain Infringement events, typically this simply means displaying which of your configured keywords this event matched on (see the Domain Threats System Overview section at the end of this article for more details). 


If you have custom classifiers added in to your business logic, there might be other types of classifier results displayed as well, including properties in the domain, hostname, or the web page content, if there is content associated to the event. Domains and hosts are analyzed by RiskIQ in terms of the following common features. Each field can be targeted individually within your classifiers as needed. 

If you are a RiskIQ admin user looking for step-by-step instructions on creating/modifying Domain Infringement classifiers, policies, or projects refer to Setting Up Domain Infringement Events

Blacklist Tab

If this domain is included on blacklists, then this tab shows additional information on what reputation sources have reported this domain, whether the blacklisting applies to the entire domain, one host within the domain, or just specific URLs on the domain,  and for what type of activity (malware, phishing, or spam).

Enforcement Tab

If this event has been enforced, then this tab will appear to show additional information about any threat mitigation actions this event has been involved in, such as the date, the user who initiated the action, the recipients of the request, and the full text of the sent messages and any responses received in return.

Crawls Tab

Whenever an infringing domain is found, RiskIQ automatically checks to see if there is any live website content hosted on it or redirected to from it. If any content is found, we send a virtual user to investigate and monitor the webpage over time.

When applicable, this section houses information on each instance a page was analyzed by virtual users. Users can select from any of the times that RiskIQ analyzed the page associated to this event (red arrow next to the timestamp indicates, active, while grey signals inactive) to see details about the virtual user's interaction with the event page and user session overall at that point in time. 

Details provided about the crawl include: 

  • An overview providing metadata on the crawl and the screenshot taken by the virtual user
    • Global Unique Identifiers for the user session and the page within the user session
    • Date and time
    • Initial URL where the virtual user began the crawl
    • Browser used
    • Geographic location of the virtual user
    • Total number of pages visited during the user session
    • Total number of pages visited that returned error messages
    • URL of the event page
    • IP address
    • Response code and message returned by the event page
    • Page Content-type
    • Page Content length
    • Page response time
    • Window name
  • The original HTML response of the page
  • The rendered document object model after the page loaded in the user's browser
  • Files
  • Cookies
  • Links
  • Headers

Managing Domain Infringement Events - Workflow and Tagging Best Practices

User Review

The flow chart below describes a decision tree encompassing best practices for reviewing Domain Infringement events. It describes in more detail the 'User Review' step in the System overview diagram at the end of this article.

  • Green represents steps taken automatically by the RiskIQ system
  • Pink represents steps taken by a human user
  • Blue represents the result of an action (e.g. a status or tag label)


Tag Set

  1. Authorized Site
  2. Phishing/Malware
  3. Traffic Diverter
  4. Undetermined
  5. Other

Domain Threats System Overview

Detection

RiskIQ detects Domain Threats based on our PDNS and WHOIS databases as well as our crawls. From these sources, we derive NOD (newly observed domains) and NOH (newly observed hosts) feeds, which we then compare to the keywords and policies configured in each workspace. For NOD, this process occurs hourly. For NOH, it occurs daily. We process each domain and hostname through several steps to find both infringing domain names as well as subdomains/hosts during the inspection vs. workspace policies:

First, we convert any Punycode-encoded hostnames to ASCII and map homoglyphs to their ASCII equivalents.  Many threat actors try to hide domain threats by creating domains that use non-ASCII characters that will display similarly to ASCII characters – for example, "riskiqbånk.com" instead of "riskiqbank.com."  Since URLs may only contain a limited number of characters (a subset of ASCII), these hostnames will be encoded via Punycode.  For example, "riskiqbånk.com" will be encoded  as "xn--riskiqbnk-ora.com."  A web browser would then decode this hostname and display it as "riskiqbånk.com" to a user.  This step ensures that the domain or hostname we analyze is what a user would likely interpret it to be (in this case "riskiqbank.com").

Next, we compare the similarity of observed domains and hosts to the brand keywords configured in a customer's workspace, including exact matches, regular expression matches, and/or "fuzzy matches" as specified in the config. While a basic string distance or other simple algorithms may give us words that are roughly similar, it will not interpret a hostname as a human user would and may result in both missed detections as well as false positives.  For example, "friskyband.com" has a small word distance to "riskiqbank.com", but a human user would not think that "friskyband.com" was somehow associated with the brand "RiskIQ Bank."  

In order to mimic most closely how a user would interpret a hostname, we augment simple word distance calculation with a dynamic programming approach to parse a domain into its most probable word segments.  For example, the parser would deduce that "riskiqbank.com" should be tokenized as "riskiq / bank / com."  Since many domain infringement attempts will take advantage of common misspellings and common "fat finger" typos, such as "riskiqbanck.com" or "riskqbank.com" or "riskiqvank.com," the parser will also look for slightly misspelled words when it parses a hostname.  

Then an algorithm developed by the RiskIQ Data Science team uses several features of the parsed hostname to consider the context, such as whether it includes the keywords we are looking for, whether they are they misspelled,  and how many other 'real' words are in the hostname (vs. random characters) to decide if a hostname is likely infringing or not. Notably this approach can also handle infringements that "span" multiple parts of a domain as an additional layer of obfuscation that's becoming increasingly popular with threat actors. For example ("risk.iqbank.com")

System Overview

The diagram below follows a Domain Infringement event through the RiskIQ system from a domain or host first being observed,  through the event creation and monitoring, including enforcement procedures to resolution, and post-resolution monitoring if applicable. 

  • Green represents steps taken automatically by the RiskIQ system
  • Pink represents steps taken by a human user (refer to User Review diagram above for a detailed view of this step)
  • Blue represents the result of an action (e.g. a status or tag label)

Monitoring and Auto-Resolution

  • Domain Infringement events are monitored at least every 48 hours, or instantly whenever a Whois or DNS change is observed if sooner than 48 hours since the last monitoring check. Additional samples of events can occur outside of this schedule if a URL on the domain/host happens to be crawled again for other reasons outside of the scheduled event monitoring. 
    • Monitoring times are somewhat rough--to balance load across the entire system, so crawls may be slightly advanced or delayed to prevent road spikes.
  • Domain Infringement event monitoring includes re-checking that the domain/host is not in inventory and is still a policy violation to determine whether the event is active or not. After that, the system then tries to crawl the domain/host with "http://" or "https://" appended in front of it. If either crawl gets a non-zero http / https response, that crawl / snapshot will be included with the event for additional context, however, a successful crawl / live website is not required for the event to be active.
    • If both crawls succeed, the first one (starting with http as the initial URL) is used as the sample shown in the event's crawls tab
  • Upon the first inactive monitoring check of an event, an additional check will be scheduled 12 hours later to confirm whether it should resolve or the first one was an anomaly.
  • Events in the Monitor status will automatically change to Tenacious immediately upon a Whois or DNS change being observed.
  • An event will automatically resolve after 2 consecutive inactive monitoring checks that are at least 1 hour apart.
  • Events change from Resolved to Tenacious if the next monitoring check is found to be active.