# Threat Classification Sources

> Threats can be classified by Spectra Core, Spectra Intelligence, dynamic analysis, or manually overridden. This page also contains a list of all possible classification reasons for a sample.

In addition to classification from the [Spectra Core](/General/AnalysisAndClassification/SpectraCoreAnalysis) engine included in the Spectra Analyze appliance, the threat classification for samples comes from either the Spectra Intelligence service or an on-premises T1000 File Reputation Appliance.

Appliance administrators should configure access to the desired reputation service (Spectra Intelligence or T1000) via the [System Configuration](/SpectraAnalyze/Administration/configuration-update/configuration/) page. **Only one of those services should be configured, not both. If both are configured, the T1000 service will be used by default.**

If the appliance is not connected to the Spectra Intelligence or to the T1000 appliance, then no classification or AV scan information (malicious, suspicious, known) will be present. However, classifications will still come from Spectra Core (RHA1, signatures and so forth), which is locally installed on the appliance.

When either the Spectra Intelligence or the T1000 reputation service is properly configured, the sample threat status will incorporate data from Spectra Core and from the configured reputation service.

## Threat Classification Descriptions

The following is a list of all possible classification reasons a sample can have. The classification reason specifies which technology detected this threat. It is visible on the [landing page of the Sample Summary page](./sample-details-summary.md) and in the expanded row on the Search & Submissions page. Files will usually have multiple detections from more than one classifier, but the classification reason tile on the Sample Summary page always shows the one that produced the final classification.

**Note: The list of classification reasons can be expanded by enabling the [Risk Tolerance](../Appendix/risktolerance.md) preview feature.**


### **Classified by: Threat Reputation**

The sample was classified by the Threat Reputation scanner.

### **Classified by: Certificate Validation**

Digital signatures include a file integrity validation hash. Validating digital certificates is a multi-step process. Valid certificates have a properly formed digital certificate chain and pass file hash integrity validation. Spectra Core detects signed file tampering and is capable of detecting signer impersonation, certificate malformation and content modification. Failing to comply with any of these checks will classify the file as at least suspicious. The displayed threat name will reflect the detected type of the tampering attempt. When a self-signed certificate is trying to misrepresent itself and emulates a trusted certificate, the displayed threat name will be `{Platform}.Certificate.Impersonation`. On the other hand, when a file fails integrity validation, the threat name can appear as `{Platform}.Certificate.Invalid` or `{Platform}.Certificate.Malformed`. In case of valid signing time, with signature that is created after signing certificate is already expired or revoked by Certificate Authority, threat name will be `{Platform}.Certificate.SignedAfterExpiration` and `{Platform}.Certificate.SignedAfterRevocation` respectively.

### **Classified by: Threat Signature**

Rules, Indicators, Classifications and Capabilities (RICC) is an offline database that applies static analysis rules to analyzed content. Part of its responsibility is to classify files based on signatures and unique metadata properties found only in malicious files. Two such classification technologies are deployed through RICC. Byte Pattern Matches as signatures that detect known threats, and Malware Artifacts Classifier that looks at the metadata for malware clues. Both of these technologies correlate the detection to a named threat. In terms of classification, they are the most specific detection technologies within the engine, and are reserved to be used only for precise threat detections.

### **Classified by: Format Structure**

The sample was classified based on the format structure of the file determined by Spectra Core. Spectra Core contains a large collection of file format parsers. Some file formats are used exclusively by malware, while other, “legit” file formats, can be structured in a suspicious manner. Samples containing those file formats receive this classification.

Unlike file or threat reputation results, this classification method is not constantly updated. New information and signatures for this method can only be obtained by updating the entire appliance to a new release.

### **Classified by: Email Contents**

Email messages are stored in structured file formats. This encapsulation includes email headers, message body and a number of attachments. Any of these components can be malicious and therefore needs to be inspected. Email headers are checked for identity misrepresentation that relates to phishing and BEC attacks. Message bodies are inspected for URLs that could lead to phishing and malware downloads. Attachments are decomposed through static analysis in search for malicious code. Additionally, any attached file is also inspected for embedded URLs that themselves are checked for malicious intent. When this technology detects phishing, it will name the threat as `Email.Phishing.{ServiceName}`. The following services can be identified: Adobe, Amazon, AmericanExpress, Apple, BankOfAmerica, ChaseBank, DocuSign, Dropbox, Ebay, Facebook, Google, LinkedIn, Microsoft, Netflix, PayPal, Twitter and WhatsApp. If the email was detected as malicious due to embedded URL, the threat name can appear as `Email.Hyperlink.Homoglyph`

### **Classified by: Exploit Signature**

During engine analysis, parsed format structure is validated and any departures from specification are reported. Detected malformations are automatically mapped back to exploits that are known to abuse format parsing bugs. Exploit detectors are a special kind of signature detection. They are implemented individually for each supported format, and are made to detect known exploits. Exploit detection is available for images, documents, archives and mobile application package formats. When an exploit is detected within an image format, the reported threat name can be `{Platform}.Exploit.CVE-{ID}`.

### **Classified by: File Contents**

During automated file extraction, the supported formats are decomposed recursively. Unexpected format combinations can be discovered during extraction. For example, documents and multimedia files should never embed executable files. If such unusual format combinations are discovered, the engine will declare those files as suspicious with the following threat name: `{Platform}.Format.Content`.

### **Classified by: Explainable Machine Learning**

