Malwarebytes Nebula Integration via API

Purpose

This guide explains how to generate OAuth2 API credentials in the Malwarebytes Nebula console (ThreatDown cloud endpoint security platform) and how to use them in Logsign USO to ingest Nebula detection and management events for security analytics and forensic purposes.

Malwarebytes Nebula is a cloud-hosted console with no on-premises equivalent, so it exposes its data exclusively through a REST API rather than syslog. This API poller is the supported and only way to bring Nebula event data into Logsign USO.

Prerequisites

The account you use to create the OAuth2 application must have administrative access to the Nebula console's Integrate section. According to Malwarebytes' third-party integration documentation, creating OAuth2 credentials requires a Super Admin role; this could not be independently confirmed against Malwarebytes' own support portal, which blocks automated access; verify with a Nebula administrator if a lower-privileged role also has access to this screen.

The OAuth2 application must be granted at least read scope. This is the scope Logsign requests when exchanging credentials for an access token; a narrower scope will cause authentication to fail.

Step 1: Locate Your Nebula Account ID

Sign in to your Nebula console at https://cloud.malwarebytes.com/. After login, look at the browser address bar; it has the form https://cloud.malwarebytes.com/<account-id>/dashboard/.... The UUID-formatted segment between the first and second / after the domain (for example abcdef12-5467-ffff-aaaa-abcdef12adda) is your Account ID. Copy it; you will enter it in Logsign in Step 4.

Step 2: Create an OAuth2 Client ID and Client Secret

1. In the Nebula console, go to Integrate > Add (menu naming per third-party documentation; not independently verified against the current console UI).
2. Enter an application name so the credential is identifiable later (for example, "Logsign USO integration").
3. Grant at least the read scope/permission.
4. Save. The console displays a Client ID (format similar to mwb-cloud-...) and a Client Secret (a long hexadecimal string).
5. Copy both values immediately. The Client Secret is shown only once at creation time; if it is lost, a new Client ID/Secret pair must be generated.

Step 3: Build the Basic Auth Token for Logsign

Logsign's Nebula poller does not encode your credentials itself; it sends whatever value you provide directly in the Authorization: Basic header of its OAuth2 token request. You must Base64-encode the string <Client ID>:<Client Secret> yourself and paste the resulting string into Logsign, for example:

echo -n "mwb-cloud-xxxxxxxx:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" | base64

Do not paste the raw Client Secret into Logsign's Token field; it must be the Base64-encoded Client ID:Client Secret pair, or authentication will fail.

Step 4: Configure the Integration in Logsign USO

Log in to Logsign USO and add a new Malwarebytes Nebula data source (Settings > Add Device > API > Malwarebytes Nebula). You will be asked for:

After saving these three fields, use the Check Connection button. This calls Logsign's own backend, which repeats the exact same OAuth2 token request the poller uses and reports success only if that request returns HTTP 200. It confirms your Client ID/Secret pair is valid and can obtain a token; it does not confirm the Account ID is correct or that the credential has access to the Events endpoint. A wrong Account ID would only surface as an authorization error on the first actual polling cycle.

Logsign then polls Malwarebytes Nebula's GET /nebula/v1/events endpoint on a recurring schedule, using each response's timestamp field as the sync cursor (advanced by one microsecond after the last event processed) so the next poll only requests events after that point. When the cached access token expires or is rejected with HTTP 401, Logsign automatically re-authenticates using the same Basic token and retries the request; no manual token refresh is required.

Notes and Limits

• This poller retrieves only the Events endpoint (/nebula/v1/events); endpoint detections, scans, machine registration/lock, and scheduled report events. Other Nebula console data, such as asset inventory, policy configuration, or user management records, is not part of this integration.
• The poller's code does not implement any page-size or cursor-based pagination; each poll issues a single request with a start time filter and processes whatever the API returns in that one response. Whether Malwarebytes enforces a server-side cap on events per response could not be confirmed (the official ThreatDown support portal blocks automated/scripted access). In environments with a very high volume of Nebula events, consider setting a short initial "Log Start Date" (for example, 1 day instead of 30 days) to reduce the chance of an oversized first response; not verified against Malwarebytes' own rate-limit documentation.
• Only ten event types are currently mapped to a specific Logsign Context/Type/SubType in the shipped event library (for example machine.registered, user.locked, scheduled.threat.scan.failure). Any other event type Nebula returns is still ingested, but falls back to a generic Security/Scan/Info classification rather than a specific one.
• If polling stops or repeatedly logs authorization errors, check first whether the OAuth2 Client ID/Secret pair was revoked or rotated in the Nebula console, and whether the Base64 token pasted into Logsign's Token field is still built from the current Client Secret. Regenerate the credential and update the data source in Logsign USO if needed.
• The Account ID is not validated at save time in Logsign; only the OAuth2 token exchange is. Double-check the UUID copied from the console URL in Step 1 before saving, since a typo will not be caught until the first poll attempt.