Thanks again for the reply. I hit the 'Googles' and was able to find an interesting article giving an example of uploading your own "cmd.exe" to overcome the issue I was having.  Rewrote the ASP script to point to my cmd.exe and was able to get "network service" level privileges.

Thank you for the reply. I am able to upload via writing a small perl script. The application fails to validate the location of the configuration file, and an attacker can specify an extra "\" and the server will read the config file via smb or webdav. The configuration file specifies the location of the logfile. For example:


Once uploaded though I cannot take advantage of exec() or system() with perl, (you can run logfile script multiple times) as the IIS account appears to not have the proper permissions to execute cmd.exe. When I tested in a lab environment, and changed permissions of cmd.exe to 'everyone', I was able to get a shell. This also appears to be the same problem with the metasploit payloads as well (cmd.exe).

I guess what I am asking is what do you do when pentesting an app running on IIS since it uses the guest account? Maybe I need some other creativity (look for other files containing passwords, etc). Any ideas? Just looking for other opinions or ideas.

Thanks!

Hello all,

Fairly new pentester here, having issues executing a metasploit payload uploaded by the IIS guest account. All payloads seem to fail, or do not have adequate permissions to execute.

Background on target:
IIS 6 running on Win2kSP2 with ASP. The IIS guest account has read/write/execute. I can upload a file through a vulnerability I discovered, however I cannot execute. If for example I upload and ASP shell, I receive an error saying access denied on line etc (which is at the end of the payload). I have verified ASP scripts can run by uploading something simple like document.write("hello"). Maybe I can use a different payload?

Any ideas here or suggested reading you can point me to?