47 lines
4.6 KiB
Markdown
47 lines
4.6 KiB
Markdown
|
|
|||
|
|
SSH, Remmina
|
|||
|
|
|
|||
|
|
|
|||
|
|
You can get incredibly far doing AD enumeration from a Kali machine. Still, if you genuinely want to do in-depth enumeration and even exploitation, you need to understand and mimic your enemy. Thus, you need a Windows machine. This will allow us to use several built-in methods to stage our enumeration and exploits. In this network, we will explore one of these built-in tools, called the `runas.exe` binary.
|
|||
|
|
|
|||
|
|
using the current running user to login to the other computer using runas
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
runas.exe /netonly /user:<domain>\<username> cmd.exe
|
|||
|
|
```
|
|||
|
|
- **/netonly** - Since we are not domain-joined, we want to load the credentials for network authentication but not authenticate against a domain controller. So commands executed locally on the computer will run in the context of your standard Windows account, but any network connections will occur using the account specified here.
|
|||
|
|
- **/user** - Here, we provide the details of the domain and the username. It is always a safe bet to use the Fully Qualified Domain Name (FQDN) instead of just the NetBIOS name of the domain since this will help with resolution.
|
|||
|
|
- **cmd.exe** - This is the program we want to execute once the credentials are injected. This can be changed to anything, but the safest bet is cmd.exe since you can then use that to launch whatever you want, with the credentials injected.
|
|||
|
|
|
|||
|
|
|
|||
|
|
## More infromation about DNS
|
|||
|
|
|
|||
|
|
Finding the DNS IP address of a machine can be valuable when performing enumeration in an Active Directory (AD) environment. Enumeration is the process of collecting information about a network or system, and DNS IP addresses can provide valuable information about the machines on a network.
|
|||
|
|
|
|||
|
|
When an attacker wants to target a particular machine, one of the first steps is to identify the IP address of that machine. Knowing the DNS IP address of a machine can give the attacker an idea of the machine's location on the network and the IP range that it belongs to. This information can be used to identify other machines in the same subnet, which can be valuable in identifying other potential targets.
|
|||
|
|
|
|||
|
|
Additionally, knowing the DNS IP address of a machine can also be used to identify the type of machine, its operating system, and other information about the machine's configuration. This information can be used to identify vulnerabilities and potential attack vectors that can be exploited.
|
|||
|
|
|
|||
|
|
|
|||
|
|
**Question:** _Is there a difference between_ _`dir \\za.tryhackme.com\SYSVOL` and `dir \\<DC IP>\SYSVOL`_ _and why the big fuss about DNS?_
|
|||
|
|
|
|||
|
|
Response
|
|||
|
|
There is quite a difference, and it boils down to the authentication method being used. When we provide the hostname, network authentication will attempt first to perform Kerberos authentication. Since Kerberos authentication uses hostnames embedded in the tickets, if we provide the IP instead, we can force the authentication type to be NTLM. While on the surface, this does not matter to us right now, it is good to understand these slight differences since they can allow you to remain more stealthy during a Red team assessment. In some instances, organisations will be monitoring for OverPass- and Pass-The-Hash Attacks. Forcing NTLM authentication is a good trick to have in the book to avoid detection in these cases.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
## EXTRA
|
|||
|
|
|
|||
|
|
We can use the following command to force a network-based listing of the SYSVOL directory:
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
dir \\za.tryhackme.com\SYSVOL\
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
SYSVOL is a shared folder that is used to store the Group Policy Objects (GPOs) of an Active Directory (AD) environment. GPOs are used to manage the configuration settings of computers and users in a Windows domain.
|
|||
|
|
|
|||
|
|
The SYSVOL folder is located at "\DOMAIN\SYSVOL" on the AD server and it is accessible by default to any user who is authenticated on the AD, via Kerberos authentication protocol. This means that any user who has an account in the AD domain can access the SYSVOL folder, and as a result, any GPOs that are stored in that folder.
|
|||
|
|
|
|||
|
|
It's worth noting that the SYSVOL folder can contain sensitive information such as scripts, batch files, or even credentials, such as service account credentials, that are used to configure the GPOs settings. These credentials are encrypted in the SYSVOL but could be decrypted by attackers with access to the folder. Additionally, an attacker with access to SYSVOL could also modify the GPOs or script files, that could lead to additional impacts on the domain, as well as an attacker being able to move laterally within the network.
|
|||
|
|
|
|||
|
|
SYSVOL = This is the directory where AD GPOs are stored to be replicated to domain-joined machines
|