Integrating Bitdefender GravityZone with Wazuh

| by | Wazuh 4.9.1
Post icon

Organizations face increasingly sophisticated threats that require a proactive and multi-layered defense strategy. Organizations often leverage multiple security solutions to improve their security posture. Centralized visibility for organizations that use multiple security solutions is essential for operational efficiency. Wazuh, an open source Security Information and Event Management (SIEM) and Extended Detection and Response (XDR) platform helps to achieve this.

Organizations with existing security solutions like Bitdefender GravityZone (GZ) can centralize visibility by forwarding their logs to Wazuh. Integrating with Wazuh allows organizations to unify security alerts from all different sources. Through Wazuh capabilities, security teams can monitor, correlate, and analyze security events from Bitdefender GZ and other sources.

This blog demonstrates how Bitdefender GZ logs can be exported to the Wazuh server for continuous monitoring and analysis.

Infrastructure

We use the following infrastructure to demonstrate the integration of Bitdefender GravityZone with Wazuh.

  • Wazuh 4.9.1 central components (Wazuh server, Wazuh indexer, and Wazuh dashboard). Follow this guide to download and set up the Wazuh virtual machine.
  • An Ubuntu endpoint with a minimum hardware requirement of 2GB RAM, 80GB HDD, and a public IP address to serve as the log connector. The Ubuntu connector endpoint stores the syslog data from Bitdefender and forwards it to the Wazuh server.
  • A Bitdefender GravityZone account.
  • A Windows 11 endpoint with a Bitdefender agent deployed. The Bitdefender agent monitors security events on the Windows 11 endpoint.

Configuration

We will perform the following configuration steps.

The sections below show how these steps are implemented.

Configuring the Ubuntu connector endpoint

The Ubuntu endpoint serves as a connector server between Bitdefender GravityZone and Wazuh. Perform the following steps on the Ubuntu endpoint to set up log collection from Bitdefender GZ via API:

1. Run the command below to add the Bitdefender connector repository to APT:

# echo "deb http://download.bitdefender.com/repos/deb-hydra20-evpsc/ bitdefender non-free" >> /etc/apt/sources.list

2. Add the digital signature, update APT, and install the GravityZone package:

# curl -sS https://download.bitdefender.com/repos/gzrepos.key.asc | apt-key add -
# apt update  
# apt install gz-evpsc

3. Navigate to the Bitdefender installation path that contains its configuration script:

# cd /opt/bitdefender/gz-evpsc

4. Run the configuration scripts using the appropriate parameters:

# ./config.sh <BITDEFENDER_PORT> <SYSLOG_PORT> <TRANSPORT> <TARGET> <AUTH> <CONFIG_FILENAME>

Where:

  • BITDEFENDER_PORT: The port used by Bitdefender GZ event push service to access the Ubuntu connector endpoint. It uses port 3200 by default.
  • SYSLOG_PORT: The port used by the Ubuntu connector endpoint to forward logs to Wazuh SIEM.
  • TRANSPORT: The protocol used to transfer data. This can be TCP or UDP.
  • TARGET: The Wazuh server’s publicly accessible IP address.
  • AUTH: An authentication key string used to access the SIEM through the API. It is a randomly generated key.
  • CONFIG_FILENAME: The name of the configuration file (config.json). 

When the necessary parameters are supplied, it should look like the example below:

# ./config.sh 3200 514 Tcp 127.0.0.1 'Basic dGVzdDp0ZXN0' config.json

Note: Certificates obtained from a Certificate Authority (CA) can be added to the configuration by placing the certificate details in the following files.

> /opt/bitdefender/gz-evpsc/api/config/server.key
> /opt/bitdefender/gz-evpsc/api/config/server.crt

This is optional because the config.sh script executed earlier creates self-signed certificates for the connector endpoint.

5. Enable the event push service on the Ubuntu connector endpoint:

# systemctl enable gz-evpsc

6. Start the event push service:

# systemctl start gz-evpsc

Testing the Connector

The configured connector can be tested by sending a payload to the collector service using the below command. Replace the authorization header and the URL with the details configured earlier during the execution of the config.sh script. Upon successful execution of the below commands, the response code OK is generated.

