# T1000 Documentation > T1000 threat intelligence appliance documentation. This file contains the documentation for one product, following the llmstxt.org standard. ## Shared documentation The concepts, classification rules, deployment requirements, and security configuration shared across all ReversingLabs products are in a separate file. Read it alongside this one: - [General concepts and reference](https://docs.reversinglabs.com/llms-general.txt) ## Spectra Core lookup tables These reference tables aren't included here — each is a large value-to-description table. Fetch one when you need to resolve a specific value: - [Spectra Core indicators](https://docs.reversinglabs.com/General/SpectraCore/indicators.md) — indicator ID to the behavior it describes - [Security grades and codes](https://docs.reversinglabs.com/General/SpectraCore/grade-codes.md) — security grades (A-F) and RC, WC, and SC codes - [Spectra Core certificate trust store](https://docs.reversinglabs.com/General/SpectraCore/cert-trust-store.md) — trusted certificates with serial numbers and thumbprints - [Spectra Core tags](https://docs.reversinglabs.com/General/SpectraCore/core-tags.md) — tag name to what it means ## T1000 # T1000 — Network Appliance for File Reputation ReversingLabs T1000 Appliance provides on-premises access to an up-to-date copy of ReversingLabs Spectra Intelligence, the industry's most comprehensive source for threat intelligence and data reputation files. With a local database, customers do not incur latency penalties and privacy risks associated with the Internet. The T1000 Appliance uses a NoSQL database optimized for data replication, and supports advanced searches across billions of file records in milliseconds. ## T1000 R1 and XG T1000 R1 and T1000 XG share the same core data model, but XG exposes additional sample metadata and analysis endpoints. While R1 supports only the TCA-0101 (Malware Presence) API, XG additionally provides TCA-0104 (File Analysis), TCA-0103 (Historic multi-AV scan records) and the XG-CFS forensic sampling service. **Info: The documentation for API endpoints titled TCA-XXXX is mirrored from ** [Spectra Intelligence](/SpectraIntelligence/API/FileThreatIntel). The functionality is equivalent in terms of requests: URL structure, request parameters, and so on. In terms of responses, certain information won't be present in T1000: - history - hashes that are not SHA256, SHA1 or MD5: - SHA384 - SHA512 - RIPEMD160 - scanner metadata: - version used for this scanning report - update timestamp Where such information is available with a direct call to Spectra Intelligence, T1000 will return `null`. When sending requests, use the username and the password created with the Appliance management interface. ### Response Status Codes | Code | Description | |----- | ------------------------------------------------------------------------------------------------------------------ | | 200 | The request has succeeded. | | 400 | The request could not be understood by the server due to malformed syntax. | | 401 | The request requires user authentication. | | 403 | The server understood the request, but is refusing to fulfill it. | | 404 | The server has not found anything matching the request URI. | | 429 | License has expired. | | 500 | The server encountered an unexpected condition which prevented it from fulfilling the request. | | 503 | The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. | --- ## Getting started with T1000 This guide walks you through authorizing the T1000 appliance, applying your license, creating an API user, and verifying the setup with a file reputation lookup. ## Prerequisites Before you begin: - T1000 appliance deployed and powered on (see [Deployment](./deployment.md)) - Network configured via the VM console (see [Management](./management.md)) - Access to a web browser on a machine that can reach the appliance IP - `curl` installed for API testing :::tip[Initial credentials] Your initial administrator username and password for the web management interface are provided by [ReversingLabs Support](mailto:support@reversinglabs.com). Contact support before proceeding if you do not have them. ::: ## Step 1: Log in to the web management interface Open a browser and navigate to the appliance management interface on port 10000: ``` http://:10000 ``` Log in with the default credentials provided by [ReversingLabs Support](mailto:support@reversinglabs.com). On first login you are prompted to set a new password — do this before proceeding. **Note: The web management interface may be unresponsive for 10–60 minutes after each restart while the database completes internal verification. Wait for it to become available before continuing.** ## Step 2: Obtain your license (authorize the appliance) The T1000 appliance cannot retrieve database updates or respond to API requests until it is authorized. Authorization links the appliance to your ReversingLabs account. 1. In the web management interface, navigate to **RL Appliance > Authorization**. 2. Copy the values from the following fields: - **Appliance Type** - **Appliance ID** - **Appliance Key** - **Appliance Version** - **Appliance Username** - **Expiration Date** (shows "N/A" on an unlicensed appliance — include it anyway) 3. Send all of these values to [support@reversinglabs.com](mailto:support@reversinglabs.com) to request your authorization token. 4. When ReversingLabs Support responds with the token, paste it into the **Token** field on the Authorization page. 5. Select **Authorize**. 6. Restart the appliance after successful authorization (**RL Appliance > Dashboard > Reboot**). After restart, the appliance begins downloading the latest database updates from Spectra Intelligence. The Authorization page will show the license expiry date and the number of available updates. ## Step 3: Create an API user REST API access requires a dedicated user account. The default admin account cannot be used for API calls. 1. Navigate to **RL Appliance > User Management**. 2. Enter a username (alphanumeric only, must not be `admin`). 3. Select **Add User**. 4. Note the generated 8-character password shown in the **User info** section. Usernames always have the `u/` prefix — for example, if you enter `analyst`, the full username is `u/analyst`. Use this full prefixed form in all API requests. **Note: Passwords are auto-generated and cannot be manually set. Use the **Reset password** button to generate a new one if needed.** ## Step 4: Verify with an EICAR hash lookup Once the appliance has downloaded its initial database update, verify it is working by querying the EICAR test file hash — a well-known test sample that every threat intelligence database should classify as malicious. ```bash curl -u "u/:" \ "http:///api/databrowser/malware_presence/query/sha1/list?format=json" \ -H "Content-Type: application/json" \ -d '{"rl": {"query": {"hash_type": "sha1", "hashes": ["3395856ce81f2b7382dee72602f798b642f14d45"]}}}' ``` A successful response confirms the appliance is authorized, the database has loaded, and API access is working: ```json { "rl": { "malware_presence": { "entries": [ { "sha1": "3395856ce81f2b7382dee72602f798b642f14d45", "status": "MALICIOUS", "threat_level": 5, "classification": { "classification": "malware", "type": "Virus", "platform": "DOS", "family_name": "EICAR-Test-File" } } ] } } } ``` If the response returns `UNKNOWN` or an authentication error, see [Troubleshooting](#troubleshooting). ## Troubleshooting | Symptom | Likely cause | Action | |---|---|---| | Web interface unreachable on port 10000 | Database verification still in progress | Wait up to 60 minutes after restart | | Authorization page shows "N/A" for all fields | Appliance not yet networked | Configure network via VM console first | | EICAR returns `UNKNOWN` | Database update not yet complete | Wait for updates to finish; check update status on the Authorization page | | API returns `401` | Wrong username format or password | Ensure username includes the `u/` prefix | | API returns `429` | License expired | Re-authorize the appliance and contact [support@reversinglabs.com](mailto:support@reversinglabs.com) | ## Next steps - [Configuration](./configuration.md) — proxy settings, certificate management, REST API protocol - [Management](./management.md) — network settings, DNS, NTP, password reset via VM console - [File Threat Intelligence API](/SpectraIntelligence/API/FileThreatIntel/) — full API reference for hash lookups and file analysis reports --- ## Deployment ## Appliance Deployment The T1000 virtual machine is provided as an OVA file or AMI file. When provided as an OVA file, it is stored on a USB HDD disk provided by ReversingLabs. A file containing the MD5 hash, e.g., `ReversingLabs-T1000-R1-YYYY-MM-DD.ova-md5` of the .OVA file is present in the root folder of the USB HDD. The method of deployment is standard for the underlying infrastructure. Follow one of these two resources for deployment: - [VMware vSphere](https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/7-0/vsphere-virtual-machine-administration-guide-7-0/deploying-ovf-templatesvm-admin/deploy-an-ovf-template-flex-and-h5vm-admin.html) - [AWS AMI](https://docs.aws.amazon.com/imagebuilder/latest/userguide/ib-tutorials.html) ## Minimum VM requirements for T1000 Virtual Appliance Shared requirements: - Virtual environment compatible with VMWare vSphere Hypervisor 5.5 (ESXi 5.5, Virtual machine hardware version 10) - 64 GB RAM - 16 CPU - All disks must be SSD Specific requirements: - T1000 XG: 18 TB free disk space (thin provisioning) with room to grow to 24 TB for the next 12 months (24 TB thick provisioning) - T1000 R1: 16 TB free disk space - T1000 AV: 20 TB free disk space --- ## Management The T1000 appliance must be configured on first boot. Network settings are configured via the VM console (reachable from vSphere Client or vSphere Web client) on TTY1. The VM console interface makes it possible to setup IP and DNS, run shutdown or restart procedures, and reset the web interface password. When connected to the VM console, a menu and basic information such as MAC, IP, and GATEWAY address are displayed on TTY1. The addresses visible in the screenshot below are only for illustrative purposes. Users need to use the addresses that are valid in their production network environments. First, choose how the appliance will obtain the IP - statically or dynamically (DHCP). Currently active setup is indicated with an \[active\] mark beside the menu item. ![](./_static/images/t1000-appliance-management-console.png) Use the numbers to select individual settings. For example, press 1 to choose interface, press 2 to configure a static IP address, and so on. Select values with `Enter`, confirm with `y`, or cancel with `n`. When specifying network settings, after changing them, wait for the *Network configuration has been saved* message, and then reboot the appliance. 1. **Interface selection**: The default interface is `eth0`, but this can be changed. 2. **Static IP settings**: - The networking information uses dotted decimal notation. - Specify each of the networking values (IP address, subnet mask, broadcast address, gateway IP address). 3. **Dynamic IP (DHCP) settings** 4. **DNS settings** 5. **NTP settings** 6. **Reset the password** - This resets the Web management interface password to its original default. 7. **Shutdown/restart** --- ## Configuration The T1000 appliance has a built-in graphical user interface that provides configuration options for authorization, proxy settings, dashboard, upgrade, user management, exporting and importing accounts, replicator endpoint settings, certificate management, and other system tool modules. Customers can access this interface in a web browser. **Note: The Web Management Interface is not fully usable while the database is going** through internal verification. Depending on the hardware, this process can take between 10 and 60 minutes each time the appliance is restarted. ## Web management To access the management interface for the first time, open the following address in a web browser: ``` ://:10000 ``` ![](./_static/images/t1000-web-login.png) On the login page, use the provided username and password to log in. After the first login, it is necessary to provide a new password and log in with it. When first started, the T1000 appliance contains no authorization data. This makes the appliance unable to connect to Spectra Intelligence, and unable to retrieve the latest updates. Furthermore, the fields for total remaining cloud updates, total cloud updates, and update status are blank. After authorization, T1000 will download the latest database updates from Spectra Intelligence. By default, feed updates will be retrieved from `https://data.reversinglabs.com/replicator/v1` on port 443.The Replicator URL can be changed in the T1000 Replicator Endpoint Module. When the appliance is authorized, the fields on the login page will contain information about the appliance status: - **Total remaining cloud updates** - the number of available updates not yet downloaded - **Total cloud updates** - total number of available updates for download - **Update status** - current status of downloaded updates To log out from the appliance, select **Logout** from the upper right menu that displays the username. ## Authorization The T1000 appliance needs to be authorized to be able to update the local database. Navigate to the main menu and select **RL Appliance > Authorization** to load the Authorization module. ![](./_static/images/t1000-authorization-module.png) If an email client is configured on the system, use the link on the right side under the **Authorize** button. If an email client is not configured, copy the content of the **Appliance Type**, **Appliance ID**, **Appliance key**, **Appliance version**, **Appliance username** and **Expiration date** fields and send it to support@reversinglabs.com. Note that in the unauthorized appliance state, the **Appliance Username** and **Expiration Date** fields will display as "N/A". ![](./_static/images/t1000-authorization-token.png) Copy the received token into the **Token** field and **Authorize** the appliance. After successful authorization, restart the VM. When the appliance is successfully authorized, create a user to access the REST API. ## Licensing The T1000 appliance uses licenses with expiration dates. In the initial phase, when the license is in an inactive state, certain modules (excluding the Authorization module), configurations and API access are restricted. In this state all displayed information will indicate "Your license is not activated." Upon successful authorization, all modules become accessible, and information regarding the license status and expiry date becomes visible within the Authorization module. ## Managing users This module manages users that are connecting to the REST API of the appliance. Navigate to the main menu and select **RL Appliance > User Management**. The username can contain only alphanumeric characters, and it cannot be `admin`. Usernames always have the `u/` prefix and must be used with that prefix. Usernames and passwords are case-sensitive. ![](./_static/images/t1000-user-info.png) When a user has been successfully added, the "User info" section will display the new username and its generated 8-character-long password. Users can be disabled, or deleted. Passwords cannot be manually changed, but a new password can be generated using the **Reset password** button. ### Importing and exporting accounts The exporting and importing accounts functionality is used to export or import an existing account database to or from another ReversingLabs T1000 appliance. Navigate to the main menu and select **RL Appliance > Export and import accounts** to access this functionality. **Note: When importing accounts with the same name (e.g., `u/test`), the existing** account(s) will be overwritten. ------------------------ The **RL Appliance** menu contains additional configuration options. - You can set a proxy (HTTP/HTTPS). - You can start/stop the appliance on the Dashboard page. - You can switch between HTTP and HTTPS for API access on the REST API Protocol toggling page. - Upgrading is done by uploading an upgrade file on the Upgrade page. The machine needs to be rebooted after upgrade. **Warning: Restart the appliance only if the upgrade was successful.** - The replicator endpoint page allows changing the URL for the replicator service. Custom settings here may break the appliance, so please contact support if you need a custom URL for the replicator service. **Changing this setting requires an appliance restart.** - The Certificate Management page allows replacing the SSL certificate and key for the web server. By default, the machine uses a self-signed certificate from ReversingLabs. ## Help The built-in ReversingLabs Appliance Help documentation contains basic information about the modules and the REST API provided by the T1000 appliance. To access this documentation, click the **help** link inside the search box. ## System configuration ### Network interfaces **Tools > Network Configuration > Network Interfaces** ![](./_static/images/t1000-network-interfaces.png) At the top, under **Interfaces Active Now** are the interfaces that are currently enabled and have an IP address assigned. All loopback, Ethernet and PPP interfaces will be shown, although not all will be editable. At the bottom, under **Interfaces Activated at Boot Time** are the interfaces that have been configured to be activated at boot. The two lists will not necessarily be the same, as some interface types (such as PPP) are not activated at boot time, and do not appear in the second list. #### How to change the IP address 1. If the interface appears under both **Interfaces Active Now** and **Interfaces Activated at Boot Time** (as most of the editable ones do), click its name in the lower list. This will open a dialog for editing its settings. 2. To assign a different address, enter it into the **IP Address** field. To enable dynamic IP address assignment by a DHCP server, select the **From DHCP** option. 3. If necessary, change the **Netmask** field. If the **Netmask** or the **IP address** fields are changed, the Broadcast address based on the new netmask and IP also needs to be set. 4. When editing an active interface, the **MTU** and **Hardware address** fields will be available. The **MTU** field should be edited only by experienced users because it can seriously impact network performance or completely cut the system off from the rest of the network. The hardware address should only be changed if the network card needs a different Ethernet address, which is rarely necessary. 5. If editing a boot-time interface, make sure the **Activate at boot?** option is set to **Yes** so that the interface is brought up when the system starts. If editing an active interface, make sure the **Status** option is set to **Up** so that it can be used immediately. 6. When done editing a boot-time interface, click the **Save & Apply** button to save changes for use at boot time, and to make them immediately active. When editing an active interface, just click `Save` to apply changes. #### How to configure routing **Tools > Network Configuration > Routing & Gateways** Any system attached to a large network needs to know the address of the default gateway. In some cases, the system itself may be a gateway as well - perhaps forwarding data between a local area network and a broadband connection. In this case, it must be configured to forward incoming packets that are destined for some other address. In some cases, the traffic destined for certain networks may have to be sent through another router instead of the default gateway. If more than one IP networks share the same LAN, the traffic for any of those networks must be sent using the correct interface. If either of these are the case on your network, static or local routes need to be configured so that the system knows where to send packets for certain destinations. To change the default gateway used by your system or enable packet forwarding, follow these steps. 1. Enter the IP address of the default gateway into the **Default router** field. 2. Enter the name of the network interface that must be used to reach the default router into the **Default route device** field. On some Linux distributions this field is optional, meaning that the system will set it automatically. On others, there is a **Gateway** field next to the **Default router** field. 3. To enable routing, set the **Act as router?** option to **Yes**. 4. On RedHat, Mandrake, MSC and Turbo Linux, static routes can be set up using the **Static routes** table. Each static route must be in a new row containing the following information: - In the **Interface** column, enter the interface that will be used to reach the router, such as eth0 - In the **Network** column, enter the address of the remote network, such as 192.168.5.0 - In the **Netmask** column, enter the network's netmask, such as 255.255.255.0 - In the **Gateway** column, enter the IP address of a router that knows how to forward data to the network, such as 192.168.4.1 5. On distributions mentioned in step 4, routing to additional IP networks can be set using the **Local routes** table. Each route needs to be in a new row containing the following information: - In the **Interface** column, enter the name of the interface that the LAN is connected to, such as eth1 - In the **Network** column, enter the address of the additional IP network, such as 192.168.3.0 6. Click the **Save** button when done modifying the settings. Any changes will not be activated immediately - instead, they will only take effect on the next boot. If the system's primary network connection is via PPP dialup, then the default gateway will be assigned automatically when connecting, and removed when disconnected. Therefore it is not necessary to set it up with this dialog. #### How to change the hostname or DNS settings **Tools > Network Configuration > DNS Client** Enter the new hostname (composed of letters, numbers, underscores and dots) into the **Hostname** field. Click the **Save** button to immediately apply the change. The browser will redirect to the main Network Configuration module page. If there’s a local DNS server running on the network, don't forget to update the entry for the reconfigured system there as well. To change the system's DNS settings, follow these steps: 1. Click the **DNS Client** icon on the main Network Configuration module page to open the configuration dialog. 2. Enter the addresses of up to three servers into the **DNS servers** field. If the first is not available, the system will try the second, or the third. Most networks will have at least a primary and secondary DNS server to increase reliability in case one fails. 3. The **Resolution order** field can be used to control where the system will look when resolving hostnames and IP addresses. Generally, the defaults are reasonable, with the `/etc/hosts` file listed first and DNS later. However, if NIS is used for hostname resolution, it must be selected somewhere in the order. 4. In the **Search domains** field, enter any domain names to automatically append to resolve hostnames. For example, if *foo.com* was on the list and the user ran the command `telnet server1`, then the IP address for *server1.foo.com* would be looked up. 5. When done modifying the settings, click the `Save` button. Any changes will take effect immediately in all programs running on the system. If the system's only network connection is via dial-up, the DNS servers may be assigned automatically by the ISP depending on the PPP configuration. ##### Editing host addresses On a small network with only a few systems, there is an option of not running a DNS server at all, but instead keeping the addresses of every system in the hosts file on each system. ![](./_static/images/t1000-address.png) To view the addresses on the current system, click the **Host Addresses** icon on the main Network Configuration module page. There will always be an entry for `localhost`, and probably one for the local system's hostname as well. If the system's IP address or hostname have been changed, the host addresses list will probably not reflect the change, which could cause problems. To change a host address, follow these steps: 1. Click a host IP address in the list, which opens the configuration dialog. 2. Enter the new address into the **IP Address** field. 3. Enter any hostnames into the **Hostnames** field. It is always a good idea to enter both the short and long forms of any hostname, such as `server1.foo.com` and `server1` so that both can be used. 4. Click the **Save** button. If there are no errors in the dialog, the browser will return to the list of hosts and addresses. Extra host addresses can be added by clicking the *Add a new host address* link above or below the list. There are no restrictions on the same hostname being associated with two different IP addresses, or the same IP address appearing twice in the list. ### Running processes This module can be used to view, kill, re-prioritize, and run processes on the system. When opened for the first time from the System category, the main page will display a tree of processes. ![](./_static/images/t1000-running-processes1.png) #### Starting a Process The module can also be used to run simple commands, either in the foreground so that their output is displayed, or in the background as daemons. This can be useful for running a command without having to login via telnet or SSH (or if a firewall is preventing a telnet or SSH login). The following steps describe the procedure for starting a process. 1. On the main page of the module, click the **Run** link next to the display mode options. This redirects to the dialog for starting a new process. 2. Enter the command into the **Command to run** field. 3. If the command is something that will take a long time to run, the **Run mode** option can be set to **Run in background** to automatically put the process in the background. To see the output from the command, leave the option set to **Wait until complete**. 4. Enter any input to be fed to the command into the **Input to command** field. 5. Click the **Run** button to execute the command. If the **Wait until complete** option was selected, any output from the command will be displayed. #### Viewing, stopping, or prioritizing a process To see the full details of any running process, click its **Process ID column** entry in any of the sections on the main page. This opens the process information page. ![](./_static/images/t1000-running-processes3.png) The process can be stopped with a `TERM` signal by clicking the **Terminate Process** button. Because this can be ignored by some commands, the **Kill Process** button can be used to send a `KILL` signal if the termination fails. Unless the process hangs inside a kernel system call, killing it is guaranteed to succeed. Other signals can be sent by selecting the type of signal next to the **Send Signal** button before clicking it. Some of the more useful signals include: - `HUP`: for many server processes, this signal will cause them to re-read their configuration files - `STOP`: suspends the process until a CONT signal is received - `CONT`: resumes a process that has been suspended by a STOP signal The information page can also be used to change the `nice` level of a running process, giving it a higher or lower priority. To change the priority of a process, select a new level from the **Nice level** list, and then click the **Change** button. Lower levels mean higher priorities, so a process with a nice level of 10 will get less CPU time than the one with level 5. ## Bootup and shutdown This module allows creating and editing scripts that run at bootup and shutdown time. The main page of the module displays a list of all available actions (whether or not they are started at boot), and a short description for each. ![](./_static/images/t1000-bootup-shutdown-module.png) To avoid the risk of losing data on the local hard drives, the system should always be rebooted or shut down with the appropriate commands, instead of turning off the power or pressing the reset button. If the system was improperly shut down, it will perform a lengthy file system check with `fsck` at next boot time if using a non-journaling filesystem. To reboot the system, follow these steps: 1. At the bottom of the Bootup and Shutdown module page, click the **Reboot System** button. This opens a new page prompting for reboot confirmation. 2. Click the **Reboot System** button on the confirmation page. The shutdown process starts immediately, and the current console session is automatically logged out. After all the shutdown scripts have been executed, the system will boot up again. The procedure for shutting down the system is nearly identical, and triggered using the **Shutdown System** button at the bottom of the page. --- ## T1000 R1 --- ## File reputation (TCA-0101) <_ /> --- ## T1000 XG --- ## File reputation (TCA-0101)(XG) <_ /> --- ## Historic multi-AV scan records (TCA-0103) <_ /> --- ## File analysis (TCA-0104) <_ /> --- ## Cyber Forensic Service (XG CFS) ## Introduction XG CFS provides all available cyber forensic Spectra Intelligence XG metadata for the requested sample(s) on the T1000 XG appliance. The service supports single and bulk queries. ## XG CFS Single Query Returns information for a single hash. ### Request - Requests can be sent using the GET method or the POST method. - Both methods use Basic Authentication. - Both methods support specifying hashes in the URL. - POST allows specifying hashes in the request body as form data. ``` GET /api/xg/cfs/1/hashinfo/lookup.{format} ``` ``` POST /api/xg/cfs/1/hashinfo/lookup.{format} ``` Path parameters: - `format`: Specifies the response format. Supported values: `xml`, `json` Query parameters: - `md5` - `sha1` - `sha256` Examples: ``` GET /api/xg/cfs/1/hashinfo/lookup.json?sha1=550a0e228ff317c74d62b668d260eb0a60bfeb39 ``` ### Response ```json5 { "hashinfo": { "peheadermetadata": { "version": "", "description": "", "language": "", "companyname": "", "originalname": "", "codepage": "", "productname": "", "productversion": "", "fileversion": "" }, "fileinfo": { "firstseendateutc": "2024-12-09T16:49:11Z", "iscontainer": false, "crc32": "", "filesizebytes": 11401, "ssdeep": "", "md5": "9c966d6b81788f1a0026aef16355927a", "sha1": "00020c16c9a3f1ba16f0d339bdca3d64af4eb12a", "ispeformat": false, "firstseenname": "", "sha256": "fc2a50fff96621a8e72916d4feca6aaf773da8eb17422f1a9645348ee9f28c8a", "isexecutable": false }, "trust": 8, "threat": 0, "certificate": { "commonname": "", "certificateexinfo": { "validfromdateutc": "", "publisher": "", "issuerthumbprint": "", "name": "", "serialnumber": "", "validtodateutc": "", "thumbprint": "" } } }, "request": "/api/xg/cfs/1/hashinfo/lookup.json?sha1=00020c16c9a3f1ba16f0d339bdca3d64af4eb12a" } ``` The response contains one top-level `hashinfolookup` object for the requested hash. The `request` object contains the data submitted in the request. The response code 404 is returned with a message "Missing Hashinfo for sample" when a hash is not found in the database. `hashinfo.certificate` - `certificateexinfo`: Detailed view of certificate information for the requested hash. Contains metadata such as thumbprint of certificate issuer, certificate name, certificate publisher (organization name), certificate serial number, certificate thumbprint, date the certificate is valid from (in UTC), date the certificate is valid until (in UTC). - `commonname`: The certificate common name. --------------- `hashinfo.fileinfo` - `crc32`: CRC32 value of the requested hash. - `filesizebytes`: Sample size in bytes. - `iscontainer`: Indicates whether or not the requested sample is a container. - `isexecutable`: Indicates whether or not the requested sample is executable. - `ispeformat`: Indicates whether or not the file format of the requested sample is PE (Portable Executable). - `firstseendateutc`: First seen date of the requested sample (in UTC). - `firstseenname`: First seen name of the requested sample. - `md5`: MD5 value of the requested sample. - `sha1`: SHA1 value of the requested sample. - `sha256`: SHA256 value of the requested sample. - `ssdeep`: SSDEEP value of the requested sample (if available). ---------------- ` hashinfo.peheadermetadata` - `codepage`: Codepage metadata from the PE header of the requested sample. - `companyname`: Company name metadata from the PE header of the requested sample. - `description`: Description metadata from the PE header of the requested sample. - `fileversion`: File version metadata from the PE header of the requested sample. - `language`: Language metadata from the PE header of the requested sample. - `originalname`: Original name metadata in the PE header of the requested sample. - `productname`: Product name metadata in the PE header of the requested sample. - `productversion`: Product version metadata in the PE header of the requested sample. - `version`: Version metadata from the PE header of the requested sample. ## XG CFS Bulk Query This query retrieves nearly identical data as the single query does, but for multiple sample hashes within a single response. It is more network-efficient compared to multiple single queries. ### Request - Requests can be sent using the GET method or the POST method. - Both methods use Basic Authentication. - Both methods support specifying hashes in the URL. - POST allows specifying hashes in the request body as form data. ``` GET /api/xg/cfs/1/hashinfos/lookup.{format} ``` ``` POST /api/xg/cfs/1/hashinfos/lookup.{format} ``` Path parameters: - `format`: Specifies the response format. Supported values: `xml`, `json` Query parameters: - `md5` - `sha1` - `sha256` When requesting a list of hashes, they should be submitted as multiple `hash_type=hash_value` pairs. Hashes can be submitted as part of the request URL or in the POST body (form data). The hashes can be serialized in one or both of the following ways: 1. One argument, comma-separated list: A set of hashes may be a comma-delimited list in a single argument, like so: ``` md5=hash1,hash2,hash3 ``` 2. Multiple arguments of the same type: A set of hashes may each be a separate argument of the same type, like so: ``` md5=hash1&md5=hash2&md5=hash3 ``` #### Examples GET requests: ``` GET /api/xg/cfs/1/hashinfos/lookup.json?sha1=550a0e228ff317c74d62b668d260eb0a60bfeb39,a183f2a0906357488256945754592faa4bd4f7ba ``` ``` GET /api/xg/cfs/1/hashinfos/lookup.json?sha1=550a0e228ff317c74d62b668d260eb0a60bfeb39&sha1=a183f2a0906357488256945754592faa4bd4f7ba ``` POST request: ``` POST /api/xg/cfs/1/hashinfos/lookup.json ``` Form data: ``` sha1=550a0e228ff317c74d62b668d260eb0a60bfeb39&sha1=a183f2a0906357488256945754592faa4bd4f7ba ``` ### Response ```json5 { "totalcount": 1, "request": "/api/xg/cfs/1/hashinfos/lookup.json", "hashinfos": [ { "certificate": { "commonname": "", "certificateexinfo": { "validfromdateutc": "", "publisher": "", "issuerthumbprint": "", "name": "", "serialnumber": "", "validtodateutc": "", "thumbprint": "" } }, "requestsha1": "00020c16c9a3f1ba16f0d339bdca3d64af4eb12a", "peheadermetadata": { "version": "", "description": "", "language": "", "companyname": "", "originalname": "", "codepage": "", "productname": "", "productversion": "", "fileversion": "" }, "isfound": true, "threat": 0, "fileinfo": { "firstseendateutc": "2024-12-09T16:49:11Z", "iscontainer": false, "crc32": "", "filesizebytes": 11401, "ssdeep": "", "md5": "9c966d6b81788f1a0026aef16355927a", "sha1": "00020c16c9a3f1ba16f0d339bdca3d64af4eb12a", "ispeformat": false, "firstseenname": "", "sha256": "fc2a50fff96621a8e72916d4feca6aaf773da8eb17422f1a9645348ee9f28c8a", "isexecutable": false }, "trust": 8 } ] } ``` The response for the bulk request contains one `hashinfoslookup` object with one `hashinfo` object for each requested hash. The `hashinfo` object in the bulk query response contains identical fields from the `hashinfo` object in the single query response. Additionally, the following fields are returned only in the bulk query response: - `totalcount`: Indicates how many hashes were submitted in the request. - `isfound`: For each requested hash, indicates if the hash was found in the ReversingLabs database. - Depending on the requested hash type, the response includes one of: - `requestmd5` - `requestsha1` - `requestsha256`