Logging into a domain account without connection to a real domain controller

Windows domain member computers cache some domain users' password hashes so that recent users of the machine can still log in even when the computer can't reach a domain controller to check the password against Active Directory. Of course, if the user was not one of the most recent logins or has never logged into the machine to get their credentials cached, they cannot log in without contacting a domain controller since Windows cannot verify their password or even their existence. It's pretty easy to get into a machine by using the cmd.exe-as-sethc.exe trick and creating a new local user at the login screen, but if you want to avoid offline writes to the disk for some reason, want the new profile to be associated with a domain user once reconnected to the domain, or just want to have a fun adventure (for some definition of "fun"), it's possible to set up a fake domain controller. To avoid bizarre behavior after reconnection to the real domain, you will need to know a domain user's username, NetBIOS domain name, and SID. Conveniently, all of this can be obtained on one line from whoami /user when logged into a domain-joined computer that presumably has a DC connection or cached credentials.

Of course, it would be very bad if just anyone could set up a fake DC and distribute arbitrary policy changes to execute arbitrary code without touching the machine. To prevent this, every domain-joined computer has a "machine account" in Active Directory and keeps the password to it in an LSA secret locally. The computer uses that password to log onto and verify the domain. If machine logon fails, e.g. due to a machine account password mismatch, user logon fails with "the trust relationship between this workstation and the primary domain failed." 

So we'll need to extract the machine password. Boot the target computer from a flash drive (Windows PE or portable Linux, doesn't matter) and copy out SYSTEM and SECURITY from C:\Windows\System32\config. On a computer you already control, start Mimikatz in interactive mode. Elevation is not necessary for the program itself, but it probably will be to tell your antivirus to stop complaining about the tool. Run this command to dump LSA secrets:

lsadump::secrets /system:C:\copied\SYSTEM /security:C:\copied\SECURITY

Note the $MACHINE.ACC secret's NTLM hash. The DC doesn't need the password itself.

We will also need to know the domain's DNS/realm name and the target computer's name. If those are not known, they can be obtained from the exfiltrated SYSTEM hive, which can be opened in the Registry Editor with File | Load Hive when HKEY_LOCAL_MACHINE is selected. The domain DNS name can be found in the ControlSet001\Services\Tcpip\Parameters key; the computer name is in ControlSet001\Control\ComputerName\ComputerName.

With that information, we can set up a Samba Active Directory domain controller. I tested this on a standard Ubuntu 20.04 distribution in a VM based on this wiki page. First install the ifupdown package since we're going to remove the other networking components that might get in the way. (On the first try I only thought to install that after I ripped out the other network tools. Oops.) Disable the systemd-resolved service, then uninstall/purge the network-manager package. Remove the /etc/resolv.conf symlink and replace it with a new file specifying a public nameserver like 8.8.8.8. Rewrite /etc/network/interfaces to specify a static IP. Bring the network interface online with ifup eth0 and make sure the IP is correct with ip addr. Adjust /etc/hosts to resolve both the domain's fully-qualified DNS name (e.g. example.com) and the server's FQDN (e.g. mirage.example.com) to that static IP.

Now you can install the necessary packages for a DC. One of the Kerberos-related packages will prompt for realm information during setup - I think that configuration is going to get rewritten by Samba later, but just to be safe, give it the domain FQDN as the realm and the server's name as the server list. Delete the Samba configuration, Samba state, and Kerberos configuration as directed in "Preparing the Installation".

The domain SID is just the domain user's SID without the last component (the RID). Make sure to specify that when provisioning the domain:

sudo samba-tool domain provision --domain=EXAMPLE --domain-sid=S-1-5-X-Y-Z --realm=EXAMPLE.COM --adminpass=SecurePassword!

Copy Samba's desired Kerberos configuration into place:

sudo cp /var/lib/samba/private/krb5.conf /etc/krb5.conf

During the provisioning, Winbind was set up as the DNS server and set its forwarding server to the public server specified previously in resolv.conf. Now that Winbind handles name resolution, update /etc/resolv.conf to use the local server itself. Unmask, enable, and start the samba-ad-dc service. The domain controller should now be running. Test the three aspects of it.

Now things should move quickly. Create a machine account for the target computer:

sudo pdbedit -a -u TARGET$ -m

