To deliver the payload, we chose to use a 2-stage payload, with the first stage being a powershell script. Kali will be our attacking machine since it offers a wide range of tools, and we will be using the meterpreter framework to control the victim machine. More antivirus tests can be found at the following sections. dll file, and run the payload in memory will be able to open a reverse shell undetected. We believe that using similar evasion method to generate a. Nevertheless, being able to be downloaded undetected by most antivirus solutions has proved that the evasion method works. Unfortunately, since windows recently added meterpreter signatures (the toolset that we're using to gain control of the victim machine), once the shellcode is reassembled, windows defender can still detect the signature, so the success rate of the payload is not very high, although we did manage to gain control a few times. After obfuscation is done, build the source code into a. Each part are individually assembled and the 4 parts are pieced together at the end. In the final payload, the source code can be found under final/payload_source.cpp, the shellcode is broken into 4 parts, each with their own scrambled bytes, and with many extra bytes and strings thrown in between. Windows defender has gotten very good at recognising signature of the payloads, so more memcpy functions will have to be used to evade detection. Windows defender will be our primary antivirus solution to evade, since it's the most common antivirus on a windows computer. The random bytes can be generated using, filled and counted using Cyberchef. Using the function, we can replace the geninue bytes with dummy bytes, and store the genuine bytes in another string, when the executable runs, the genuine shellcode will then be assembled. We chose to use reverse https encoded using the shikata_ga_nai encoder and output in C, this will make the shellcode harder to detect. The signature of the payload must not be in any antivirus databases, so a completely new custom payload will have to be created.įirst, we can use msfvenom to generate a shellcode, this will be the basis where the custom payload will be built on. Most antiviruses scan for known signatures to detect viruses/malwares, in order to successfully deliver the payload to the victim machine, which means most of the commonly used payloads and obfuscation method will not work. When a USB device is first initialised, a notification will show up in windows with the name of the device, to change the name of Digispark to better hide the device, navigate to the Arduino config file libraries\DigisparkKeyboard\usbconfig.h, the name can be changed accordingly. To program Digispark after flashing to the new bootloader, bridge the GND and P0 pins on Digispark with a conductive wire when uploading new code. To flash the firmware, unzip the micronucleus folder, in a command prompt, enter the full path of micronucleus.exe, followed by the full path of the bootloader hex file, then plug in Digispark to the computer.Īfter the bootloader is flashed, the delay should be removed. The bootloader can be found here under the name, the program to flash the bootloader can be found here. This has caused issues for Windows to fail to recognise Digispark as a USB device when it is connected to the hub with another keyboard, a new bootloader is needed to remove the delay, removing the delay also allows the attack to be carried out faster. Digispark bootloaderīy default, the Digispark have a 5 second programming delay once plugged in for uploading new code. The sorce code of the Digispark keystrokes will be explained at a later section. ![]() After the desired code is written into the IDE, press the upload button in the IDE and connect Digispark into the computer. ![]() We can use either the Arduino IDE or the PIO extenstion in Visual Studio Code. To program Digispark to deliver the keystrokes we wanted, we will need an IDE to write to Digispark. The completed keyboard looks identical to when it was unmodified: The internal connections and layout of the completed keyboard are as follows: The upstream port of the USB hub is what will be connected to the computer. The internal keyboard PCB is connected to the USB hub, and digispark is also connected to up. ![]() We want to use Digispark to deliver the payload while still keeping the keyboard functional, so a USB hub is needed. Parts usedĭigiSpark with Arduino ATtiny85 microprocessor The following is detailed documentation on the steps
0 Comments
Leave a Reply. |