Finding Rogue Devices On Privileged Networks
  • 3 Minutes To Read
  • Print
  • Share
  • Dark
    Light

Finding Rogue Devices On Privileged Networks

  • Print
  • Share
  • Dark
    Light

Watch the “Finding Rogue Devices On Privileged Networks” video, or read below.

FINDING ROGUE DEVICES ON PRIVILEGED NETWORKS

While the definition of a “rogue device” varies widely, a consensus definition would include at least three elements:

  • A device that is on a privileged network
  • A device that is not expected to be on the network
  • A device that is or has the potential to be used for malicious intent

Although some vendors define rogue devices as “just plain malicious in nature,” this strict definition omits devices like the “rogue Raspberry Pi that allowed criminals to access NASA JPL systems.” So for the purposes of this article, we’re talking about devices on privileged networks that are not supposed to be there and may be used for malicious intent.

CHALLENGES IDENTIFYING ROGUE DEVICES ON PRIVILEGED NETWORKS

The biggest challenge in identifying rogue devices on privileged networks is the lack of information about the device and its context. This makes it difficult to identify which devices are not supposed to be on the privileged network.

DATA SOURCES NEEDED TO FIND ROGUE DEVICES ON PRIVILEGED NETWORKS

  • Network/Infrastructure Data — Connecting to the network infrastructure allows you to see devices that are known to the network
  • Directory Services / Endpoint Management Solutions — Services like Active Directory or Azure AD that authenticate and authorize users and devices
  • Configuration Management Tools — Services like SCCM
  • Virtualization Tools — Shows all VMs in the environment
  • Vulnerability scanner console — By connecting to the admin console of the vulnerability scanner, you can see all devices that are known and that are being scanned

FINDING ROGUE DEVICES ON PRIVILEGED NETWORKS

When looking for rogue devices using Axonius, you can build simple queries ranging from the broadest possible scenario to the most detailed.

Let’s take a look at a query to find rogue devices on privileged networks. The query below looks for the following: devices on a Fortigate network, not in VMWare, not in Active Directory, not in Hyper-V, not in Jamf Pro, and last seen in Axonius within the past four days.


This query can be represented in the Axonius Query Wizard as:
Screenshot 1.0

This query can also be represented as an AQL (Axonius Query Language) expression:

(adapters_data.fortigate_adapter.id == ({"$exists":true,"$ne":""})) and not (adapters_data.esx_adapter.id == ({"$exists":true,"$ne":""})) and not (adapters_data.active_directory_adapter.id == ({"$exists":true,"$ne":""})) and not (adapters_data.hyper_v_adapter.id == ({"$exists":true,"$ne":""})) and not (adapters_data.jamf_adapter.id == ({"$exists":true,"$ne":""})) and specific_data.data.last_seen >= date("NOW - 4d")



Here are the results:
Screenshot 1.1

That query will return all rogue devices on any Fortigate network, and we can add filter criteria to show only devices that are not on the guest network using the following:


This query can also be represented in the Axonius Query Wizard as:
Screenshot 2.0

This query can also be represented as an AQL (Axonius Query Language) expression:

(adapters_data.fortigate_adapter.id == ({"$exists":true,"$ne":""})) and not (adapters_data.esx_adapter.id == ({"$exists":true,"$ne":""})) and not (adapters_data.active_directory_adapter.id == ({"$exists":true,"$ne":""})) and not (adapters_data.hyper_v_adapter.id == ({"$exists":true,"$ne":""})) and not (adapters_data.jamf_adapter.id == ({"$exists":true,"$ne":""})) and specific_data.data.last_seen >= date("NOW - 4d") and not adapters_data.fortigate_adapter.interface == regex("guest", "i")



Here are the results:
Screenshot 2.1

TAKING ACTION ON ROGUE DEVICES

Any time a rogue device is identified, security teams need to automatically know and then take action to remove the device from any privileged network. The Axonius Security Policy Enforcement Center allows customers to determine which automated action to execute.

Highlighted Actions Include:

  • Notify - Let someone know about the unscanned cloud instance via email, Slack, Syslog, or by CSV
  • Create Incident - Create an incident using a ticketing system like ServiceNow, Jira, or Zendesk
  • Enrich Device or User Data - Enrich data with Shodan, Censys, or Portnox to show what is publicly known

For more details, see Action Library.

Was This Article Helpful?