Suspicious Admin

Triggers

• The host is using protocols correlated with administrative activity (RDP, SSH, IPMI, iDRAC, etc.) in ways which are considered suspicious

Possible Root Causes

• The host has begun using an administrative protocol to connect to a system for which one or more other hosts have already been observed to be regular administrators using the same protocol
• Administrative connections via a particular administrative protocol to a system which has no known regular administrators using that protocol will not result in a detection
• Administrative connections to a system which has a known regular administrator host using the chosen protocol will also not result in a detection if there is significant overlap in administrative connections to other systems between this host and the other known administrator host
• If such an administrative connection recurs over a period of several days, it is considered normal and no longer will trigger a detection
• The detection may be benign when it involves a host assigned to a new employee authorized to administrate the target systems or when the role of the employee has undergone a significant change

Business Impact

• Administrative protocols are a primary tool for attackers to move laterally inside a network in which they have already established a toehold
• Given that administrative connections are typically used in conjunction with administrative credentials, the attacker may have almost unconstrained access to systems and data that are the organization’s key assets
• Unexpected and unexplained administrative connections represent a huge potential risk in the lifecycle of a major breach

Steps to Verify

1. Verify whether the host belongs to an employee whose job function requires administrative access to other systems
2. Verify whether the employee who has been assigned the host should be using the particular administrative protocol to administer the identified system
3. Inquire whether the owner of the host actually initiated the administrative connection in order to determine whether the host has been compromised
4. Check the logs on the administered target for the creation of new accounts, the launch of abnormal processes and the modification of registry key
5. If employee associated with this host was not the originator of the admin session, reset all domain and local admin credentials belonging to the employee across the local machine and the network
6. If the credentials of the employee whose machine was compromised had domain administrative privileges, the secret key of the domain controller may have been compromised and may need to be reset – search for “krbtgt account password change” to find instructions on how to do this
7. Verify that the host from which the administrative connection was originated is a jump system as this may mean that the originator of the administrative connection is an upstream host which connected to the jump system