It’s Not Always About the Perimeter – A Look at Domain Reconnaissance

It’s Not Always About the Perimeter – A Look at Domain Reconnaissance

In this information age, security threats are commonplace and can be devastating to a business. The ability to quickly and accurately detect cyber-threats is one of the most critical capabilities of cybersecurity teams. Companies depend on these teams to ensure that their environments remain hardened and vulnerability free; yet threat actors are still successfully breaching them. This is because a majority of cybersecurity teams focus’ has always been on hardening a company’s perimeter (i.e. Internet-facing assets), in order to prevent threat actors from gaining access. However, even the most hardened environments can be susceptible to spear phishing attacks and newly discovered security vulnerabilities (commonly known as Zero-Days).

 

After establishing a foothold, an adversary begins to move towards their intended goal compromising other systems along the way. Whether it’s accessing sensitive stored data such as credit card information and Personally Identifiable Information (PII), or compromising the network completely, an adversary must first formulate a plan of attack. Often, this involves strategic lateral movement throughout the network, while slowly increasing privileges at each point along the way. To achieve this, the adversary needs to know where to go, and what identities they need to compromise; this usually involves a technique called domain reconnaissance

 

Domain1

Figure 1: Attack Chain Highlighting Domain Reconnaissance

 

Threat actors perform domain reconnaissance against a target domain’s Active Directory (AD) to first learn what users, systems and groups exist in a domain, who has what privileges, and what tasks systems perform. With this information the attacker can focus on where they need to go and what accounts need to be compromised to successfully exfiltrate the target information. Domain reconnaissance is very difficult to prevent because AD has no way of distinguishing whether the request came from a valid source or from an adversary.

 

As a result, an adversary only needs to compromise a valid set of credentials or a valid user’s session on a domain-joined system, to authenticate to AD and perform lookups as a valid user. These actions are commonly performed using Windows-based applications such as PowerShell.exe, and CMD.exe which have the built-in functionality to enumerate this information and are native to all Windows systems. 

 

net view — Obtain a list of connectable domain resources  net user — Manage local/domain accounts  net group — Obtain a list of users belonging to certain domain groups  net use — Access to resources

 

Domain2

Figure 2: Net Command Execution Detected

 

Adversaries often use these functions to map out an environment and choose their targets based on the gathering of information with high successes. Blue Teams, or internal cybersecurity defensive teams, routinely react by blacklisting or locking down PowerShell.exe and CMD.exe, believing this will prevent not only domain reconnaissance but also code execution. However, blacklisting applications is not effective. For example, simply restricting PowerShell.exe and CMD.exe is ineffective because the raw net.exe command application can be still executed without restriction. An adversary can use other applications to call these command applications and view the results. It’s not feasible to permanently disable these either, as this can inhibit a network administrator’s ability to carry out routine administrative tasks. 

 

With the inception of threat hunting and threat-hunting tools, Blue Teams have adapted by relying on system logs to hunt and detect these threats by creating alerts or monitoring for suspicious traffic. These techniques and tools allow Blue Teams to monitor behaviors, and therefore differentiate suspicious requests from benign ones. This allows Blue Teams to detect, investigate and stop the adversaries before they accomplish their goal, by revoking the adversaries’ access.

 

Domain3

Figure 3: Net Command Execution Detected

 

Domain4

Figure 4: Net Command Execution Detected

 

As a result, the adversaries have begun to rely on other techniques and services, including Lightweight Directory Access Protocol (LDAP), to perform these functions.

 

LDAP is a protocol used to access and modify information stored within AD. LDAP is often used to consolidate an entire organization’s AD structure into a central repository. For example, rather than managing user lists for each group within an organization, LDAP can be used as a central directory accessible from anywhere on the network, allowing for simple, fast data query and retrieval. LDAP can also bridge the gap between non-Windows-based applications and services deployed in corporate environments, allowing them to communicate with the domain to view users, groups and system objects. 

 