# curl -k -H 'Authorization: Basic <AUTH>' \
-H "Content-Type: application/json" \
-d '{"cef": "0","events": ["CEF:0|Bitdefender|GravityZone|6.4.08|70000|Registration|3|BitdefenderGZModule=registrationdvchost=TEST_ENDPOINTasdadBitdefenderGZComputerFQDN=test.example.com dvc=192.168.1.2","CEF:0|Bitdefender|GravityZone|6.4.0-8|35|Product ModulesStatus|5|BitdefenderGZModule=modules dvchost=TEST_ENDPOINTasdadBitdefenderGZComputerFQDN=test.example.com dvc=192.168.1.2","CEF:0|Bitdefender|GravityZone|6.4.0-8|35|Product ModulesStatus|5|BitdefenderGZModule=modules dvchost=TEST_ENDPOINTasdadBitdefenderGZComputerFQDN=test.example.com dvc=192.168.1.2"]}' \
https://<CONNECTOR_IP>:<BITDEFENDER_PORT>/api

Where:

  • AUTH: An authentication key string used to access the SIEM through API. This is not the API key; it is a randomly generated key.
  • CONNECTOR_IP: The Ubuntu connector endpoint IP address.
  • BITDEFENDER_PORT:  The port used by Bitdefender GZ event push service (3200) to access the Ubuntu connector endpoint.

Note: The authorization header and URL provided earlier are in the path below:

# /opt/bitdefender/gz-evpsc/api/config/config.json

Using the Bitdefender GravityZone API

Generate an API key using the steps below:

1. Click on your username at the top-right corner of the console.

2. Select My Account.

3. Scroll down to the API keys section at the bottom of the page and click on Add.

4. Provide an appropriate API key description and select the relevant API service.

Bitdefender GravityZone API
Figure 1: Bitdefender GravityZone API key generation.

5. Click on Generate to generate the API key. Make sure to store your API key securely for later use.

6. In the Control Center API section, take note of the Access URL, as this will be required in the next section.

Exporting GravityZone logs to the Ubuntu connector endpoint

Bitdefender GZ logs are first sent to the Ubuntu connector endpoint and then forwarded to the Wazuh server for analysis. Perform the steps below to configure the Bitdefender GZ Control center to forward logs to the Ubuntu connector endpoint via the earlier defined URL:

1. Execute the command below on the Ubuntu connector endpoint to encode the API key in base64 as Bitdefender GZ requires. To do this, append a colon “:” at the end of the API key and then encode it using a base64 algorithm:

# echo -n "<BITDEFENDER_API_KEY>:" | base64 -w 0

Where:

<BITDEFENDER_API_KEY>: API key generated from the API keys section on Bitdefender GZ console.

-n: Ensures no extra characters or hidden characters are added.

-w 0: Ensures that there are no line breaks in the output

2. Execute the command below to initiate the configuration using the base64 API key.

Ensure that the authorization header and URL values are replaced with the values in the /opt/bitdefender/gz-evpsc/api/config/config.json file. Replace CONTROL_CENTER_API_ACCESS_URL and API_KEY_BASE64_ENCODED_WITH_COLON_APPENDED with the values gotten from your Bitdefender GravityZone instance.

# curl --tlsv1.2 -sS -k -X POST \
<CONTROL_CENTER_API_ACCESS_URL>/v1.0/jsonrpc/push \
-H 'authorization: Basic <API_KEY_BASE64_ENCODED_WITH_COLON_APPENDED>' \
-H 'cache-control: no-cache' \
-H 'content-type: application/json' \
-d '{"id":"1","jsonrpc":"2.0","method":"setPushEventSettings","params":{"serviceSettings":{"requireValidSslCertificate":false,"authorization":"Basic <AUTH>","url":" https://<CONNECTOR_IP>:<BITDEFENDER_PORT>/api"},"serviceType":"cef","status":1,"subscribeToEventTypes":{"adcloudgz":true,"antiexploit":true,"aph":true,"av":true,"avc":true,"dp":true,"endpoint-moved-in":true,"endpoint-moved-out":true,"exchange-malware":true,"exchange-user-credentials":true,"fw":true,"hd":true,"hwid-change":true,"install":true,"modules":true,"network-monitor":true,"network-sandboxing":true,"new-incident":true,"ransomware-mitigation":true,"registration":true,"supa-update-status":true,"sva":true,"sva-load":true,"task-status":true,"troubleshooting-activity":true,"uc":true,"uninstall":true}}}'

3. Allow approximately 10 minutes for the settings to apply, then proceed to make a request using:

