“Unknowns” in the Indicators of Attack Alerts

In some cases, you may encounter “unknown” entries in the Indicators of Attack (IoA) alerts, as shown in the following image:

These entries typically arise due to the following key scenarios:

1. External DNS Outside Active Directory (AD)

   If your organization uses DNS servers outside the Active Directory (AD) domain, it is important to note that the product does not support non-AD DNS environments. This means that when certain DNS queries or requests are routed through external DNS servers that are not part of AD, Tenable Identity Exposure cannot identify them, leading to “unknown” entries in the IoA alerts list.

   Such "unknowns" are expected in these cases and are not indicative of any malfunction or error within Tenable Identity Exposure. This is due to the nature of the integration with Active Directory, which requires DNS records to be managed within the AD environment for complete visibility and tracking.

   Solution

   • To minimize these "unknown" entries, ensure that your DNS infrastructure is fully integrated into AD for domains and resources that are critical for identity exposure monitoring.

   • If DNS queries must go outside of AD, understand that these “unknowns” will continue to appear, as Tenable Identity Exposure cannot resolve them.

2. Insufficient Permissions for Tenable Identity Exposure Account

   Another reason for "unknown" entries in the IoA alerts could be that the account Tenable Identity Exposure uses lacks sufficient permissions to read DNS entries. The Tenable Identity Exposure service requires read permissions to properly access and analyze DNS records within the Active Directory.

   Solutions

   To resolve this, ensure that the account Tenable Identity Exposure uses has read access to the necessary DNS entries within AD. Specifically, this account must have permission to query DNS servers and access the records it needs to perform identity exposure analysis.

   If the Tenable Identity Exposure account does not have proper read permissions, you can grant them using the following procedures.

   Tip: In the script, you only need to change the name of the account Tenable Identity Exposure uses. Read permissions are included in the following attributes:

   • distinguishedName

   • dnsRecord (contains the IP)

   • name

   • ntSecurityDescriptor

   • objectCategory

   • objectClass

   • objectGUID

   You have the two following options using PowerShell scripts:

   1. In your Active Directory manager, set the Read permissions on the container (dnsZone) and propagate it all children dnsNode (recommended solution if applicable):

      Copy

      Import-Module ActiveDirectory
      
      $identity = New-Object System.Security.Principal.NTAccount('EXAMPLE\user2') # Service account used by TIE for collect/listening
      $dnsZonePartition = (Get-ADRootDSE).namingContexts | Where-Object { $_ -match "DomainDnsZones" }
      
      # dnsRecord attribute GUID
      # and Public-Information property set GUID
      $guids = @('e0fa1e69-9b45-11d0-afdd-00c04fd930c9', 'e48d0154-bcf8-11d1-8702-00c04fb96050')
      
      $dnsZones = Get-ADObject -LDAPFilter "(objectClass=dnsZone)" -SearchBase $dnsZonePartition
      
      ForEach ($dnsZone in $dnsZones) {
          $acl = Get-Acl -Path "AD:\$dnsZone"
      
          ForEach ($guid in $guids) {
            $ace = New-Object System.DirectoryServices.ActiveDirectoryAccessRule(
              $identity,
              [System.DirectoryServices.ActiveDirectoryRights]::ReadProperty,
              [System.Security.AccessControl.AccessControlType]::Allow,
              [guid]$guid,
              [System.DirectoryServices.ActiveDirectorySecurityInheritance]::All,
              [guid]'e0fa1e8c-9b45-11d0-afdd-00c04fd930c9' # dnsZone GUID
              )
      
            $acl.AddAccessRule($ace)
          }
      
          # ntSecurityDescriptor
          $ace = New-Object System.DirectoryServices.ActiveDirectoryAccessRule(
              $identity,
              [System.DirectoryServices.ActiveDirectoryRights]::ReadControl,
              [System.Security.AccessControl.AccessControlType]::Allow,
              [System.DirectoryServices.ActiveDirectorySecurityInheritance]::All,
              [guid]'e0fa1e8c-9b45-11d0-afdd-00c04fd930c9' # dnsZone GUID
              )
      
          $acl.AddAccessRule($ace)
          Set-Acl -Path "AD:\$dnsZone" -AclObject $acl
      }

   2. Set the read permissions on all the existing dnsNode objects (on the dnsZone affecting all children dnsNode):

      Copy

      Import-Module ActiveDirectory
      
      $identity = New-Object System.Security.Principal.NTAccount('EXAMPLE\user2') # Service account used by TIE for collect/listening
      $dnsZonePartition = (Get-ADRootDSE).namingContexts | Where-Object { $_ -match "DomainDnsZones" }
      
      # dnsRecord attribute GUID
      # and Public-Information property set GUID
      $guids = @('e0fa1e69-9b45-11d0-afdd-00c04fd930c9', 'e48d0154-bcf8-11d1-8702-00c04fb96050')
      
      $dnsNodes = Get-ADObject -LDAPFilter "(objectClass=dnsNode)" -SearchBase $dnsZonePartition
      
      ForEach ($dnsNode in $dnsNodes) {
          $acl = Get-Acl -Path "AD:\$dnsNode"
      
          ForEach ($guid in $guids) {
            $ace = New-Object System.DirectoryServices.ActiveDirectoryAccessRule(
              $identity,
              [System.DirectoryServices.ActiveDirectoryRights]::ReadProperty,
              [System.Security.AccessControl.AccessControlType]::Allow,
              [guid]$guid
              )
      
            $acl.AddAccessRule($ace)
          }
      
          # ntSecurityDescriptor
          $ace = New-Object System.DirectoryServices.ActiveDirectoryAccessRule(
              $identity,
              [System.DirectoryServices.ActiveDirectoryRights]::ReadControl,
              [System.Security.AccessControl.AccessControlType]::Allow
              )
      
          $acl.AddAccessRule($ace)
          Set-Acl -Path "AD:\$dnsNode" -AclObject $acl
      }

3. Supported DNS partitions

   Tenable Identity Exposure does not perform active DNS resolution. Instead, it relies on DNS entries extracted from the ForestDnsZones and DomainDnsZones partitions. If you use custom DNS partitions, Tenable Identity Exposure will not crawl them or store their DNS entries.