Malware Hosting

This category represents a domain that is hosting static files containing malicious code. The formats of such static files include, but are not limited to:

• Windows PE executables
• Windows DLLs
• Linux ELF executables
• Linux Shared Object libraries
• Perl, Python, Ruby, and Shell scripts

Evidence

Indicators include one or more of the following observed within the past 72 hours:

• Domain provides access to a static URL path, (e.g. http://domain.com/directory/malware.exe) which contains content detected by at least 30% of VirusTotal anti-virus vendors as malware, not including signatures containing the substrings “PUP” (Potentially Unwanted Program) or “Adware”.
• Documentation must include VirusTotal analysis of the file, detection ratio, and malware classification summary (e.g. “trojan”, “bot”) for each file that has a unique SHA256 hash.
• SHA256 hash included in VirusTotal analysis must match the SHA256 hash of the content.
• Analyst must have reasonable suspicion that the signature matches are not false positives.
• Domain provides access to a static URL path which is determined to be malicious by a professional analyst, via dynamic analysis indicators including but not limited to:
• Network traffic matching signatures corresponding to known malware, as indicated by a Network Intrusion Detection System (NIDS) such as Snort or Suricata.
• Documentation must include VirusTotal PCAP analysis, or a similar analysis web service, indicating the NIDS signature matches.
• Network traffic indicating connection and channel join of an Internet Relay Chat (IRC) server, not initiated by the user. Small snippet of IRC protocol traffic should be included, as well as the IRC server domain.
• Other explicitly malicious behavior such as recording keystrokes, reading saved browser passwords, silently launching a Bitcoin (or related) mining application, or communicating with a server that has been identified by one or more third party services as malicious is observed by a professional analyst.
• All information related to the malicious observances must be documented.

Exploit/Social Engineering Kit Hosting & Collusion

This category represents a domain that plays a role in a “browser exploit kit,” which is defined as a web application that attempts to exploit vulnerabilities in a web client’s browser and browser plugins to run malware. Exploit kits will often use multiple domains, and multiple servers, as part of their infrastructure. Parts of this infrastructure is sometimes referred to as a Traffic Direction System (TDS). Domains participating in an exploit kit infrastructure include redirectors and domains hosting the exploit code.

This definition also includes domains containing pages that do not exploit software vulnerabilities but instead act as social engineering mechanisms, for example pages that trick the user into thinking their Java or Flash plugin needs to be updated and convincing them to run a malicious executable, or pages that provide access to a “chat room” which requires a malicious Java applet to run in order to join the room.

These do not fall under the “Malware Hosting” classification, as the actual malicious files that are eventually downloaded may be hosted on a separate domain.

Evidence

Evidence of a domain serving an exploit kit is determined by the presence of malicious client-side code on one or more web pages. Indicators include one or more of the following observed within the past 72 hours:

• Domain hosts Javascript, Flash content, Java applet, or similar browser client-side code that is detected by at least 30% of VirusTotal anti-malware vendors through either its URL scanning analysis or file analysis.
• Documentation must include link to VirusTotal analysis.
• Domain hosts client-side code that is flagged by a NIDS, or causes malware to be downloaded and/or ran as determined by dynamic analysis conducted by a professional analyst.
• Documentation must include all matched signatures, the name of the exploit kit family if known, and some form of evidence such as the URL pattern or Javascript being tied to an exploit kit.

Evidence of a domain serving a social engineering kit is determined by the presence of highly misleading content on one or more web pages that attempts to convince a user to download and/or run malware.

• Domain hosts content that attempts to entice the user to run a file that meets the requirements for the category of Malware Hosting (e.g. detected by at least 30% of VirusTotal anti-malware vendors).
• Documentation must include a screenshot of the social engineering page, plus the Malware Hosting requirements, except the malware does not need to reside on the domain. The screenshot should clearly include the URL, the misleading content, and some sort of prompt to download or run the malicious file.

Evidence of a domain playing a role as a redirector in a malware TDS or exploit kit infrastructure is determined by the observation of one or more techniques used to redirect a web client to an exploit kit, or to another redirector as part of a “redirect chain” to an exploit kit. The redirect may not visibly redirect the page, and instead may load the new content in an element on the current page.

The URL pointing to the next redirector or exploit may be identified in the following ways. Note that some of these may be set statically on the page, or are created dynamically by Javascript.

• The “Location” header of an HTTP 301, 302, 303, or 307 response.
• The “content” attribute of an HTML <meta> tag containing the “http-equiv=’refresh’” attribute.
• The “src” attribute of an HTML <iframe> tag.
• A URL set as the value of the Javascript “document.location” or “window.location” attribute.

The redirect/loading chain must be documented in full, and at least one of the domains in the redirect chain must meet the exploit kit or social engineering kit evidence and documentation requirements.

Botnet Command & Control

This category represents a domain which is hosting a command & control interface for a malicious “bot network” (botnet). Often these domains will host HTTP or IRC servers that provide an interface for a botnet operator to issue commands to infected hosts and direct them to launch DDoS attacks and send spam.

Evidence

Evidence of a domain acting as a command & control server for a botnet is determined by malware engaging in bidirectional communication with a server which it finds by resolving this domain, within the past 72 hours. Indicators include:

• An executable flagged by at least 30% of VirusTotal vendors as malicious is observed by an online dynamic analysis service to send network traffic to this domain, containing at least 10 bytes of payload data in total.
• Documentation must include link to VirusTotal behavioral analysis of a file, VirusTotal analysis of a PCAP generated by running that file, or a link to a reputable dynamic analysis service such as malwr.com, anubis.iseclab.org, or threattracksecurity.com. A brief summary of the traffic should be included, such as the destination IP address and port, protocol if known, and bot family if known.
• A link should be provided to the PCAP
• An executable observed to send network traffic to this domain is determined to be malicious by a professional analyst.
• Above documentation must be included, plus evidence that the network traffic to this domain is indicative of a botnet command & control protocol. Evidence may include links to reports from analysis services, and/or a PCAP + summary of the observed traffic, and why it is indicative of botnet communication.

Phishing

This category represents a domain hosting pages that try to entice a user to enter sensitive information, usually by impersonating another website or company. We will generally report phishing domains through our partner APWG.

Evidence

Evidence of a domain name being used for phishing is determined by the presence of one or more phishing pages hosted on that domain within the past 72 hours. Indicators include:

• Domain is hosting a page that clearly misrepresents itself, and attempts to gather a user’s name, email, password, answer to a security question, or other private information.
• Documentation must include a link to the phishing pages, a brief description of what it is trying to impersonate and/or represent, and a screenshot clearly showing the URL and the part of the page designed to harvest sensitive information.