# curl --tlsv1.2 -sS -k -X POST \
<BITDEFENDER_CONTROL_CENTER_API_ACCESS_URL>/v1.0/jsonrpc/push \
-H 'authorization: Basic <API_KEY_BASE64_ENCODED_WITH_COLON_APPENDED>' \
-H 'cache-control: no-cache' \
-H 'content-type: application/json' \
-d '{"id":"3","jsonrpc":"2.0","method":"getPushEventSettings","params":{}}'
{
  "id": "2",
  "jsonrpc": "2.0",
  "result": {
    "serviceSettings": {
      "authorization": "********",
      "requireValidSslCertificate": false,
      "url": "https://your_web_server_hostname_or_public_IP:port/api"
    },
    "serviceType": "cef",
    "status": 1,
    "subscribeToCompanies": null,
    "subscribeToEventTypes": {
      "adcloud": false,
      "antiexploit": true,
      "aph": true,
      "av": true,
      ……….
      "uninstall": true
    }
  }
}

You can also use the sendTestPushEvent API method to trigger a test event:

# curl --tlsv1.2 -sS -k -X POST \
https://<BITDEFENDER_CONTROL_CENTER_APIs_ACCESS_URL>/v1.0/jsonrpc/push \
-H 'authorization: Basic <API_KEY_BASE64_ENCODED_WITH_COLON_APPENDED>' \
-H 'cache-control: no-cache' \
-H 'content-type: application/json' \
-d '{"id":"4","jsonrpc":"2.0","method":"sendTestPushEvent","params":{"eventType": "av"}}'
{
  "id": "4",
  "jsonrpc": "2.0",
  "result": {
    "computer_name": "FC-WIN7-X64-01",
    "computer_fqdn": "FC-WIN7-X64-01",
    "computer_ip": "**.**.**.**",
    "computer_id": "59a1604e60369e06733f8abb",
    "product_installed": "BEST",
    "malware_type": "file",
    "malware_name": "EICAR-Test-File (not a virus)",
    "file_path": "C:\\eicar0000001.txt",
    "hash": "8b3f191819931d1f2cef7289239b5f77c00b079847b9c2636e56854d1e5eff71",
    "final_status": "deleted",
    "timestamp": "2017-09-08T12:01:36.000Z",
    "companyId": "5ac8460f8a799399a78b456c",
    "module": "av",
    "_testEvent_": true
  }
}

Note: Logs exported from Bitdefender GZ can be found in the file path:

# /opt/bitdefender/var/log/gz-evpsc/log.txt

Configuring Rsyslog on the Ubuntu Connector Endpoint

In this section, we install and configure Rsyslog to forward the events from the Ubuntu connector endpoint to the Wazuh manager. While some Linux distributions have Rsyslog pre-installed, you can install it on the Ubuntu connector endpoint using the steps outlined below if it has not already been installed.

1. Execute the following commands to install Rsyslog:

# apt-get update
# apt-get install -y rsyslog

2. Modify the /etc/rsyslog.conf file by uncommenting the parameters below to enable remote logging.

  • For TCP
module(load="imtcp")
input(type="imtcp" port="514")
  • For UDP
module(load="imudp")
input(type="imudp" port="514")

3. Start and enable Rsyslog:

# systemctl start rsyslog
# systemctl enable rsyslog

Wazuh server configuration

Perform the following steps on the Wazuh server to set up syslog collection from the Ubuntu connector endpoint. 

1. Add the following to the <ossec_config> block of the /var/ossec/etc/ossec.conf configuration file:

<ossec_config>  
<remote>
    <connection>syslog</connection>
    <port><PORT></port>
    <protocol><PROTOCOL></protocol>
    <allowed-ips><ALLOWED_IP></allowed-ips>
    <local_ip><WAZUH_MANAGER_IP></local_ip>
  </remote>
</ossec_config>
  • connection: Indicates the type of incoming connection to allow. In this case, we use syslog, a standard protocol for transmitting log messages over a network.
  • PORT: Specifies the network port number for the remote connection. Replace <PORT> with your desired port number. Remember that the same port number should be set on the Ubuntu connector endpoint.
  • PROTOCOL: Indicates the communication protocol. Replace <PROTOCOL> with your chosen protocol, either TCP or UDP. Be sure to configure the same protocol on the Ubuntu connector endpoint.
  • allowed-ips: Indicates which endpoints are permitted to send logs to this server. Replace <ALLOWED_IP> with the IP address of the Ubuntu connector endpoint.
  • local-ip: Identifies the local IP address of the Wazuh server to be used for this connection. Replace <WAZUH_MANAGER_IP> with the IP address of your Wazuh server.

