This article shows how to leverage the Lumu Defender API and Cynet API to mitigate security risks.

Requirements

• A Cynet 360 AutoXDR Elite or above subscription
  • The Cynet console must have the Endpoint Detection & Response (EDR)
    module enabled.
• Lumu Defender API key
  • To retrieve an API token, please refer to the Defender API document.
• Script host.
  • A scripting host is required to deploy the integration. This host must have Internet visibility over Lumu Defender API endpoints and Cynet Cloud. According to the deployment model you select, you will need a host with:
    • Python 3.12+
      or
    • A Docker-enabled host.
• Script package
  • Contact the Lumu support team to request the package we created to deploy the required files.

Contacted hosts

• Lumu services:
  • defender.lumu.io (HTTPS and WSS traffic)
• Cynet services
  
• YOUR_INSTANCE.api.cynet.com (HTTPS traffic)

Integration’s overview

• Threat Hunting
• Remediation Playbooks
• Automatically Remediating Alerts

The Threat hunting feature is supported on Windows devices only.

Preliminary Setup - Cynet 360 AutoXDR

While several of the steps mentioned are labeled as “Optional”, Lumu very strongly recommends executing them to maximize the integration’s capabilities.

• Create a dedicated integration role with the least privileges (optional, but recommended).
• Create an API user.
• Enable the Cynet Threat Hunting feature.
• Collect your Cynet console base URL.
  
• Obtain your Cynet clientID

Create an integration role (recommended)

We recommend creating a dedicated integration role to track usage if needed and uphold the principle of least privilege. If you prefer not to create a new role, you can use one with the privileges outlined in this section. If you choose to use an existing user, ensure you have the necessary credentials available for a future step.

1. Make sure you are located in the account you want to integrate with Lumu. Head to the left navigation bar, then click on your MSP organization name. Finally, locate the account you want to configure and click on it.

Follow these steps inside your Cynet console to create it.

1. In your account window, head left to the navigation bar, expand the Settings section and click on the Users & Roles menu.

2. In the User & Roles window, click on the Roles tab, then click on the Add Role button.

3. On the panel that opens, enter the following information:

a. Under Role Name(1), provide a distinctive name for the role.

b. In the Permissions list, unfold the API(2) dropdown, and select the API - full access(3) permission

c. Once you’re done, click on the Add(4) button to save your new role.

Create an API user

1. In your account window, head left to the navigation bar, expand the Settings section and click on the Users & Roles menu

2. In the User & Roles window, click on the API Users tab, then click on the New button.

3. In the panel that opens, fill in the data following these guidelines:

a. Under Display Name(1), provide a distinctive name for the API user.

b. Under User Role(2), enter the name of the user role created in the Create an integration role section.

c. When finished, click on the Add(3) button to save your integration user.

4. The API Access-Key & Secret-Key window will appear. Take note of the Access-Key and the Secret-Key field data and keep them on hand, these will be required later to configure the integration.

This will be the only time these will be shown.

Enable the Cynet Threat Hunting feature

The Threat Hunting feature must be enabled to make the integration work. To enable this feature, follow these steps inside your Cynet console:

You must perform this task for every Windows group.

1. Head to the left navigation bar, expand the Settings section and click on the Groups menu.

2. In the Groups window, look for the required endpoint group and click on the Pencil icon to edit it. In this example, the icon is displayed on “Manually Installed Endpoints”.

3. In the Settings tab, click on the Advanced settings link under the Endpoint Detection & Response (EDR) section.

4. Enable the Threat Hunting toggle

5. Save your changes by clicking on the Ok button

After enabling Threat Hunting for the selected groups, you must define the Alert Severity for the threat hunting-related alerts.

1. In the Settings section, click on the Threat Hunting menu.

2. In the Threat Hunting window, look for the Alert Severity field. Select the most suitable value for your security operations. Click on the Save Changes button when done.

Collect your Cynet base URL

The Cynet base URL is required for setting up the integration in later steps, the URL follows the next structure:

The CYNET-URL-INSTANCE is needed to configure the integration

Obtain your Cynet client ID

• If you are a single tenant: Contact Cynet to receive your client ID
• If you are an MSSP: In the Cynet 360 console, navigate to Global Settings > Client Site Manager > Sites Status. Collect the ID for the required site. This process is outlined in this document.

Preliminary setup - Lumu Portal

• Lumu Defender API key
• Company UUID

Collect the Lumu Defender API key

To collect the Lumu Defender API key, please refer to the Defender API document.

Collect your Lumu company UUID

To collect your Lumu company UUID, log in to your Lumu portal. Once you are in the main window, copy the string below your company name.

Preliminary Setup - Choose your integration environment

• Run it as a Python script executing the install.sh bash file
  • Creates a Python virtual run time and its dependencies for you
  • Installs the crontab line in the host
• Run it as a Docker container.

If you use the install script, use the uninstall.sh bash file to remove the integration from the host.

Set up the configuration files

• companies.yml: this file contains the information collected from the Lumu portal
• integrations.yml: this file contains the information collected from your Cynet instance

Inside the integration package, you will find sample files you can use to build your configuration files. These files are companies_template.yml and integration_template.yml.

Complete the companies file

The companies file is in charge of defining how the integration connects to Lumu and extracts the information of the incidents and related indicators of compromise.

All the parameters in red should be replaced with the real data necessary for your integration deployment. For example, the parameter “COMPANY-UUID” should end up as something similar to “aa11bb22bb33-123a-456b-789c-11aa22bb33cc”. Follow these indications for all similar parameters.

