Search

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

January 29, 2019

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.

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.

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.

Figure 3: Net Command Execution Detected

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.

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.

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.

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:

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.

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.

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.

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.

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:

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.

Senior Consultant

Matthew Eidelberg is a senior consultant in Optiv’s advisory services practice on the attack and penetration team. Matthew’s primary role is to perform network penetration tests to determine vulnerabilities and weakness in customer network and environments. Matthew specializes in advance threat simulation, and wireless infrastructure attacks.

Footer menu

Secondary footer menu

Copyright

Copyright @ 2019. Optiv Security Inc. All Rights Reserved

Disclaimer

The content provided is for informational purposes only. Links to third party sites are provided for your convenience and do not constitute an endorsement. These sites may not have the same privacy, security or accessibility standards.

This site uses cookies to store information on your computer. Some are essential to make our site work;
others help us improve the user experience. By using this site, you consent to the placement of these cookies.
Read our Privacy Policy
to learn more. Agree

Privacy Policy

Privacy at Optiv Security Inc.

Optiv Security Inc. and its affiliates (“Optiv”) respects your privacy and is committed to protecting the privacy of our visitors and clients. We uphold the highest industry standards in privacy and permission marketing. This privacy policy explains what personal data Optiv collects from you, through our interaction with you on our website and through provision of services and product resale transactions, and how we use that data.

Security and Privacy

Optiv's websites use reasonable commercial methods and security measures to protect against the loss, misuse, and alteration of the data under our control. We store the data collected in a database in a secure environment protected from unauthorized access, use, or disclosure. When personal data is transmitted, it is protected with encryption, such as the Secure Socket Layer (SSL) protocol.

Data Collected

Optiv collects data to operate effectively and to provide you the best experiences with our site, our services, and our product resale transactions. When you visit Optiv websites, our system uses cookies to collect statistical data about your visit to our sites (e.g., IP address, pages visited, origin of visitor domains, types of browsers used, and demographic information). This data provides Optiv with general statistics regarding our sites, giving insight into how effective certain areas of our sites are to users and how we might improve user experience. Optiv collects personal data you provide when you send us e-mails, when you register for any of our events or classes, in the operation of services, and through product resale transactions. Please keep in mind that if you directly disclose personal data, personally identifiable information, or personally sensitive data through Optiv public message boards, this information may be collected and used by others. Note: Optiv does not read any of your private online communications.

How Optiv Uses Personal Data

Optiv enforces a strict internal policy regarding data protection requirements. Personal data submitted to Optiv is used by employees managing this information for specific purposes only. These purposes include contacting you (via email, phone, etc.) in an effort to respond to a request or to provide a service or product, and to notify you of Optiv events and other Optiv-related activities such as training. Optiv may also contact you with surveys in order to conduct research about your opinion of current services or of potential new services that may be offered.

Reasons Optiv Shares Personal Data

Optiv shares your personal data with your consent or as necessary to complete any transaction you have requested or authorized. Optiv also shares data with Optiv-controlled affiliates and subsidiaries; with vendors working on your behalf; when required by law to respond to legal process; to protect our customers; to maintain the security of our services; and to protect the rights or property of Optiv.

How to Control Your Personal Data and Opt-Out

You can always choose whether you wish to receive promotional email, SMS messages, telephone calls and postal mail from Optiv. You can opt-out from receiving interest-based advertising from Optiv by emailing info@optiv.com. You can also opt-out from email communications by clicking on the opt-out (unsubscribe) link in any message you receive from us. This will allow you to unsubscribe or update your message preferences.

Refer a Friend/Forward-to-a-Friend Functionality

If you feel that information about Optiv could be useful to a third party you know (e.g., your co-workers, other professionals, etc.), you may use our forward-to-a-friend functionality. If you choose to use our referral service to tell someone about Optiv, we will ask you for their e-mail address. We will send them a one-time email inviting them to visit the site. Optiv stores this information for the sole purpose of sending this one-time email and tracking the success of our referral program.

Blog Sites

If you leave a comment on an Optiv blog, you should be aware that any personal data or personally identifiable information you submit on our blog site can be read, collected, or otherwise used by anyone who reads the blog or who visits the URL of the blog post you comment on. We are not responsible for use of this information by non-Optiv personnel.

Your name and e-mail are required for verification and protection against spam. The name you leave will be published and is used as an identifier of the comment. The email provided is not published. All blog content including posts, articles, and comments, are reviewed before being published.

Testimonials

We post customer testimonials on our website. These testimonials may contain personal data, such as the customer's name. We obtain your consent prior to posting the testimonial, so that we can post your name along with the testimonial.

Cookies and Similar Technologies

Client-side cookies (small text files placed on your device) are used to verify the login status of customers using products or services linked directly with our website. One of the primary purposes of cookies is to provide a convenience feature to save you time. The purpose of a cookie is to tell the Web server that you have returned to a specific page. For example, if you personalize pages, or register on site, a cookie helps Optiv to recall your specific information on subsequent visits. The information you previously provided can be retrieved, so you can easily use the features that you customized. You have a variety of tools to control cookies and similar technologies including browser controls to block and delete cookies, and controls from some third-party analytics service providers, to opt out of data collection through web beacons and similar technologies. If a user rejects the cookie, they may still use our sites; however, the user may not be able to access all areas of our sites.

Third Party Websites

Please be aware that other websites that may be accessed through our site may collect your personal data. Optiv does not share your personal data with those websites and is not responsible for their privacy practices. Please check the applicable Privacy Policy of those sites.

Children's Privacy

These websites are not intended for people under the age of 13. Optiv does not knowingly solicit or collect information from children or minors (under the age of 18). Optiv complies with The Children’s Online Privacy Protection Act (US), The Personal Information Protection and Electronic Documents Act (Canada), and such other laws.

Policy Consent

By using our websites, you agree to this Privacy Policy. This policy appears in its completed form and supersedes any earlier version.

Notification of Changes

This Privacy Policy is subject to change without notice. Any changes to this policy will be posted on our site at least one week prior to their taking effect. If at any point, we decide to use personal data or personally identifiable information in a manner different from that stated at the time it was collected, we will notify users via email of the changes to our policy. Users will have a choice as to whether or not we use their information in this different manner. We reserve the right to modify this privacy policy at any time, so please review it frequently. If we make material changes to this policy, we will notify you here, by email, or by means of a notice on our website.

Privacy Policy Effective Date: May 10, 2018

Optiv welcomes your comments regarding this statement of privacy. If you believe that Optiv has not adhered to this statement, please contact us at: legal@optiv.com. We will use reasonable efforts to promptly determine and remedy the problem.