Nytro Posted March 9, 2013 Report Posted March 9, 2013 [h=1]PSExec Demystified [/h]Posted by thelightcosine in Metasploit on Mar 9, 2013 10:28:33 AM Multiple modules inside the Metasploit Framework bear the title PSExec, which may be confusing to some users.When someone simply refers to “the PSExec module”, they typically mean exploit/windows/smb/psexec, the original PSExec module. Other modules are more recent additions, and make use of the PSExec technique in other ways. Here’s a quick overview of what these modules are for:[TABLE=width: 437][TR][TD]Metasploit Module[/TD][TD=width: 118]Purpose [/TD][TD=width: 149]Comment [/TD][/TR][TR][TD=width: 171]exploit/windows/smb/psexec[/TD][TD=width: 118]Evading anti-virus detection [/TD][TD=width: 149]Service EXE is now getting caught by most AV vendors. Use custom templates or MOF upload method to circumvent AV detection.[/TD][/TR][TR][TD=width: 171]exploit/windows/local/current_user_psexec[/TD][TD=width: 118]Local exploit for local administrator machine with goal to obtain session on domain controller[/TD][TD=width: 149]Great starting point to take over an entire network. Attack is less likely to get noticed because it uses legitimate access methods. [/TD][/TR][TR][TD=width: 171]auxiliary/admin/smb/psexec_command[/TD][TD=width: 118]Run arbitrary commands on the target without uploading payloads. [/TD][TD=width: 149]Unlikely to be detected by AV but limited because you can only send one command, not obtain a session. [/TD][/TR][TR][TD=width: 171]auxiliary/scanner/smb/psexec_loggedin_users[/TD][TD=width: 118]Get list of currently logged in users [/TD][TD=width: 149]Run this module against all targets to get tons of information on your targets. [/TD][/TR][/TABLE]We’ll now look at each one in detail below. First, let’s talk about what PSExec is, and where the idea comes from.[h=2]The PSExec Utility[/h] The name PSExec comes from a program by the same name. Mark Russinovich wrote this utility as part of his sysInternals suite in the late 90s to help Windows Administrators perform important tasks, for example to execute commands or run executables on remote systems.The PSExec utility requires a few things on the remote system: the Server Message Block (SMB) service must be available and reachable (e.g. not blocked by firewall); File and Print Sharing must be enabled; and Simple File Sharing must be disabled.The Admin$ share must be available and accessible. It is a hidden SMB share that maps to the Windows directory is intended for software deployments. The credentials supplied to the PSExec utility must have permissions to access the Admin$ share.PSExec has a Windows Service image inside of its executable. It takes this service and deploys it to the Admin$ share on the remote machine. It then uses the DCE/RPC interface over SMB to access the Windows Service Control Manager API. It turns on the PSExec service on the remote machine. The PSExec service then creates a named pipe that can be used to send commands to the system.[h=2]The PSExec Exploit (exploit/windows/smb/psexec)[/h] The PSExec exploit modules in Metasploit runs on the same basic principle as the PSExec utility. It can behave in several ways, many of them unknown to most users.[h=3]The Service EXE[/h] In this method, the exploit generates and embeds a payload into an executable, which is a Service image uploaded by the PSExec utility – similar to the PSExec service. The exploit then uploads the service executable to the Admin$ share using the supplied credentials, connects to the DCE/RPC interface, and calls into the Service Control Manager before telling SCM to start the service that we deployed to Admin$ earlier. When the service is started, it starts a new rundll32.exe process, allocates executable memory inside that process and copies the shellcode into it. It then calls the starting address of that memory location as if it were a function pointer, executing the stored shellcode.The service EXE is generated using an executable template with a placeholder where the shellcode is inserted. The default executable templates in Metasploit Framework are flagged by major AV solutions because most anti-virus vendors have signatures for detecting these templates. No matter what payload you stick in this executable template, it will get flagged by AV.[h=4]AV Evasion[/h]The PSExec exploit has several advanced options. The first is the options to supply alternative executable templates.There are two separate options: One is to use set EXE::Path, which will tell Metasploit to look in a different directory for the executable templates. The other is set EXE::Template, which is the name of the executable template file to use. If you create an executable template and store it in a different directory, you will need to set both of these options. Writing a custom executable template is a good way to avoid AV detection. If you write your own EXE template for the PSExec exploit, it must be a Windows service image. In addition to writing a custom executable template, you can write an entire executable on your own. This means that a Metasploit payload will not actually get inserted. You will code the entire behavior into the EXE itself. The psexec exploit module will then upload the EXE and try to start it via SCM.Tip: If you would like to save time evading anti-virus, you can use the dynamic executable option in Metasploit Pro, which generates random executable files each time that are much less likely to be detected by anti-virus. (Watch my webcast Evading Anti-virus Detection with Metasploit for more info.)[h=3]The Management Object File (MOF) upload method[/h]MOF files are a part of the Windows Management Instrumentation (WMI). They are Manage Object Files. They contain WMI information and instructions. MOF files must be compiled to work properly, however there is a way around that on Windows XP. In Windows XP, if you drop an uncompiled MOF file in the system32\wbem\mof\ directory, Windows XP will compile the MOF for you and run it. The PSExec exploit has a method for using this to our advantage. If you set MOF_UPLOAD_METHOD true, it will do a few things differently. Our payload EXE will be generated as a normal instead of a service EXE. It will then upload it via Admin$ as expected before generating a MOF file that will execute the EXE we uploaded. It will use Admin$ to deploy the MOF file to the MOF directory. Windows XP will then compile and run the MOF, causing our payload EXE to be executed.The MOF method can be combined with the custom EXE or custom template methods described above to try and evade AV as well. The MOF Method currently only works on Windows XP as later versions require the MOF to already be compiled in order for them to run.[h=2]The PSExec Current User Local Exploit(exploit/windows/local/current_user_psexec)[/h] The Current User PSExec module is a local exploit. This means it is an exploit run on an already established session. Let’s set up a scenario to explain how this works. In our scenario you do the following:Set up a browser exploit at some addressTrick a local system administrator to visiting the siteGet a reverse Meterpreter shell, inside the administrator’s browser processRun netstat to see if the administrator is connected to one of the Domain controllersSo now Meterpreter is running on a system administrator’s box under her user context. While there may not be something you’re interested in on her workstation, she has permission to access a domain controller (DC), which you would like to shell. You don’t have her credentials, and you cannot talk directly to the DC from your box.This is where the current_user_psexec module comes in. This local exploit works the same way as the psexec exploit. However, it runs from the victim machine. You also do not supply any credentials. This exploit takes the authentication token from the user context, and passes that alone. This means you can get a shell on any box the user can connect to from that machine and has permissions on, without actually knowing what their credentials are.This is an invaluable technique to have in your toolbox. From that first machine you can compromise numerous other machines. You can do this without having set up any proxy or VPN pivots, and you will have done it using legitimate means of access.[h=2]The PSExec Command Execution Module (auxiliary/admin/smb/psexec_command)[/h] Submitted by community contributor Royce @R3dy__ Davis, this module expands upon the usefulness of the PSExec behavior. It utilizes the same basic technique but does not upload any binaries. Instead it issues a single Windows command to the system. This command is then run by the remote system. This allows arbitrary commands to be executed on the remote system without sending any payloads that could be detected by AV. While it does not get you a shell, it will allow you to perform specific one off actions on the system that you may need.[h=2]The PSExec Logged In Users Module (auxiliary/scanner/smb/psexec_loggedin_users)[/h] Also brought to you by Royce @R3dy__ Davis, this module is a specialized version of the command execution one. It uses the same technique to specifically query the registry on the remote machine and get a list of all currently logged on users. It is a scanner module which means it can also run against numerous hosts simultaneously, quickly getting the information from all the targeted hosts.[h=2]Summary[/h] What we’ve seen here is that the PSExec technique is actually a relatively simple mechanism with immense benefit. We should all remember to thank Mark Russinovich for this wonderful gift he has given us. As time goes by, people will find many more uses for this same technique, and there is room for improvement on how these modules work and interact. The PSExec exploits are two of the most useful, and most reliable, techniques for getting shells in the entire Metasploit Framework.Sursa: https://community.rapid7.com/community/metasploit/blog/2013/03/09/psexec-demystified Quote
