Overview#

When conducting penetration testing or red team assessments against an Active Directory (AD) environment, there are scenarios where valid credentials are obtained, but interactive access to a domain-joined machine is unavailable. In such cases, Credential Injection techniques allow an attacker to utilize the credentials without logging into a domain-joined system.

One of the most effective ways to achieve this on a Windows machine is by leveraging the built-in runas.exe utility with the /netonly flag.

2. The runas.exe Command and Its Parameters#

To effectively use runas.exe, it’s essential to understand how its syntax works and what each parameter means.

Basic Syntax#

runas.exe /netonly /user:<domain>\<username> <command>

Explanation of Parameters:#

• /netonly:
  • This flag is used to instruct runas.exe that the credentials provided should only be used for network authentication (to authenticate against resources such as file shares or domain services).
  • The local machine remains in the context of the current user, so the attacker doesn’t gain elevated privileges on the local system.
• /user:
  • This specifies the domain and username in the format <domain>\<username>.
  • Always use the Fully Qualified Domain Name (FQDN) of the domain instead of the NetBIOS name for better name resolution in the domain environment.
• <command>:
  • The command specifies the program that will run with the injected credentials. Common choices are cmd.exe or PowerShell, but you can use any executable that suits your needs, depending on what you want to accomplish with the injected credentials.

Example :#

runas.exe /netonly /user:example.com\user123 cmd.exe

• This command runs cmd.exe under the credentials of user123 in the domain example.com.
• The system will prompt for the password for user123, and once entered, the command prompt (cmd.exe) will open with the credentials loaded into memory.

3. Practical Use of runas.exe for AD Credential Injection#

Once the credentials are injected into memory, they can be used for network-based authentication across the domain. The injected credentials will allow you to authenticate to domain resources, but not elevate privileges on the local system.

Practical Use Cases:#

• Accessing Shared Folders:

  Using runas.exe to authenticate as a domain user lets you access shared network folders and services that are otherwise restricted by the local system’s user context.

  dir \\<domain>\share

  • This will allow you to enumerate and interact with network shares and SYSVOL directories without being a domain-joined machine.

  • Authenticating to SQL Server:

    In many environments, SQL Server can be configured to use Windows Authentication, allowing domain users to connect without a separate SQL login. By injecting valid AD credentials, an attacker can gain access to SQL Server instances that rely on Windows Authentication.

    • For example, you could run SQL Management Studio (ssms.exe) using runas.exe and authenticate to the SQL server as the injected user, bypassing the need for separate SQL credentials.

  • Web Application Authentication:

    Many internal web applications use NTLM (Windows Integrated Authentication) to authenticate users. If you have domain credentials loaded, you can interact with these applications without needing to enter credentials manually. Just by opening a browser session from a runas-spawned command prompt, NTLM authentication will automatically pass the AD credentials.

  Example of Running SQL Management Studio:#

  runas.exe /netonly /user:example.com\user123 ssms.exe

  This command would launch SQL Management Studio (ssms.exe) under the user123 credentials, allowing access to any SQL servers the user has permissions to interact with.

  ---

  4. Verifying the Success of Credential Injection#

  After successfully injecting the credentials, the next step is to verify that they are being used properly and that the network authentication is functioning.

  Testing Network Authentication#

  One of the most reliable ways to test if the credentials were correctly injected is by accessing the SYSVOL directory on the domain controller. The SYSVOL share contains important Group Policy Objects (GPOs) and other domain-related files, which are accessible to all domain users.

  You can use the following command to test:

  dir \\<DomainController_FQDN>\SYSVOL\

  • If the command successfully lists the contents of the SYSVOL directory, it indicates that the credentials are working correctly and you can now interact with domain resources.
  • If the command fails, the credentials might be incorrect, or there could be a permissions issue.

  ---

  5. DNS Configuration for Network Authentication#

  To ensure smooth communication with domain resources (such as the Domain Controller), it’s critical to have proper DNS resolution. Typically, the DNS server should be set to the Domain Controller itself.

  Manually Configuring DNS#

  If DNS is not automatically configured, you can manually set the DNS server on the machine to point to the Domain Controller’s IP:

  $dnsip = "<DomainController_IP>"
  $index = Get-NetAdapter -Name 'Ethernet' | Select-Object -ExpandProperty 'ifIndex'
  Set-DnsClientServerAddress -InterfaceIndex $index -ServerAddresses $dnsip

  After setting the DNS, use the following command to verify the DNS configuration:

  nslookup <domain_FQDN>

  This ensures that the machine can properly resolve domain names and communicate with the Domain Controller.

  ---

  6. Authentication Types: Kerberos vs. NTLM#

  An important consideration when using runas.exe for credential injection is the authentication type used for network communication.

  • Kerberos Authentication:
    • This is the preferred method for authenticating users to domain resources. When you use the FQDN of a domain controller (e.g., \\<DC_FQDN>\SYSVOL), the system will try to authenticate using Kerberos.
  • NTLM Authentication:
    • If you provide the IP address of the domain controller instead of the FQDN (e.g., \\<DC_IP>\SYSVOL), the authentication will fall back to NTLM. NTLM is less secure than Kerberos, but this fallback method can be useful in situations where you want to avoid Kerberos authentication (e.g., to bypass detection during a red team exercise).

  Example:#

  dir \\<DC_FQDN>\SYSVOL

  This will use Kerberos.

  dir \\<DC_IP>\SYSVOL

  This will use NTLM.

  ---

  7. Post-Injection Exploitation Scenarios#

  Once the credentials are successfully injected, a variety of post-exploitation actions can be carried out using those credentials.

  Examples of Post-Exploitation#

  • Network Shares:

    Attackers can access file shares, read and exfiltrate sensitive information, and potentially upload malicious files if the user has write permissions.

  • SQL Server Authentication:

    Using Windows Authentication, an attacker can access SQL Servers to dump sensitive data, such as password hashes or confidential business data.

  • Enumerating Active Directory Objects:

    Once authenticated, attackers can start enumerating AD objects (users, groups, machines), which can reveal valuable information about the domain structure and potential targets for further exploitation.