In the previous post, I hope you guys are in a victim system. The first thing pops into your head that is what we are looking for or waiting for us. Don’t get stuck here, I think we should find out where victim’s sensitive data is being store and how to take it from them. But on the network, your situation will be failed into two cases: don’t have credentials or vice versa.
1 . You don’t have any credential on the network
In this case, you have understood about the network. Maybe you can crack their Wifi or just turn on tcpdump and try some passive attack with domain controller. One of the first tool could help you that is Responder.
Responder will listen and reponse LLMNR (Link Local Multicast Name Resolution) and NBT-NS (NetBIOS over TCP/IP Name Service). Here is some basic information about them:
When a Visa Windows machine onwards tries to resolve a hostname to an IP address, the machine attempts to resolve the name in the following order:
-Domain Name System (DNS)
- DNS resolver cache (including hosts file contents)
- DNS servers
- LLMNR cache
- Multicast (IPv6 FF02::1:3) (IPv4 22.214.171.124)
-NetBIOS o WINS servers (if configured)
- LMHosts file
- NBNS Broadcast
If you guys want to determine a SMB and NTLM version in a Windows environment, you guys could have a quick look here.
However, grabbing a packet capture on the typical Windows network usually reveals that both LLMNR and NBNS broadcasts are usually failing. Some of the reasons for the DNS requests that precede these broadcasts failing are:
• Mistyped addresses.
• Software configured to contact hosts that no longer exist or do not reside on the current network.
• Queries for ‘wpad’ – The Web Proxy Auto-Discovery Protocol (WPAD) is enabled in by default on Windows machines and will attempt to resolve this name.
• Random looking names caused by Google Chrome detecting DNS redirection.
The primary goal of the attacker in this scenario is to obtain the encrypted NTLM challenge response, which can then be brute forced offline with password cracking tools to retrieve the clear text password of the currently logged-in user.
python ./Responder.py -i [Attacker IP] -b Off -r Off -w On
When a WPAD file has been sent to the victim, it means all of victim’s web traffic will go through our host as a proxy. If they go to HTTP site for example, we can take their plain text username/pasword or become them with their cookie. 😀
Or you can collect their credential hash.
Then you could decode it by JOHN and rockyou.txt wordlist.
Although it can’t decode this time, but it could work with another wordlist.
Just remember here is the most easily example of it. We will take a deeper look later.
2 . With a credential ( but not an admin )
If you are on the host that could connected to Active Directory domain, it will be a good deal. You need to escalate your privileges in this situation for get their data.
You can try to handle Group Policy Preference (GPP) vulnerable. That are extensions for Active Directory to config settings. Then you can gain username and password of Local Admin Account that is created by it. Because it is stored on the readable domain by any AD user account.
This information will be stored in file Groups.xml under \[DomainController]\SYSVOL[Domain]\Policies. Their password is encrypted by AES. But we have the public key by Microsoft, so we can decrypt it easily.
On the other hand, you don’t want to crack their password or snip them, you could try Windows Credential Editor, just for fun.Windows Credentials Editor (WCE) is a security tool that allows to list Windows logon sessions
and add, change, list and delete associated credentials (e.g.: LM/NT hashes, Kerberos tickets and
clear text passwords. It could give you list logon sections ( wce –l ) or NTLM hash credentials ( wce –w )
I think you could try two first situations for a week to check and learn how it works, then I could give you guys further example about it. After that, I also show you what we could do when we are owning the network in the next post.