Skip to main content

Datadog Credentials

Datadog credentials are used to authenticate and authorize access to Datadog's monitoring and analytics platform. These credentials can include API keys, application keys, and other tokens that allow users to send data to Datadog, configure monitoring settings, and access dashboards. Exposure of these credentials is a significant security concern as it can lead to unauthorized access to sensitive monitoring data and potential manipulation of monitoring configurations.

How Does It Look​

Datadog credentials can appear in various contexts, such as:

  • Environment variables:

    export DATADOG_API_KEY="dd_api_key_1234567890abcdef"
    export DATADOG_APP_KEY="dd_app_key_abcdef1234567890"

  • Configuration files (YAML):

    datadog:
      api_key: "dd_api_key_1234567890abcdef"
      app_key: "dd_app_key_abcdef1234567890"

  • Code snippets:

    from datadog import initialize, api

    options = {
        'api_key': 'dd_api_key_1234567890abcdef',
        'app_key': 'dd_app_key_abcdef1234567890'
    }

    initialize(**options)

  • Connection strings:

    datadog://dd_api_key_1234567890abcdef@dd_app_key_abcdef1234567890

Severity​

  • 🟠 High

The severity of exposed Datadog credentials is high because they provide access to monitoring data and configurations. An attacker with these credentials can manipulate monitoring settings, potentially hiding malicious activities or causing operational disruptions. The blast radius includes all systems and applications monitored by Datadog.

What Can an Attacker Do?​

With immediate access to Datadog credentials, an attacker can perform several malicious actions:

An attacker can:

  • Modify monitoring configurations (if the credential has write permissions), potentially hiding malicious activities.
  • Access sensitive monitoring data (if the credential has read access), which could include logs and metrics.
  • Disable alerts and notifications (if the credential allows configuration changes), leading to undetected incidents.
  • Inject false data into monitoring dashboards (if data submission permissions are granted).

Additionally, an attacker could use these capabilities to escalate their access or move laterally within the network by exploiting the insights gained from monitoring data.

Real-World Impact​

Exposure of Datadog credentials poses significant business risks, including:

The primary impact includes unauthorized access to monitoring data and potential manipulation of monitoring configurations.

Potential consequences include:

  • Data Exposure: Access to logs and metrics (if the credential has read access to sensitive data).
  • Operational Disruption: Altered monitoring configurations could lead to missed alerts (if the attacker has modify permissions).
  • Reputational Damage: Loss of trust if monitoring failures lead to undetected incidents.

In worst-case scenarios, attackers could use the insights from monitoring data to plan further attacks, leading to cascading effects across the organization.

Prerequisites for Exploitation​

To exploit exposed Datadog credentials, an attacker needs:

  • Network access to the Datadog API endpoints.
  • Knowledge of account-specific details such as account IDs or specific endpoints.
  • No IP restrictions or MFA enforcement on the account.

How to Verify If It's Active​

To verify if a Datadog credential is active, use the following command:

curl -X GET "https://api.datadoghq.com/api/v1/validate" \
-H "DD-API-KEY: [API_KEY]" \
-H "DD-APPLICATION-KEY: [APP_KEY]"

Valid credential response: A successful response will include a status code of 200 and a message indicating valid credentials.

Invalid/expired credential response: An unsuccessful response will include a status code of 403 or 401 with an error message indicating invalid credentials.

Detection Patterns​

Common Variable Names:

  • DATADOG_API_KEY
  • DATADOG_APP_KEY
  • DD_API_KEY
  • DD_APP_KEY
  • DATADOG_KEY
  • DD_KEY

File Locations:

  • config/datadog.yaml
  • .env
  • settings.py
  • application.properties

Regex Pattern:

(dd[_-]?(api|app)[_-]?key)[=:]["']?[a-z0-9]{32}["']?

Remediation Steps​

  1. Revoke immediately - Go to Datadog > Integrations > APIs and delete the compromised API and application keys.
  2. Audit access logs - Review Datadog audit logs for unauthorized access or configuration changes during the exposure window.
  3. Assess blast radius - Identify all systems, applications, and environments that used the exposed credential.
  4. Rotate credential - Generate new API and application keys in Datadog with least-privilege permissions.
  5. Update dependent systems - Deploy the new credential to all applications and update CI/CD pipelines securely.
  6. Harden access controls - Enable IP allowlisting in Datadog and require multi-factor authentication for access.
  7. Implement secrets management - Migrate credentials to a secrets manager (HashiCorp Vault, AWS Secrets Manager) to prevent hardcoding.
  8. Add detection controls - Set up pre-commit hooks and repository scanning to catch credential leaks before they reach production.

Credential exposures often go undetected for extended periods, increasing the window for exploitation. As a long-term strategy, plan to establish an internal process or engage an external vendor for continuous external exposure monitoring. This helps identify leaked secrets across public repositories, paste sites, dark web forums, and other external sources before attackers can leverage them. Proactive detection and rapid response are essential to minimizing the impact of credential leaks.

References​