-
  lumu:
    uuid: "COMPANY_UUID"
    defender_key: "DEFENDER_API_KEY"
    hash_type: "sha256"
    ioc_types: # list of ioc types, option one, many or all
      - hash
    adversary:  # list of adversary types, option one, many or all
      - C2C
      - Malware
      - Mining
      - Spam
      - Phishing
      - Anonymizer
    days: 3 # MIN 1, MAX 3

Within this file, COMPANY_UUID and DEFENDER_API_KEY fields are mandatory. Please use the values captured in the previous steps. The ioc_types values must match with the IOC types required by the integration, in this case, hash.

Complete the integrations file

The integration file contains the information required for the integration to connect and interact with your Cynet deployment:

- lumu:
    uuid: "COMPANY_UUID"
    adversaryTypes: [ "C2C", "Malware", "Mining", "Spam", "Phishing", "Anonymizer"] # ["C2C", "Malware", "Mining", "Spam", "Phishing", "Anonymizer"]
    days: 3 # INTEGER=(get incidents from X days of the ioc manager local db)
  app:
    name: "UNIQUE-NAME"
    clean: false # true | false
    ioc:
      - hash
    hash_type: sha256 # sha256 | sha1 | md5
    api:
      url: "https://CYNET-URL-INSTANCE.api.cynet.com/" 
      client_id: "CYNET-CLIENT-ID" # Ask it to Cynet support or MSP admin
      username: "CYNET-API-USER-ACCESS-KEY"
      password: "CYNET-API-USER-SECRET-KEY"

Keep in mind that:

COMPANY_UUID is the ID found in the Collect your Lumu company UUID step.

DEFENDER_API_KEY is the key found in the Collect the Lumu Defender API key.

CYNET-CLIENT-ID is the client ID collected from Cynet in the Obtain your Cynet client ID step.

CYNET-API-USER-ACCESS-KEY is the access key found in Step 4 of the Create an API user section, under Access-Key.

CYNET-API-USER-SECRET-KEY is the access key found in Step 4 of the Create an API user section, under Secret-Key.

You must fill in the configuration data carefully. If there are any mistakes or missing data, you’ll receive errors. Please refer to the Troubleshooting section at the end of this article for further reference.

Prepare Python on your environment

If Docker is your chosen deployment method, you may skip this step.

Deploy Integration as Python script

Make sure the install.sh script has the execution permission before running it.

If you want to modify the default running interval set up by the installation script, you can modify the latest crob job entries based on your environment requirements.

If you want to restart or uninstall the integration run the ./restart all and ./uninstall all respectively.

Script details

To use the script, you must locate yourself on the path selected for deployment (<app_lumu_root>). Use the following command to show all options available for the package:

Usage Examples

• Task: Query hashes related to Lumu incidents with default options
  

To query all the hashes related to Lumu incidents triggered in the last 30 days, run the following command.

• Task: Query hashes related to specific parameters
  

By default, the integration script will query incidents related to all adversary types.

• Task: Clean records
  

To clean the existing records in Cynet, just set up the clean flag in the integrations.yml file to true.

Then, run the integration script as follows:

The records not manipulated by the integration will be preserved.

• Other tasks
  

According to your needs, you can combine the examples shown, also, adding the –logging {file, screen} and –verbose argument can be used for better understanding of what can be rolling wrong.

Deploy as a Docker container (Optional)

Do not forget the dot "."

2. Run the container by using the following command.

With this mode, your integration will run every 5 minutes.

Troubleshooting

To collect integration logs:

Expected results

After running the integration, you will see new detected items in the Threat Hunting section, with hash records like this.

If the Threat Hunting module finds matches, it will trigger alerts. These alerts can be managed according to your security protocols.

Troubleshooting and known issues

Another instance is running

If you receive the following error.

There could be another instance running. To check this, open the pid.pid file in the integration folder. This file stores the process ID if it’s running.

Further steps

You can define remediation playbooks for your Lumu alerts and create actions to remediate them automatically. Next, you will find examples for a remediation playbook and an auto remediation rule.

Create a remediation playbook

1. Expand the left navigation menu. Click on the Remediation menu under the Settings section

2. In the Remediation window, move to the Playbooks tab. Click on the Create button

3. In the CREATE PLAYBOOK window, fill in the required information. Follow these guidelines:

a. Give a Name(1) to the playbook

b. Set the Playbook Execution Time(2) to Parallel

c. Under the Playbook Actions section, select and move the Quarantine (For Playbook)(3) and the Kill Process (For Playbook)

(4) available custom remediations to the Custom remediations playbook section

d. Click on the Save(5) button

We suggest using the previously selected custom remediations. You can select different custom remediations for your playbook according to your operating environment.

Create an auto remediation rule

1. Expand the left navigation menu and then click on the Actions menu

2. In the Actions window, move to the Auto remediation tab. Click on the Create Rule button

3. Fill in the required information. Follow these guidelines

a. Under Name(1) enter a descriptive name.

b. Under the Matching > Alert Name(2) field, type Threat Hunting Detected By File SHA256

c. Select the device groups(3) you want to apply the remediation rule to.

d. Select the Alerts Severity(4) based on the configuration made in the Threat Hunting module

e. In the Action section, select PlayBook Actions(5). Select the playbook created in the previous step

f. Click on the Save button when done.

When a Threat Hunting alert arises, the auto remediation rule will run.

• Remediation Playbooks
• Automatically Remediating Alerts