Covenant C2 is described by its authors as “A . NET command and control framework that aims to highlight the attack surface of . NET, make the use of offensive . NET tradecraft easier, and serve as a collaborative command and control platform for red teamers.”
This post is meant to supplement a video that I uploaded to my YouTube channel.
Installing Prerequisites
To begin, we have some prerequisites to install. They both can be found at the following links. Both installers work well with default settings and just basic “Next, Next, Finish”.
Secura has a great blog post on this topic already, but I wanted to share my experience with actually playing with their proof-of-concept exploit code. You can read about this exploit on their blog at https://www.secura.com/blog/zero-logon.
The exploit abuses the Netlogon Remote Protocol in Windows, which among other things, can be used to update computer passwords.
This vulnerability, and patch, isn’t exactly new. Microsoft released a patch for it last month, but there are now some public POCs in the wild that anybody can get their hands on, making this much more dangerous to leave un-patched.
Installing Tools
First, we’re going to need a few things from GitHub. I like to download the tools in my /opt directory. You can run the following command to download the prerequisites.
The above mentioned POC exploit will reset the password of the domain controller account, so BE CAREFUL RUNNING IN PRODUCTION as it will break communication to other domain controllers in the domain.
To reset the password of the domain controller account and make it null, we can use the following command.
The proof-of-concept exploit code also includes a script for restoring the old credential post-exploitation. To do this, you can grab the hex encoded machine password from the secretsdump.py output and then use the following command.
While the above mentioned article includes a table with a list of patches, I’d highly recommend checking the Windows Update Catalog for patches that might have superseded the articles mentioned in this table. For example, the September roll-ups contain this patch and are not listed in the table.
Running this exploit against a machine that has received the patch will return the following result.
Once you have low-level credentials to a Windows domain, you may be able to leverage those credentials to perform a Kerberoast attack against a higher-level user account. The easiest way to identify if a user account is vulnerable to a Kerberoast attack is via BloodHound.
Once you have identified a Kerberoastable user, you can leverage Impacket to perform the attack w/ the following command. This command will require valid domain credentials for at least a low-level user, but it should return the password hash of any Kerberoastable user on the domain.
If you’re able to come across credentials or NTLM hashes for a Windows box that has SMB enabled, you may be able to leverage the tool called winexe to gain a shell. If you have captured a NTLM hash, say from dumping a SAM database, you may be able to pass-the-hash.
Wanted to provide a single place to go for all file upload/download techniques when attacking a Windows machine from Kali Linux. This will be updated as I come across new ones and/or the next time I need to use them.
Uploading and Hosting Files
Python Web Server
The following will start a webserver in the present working directory using Python2.
python -m SimpleHTTP Server 80
The following will start a webserver in the present working directory using Python3.
We’ll need to perform a few steps to set this up, but it’s a great way to transfer files to/from a system. To begin, let’s create a directory called smb on our attacking system. Files in this directory will be available on the other end, and likewise, the other end will be able to place files into this directory.
mkdir smb
impacket-smbserver <sharename> `<path>`
Then we can mount this file share in PowerShell from the other side.
Welcome to Part 1 of this series. As each part gets released, we’ll dive deeper and deeper into the joys of LLMNR poisoning and I’ll demonstrate just how easy it makes the life of an attacker when this default legacy protocol is still running in your environment.
By the end of this series, you will be able to pivot across an ENTIRE poorly configured domain with SYSTEM-level access.
Part 1 Table of Contents:
What is LLMNR & NBT-NS?
Brief Explanation of the Exploit
Downloading and Installing Responder
Capturing NTLMv2 Hashes w/ Responder
What is LLMNR & NBT-NS?
Crowe.com does a fantastic job at giving you a high-level overview of what NetBIOS & link-local multicast name resolution do. Instead of reinventing the wheel, I will simply provide an excerpt from their website below.
“NetBIOS and LLMNR are protocols used to resolve host names and facilitate communication between hosts on local networks. NetBIOS is generally outdated and can be used to communicate with legacy systems. LLMNR is designed for consumer-grade networks in which a domain name system (DNS) server might not exist.”
If none of this sounds familiar, I highly recommend checking out the below link and reading more about these protocols before moving on.
When a computer requests access to a legitimate network resource, it usually follows a set of pre-defined queries. LLMNR and NetBIOS come into play as last resort options when other methods (such as DNS or local hosts files) don’t prove helpful. Since LLMNR & NetBIOS will attempt name resolution via broadcasted requests to the broadcast-domain, we can set up tools to listen for these requests and respond back pretending to be the intended recipient.
Poisoning Requests With Responder to Capture NTLMv2 Hashes
Now that we have our tools set up. Let’s take a deeper look at Responder. cd /opt/Responder ls
We see a handful of files, including Responder.conf (the configuration file) and Responder.py(the script used to perform the exploit). Let’s take a closer look at Responder.conf. gedit Responder.conf
So there’s a lot going on in here, but I just wanted to make you aware of the section titled Servers to Start. This is where we can configure which servers we’d like Responder to spin up to perform the exploit. We won’t actually make any changes in here just yet, just know that this conf file is very important and will be brought up in the future.
With all servers active, let’s go ahead and Run Responder on our primary interface (note yours may differ depending on your environment). sudo python Responder.py -I eth0
So what’s happening here? Responder is listening for all incoming requests in the three listed Poisoners (LLMNR, NBT-NS, DNS/MDNS). If any devices on the network need a hand resolving a hostname, fileshare, etc. they will send a broadcast out to the entire network. With this tool running, we will be able to ‘Respond’, pretending to be that destination server. From there, the device will reply back with its NTLMv2 Hash as it attempts to authenticate to the resource.
You’ll get the most responses back on a busy network with many devices in use. I’ve also found that we will get a lot of results during the beginning of shifts or once users return from lunch breaks. If you have enough patience, you should receive a response pretty soon. If you don’t have patience, then let’s see if we can force a LLMNR request..
From a Windows machine on the network, launch a File Explorer window, and attempt to Browse to a fileshare that doesn’t exist. \\infinitelogins
Within just a few moments, Responder is able to capture my NTLMv2 Hash.
That’s it for this post! Next up, I’ll be showing you what you can do with these hashes to pivot onto other machines or even score a reverse shell. In the mean-time, let me know what you thought of this and whether or not it has been helpful!
There are tons of cheatsheets out there, but I couldn’t find a comprehensive one that includes non-Meterpreter shells. I will include both Meterpreter, as well as non-Meterpreter shells for those studying for OSCP.
Table of Contents: – Non Meterpreter Binaries – Non Meterpreter Web Payloads – Meterpreter Binaries – Meterpreter Web Payloads
As I’m sure you’ve heard, there were a handful of critical vulnerabilities announced in this week’s Patch Tuesday. Included in the list of vulnerabilities is a flaw within CryptoAPI that would allow an attacker to digitally sign malicious software updates as the legitimate creator of the software. While Microsoft lists this vulnerability with a severity level of Critical, an attacker would need to first insert themselves as a Man in The Middle to be able to intercept a device’s software update request and return back a digitally signed malicious executable.
Table of Contents – Affected Operating Systems – KB’s Needed to Patch Vulnerability
If you have the time, I’d highly recommend the below Webcast on this topic from the SANS Institute’s YouTube page. It goes above any beyond any level of detail I would be able to.
Affected Operating Systems
Windows 10
Windows Server 2016
Windows Server 2019
Note: Windows 7 and older are NOT vulnerable. The Windows Update Service itself is NOT vulnerable.
The exact patch that you need depends on the exact OS Build of Windows 10 you’re running. Below is a list of the related KBs and which Operating System they patch. This list is current as of this blog’s posted date.
I recommend searching for your Build of Windows 10 by using Ctrl+F and typing the version (I.E 1909, 1903, etc.)
Welcome to my first hacking tutorial! Please consider following me on Twitter and/or subscribing to the blog if you like content like this.
In this guide, I will demonstrate how easy it is to break into a Windows machine when you have physical access, even if you have a strong password securing the account. We will go from being completely locked out, to having full Administrator access in less than 5 minutes.
This is a Beginner level attack that anybody can do. Let’s dive in!
Table of Contents – Explaining the Attack – What You Will Need – Performing the Attack – Post Exploitation – Mitigation
Note: The following are requirements for this attack to work.
A Windows computer with drive encryption DISABLED.
A windows recovery disk or installation ISO. Can be installed on a USB drive.
Physical access to the machine.
Ability to boot into the BIOS.
Explaining the attack
Before we begin, I would like to explain how the attack works. Ever wonder what the name of the file is that launches the accessibility controls on the log-in screen? Probably not, but I have. When you click the accessibility control icon, Windows launches a utility called utilman.exe.
Well what could happen if we were to modify utilman.exe so that we can do more nefarious things? Perhaps we can replace utilman.exe with a command prompt window? Would this allow us to launch a command prompt instead of accessibility controls when the shortcut gets pressed?
What you will need
You must have a few things prepared ahead of time.
A Windows InstallerDisk or USB Drive. You can create a bootable Windows installer by downloading the ISO file from Microsoft and placing it on the USB drive using a tool such as Rufus. Let me know if a guide on this process would also be helpful.
Physical access to the machine.
That’s it. The rest can be done by hand!
Performing the attack
1) Place your Windows Installation Media into the machine and Reboot the system.
2) As the system boots, we need to press a key to boot into the BIOS. Each computer is different, but you can typically achieve this by pressing an F-Key as the system boots up, such as F12.
3) In this BIOS, navigate to the Boot Options and select your Installation Media Method. This will likely be listed as a USB Drive or a CD-ROM.
4) Allow the system to boot up. It should load into your Installation Media instead of the fully installed Operating System. Once booted, click on Next.
5) When taken to this screen, select Repair Your Computer.
6) Out of the list of options, select Troubleshoot.
7) Now we have the option to select Command Prompt.
8) You should be presented with a shell that defaults to the X:\Sources directory. This is the present working directory of the installation media we’ve created. Since the Operating System (OS) isn’t actually installed here, we need to locate where the OS lives if we’re going to modify utilman.exe. Run the following command: diskpart
Once the DISKPART utility loads, run the command: list volume
You should see a list of all current volumes located on the machine, and their associated drive letters. Based on the label and size of the results, we can tell which drive letter is a System Restore partition, and which one isn’t. In my example, the system drive is represented by letter D:\
Type the following command to kill the DISKPART utility and go back to the regular shell. exit
9) Now that we know what drive letter represents the system drive, lets Change into it by typing the following command: d: Note: You may need to use a different drive letter based on the results of the above step.
We should see the current directory of the shell change to d:\Windows\System32>
10) Luckily for us, utilman.exe lives in the System32 folder. Let’s run the following command to rename the existing utilman.exe so we don’t lose the file. rename utilman.exe utilman.old
11) With utilman.exe safely out of the way, let’s take a copy of the Command Prompt utility and name that copied version utilman.exe. copy cmd.exe utilman.exe
12) With everything now in place, Remove the Installation Media and Reboot the machine. Allow it to boot into the fully installed operating system as normal.
13) Once the machine boots, you should be presented with the typical login screen. However, clicking on the Accessibility Options now launches cmd.exe instead of utilman.exe
We can run the following command to see that we have SYSTEM level access, the highest level of access you can have on a machine. whoami
Post exploitation
From here, you’ve already got all the access you need to browse the machine’s files, execute commands, or add/remove users. Some of my favorite things to do are below.
Reset an existing user’s password. net user <USERNAME> <PASSWORD>
Create a local administrator account. net user <USERNAME> <PASSWORD> /add net localgroup administrators <USERNAME> /add
Exploit Mitigation
This goes to show just how easy it is for an attacker to take control of a system within just a few minutes if they have pysical access to it. While having strong credentials are important, they prove useless in this case if we have the ability to just reset the credentials.
The best mitigation strategy in this case would be to implement hard-drive encryption. With the drive encrypted, we would have never been able to make changes to the directory storing system files without first knowing the encryption key.
Windows has a built-in drive-encryption mechanism called BitLocker. This is a free service and super effective at preventing these type of attacks, as well as provides protections against an attacker pulling your hard-drive and looking through its contents offline. More details on this topic in a future blog-post, but for now you can find out how to enable this protection for yourself by referencing Microsoft’s guide. https://support.microsoft.com/en-us/help/4028713/windows-10-turn-on-device-encryption
Please let me know what you thought of this post and if this was at all helpful to you. Let me know what you’d like to see next and whether or not a guide on implementing BitLocker is worthwhile.
This post intends to serve as a guide on activating a purchase ESU license key on a Windows 7 box. I’m making the assumption that you have already gone through the procedure to purchase the Windows 7 ESU key and have access to it.
If you haven’t, you should be able to purchase one through a distributor (such as Ingram Micro) and link it to your Office 365 tenant as a subscription-item. If you are a partner and need details on procuring Windows 7 ESUs through the Partner Center, see Purchasing Windows 7 ESUs as a Cloud Solution Provider
Table of Contents – Installation Prerequisites – Manual Installation and Activation – Automating via Batch Script – Additional References
Installation Prerequisites
There are some updates that you’re going to need to ensure are installed on your system(s) first. The official Microsoft documentation links to older KB’s, but those have been replaced by newer ones. As of this post’s creation dates, here are the latest KB’s that you will need.
One the prerequisites are installed, you can follow these steps to activate Extended Security Updates (ESU) for machines that are connected to the internet.
1) First, locate and Copy the ESU Key to your clipboard.
2a) Open an Elevated Command Prompt window and run the following command. slmgr /ipk <ESU KEY>
After a few moments, you should get a message confirming that the product key was installed.
2b) If you are unable to interact with the desktop GUI, you can leverage the cscript command to write the output to the console. cscript "c:\windows\system32\slmgr.vbs" /ipk <ESU KEY>
3a) Now that the key is on the system, we need to locate its Activation ID so we can activate the key in a future step. Run the following command: slmgr /dlv
3b) While the command above will present the Activation ID to us, it’s not easy to copy. Let’s run the command again, but leverage cscript so we can copy the Activation ID value from the console. cscript "c:\windows\system32\slmgr.vbs" /dlv
4) With the Activation ID copied, let’s move forward with the activation. slmgr /ato <ESU ACTIVATION ID>
5) Once you have activated the ESU product key, you can verify the status at any time by running the following command and referencing the License Status value. slmgr /dlv
Automating the Process via Batch Script
The ESU license is activated — Great! Now how do we automate this process for the rest of our machines? Lets create a quick batch script that we can then push out via a RMM solution and/or GPO logon scripts.
Note: I am not a scripting expert, but I was able to piece the following together. Please reach out or leave comments below if you see necessary improvements.Make sure you pass a value for the %Key% variable, or replace the variable in your script with your actual key.
@echo off cscript "c:\windows\system32\slmgr.vbs" /ipk %Key% for /f "tokens=*" %%a in ('cscript C:\WINDOWS\system32\slmgr.vbs /dlv ^| findstr /b ^"Activation ID: ^"') do set actID=%%a set actID=%actID:Activation ID: =% cscript "c:\windows\system32\slmgr.vbs" /ato %actID% cscript "c:\windows\system32\slmgr.vbs" /dlv
Troubleshooting Tip: While the above script worked for me, the value that gets returned for %actID% may be incorrect for you if you have multiple products installed on your system, such as a previous ESU or OEM license. If you notice that your License Status still shows Unlicensed after running the script, the %actID% is likely populated with another product installed on your system.
EDIT: A user on Reddit sent in a tip that the ActivationIDs should remain the same across all machines for this year’s ESU. I haven’t verified if that’s the case or not, but that should resolve issues related to pulling down the incorrect %actID%. Updated batch script could be as follows in that case:
Check out Microsoft’s official documentation on this topic, including information on how to activate the ESU on machines without internet connectivity.
