Depending on the size of your network, you may or may not know exactly who on your IT staff is an administrator, what they have access to or even who outside of IT has administrator rights to different systems. In this document, I’ll discuss a variety of methods you can leverage within SecurityCenter to mine data from Nessus, the Passive Vulnerability Scanner and the Log Correlation Engine to develop lists of users and systems that behave like an administrator.
Leveraging a List of Admins
If you have a list of administrators, you can leverage a SecurityCenter dynamic asset list to search for any IP address that has a record of at least one of those accounts. There are several vulnerability records that could be mined for this data including:
- 10339 – SMB Use Domain SID to Enumerate Users – Nessus check that lists all Windows accounts on a system
- 10860 – SMB Use Host SID to Enumerate Local Users – Nessus check that lists all local Windows accounts on a system
- 60019 – Mac OS X Admin Group User List – Nessus check that lists all OS X accounts in the administrator group
- 71246 – Enumerate Local Group Members – Nessus check to list all local user accounts on Windows systems
- 72684 - Enumerate Group Members – Nessus check to list all user accounts on Windows systems
- 800001 – Users Discovered – LCE log that lists any user ID seen or associated with the particular IP address in question
- 800041 – User Source Summary – LCE log that tracks all user IDs observed logging on from this particular IP
- 800536 – Daily User Summary – LCE log that lists the unique list of user IDs associated with all programs, applications and processes run on this IP address
If I have a list of less than fifty or so administrators, I would create one large dynamic asset list looking any type of vulnerability record with their name in it. This may create some false positives, for example, if you have a Randy Oot working for you with an ID of ‘root’, however, it is more efficient than going through each plugin piecemeal.
Most of the SecurityCenter deployments I work with have LCE configured to log the active users under plugin 800001. An example dynamic asset rule looking for a list of administrators named “admin1” through “admin7” is shown below. Replace these with your administrator account names to create a list of their systems automatically.
The result of the dynamic asset list will be a list of IP addresses that are used by your administrators. We will close this document with a brief discussion on how to audit these systems.
If you have Authentication Logs
Logs from any type of device that show when a user logs into one system from another system are invaluable to determine where your administrators are working from.
The LCE simplifies the process of finding your administrators since it tracks which accounts log in from which systems with the User_Source_Summary event. For example, consider the log from the IP address of one of my Nessus scanners:
User_Source_Summary - the following user accounts have logged into remote hosts from 192.168.1.40 - rongula, root, Administrator, admin
These user names are all the account names observed logging into another system from this IP address. This includes my Nessus credentialed logins as well as when I started a remote windows desktop into this system and used SSH to log in to some of my Linux lab systems.
To find your administrators, you can search these logs for your known administrator accounts. You can also leverage SecurityCenter dynamic asset lists and plugin 800041, which represents the summary log as an informational vulnerability found by the LCE.
Below is an example dynamic asset list which searches for systems with 800041 records that also contain “root” or “administrator”. Hopefully, this sort of authentication isn’t allowed on your network. Below is a screen shot of how the dynamic asset list is created.
This asset rule is also now present in the SecurityCenter feed of available dynamic assets and is named "Admin Systems".
If you would like more granularity to determine which types of logins are occurring on your network, consider leveraging the details of plugin 800019 “Login Statistics.” This plugin reports the average number of login events per day and the total observed. Below is a screen shot:
In this screen shot, the host at 192.168.1.12 had a wide variety of login types which have been observed at least once. For example, one of them was “SC4-Login” which indicates this system logged into a SecurityCenter at least once. If we were to add “SC4-Login” as a text filter to this query and then perform an IP summary, we’d have a list of every IP that ever logged into a SecurityCenter.
This technique could further be leveraged to look for specific classes of authentications such as those related to Cisco devices or firewalls.
The bottom line with this technique is to develop a list of systems that were observed to log in as an administrator at least once to another system.
Based on Network Trust
The last type of technique we will consider are trust relationships found by the Passive Vulnerability Scanner. When PVS observes a TCP connection, it maps it to a database of all previously seen connections between each IP address on the network and the associated port. This allows PVS to report on any type of browsed port, including those associated with administrator activities. There are two major “client-side” plugins we can use for this sort of tracking:
- 2 – Client Side Port Usage – Logs all ports browsed by a given IP address, including traffic to the Internet and local systems
- 3 – Internal Client Trusted Relationship – Logs all ports browsed within the local network
In general, I suggest plugin #3 be used since it naturally only logs trust relationships on the inside of the network. If you had assets outside of your local network, such as running at Amazon, you may want to use #2, but you also may want to include those IP addresses in what your PVS considers to be “internal”.
Having said that, the output of plugin #3 is very straightforward. Below is an example:
In this case, it has reported that host 192.168.1.11 connects to 192.168.1.24 on port 31300. This is the traffic from my LCE client which operates on pot 31300 and not very indicative of an administrator doing their job.
A simplistic view of administrator activity is to look for them logging into other systems over administration ports – 22 for SSH, 3389 for RDP, 5900 for VNC and 6000 for X-Windows. Many of these ports can be re-defined and it’s also possible to run multiple versions of services, such as VNC, on multiple ports. Telnet on port 23 could also be added to this list.
There is also great value in looking for any systems on your network that have been seen to connect at least once to services on ports 22, 3389, 5900 or 6000. Below is a query leveraging the vulnerability analytics screen on my lab system which identified two systems with this condition:
For my lab, these systems are my main Linux server and my Nessus scanner which performs a variety of credentialed audits to other targets.
Saving the IP addresses from this query for later user can be accomplished by using the “Save Asset” option.
Analyzing your Administrator Systems
We’ve reviewed three different techniques to enumerate the systems used by your administrators, all of which result in creating an asset list of some sort. These lists of IP addresses identify the systems on your network that your administrators work from. Analyzing them for vulnerabilities or suspicious behaviors can help identify risk to your network. Below are some checks you can consider performing on these lists:
- Does this asset list browse directly to the Internet or accept connections from the Internet? PVS plugin 16 identifies Internet browsing and plugin 14 identifies systems that receive external connections.
- Are there any social networking hits? PVS logs many types of FaceBook, YouTube and other social media hits. Many of these are placed in the Internet Services plugin family.
- Are these systems exploitable at all? For PVS, looking for exploitable client-side vulnerabilities is performed with a filter for port=0 and exploitable=yes. For Nessus checks, consider looking for exploitable vulnerabilities with CVSS tags of “AC:H” or “AC:M” to look for client-side exploits.