SANS ISC: Administrator's Password Bad Practice

• SANS Site Network
  • Current Site
  • SANS Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

Just a quick reminder about some bad practices while handling Windows Administrator credentials. I'm constantly changing my hunting filters on VT. A few days ago, I started to search for files/scripts that use the Microsoft SysInternals tool psexec[1]. For system administrators, this a great tool to execute programs on remote systems but it is also used by attackers to pivot internally. This morning, my filter returned an interesting file with a VT score of 11/66. The file is a compiled AutoIT script. This kind of malicious files is coming back via regular waves[2]. AutoIT executable can be easily decompiled. To achieve this, I'm using Exe2Aut.exe[3]. This tool has not been updated for a while but is still doing a good job.

I decompiled the malicious file which was not malicious at all. It was a script created by a Windows administrator to automate the creation of users' directories. This seems a legit script, however, there were two security issues in this very little script:

The first one was the hardcoded domain admin credentials in the script:

$adusername = "Administrator"
$adpassword = "*C0rnHu******"

The password was a strong one but once the file is published on VT, you can consider the password as lost. Other interesting information are also hardcoded:

$server = "Pithos"
$folderpath = "E:\Users\"
$server = "RMT-SLIA-FILE01" 

Note: the Microsoft domain was also present in the file and a simple Google search helped to guess the company. Could we call this a "virtual compromisation"?

The second issue is nastier. The developer is using PsExec to execute a script on a remote server:

RunWait("C:\pstools\psexec.exe \\" & $server & " -u " & @LogonDomain & "\" & $adusername & " -p " & $adpassword & " C:\createudir.bat")

Used in this way (with '-u' and '-p' options), PsExec sends the credentials in clear text across the network. Hopefully, it has been fixed by Microsoft starting with PsExec version 2.1. An alternative to this to protect the credentials is to open a NULL session to the remote host prior to calling PsExec. This way, NTLM or Kerberos will be used. According to a post written by Mike Pilkington on the Digital Forensics SANS Blog[4], the $IPC NULL session will also prevent the domain administrator's hash to be captured by dumping tools on the remote system!

Some tips to protect your credentials:

• Do not use an outdated version of system tools
• Do not store credentials into scripts/source code (binaries can be decompiled/reversed!)
• Do not publish internal tools on VT (or any other cloud services)
• Use strong authentication mechanism to prevent credentials to cross networks and be stored in memory

Stay safe!

[1] https://docs.microsoft.com/en-us/sysinternals/downloads/psexec
[2] https://isc.sans.edu/forums/diary/AutoIT+based+malware+back+in+the+wild/22778
[3] http://domoticx.com/autoit3-decompiler-exe2aut/
[4] https://digital-forensics.sans.org/blog/2014/11/13/protecting-privileged-domain-accounts-restricted-admin-and-protected-users

Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant
PGP Key