[Suggestion][Payload] Ducky payload persistence windows

[sober]

not going to cobble together other bypasses/disables/ payloads, i was interested in a reverse shell surviving a restart

use case: pen testing an establishment, infected machine is restarted or shut down before you have a chance to utilize shell

antivirus does not seem to care about this method of adding to startup.

http://technet.microsoft.com/en-us/library/cc772785(v=ws.10).aspx#BKMK_startup

To schedule a task that runs when a user logs on
Syntax

schtasks /create /tn TaskName /tr TaskRun /sc onlogon [/sd StartDate] [/it] [/ru {[Domain\]User [/rp Password] | System}] [/s Computer [/u [Domain\]User [/p Password]]]

schtasks /create /tn "Crouching Goose hidden ducky" /tr c:\windows\system32\webstart.bat /sc onlogon

other potential "fun" uses

To schedule a task that runs when the system is idle

To schedule a task that runs with system permissions

To schedule a task that runs every N minutes

To schedule a task that runs every N hours

To schedule a task that runs every N days

Edited February 24, 2013 by sober

[no42]

Looks like a good idea.

But isn't c:\windows\system32 protected, you need admin permissions to write there, and the user my not have these rights?

[ApacheTech Consultancy]

Is this much different than using "at"? Thank you by the way, this is pretty much perfect for my "FireFox Extinguisher" payload, if it works the way I think it does.

[sober]

Looks like a good idea.

But isn't c:\windows\system32 protected, you need admin permissions to write there, and the user my not have these rights?

im sorry for confusion, this payload will work from any path, that is just an example i provided, here is an example provided by Microsoft from a different path

schtasks /create /tn "My App" /tr c:\apps\myapp.exe /sc once

Is this much different than using "at"? Thank you by the way, this is pretty much perfect for my "FireFox Extinguisher" payload, if it works the way I think it does.

a page comparing both http://technet.microsoft.com/en-us/library/cc738335

i feel personally schtasks is an easier to use, fuller solution, plus to run an executable at first has to run cmd, which means a user may have cmd prompt flashing at startup they had not had before.

Edited February 24, 2013 by sober

[sober]

Looks like a good idea.

But isn't c:\windows\system32 protected, you need admin permissions to write there, and the user my not have these rights?

originally potentially misunderstood, the exe is in sys32 and as such can not be ran by a non admin/ user who needs admin password to run exes as admin without some sort of escalation of privs

Edited February 27, 2013 by sober

[overwraith]

I think for escalation of privileges we would need some form of exploit that would take control of an application running under admin privileges right?

[ApacheTech Consultancy]

What about just getting round any UAC with the duck?

LEFT ARROW

DELAY 500

ENTER

The UAC's inherent trust that there is someone at the computer typing is one of the flaws that the duck was designed to bypass.

[sober]

I think for escalation of privileges we would need some form of exploit that would take control of an application running under admin privileges right?

typically yes, as it sits this will work on standard home users pcs, but not accounts with restricted access.

[sober]

What about just getting round any UAC with the duck?

LEFT ARROW

DELAY 500

ENTER

The UAC's inherent trust that there is someone at the computer typing is one of the flaws that the duck was designed to bypass.

problem here is that if you must type an admin password in to run admin cmd prompt, this wont work as a standard user cant access schtasks without running as admin.

[ApacheTech Consultancy]

Ahh, you mean on a domain network. If it's a standalone computer, you don't have that problem.

Can you though, copy the program, with any dependencies needed to a suitable location and use it from there, setting the environment path if needed.

I know you can do that with a few escalated privilege programs. It just depends if it's the program itself, or the directory it runs in by default that is secured by the UAC. Or, test if you can run cmd as Admin and run it from the command line. Depending on group policies, this may be an option.

Either way, the first move would be a bit of SE to find out what rights the user actually has and how far you can push the boundaries without breaking the inherent trust... then use the duck for those parts. Obviously, any admin password protected areas couldn't be used, but if you can piggy back the command into a batch file that automatically gets run as admin...

Or, use the utilmon (WindowsGate, etc) backdoor to run stuff as SYSTEM.