LDAP allows low privilege users (i.e., ones that do not have elevated or administrative privileges) to authenticate and perform queries. LDAP information is stored in a directory, so user information is referenced as objects. The example query below, would list information specific to the user (ballen), which is part of the object class user and belongs to the domain starlabs.local.

 

dc=starlabs,dc=local(&(objectClass=user)(sAMAccountName=ballen)

 

{'primaryGroupID': ['513'], 'logonCount': ['162'], 'cn': ['Barry Allen'], 'countryCode': ['0'], 'dSCorePropagationData': ['20171128224008.0Z', '16010101000000.0Z'], 'objectClass': ['top', 'person', 'organizationalPerson', 'user'], 'lastLogonTimestamp': ['131777836103028680'], 'profilePath': ['\\SLServer01\\ballen'], 'instanceType': ['4'], 'sAMAccountName': ['ballen'], 'distinguishedName': ['CN=Barry Allen,CN=Users,DC=STARLABS,DC=local'], 'sAMAccountType': ['805306368'], 'title': ['CEO'], 'objectSid': ['\x01\x05\x00\x00\x00\x00\x00\x05\x15\x00\x00\x00`\xcdu{\x1d\xd0\xaeX\x03vb\xfcc\x04\x00\x00'], 'whenCreated': ['20171128224008.0Z'], 'uSNCreated': ['20562'], 'mail': ['barry.allen@starlabs.com'], 'lockoutTime': ['0'], 'badPasswordTime': ['131777835872252709'], 'pwdLastSet': ['131563824087613604'], 'description': ['CEO'], 'objectCategory': ['CN=Person,CN=Schema,CN=Configuration,DC=STARLABS,DC=local'], 'objectGUID': ['\x0fw\x08rs\xec\xa0J\x8c\x13\xe1=\xa3\x07\x81\x11'], 'whenChanged': ['20180803152650.0Z'], 'badPwdCount': ['0'], 'accountExpires': ['9223372036854775807'], 'displayName': ['Barry Allen'], 'physicalDeliveryOfficeName': ['Central City'], 'name': ['Barry Allen'], 'homeDrive': ['Z:'], 'memberOf': ['CN=SL_R&D,CN=Users,DC=STARLABS,DC=local', 'CN=SL_Scientist,CN=Users,DC=STARLABS,DC=local'], 'codePage': ['0'], 'userAccountControl': ['66048'], 'lastLogon': ['131777836103028680'], 'uSNChanged': ['262424'], 'sn': ['Allen'], 'homeDirectory': ['\\\\SLServer01\\ballen'], 'givenName': ['Barry'], 'lastLogoff': ['0']}

 

Using LDAP queries, adversaries can access more information than the built-in Windows net.exe commands provide natively. LDAP also provides anonymity as it is difficult to detect specifically what data is being requested.

 

LDAP queries will not trigger any Kerberos or NTLM (NT Lan Manager) events besides a single log on event, thus making detection and tracking very challenging. After a successful authentication occurs, Blue Teams have no insight into what is being viewed, unless the connection is made over an unencrypted channel, i.e. using LDAP instead of LDAPS (LDAP Secure). As shown in the packet capture example below.

 

Domain5

Figure 5: Cleartext LDAP Search Query

 

Using encryption, adversaries can pull down all information related to domain users, groups, and systems in a single request. Once this information is enumerated, adversaries can review it locally, gaining the same level of information, but without sending multiple net.exe commands to AD. By doing so, adversaries do not generate any suspicious traffic alerts that could indicate their presence.

 

Domain6

Figure 6: Comparison of Net Command vs Enumerating Through LDAP

 

With this information adversaries gain understanding of the domain and who they need to target to achieve their objective. The next step in the kill chain would be finding the desired target user or system. This involves communicating and interacting with systems and domain objects, which can generate alerts, causing Blue Teams to be alerted and take remediation actions. Running attack tools, executing payloads on remote systems, or using PowerShell scripts to identify this information are all getting harder to successfully perform while remaining undetected. Endpoint solutions, ACLs and threat-hunting agents can detect these tools and techniques, preventing them from being executed. In response, adversaries are moving towards using raw Windows APIs to carry out these activities (known as living off the land). 

 

API’s are system libraries filled with functions designed to interact with the operating system to carry out specific activities at a granular level. These APIs exist in Windows operating systems by default and are used by the operating system as well as software and services to perform tasks. By directly using these APIs to perform lateral movement techniques, an adversaries’ traffic can blend in with normal network traffic making it harder to distinguish legitimate activity from malicious use. 

 

One technique that adversaries commonly use is to enumerate remote network shares. By reviewing the access associated with a particular remote share, an adversary can either compromise the system or view or modify data stored on the remote share. Adversaries will perform this looking to see what access they have on a remote system’s C$ and ADMIN$ share. This is because these shares provide administrative functions that can result in the execution of code. 

 

Using the NetrShareEnum API, adversaries can enumerate a list of available shares on a remote system. This API can be called remotely requiring only a valid set of credentials, or an active user session. This API can retrieve a large number of useful details about each available share, based on the level requested. NetrShareEnum allows for five different levels information type. While this API contains a tremendous amount of information adversaries can use, there are restrictions on who can request certain levels, as shown below: 

 

Domain table

 

While several of these levels provide information specific to permissions, these levels require elevated or administrative privileges. Any low or unprivileged user can still request access levels 0 or 1. These levels provide limited information specifically listing the names of the shares on the remote systems. This information is stored in the SHARE_INFO_0_CONTAINER structure. In the example code below the EntriesRead contains the number of shares running on the remote system while the LPSHARE_INFO_0 buffer contains the names.

 

typedef struct _SHARE_INFO_0_CONTAINER { DWORD EntriesRead; [size_is(EntriesRead)] LPSHARE_INFO_0 Buffer;  } SHARE_INFO_0_CONTAINER;

 

With these names an adversary still needs to know what access permissions are associated with each share. Adversaries are able to determine this by attempting to view the contents of the share; if this is allowed/ they have “READ” access. By contrast, testing “WRITE” access often involves attempting to actually write something to the share. Endpoint solutions have increased their sophistication in detecting changes to file systems. While most notably these mechanisms are designed to detect malware, endpoint solutions have also become more advanced resulting in the development of signatures for suspicious files that are related to malicious activity. To avoid being detected, adversaries can employ a folder creation technique. The ability to create folders in a remote share still requires write access. However, folders that contain zero data can be used to create a signature for detection. 

 

Once the adversaries know which remote systems allow them to execute code, then they look to see what users are logged on and review the privileges of these users. This allows an adversary to simply target specific hosts, compromising them and extracting user credentials, instead of compromising numerous systems and potentially being detected. There are two APIs that adversaries can take advantage of to gather this information.

 

The first is NetWkstaUserEnum. This function performs many tasks including gathering information about the users currently logged in and then storing it. It then pulls this information from all active tokens on the remote system. As a user authenticates to a system creating a valid login session, the system generates a user token. This information is stored in the WKSTA_USER_INFO structure.

 

typedef struct _WKSTA_USER_INFO_1 {   [string] wchar_t* wkui1_username;   [string] wchar_t* wkui1_logon_domain;   [string] wchar_t* wkui1_oth_domains;   [string] wchar_t* wkui1_logon_server;  } WKSTA_USER_INFO_1,  *PWKSTA_USER_INFO_1,

 

wkui1_username string contains the name of a user while the wkui1_logon_domain string contains the domain associated with the user. The other values provide additional information that adversaries may find important. The first is wkui1_oth_domains. This string contains a list of the other NetBIOS domains browsed by the workstation. Adversaries can use this information to compromise other domains that are shared by the workstation or user, that adversaries were unaware of or unable to access previously. 

 

The second is wkui1_logon_server, which contains the name of the Domain Controller the user used to authenticate. Disclosure of this information can be very impactful, so to request this API remotely, users must have administrator privileges on the remote system. 

 

The second, API is NetSessionEnum. This API provides similar information that NetWkstaUserEnum does. NetSessionEnum can query information about any valid user sessions on a remote system. The difference is that this API can be accessed by any non-Administrative users. This means that using a valid domain account an attacker can enumerate all active sessions on any system in a domain whether it be a workstation or a domain controller. 

 

Domain7

Figure 7: Domain Controller Logging Remote Sessions

 

This information is stored in the SESSION_INFO_10 structure.

 

typedef struct _SESSION_INFO_10 {   [string] wchar_t* sesi10_cname;   [string] wchar_t* sesi10_username;   DWORD sesi10_time;  DWORD sesi10_idle_time; } SESSION_INFO_10,  *PSESSION_INFO_10,  *LPSESSION_INFO_10;

 

sesi10_cname string contains the host name of the computer where the session was established on while the sesi10_username string contains the name of the user who established the session. While this API requires less privileges to execute, many detection mechanisms have created alerts monitoring for any remote requests to this API. 

 

Domain8

Figure 8: IPMI Hash Disclosure Attack

 

As a result, adversaries will often use a combination of NetrShareEnum to read the file system looking for user profiles and NetWkstaUserEnum to see active session to remain undetected, and then using NetSessionEnum requests sparingly and targeting specific hosts. With adversaries employing these techniques, domain reconnaissance and lateral movement is becoming more and more difficult to detect and and counter. Shutting down or restricting access to these core functions in a domain can impact the business’s ability to operate. 

 

For LDAP, Bue Teams should monitor LDAP traffic and look for abnormal queries. Focus these logs, looking for systems that do not need to be connecting to LDAP while also looking for high volumes of LDAP traffic to domain controllers. Alternatively implementing firewalls between your domain controllers and the rest of the network to limit your network access to LDAP services, ensuring only systems and services that require LDAP can access it, is also helpful. 

 

Defending against enumerating remote shares can be quite difficult as this function is also used for legitimate purposes in a domain. As such, it can be tricky to differentiate malicious events from benign ones. Logging of these events in a centralized system and narrowing down the scope by creating alerts for access events to ADMIN$, C$ and other business-critical remote shares, can help Blue Teams potentially zero in on potential threats. Alternatively, implementing host-based firewalls restricting access to SMB access to trusted sources can help eliminate an adversary’s ability to both enumerate remote shares as well as the permissions associated with them. 

 

As mentioned earlier NetSessionEnum can be requested by any valid domain user because the default value associated with it is set to authenticated users. By modifying the registry key: 

 

HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/LanmanServer/DefaultSecurity/SrvsvcSessionInfo

 

to one of three other allowed options: Administrators, Server Operators, and Power Users, Blue Teams can restrict who can access this information and impact an adversary’s ability to perform lateral movement. Microsoft has also released a PowerShell, NetCease to automate the process of changing this permission. 

 

Preventing domain reconnaissance means taking the above steps to help harden environments against the latest lateral movement techniques. In addition, continually reviewing processes and procedures on a regular basis also ensures that systems are current and hardened per industry best practices. 
 

Matthew Eidelberg
Engineering Fellow | Optiv
Matthew Eidelberg is an Engineering Fellow in Optiv’s Threat Management Team (Attack and Penetration specialization). His primary role focuses on leading Threat Management’s Adversary Simulation Services, which address physical, red/purple team, and other advanced assessments. Matthew’s expertise also involves research development, focusing on developing new techniques and tooling for endpoint security bypass and evasion.
Would you like to speak to an advisor?

How can we help you today?

Image
field-guide-cloud-list-image@2x.jpg
Cybersecurity Field Guide #13: A Practical Approach to Securing Your Cloud Transformation
Image
OptivCon
Register for an Upcoming OptivCon

Ready to speak to an Optiv expert to discuss your security needs?