2. Add the configuration below to the /var/ossec/etc/ossec.conf file from which Bitdefender logs are read.

<ossec_config>  
  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/messages</location>
  </localfile>
</ossec_config>

3. Restart the Wazuh manager to apply the changes:

# systemctl restart wazuh-manager

4. Review syslog logs in /var/log/messages to confirm that BitDefender Gravity Zone logs are being received on the Wazuh server:

# cat /var/log/messages | grep Bitdefender

Custom decoder

Follow the steps below to add a custom decoder to the Wazuh server to decode the Bitdefender GravityZone logs. 

1. Create a file bitdefendergz.xml in the /var/ossec/etc/decoders directory:

# touch /var/ossec/etc/decoders/bitdefendergz.xml

2. Add the following decoder to the /var/ossec/etc/decoders/bitdefendergz.xml file:

<decoder name="gravityzone">
  <program_name>CEF</program_name>
  <prematch>GravityZone</prematch>
</decoder> 

<decoder name="gravityzone_child">
  <parent>gravityzone</parent>
  <regex type="pcre2">.*(AntiMalware).*dvchost=(\S+) \S+ dvc=(\S+) \S+ BitdefenderGZMalwareType=(\S+) BitdefenderGZMalwareName=(.*) BitdefenderGZMalwareHash=(\S+) act=(\S+) filePath=(\S+) BitdefenderGZDetectionTime=(\S+).*BitdefenderGZCleanedMalwareCnt=(\d+) BitdefenderGZBlockedMalwareCnt=(\d+) BitdefenderGZDeletedMalwareCnt=(\d+) BitdefenderGZQuarantinedMalwareCnt=(\d+) BitdefenderGZIgnoredMalwareCnt=(\d+) BitdefenderGZPresentMalwareCnt=(\d+) suser=(\S+).*</regex>
  <order>BitdefenderModule,DeviceHostName,DeviceIP,MalwareType,MalwareName,MalwareHash,Action,FilePath,DetectionTime,CleanedMalwareCount,BlockedMalwareCount,DeletedMalwareCount,QuarantinedMalwareCount,IgnoredMalwareCount,PresentMalwareCount,User</order>
</decoder>

Custom rules

Add the following custom rules to the Wazuh server to generate alerts when the Bitdefender logs are received.

1. Create a file bitdefender.xml in the /var/ossec/etc/rules/ directory:

# touch /var/ossec/etc/rules/bitdefender.xml

2. Add the following custom rules to the file /var/ossec/etc/rules/bitdefender.xml:

<!-- Rules to detect Bitdefender events via syslog -->

<!-- BitDefender logs grouped -->
<group name="bitdefender-GZ">
  <rule id="100600" level="0">
    <decoded_as>gravityzone</decoded_as>
    <description>Logs from Bitdefender.</description>
  </rule>

  <!-- Rule to detect active threat -->
  <rule id="100601" level="10">
    <if_sid>100600</if_sid>
    <field name="BitdefenderModule">AntiMalware</field>
    <description>Bitdefender: $(MalwareName) detected on $(DeviceHostName) and $(Action).</description>
  </rule>
</group>

Where:

  • Rule ID 100600 groups all Bitdefender events.
  • Rule ID 100601 is triggered when a threat has been detected and deleted on a monitored endpoint.

3. Restart the Wazuh manager service to apply the changes:

# systemctl restart wazuh-manager

Testing the integration

To test the integration, perform the following steps:

1. Download a malware sample to the Windows 11 endpoint using the Command Prompt:

> curl "https://secure.eicar.org/eicar.com.txt" -o eicar

2. Navigate to the  Threat Hunting > Events tab to view the generated alert.

Bitdefender GravityZone alerts
Figure 2: Bitdefender GravityZone alerts on the Wazuh dashboard.
Bitdefender alerts
Figure 3: Bitdefender GravityZone alert details on the Wazuh dashboard.

Conclusion

Integrating Bitdefender GravityZone with Wazuh allows organizations to centralize security monitoring of their endpoints. This provides a unified view of security events and enhances visibility into detecting potential threats.

Wazuh is a free and open source SIEM and XDR platform that supports integration with several third-party solutions. To learn more about the capabilities of Wazuh, check out our documentation, blog posts, and communities for more information and support.

References