Machine learning is a predictive detection technology. Explainable Machine Learning, a concept unique to ReversingLabs, bases its classification on the principles of expandability, transparency and relevancy. Based solely on human readable indicators, machine learning models detect specific threat types and can differentiate between threats and benign files. When the machine learning model predicts that a threat type falls into a recognized category, it will name the threat as `Win[32|64].{ThreatType}.Heuristic`. However, if the model is certain that the file is a threat, but can’t place it into a threat category, it will name the threat as `Win[32|64].Malware.Heuristic`. Machine learning models are made to detect Windows executable and fileless malware types.

### **Classified by: File Similarity**

ReversingLabs Hashing Algorithm (RHA1) is a proprietary functional file similarity algorithm. It is primarily designed for executable formats, and as such it is specifically implemented for each supported format. RHA1 converts functional file features, both the code and its layout, to four precision level hashes. Each precision level represents a 25% increase in similarity between files that share the same hash at the same precision level. Lowest precision is 25% and highest is a 100%. Spectra Core comes with an offline database of blacklisted RHA1 hashes. This technology is capable of detecting polymorphic threats and their variants. Even though threats are detected based on similarity, they are still named after the threat the file is most similar to.

### **Classified by: Embedded HyperLink**

Many file formats enable active linking to content hosted on remote servers. These are commonly referred to as hyperlinks or uniform resource locators (URL). Since the active content is on a remote server, it can change at any time. However, some URLs themselves do contain information that helps to infer the content type to which they are pointing to. With static analysis, Spectra Core can detect various kinds of deceptive links without visiting the content targeted by the URL. Attacker techniques such as typosquatting, domain spoofing, and homoglyphs are detected for more than 5000 popular websites. In addition to deceptive links, the solution includes an offline database of blacklisted domains and known malicious URL patterns. When the engine finds an embedded link that points to a blacklisted domain, it will name the threat as `{Platform}.Hyperlink.Blacklisted`.

### **Classified by: Goodware Override**

Any files extracted from a parent and whitelisted by a high trust certificate, source or user override can no longer be classified as malicious or suspicious. Goodware Overrides propagate from parents to children. The goodware overrides will not apply if the extracted file is found by itself (for example, if an extracted file is rescanned without its container).

### **Classified by: Extracted Files**

The classification of certain samples originates from children samples extracted during analysis. It propagates from children to the parent, for example from a malicious executable file to the zip archive where it originated from. If this is the case, the description beneath the classification will highlight that it was based on an extracted file.

### **Classified by: YARA Rule**

The sample was classified based on YARA rules provided by ReversingLabs or by the user.

### **Classified by: NextGen Antivirus**

Sample was classified by an antivirus engine considered to be next-generation, such as those that use machine learning.

### **Classified by: File Reputation**

The sample was classified by Threat Intelligence Database. It can be obtained from a trusted source, or it was unpacked from the file originating from a trusted source.

### **Classified by: User Classification**

The sample has been manually classified locally or in the Spectra Intelligence cloud, overriding any classification from ReversingLabs. Local classifications only apply to the Spectra Analyze instance they are set on, while cloud overrides get synchronized to other ReversingLabs appliances using the same Spectra Intelligence account and to other cloud accounts with the matching company username segment (u/**company**/user)

### **Classified by: Spectra Core Classification**

The sample was classified by the Spectra Core static analysis engine.

### **Classified by: Certificate Reputation**

Applications, archives, documents and software packages can all be digitally signed. These signatures guarantee integrity and certify the origin of the content they are signing. Spectra Core comes with a customizable list of signers, or identities, that own recognized certificates. These identities can be added to either the Spectra Core certificate blacklist or whitelist. The former will declare signed content as malicious, while the latter will classify analyzed content as goodware. When a file is declared to be malicious due to a blacklisted certificate, the threat name will be displayed as `{Platform}.Certificate.Blacklisted`

### **Classified by: Sandbox**

The sample was classified by the ReversingLabs Cloud Sandbox.

## Setting Custom Classification

Users can manually override a sample’s classification:

- by selecting the **Set classification** option in the actions menu (☰) in the [Results List](../search-page.md#results-list) list, or in the *ACTIONS* menu on the [Sample Details](./sample-details-summary.md) page
- by selecting the **OVERRIDE** option in the *ReversingLabs Analysis Table* on the Sample Details page

Selecting either of those options opens the *Set classification* dialog. It consists of two tabs: **Spectra Intelligence** and **Local**. They are identical in design, but behave differently.

Local classification overrides persist only on the current Spectra Analyze appliance, they are not propagated to any other service or Spectra Analyze instance. Spectra Intelligence overrides get synchronized to other ReversingLabs appliances using the same Spectra Intelligence account, but also to other Spectra Intelligence accounts with the matching company username segment (u/**company**/user).

Samples that have both the local and the Spectra Intelligence override will be classified according to the local override.

Users can change the sample classification by modifying the threat status and trust factor values of the sample. Clicking **Save** in the dialog applies the new classification to the sample.

![Set Classification dialog with options to modify the risk score](images/analyze-set-classification.png)

For every sample classified in this way, manual classification changes are recorded in the **Sample Details > Timeline** section.

Any user of the current Spectra Analyze instance can manually change the classification of any file submitted to the appliance, regardless of who submitted the file.

For both local and Spectra Intelligence overrides, users who wish to closely keep track of classification changes to their important files should [create an alert subscription](../alerts.md#creating-a-new-alert-subscription) to get notified as soon as there is a change (by another user or by any of the ReversingLabs classification methods).