Set its NTLM password hash:

sudo pdbedit -r -u TARGET$ --set-nt-hash LONGHASH

Disable machine account password changes so the target doesn't change its password with the fake domain and render itself unable to connect to the real one:

sudo pdbedit -P "refuse machine password change" -C 1

Optionally disable user password complexity requirements:

sudo samba-tool domain passwordsettings set --complexity=off

Then create the user account you want to log in with (you will be prompted for a password):

sudo pdbedit -a -u person

At this point you can add the user to any other groups you want, perhaps Domain Administrators.

Despite pdbedit's documentation, Samba does not support setting account SIDs. We will therefore need to directly-ish edit the Samba state, specifically the LDB file in /var/lib/samba/private/sam.ldb.d/ corresponding to the main naming context for the domain. Install the ldb-tools package, stop the samba-ad-dc service, then invoke ldbedit to bring up a text editor on the user account object:

sudo ldbedit -e nano -H /var/lib/samba/private/sam.ldb.d/DC=EXAMPLE,DC=COM.ldb '(samaccountname=person)'

Find the objectSid line, change the last component (the RID) to match the real user's SID, save, and exit. The changes are immediately applied and you can start the Samba service again.

To make the target computer see the domain, you will need to adjust your DHCP server (probably your LAN's router) to specify the fake DC as the first DNS server. Power the target machine on and you should be able to log in with the credentials you decided for the user account! Once that one login works, the credentials will be cached, so the fake DC is not needed anymore. You can turn off the server and put the DHCP server's DNS settings back how they were.

Launching All the Attacks with Armitage

Kali Linux includes a GUI for Metasploit called Armitage. In addition to being a front-end and convenient GUI, Armitage offers automation of some common processes and some extra displays and features.

For example, Armitage has an option called Hail Mary. Upon activation, it will launch every attack it knows about against every host you've added to your workspace. This is obviously not stealthy at all, but in my opinion it's a great way to check if your systems are vulnerable to anything.

After activation, you'll see each attack as it's sent, and then after 30 seconds you'll see a list of shells successfully opened. If there's even one, some service running on the machine, if not the machine itself, is easily compromised.

How to Write and Compile USB Rubber Ducky Scripts

I just acquired a USB Rubber Ducky, a keystroke injector for all manner of computing devices. It took a bit of research to pick up all the knowledge necessary to get started with it, so I have written a short compilation here.

First, you'll need to remove the MicroSD card from the device, which is surprisingly difficult. Wiggle the card around a little and try to slide it out with your thumb. After the first time, it gets easier. Insert the card into your computer. If you don't have a MicroSD slot, use a MicroSD-to-USB flash-drive-ifier adapter, which may have come with your Rubber Ducky.

You'll find on the card a single file called inject.bin. This is the payload that will be executed when you plug the device into a computer. It's a proprietary binary format, so it's not easily modified directly. Instead, you write a text file in DuckyScript, which is a fairly intuitive scripting language. This text file is then compiled into the inject.bin by DuckEncode, a cross-platform executable JAR file.

I recommend creating a Windows batch file to do the compilation, since JAR files can't be drop targets by default. I made a compile.bat file that is just this line:

java -jar duckencode.jar -i %1 -o inject.bin

Place that in the same directory as the DuckEncode,jar you downloaded earlier. You can then drop any DuckyScript file onto the batch file and it will emit inject.bin from the script, which you can then move onto the device.

DELAY 2000
GUI r
DELAY 200
STRING notepad
ENTER
DELAY 400
STRING Hello!

Collecting the Plaintext Password of an Already Logged-on Windows User

In a previous post, I explained how to set up a scheduled task to nab a logging-on user's password. I said that you could kick them off their session if you wanted to use that technique when they log on again, but getting their password if they're already logged in is probably easier.

To start, you'll need WCE and PsExec. Open an elevated command prompt with permissions on the target computer (typically domain admin). Navigate to the directory containing WCE and PsExec, then type this command:

psexec \\target -s -c -f wce -w

Replace "target" with the name of the remote computer containing the user's session.

The WCE output, including the plaintext passwords of all logged-on users, will be delivered to your console in a second. That was easy!

Collecting the Plaintext Password of a Logging-on Windows User

I made a passing mention to WCE a little while back, and today I found a fun use for it. Suppose you need the password for a domain account. For example, you're a domain administrator who needs to investigate a problem user quickly: breaking the SAM/NTLM hash would take a while; resetting the password would destroy encrypted files and alert the user.

If you have administrative access to a workstation on which the target user will log on, you can use the aforementioned Windows Credentials Editor to steal the plaintext password, at least on Windows 7. (Windows 8 seems to have disabled the Digest Authentication module that leaks the password.) You'll probably need to disable or add an exception to the antivirus software, or alternatively use a PE packer - WCE is regarded in some places as a hacking tool. (Makes sense.)

Using your form of admin power, be it local or domain (use the ADMIN$ or C$ share), drop the WCE executable and a batch file containing the following somewhere on the target computer:

wce -w > pwd.txt

Open MMC and add the Task Scheduler snap-in pointed at the target computer. Add a scheduled task with the following settings:

• General tab
• Click "Change User or Group" and select SYSTEM
• Check "Run with highest privileges"
• Check "Hidden" if you want to be extra sneaky
• Triggers tab
• Add a new trigger
• Pull down "Begin the task" and choose "At log on"
• Choose "Specific user", then "Change User" specifying the target account
• Actions tab
• Add a new action
• Ensure "Start a program" is selected
• "Browse" to select the batch file
• Conditions tab
• Uncheck "Start the task only if the computer is on AC power"
• Settings tab
• Uncheck "Allow task to be run on demand"
• Uncheck "If the running task does not end when requested, force it to stop"

Save the task. When the target user next logs on, their password (and that of any other logged-on user) will be dumped to pwd.txt. If you're impatient, you can kick them off, hoping that they don't suspect anything and that they'll log right back on.

EDIT (11/25): Alternatively, you can use PsExec to grab it from an existing session immediately and silently. See the new post.

How to Stop Windows Group Policy Refreshing

Now that you are able to override the domain Group Policy locally, you might have found that it occasionally gets reset, especially after a reboot. Windows can apparently detect when the policy cache is out of sync with the domain and will attempt to resync it, destroying local customizations.

Fortunately, this can be disabled. We can do so by revoking the system's privilege to modify those registry keys. Fire up RegEdit as admin and go to:

????\Software\Microsoft\Windows\CurrentVersion\Policies

The "????" should be HKEY_LOCAL_MACHINE if the annoying Group Policy entries are Computer Configuration or HKEY_CURRENT_USER if the offending policies are in User Configuration.

Right-click the key in the left pane and choose Permissions. Notice that SYSTEM is allowed Full Control. Uncheck that box in the bottom pane, but make sure SYSTEM has Read access. If you deny read access to the SYSTEM (or remove its DACE), then it won't be able to even check whether you can do things and stuff will blow up.

Then, open up the Owner tab under Advanced and set the owner to the local Administrators group. This ensures that [1] any Group Policy-deployed script can't undo our changes and [2] you'll be able to more easily edit the settings if you choose to change the permissions again.

OK out of all the dialogs and close RegEdit. Congratulations, you are now invincible to Group Policy.

Impersonating Domain Accounts with Incognito (and avoiding 0xC0000142)

This series is getting more and more sketchy. Please don't do anything illegal or unethical with things you learn from me. I am, of course, not responsible if you mess something up or get in trouble as a result of following my instructions.

So, now that you have local admin access and can check out the Active Directory (and override Group Policy if you want to), you might have set your sights on becoming a full-power domain administrator.

To accomplish this, we will use a tool called Incognito to seize control of an in-process access token belonging to a domain admin (or anybody else). Download Incognito v2 from the bottom of the official page. Your antivirus will probably try to stop you from extracting the ZIP; disable it temporarily and then add the resulting directory to its exception list. I recommend placing this directory on your PATH environment variable because we'll be jumping all around the drive while spawning new CMD windows.

Using Incognito is simple: you type incognito list_tokens -u to see all the available tokens, then incognito execute followed by the account you want to take and then a program to run (I recommend cmd).

This works great for seizing access tokens of local users, but since Windows XP it doesn't work for domain accounts. Specifically, Incognito will claim to succeed, but CSRSS will throw 0xC0000142 (init error). This is because only NetworkService can duplicate domain tokens, and NetworkService is itself protected similarly. (Note: not technically correct. This is true enough, and the real explanation is lengthy and unnecessary.)

To get around 0xC0000142, you must be able to act as part of the operating system. Fortunately, since you're local admin, you can do that kind of thing. Run secpol.msc and find "Act as part of the operating system" in User Rights Assignment under Local Policies. Add yourself to this list.

Now, you're ready to take all the access tokens. For a token to be in the system, the target account must be signed in or have used UAC to launch an application that is running. (Convince a domain admin to install something for you?) Let's say the target account is called NAIVE\unsuspecting. I would run incognito execute NAIVE\unsuspecting cmd. This produces a command prompt as the user. There, you can reset the password of a domain admin (preferably one that isn't used anymore) with something like net user oldadmin somepassword /domain. Alternatively, launch MMC, connect to the domain controller, and add yourself (or a less obviously named new account) to the Administrators group.

And there you have it. Very easy to do; the hard part is getting a domain admin token on the system.

Overriding Group Policy on a Windows Domain

This requires already having local administrative access on the machine. To get that, see my very detailed post on that.

So you have local admin access on your Windows domain machine, but Group Policy settings are still getting in your way. Fortunately, since you're now on the nice side of Raymond Chen's airtight hatchway, you own the machine and can do something about this.

The Group Policy cache is located in parts of the registry that anybody can read but only administrators can modify. See these keys:

• HKLM\SOFTWARE\Policies (actually Local Security Policy)
• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies
• HKCU\Software\Microsoft\Windows\CurrentVersion\Policies

Entries under there (you might have to look through some subfolders) are set in the Group Policy or Local Security Policy dialogs. Since you probably don't have access to the domain server, you'll have to make your changes here to override Group Policy.

Simply find entries whose names obviously correspond to annoying restrictions, then set them to something (usually zero) that disables them. You can find explanations of the more cryptic keys in this TechNet article and the articles it links to.

Once you finish making changes, reboot the computer or at least re-login to make sure you're using the newest settings. Oh, and I should mention that it would be a good idea to back up the registry keys before doing something like this.

A Specific and Detailed Guide to Gaining Local Admin Access on a Windows Domain Computer

Note: Please use this guide only for legal/ethical purposes (e.g. system recovery). The "hack" tag is to attract search results away from damaging and dangerous procedures. This guide is easy, safe, and reversible.

So, let's say you're using a computer (probably a laptop) hooked up to a domain on which you do not have administrative rights, but you want to be a local administrator to install programs and whatnot. I have written this guide that walks you specifically through every step of doing so.

I am assuming you have these:

• A different computer on which you have local admin
• A USB flash drive of decent size, formatted FAT32
• Access to a USB port on the computer
• A contract that won't be violated when you do this
• Ability to boot from an alternate device

On a computer on which you are already an admin, go to Pen Drive Linux's web page for the USB installer. Press the big "Download UUI" button near the bottom of the page. Run the resulting application and accept the UAC prompt. Press "I Agree" after not reading the license terms. In the application, do this:

1. Select "Ubuntu" from the Step 1 list.
2. Check the "Download Link" box and press "Yes".
3. Wait for the download to finish.
4. Click Step 2's Browse button and choose the downloaded ISO.
5. Select your USB flash drive from the Step 3 list.
• If it doesn't appear, check "Show all Drives" and press "Yes".
6. Check the box to format the drive if you have a lot of junk on it.
7. Set the Step 4 slider to 0 MB.
8. Press Create.

Once the process finishes, eject the USB drive and use it to boot up the computer on which you wish to gain local admin. (If it doesn't boot into Ubuntu, you need to check BIOS settings. Unfortunately, there are many BIOSes, so I cannot document the process of changing the boot order settings.) Once it loads, choose your language and press the button to just try Ubuntu, not install it.

Disclaimer: I am not good at operating Linux and this may not be the most efficient way of accomplishing the task. It works, though.

Press the Activities text in the upper-left and choose Files (near the bottom of the resulting bar). Choose the hard drive name of the normal Windows installation and navigate to Windows\System32. (Navigation is very similar to that in Windows Explorer.) Find sethc.exe in the list, this is the program that is run when you press Shift five times (the ever-annoying StickyKeys). Rename it, for example to sethc_.exe. Find cmd.exe in the list, right-click it, and choose Copy To. Put it in the containing directory, Windows. Move up to find that copy we just made and rename it to sethc.exe by right-clicking it and choosing Rename. Right-click that and choose Move To, selecting the System32 directory.

You have just replaced the StickyKeys handler with the Command Prompt. This program will be run with administrative privileges at the logon screen.

Shut down Ubuntu using the power icon in the upper-right corner. Remove your flash drive and boot back into Windows. Press the Shift key five times to produce the Command Prompt. There, type the following command to reset the Administrator account's password (use whatever you like for the bold parameter):

net user Administrator wow_suchpassword /ACTIVE:YES

Close the Command Prompt and login using that local account. You will have to know your computer's name, which can be found in the convenient help link "How do I log on to another domain?". If your computer's name was Fleex255, you would use "Fleex255\Administrator" as the username. Enter the password you set in the previous step.

Once you're into that account, you own the machine! To elevate your normal user account, follow these steps:

1. Open Control Panel in Category view.
2. Choose Administrative Tools.
3. Choose Computer Management.
4. On the left in the resulting window, choose Local Users and Groups.
5. Enter the Groups folder.
6. Open the Administrators entry.
7. Click Add in the resulting dialog.
8. Enter your domain username and click OK.
9. Enter your domain username and password in the resulting box.
10. Click OK to close Administrators Properties.
11. Log off of the Administrator account.
12. Log into your normal domain account as usual.

Congratulations! You are now a full-power administrator of your realm, your local computer. Eventually, you should probably change the Administrator password to something better and use your new admin powers to restore that back-up copy of sethc.exe we made. (Or just go into Linux again if you don't want to jump through the hoops of NTFS ACLs.)

Disclaimer: This is not guaranteed to work forever. In fact, it's not even guaranteed to work now. I am not responsible for the consequences if you use this, don't use this, or use it incorrectly.

RSS MP3 Downloader

A lot of RSS feeds always contain an attached MP3 file, like podcasts. It's very difficult, if not impossible, to download them all at once without manually initiated every download. I don't know of any browser that is good at handling RSS that it can do so for multiple different feeds.

I encountered this issue while trying to fetch all podcasts from Reasons to Believe and therefore invented RTBDownload. It's a tiny little application that takes a folder path and an RSS XML file, parsing it for titles and file links. It then downloads all the MP3 files and places them in the folder you specify.

RTBDownload for Windows 7 and above

When it launches, navigate to the folder you want to put them all in, paste the URL of the XML file (with Edit -> Paste), and press Enter. It will inform you when it begins downloading each file. It is possible to run multiple instances of it downloading different feeds.

Install IIS on Windows XP without CD

IIS 6.0 is a very solid HTTP server (among a bunch of other Web-related services) that can be run on any Windows XP Pro computer. It's installation is usually pretty simple: Turn it on, put in your Windows install disc, and watch it install. However, you can't do the normal installation without your CD. After a little searching on the web, I have discovered a way by which IIS can be (legally) installed without having to track down that disc.

First, you'll need to download a disc image that contains the necessary files, for example this one for 32-bit SP2 (will work for installing IIS on SP3). Open a command prompt, navigate to the folder containing it and run it with the /extract switch with the destination folder path as an argument. An i386 folder will be created there, which will contain the files necessary to install IIS. Point the snap-in installer to that place and you'll be going!

Forcing Disabled Web Controls with Chrome

So you've been poking around some website and you've noticed some web control that supposedly can change a property of your browsing experience, but is disabled.  There's a relatively simple way to force the state of pretty much any standard web forms control, disabled or hidden.

First, get to the page that displays the control you want to force in Google Chrome.  Press the F12 key to open the developer's client-side page editor.  This will display a tree of the HTML elements Chrome is aware of.  Mousing over one of these elements will highlight the area of the page contained in the technical element; expand all the things until only the control is highlighted.

Scroll to the right to find something like "hidden" or "disabled".  Double-click that text area to enter editing mode and delete the restricting keywords.  After you press Enter, Chrome will do another set of render passes, reflecting the changes you just made.  Set the state of your control how you normally would and press the appropriate submit button.  It's not guaranteed that the server is programmed to respect any state on that control, but there's a decent chance they weren't expecting this.