قالب وردپرس درنا توس
Home / Tips and Tricks / How to Capture USB Rubber Spirits on Your Computer with USBRip «Zero Byte :: WonderHowTo

How to Capture USB Rubber Spirits on Your Computer with USBRip «Zero Byte :: WonderHowTo



If left unattended, a hacker with USB Rubber Ducky and physical access to the computer can infiltrate even the most secure computer. Such attacks are often detected without the use of a tool like USBRip, which can give you assurance that your device has not been compromised.

It can be difficult to know if your device has been reached previously, which allows logging to make it easier to determine when a suspicious device has been inserted into a port. USBRip can't look through old system logs to capture past events, but it can keep an eye on everything that happens after installing it, to protect against being hacked in the future.

What are HID attacks?

A human interface device, or HID, is a device used by a person to control a computer; Keyboards and computer mice are prime examples. HIDs have elevated privileges over a program or script because the operating system assumes that commands from a HID come from a person authorized to use the computer.

Hackers have created tools, such as USB Rubber Ducky, that exploit the inherent trust between a computer and a HID. While a USB Rubber Ducky mimics the appearance of a standard flash drive, when connected to a computer, it functions as a keyboard that can input pre-recorded keystrokes and commands in lightning strikes.

The types of attacks that hackers have carried out using a USB Rubber Ducky, Digispark and similar tools are extensive; they range from planting a backdoor on macOS and Windows computers to sending an email with a screenshot of all the user credentials stored in Firefox.

Discovering Ducky

Because the computer believes that USB Rubber Ducky is just another keyboard, it will execute the commands immediately without giving the target any visible warning that they were compromised. As long as Ducky Script is careful to clean itself up – by closing all the windows it opened, erasing the terminal history and making the computer appear to be in the same state as the target left it in – an attack can be fully detected

That means not that it is impossible to prevent or detect such attacks. There are some tools out there, like DuckHunter, that aim to limit the effects of HID attacks by looking at suspicious behaviors like keystrokes that write too fast. While the DuckHunter project has not been updated since 2017, there is another tool that can provide evidence of a HID attack, which is both powerful and currently maintained.

USBRip utilizes system logs to display a complete history of each USB device connected to a Linux computer. Although an attacker may remove these logs as part of the cleanup process, they are much less likely to do so during more critical and time-consuming cleanup steps, such as removing all direct evidence of access to the computer. Even better, since USB Rubber Ducky and Digispark were both manufactured by specific manufacturers, USBRip can search the logs for devices with suspected fingerprints.

What You Will Need

USBRip is written in Python, which is cross-platform and should allow USBRip to run on most Linux systems. Because it mostly analyzes Linux system logs, it currently runs only on Linux devices. For this guide we use Kali Linux, but for steps in another system, check out our video for another example.

Make sure your system is fully updated and upgraded with apt update and apt upgrade commands and make sure Python is installed by typing python into a terminal window. If you get an interactive Python shell, you have everything you need and can type quit () to quit. Otherwise, you can install Python by running apt install python .

  ~ # python

Python 2.7.16 (default April 6, 2019, 1:42:57 PM)
[GCC 8.3.0] on linux2
Enter "help", "copyright", "credits" or "license" for more information.

>>> quit () 

I would also recommend installing Python3:

  ~ # apt install python3-venv p7zip-full -y

Reading Package Lists ... Ready
Building dependent trees
Reading information about the state ... Ready
p7zip-full is already the latest version (16.02 + dfsg-7).
python3-venv is already the latest version (3.7.5-3).
The following packages were installed automatically and are no longer required:
dh-python libdouble-Conversion1 liblinear3
Use "apt autoremove" to remove them.
0 upgraded, 0 newly installed, 0 to remove and 1853 not upgraded. 

Step 1: Configure Some Linux Files

For USBRip to analyze system logs, we need to configure some files in the root directory. First we need to delete a row from the /rsyslog.conf file. If you want to uninstall USBRip and restore your computer to its original state, it will be easier just to comment it.

Use a terminal window and open the rsyslog.conf file with your favorite text editor. It will be in your / etc directory, and you can jump to edit the file. In our case we use nano, so we go to nano /etc/rsyslog.confebrit19459023]and the file opens. If you are not root, use sudo with it and many of the other commands in the guide below.

  ~ # cd
~ # nano /etc/rsyslog.confebrit19659016??When it opens, scroll down and comment on the line that says: 

  $ ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat 

Then place a # in front of it. That section should look like this now:

  #### GLOBAL DIRECTIVES ####
###########################

#
# Use traditional timestamp format.
# To enable high-precision timestamps, comment on the following line.
#
# $ ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

#
# Set default permissions for all log files.
#
$ FileOwner root
$ FileGroup adm
$ FileCreateMode 0640 

Save and exit the file now and be careful not to change the file name. After changing the old way our computer stores system logs, we have to replace it with the method that USBRip can use. In the same terminal window, enter the command below.

  ~ # echo & # 39; $ ActionFileDefaultTemplate RSYSLOG__FileFormat & # 39; | tee /etc/rsyslog.d/usbrip.conf

$ ActionFileDefaultTemplate RSYSLOG__FileFormat 

It creates a new .conf file that USBRip will use with a different format to store system logs. Then we have to clean our computer from its current system logs, which are in the wrong format. We can do this with the following command.

  ~ # rm -f / var / log / syslog * / var / log / messages * 

Finally, we need to restart rsyslog with the command below. When that is done, we can proceed to the installation of the program.

  ~ # systemctl restart rsyslog 

Step 2: Install USBRip

Now that the system files have been configured properly, we can install USBRip. Begin by navigating to a directory of your choice in a terminal window and cloning the guitar repository with the following command.

  ~ # git clone https://github.com/snovvcrash/usbrip.git

Cloning to "usbrip" ...
remote control: List items: 130, done.
remote control: Count items: 100% (130/130), done.
remote control: Compression of objects: 100% (89/89), done.
remote control: Total 1266 (delta 70), recycled 77 (delta 39), recycled 1136
Receiving Objects: 100% (1266/1266), 1.14 MiB | 4.83 MiB / s, clear.
Loose delta: 100% (790/790), done. 

After that, navigate to the cloned directory and start installing the necessary Python libraries and dependencies. To do so with beep and use the installer program.py, check out our video guide.

  ~ # cd usbrip
~ / usbrip # chmod + x ./installers/install.sh
~ / usbrip # sudo -H ./installers/install.sh -s

>>>> Create directory: & # 39; / opt / usbrip & # 39;
>>>> / opt / usbrip already exists. First round:
sudo uninstall.sh - all 

Then close the folder / usbrip and start up the help page to check what is there.

  ~ / usbrip # cd
~ # usbrip -h

sage: usbrip [-h] {banner, events, storage, ids} ...

positional arguments:
{Paths, Events, Storage, IDs}
banner show tool banner
events work with USB events
storage work with USB event storage
ID works with USB ID

optional arguments:
-h, --help show this help message and finish 

Now we can check that USBRip has been installed correctly by typing usbrip in the terminal and make sure we get the following mudguard. [19659015] ~ # usbrip

_ {{4}} {v2.2.1-1}
_ _ ___ | | _ ___ [E] ___
| | | _ - | . | _ [n]. |
| ___ | ___ | ___ | _ | [5] _ |
x [!] _ | https://github.com/snovvcrash/usbrip

Usage: / usr / local / bin / usbrip [-h]

If you see it, we have the first step to install USBRip ready.

Step 3: Search the entire USB event history

Now that the USBRip has been installed, let's see the history of all USB events that happened on our computer. We can do this with the following command.

  ~ # usbrip events history

_ {{4}} {v2.2.1-1}
_ _ ___ | | _ ___ [e] ___
| | | _ - | . | _ [n]. |
| ___ | ___ | ___ | _ | [5] _ |
x [I] _ | https://github.com/snovvcrash/usbrip

[*] Started 2020-02-14 17:11:37
[17:11:37] [INFO]   Trying to run journal ...
[17:11:37] [INFO]   Successfully run journalctl
[17:11:37] [INFO]   Reading of journalctl output
100% | █████████████████████████████████ | 2089/2089 [00:00<00:00, 251208.49line/s]
[?] How would you like your event history list to be generated?

    1. Terminal stdout
    2. JSON-file

[>] Enter the number you choose (default 1): 

It now allows you to either print the USB history in the terminal or save it as a JSON file. For now, let's just see it in the terminal by entering 1 .

  [>] Enter the number you selected (default 1): 1

[17:13:34] [INFO]   Prepare collected events
------------------------------------------------
Connected: 2020-02-14 15:42:48
User: kubuntu
VID: 046d
PID: c52b
Product: USB receiver
Manufacturer: Logitech
Serial number: ∅
Bus Sports: 1-1
Disconnected from: ∅
------------------------------------------------
[*] Close of 2020-02-14 17:13:34
[*] It took time: 0: 01: 57.087803 

As you can see above, the list of USB events is limited to the Logitech Bluetooth mouse receiver that I connected to my laptop.

Unfortunately, because we had to remove all incorrectly formatted system logs, we can only see USB event history since we installed USBRip. Despite this limitation, we were still able to learn some interesting information about the USB device, such as the timestamp when it was connected and disconnected (or if it was ever disconnected).

We can also see VID and PID, which are numbers used by computers to identify a USB device to know which drivers need to be installed. VID is assigned by usb.org, and PID determines the manufacturer. We also learn what the device is, the manufacturer's name, and what USB port the device is connected to.

After a few days, the number of USB events on your computer will start to increase and we will want to condense the list into a more readable format. We can limit the request to the last 20 USB events and format it as a condensed table instead of a list.

  ~ # usbrip events history -n 20 - table

_ {{4}} {v2.2.1-1}
_ _ ___ | | _ ___ [E] ___
| | | _ - | . | _ [N]. |
| ___ | ___ | ___ | _ | [5] _ |
x [1] _ | https://github.com/snovvcrash/usbrip

[*] Started 2020-02-14 22:18:00
[22:18:00] [INFO]   Trying to run journal ...
[22:18:00] [INFO]   Successfully run journalctl
[22:18:00] [INFO]   Reading the journalctl output
100% | █████████████████████████████████ | 2095/2095 [00:00<00:00, 364532.95line/s]
[22:18:00] [INFO] Filtering events
[?] How would you like your event history list to be generated?

    1. Terminal stdout
    2. JSON-file

[>] Enter the number you selected (default 1): 1

[22:18:02] [INFO]   Prepare collected events
[22:18:02] [INFO]   Representation: table 

It should show something like:

  ┌USB-History-Events───┬─────────┬──────┬──── ─ ─┬──────────────────────────────────┬──────────── ─ ────────────────────┬──────────────────────────┬─ ─ ────┬─────────────────────┐
│ Connected │ Users │ KNOW │ PID │ Product │ Manufacturer │ Serial Number │ Port │ Connected │
├─────────────────────┼─────────┼──────┼──────┼─── ───────────────────────────────┼────────────────── ───────────────┼──────────────────────────┼──────┼ ─────────────────────┤
│ 2020-02-14 • • - - - - - - - - - - - - - - - - -
│ 2020-02-14 17:30:04 │ kubuntu │ 1d6b │ 0002 │ xHCI Host Controller │ Linux 5.0.0-25 generic xhci-hcd │ 0000: 00: 14.0 │ usb1 │ ∅ │
│ 2020-02-14 18:05:23 │ kubuntu │ 0930 │ 6544 │ DataTraveler 2.0 │ Kingston │ 00241D8CE51BC16029500C03 │ 1-2 │ 2020-02-14 18:07:23 │
│ 2020-02-14 18:22:56 │ kubuntu │ 1c7a │ 0570 │ EgisTec Touch Fingerprint Sensor │ EgisTec │ 000253CD │ 1-6 │ 2020-02-14 18:24:45 │
│ 2020-02-14 18:32:16 │ kubuntu │ 1c7a │ 0570 │ EgisTec Touch Fingerprint Sensor │ EgisTec │ 000253CD │ 1-6 │ ∅ │
│ 2020-02-14 19:59:54 │ kubuntu │ 1d6b │ 0003 │ xHCI Host Controller │ Linux 5.0.0-25 generic xhci-hcd │ 0000: 00: 14.0 │ usb2 │ ∅ │
│ 2020-02-14 19:59:54 │ kubuntu ca 04ca │ 3016 │ ∅ │ ∅ │ │ 1-5 │ ∅ │
│ 2020-02-14 19:59:54 │ kubuntu │ 1c7a │ 0570 │ EgisTec Touch Fingerprint Sensor │ EgisTec │ 000253CD │ 1-6 │ ∅ │
│ 2020-02-14 19:59:54 │ kubuntu │ 0bda │ 57f2 │ HD WebCam │ KS0HD050046430866CLM06 │ 200901010001 │ 1-7 │ ∅ │
│ 2020-02-14 19:59:54 │ kubuntu │ 046d │ c52b │ USB receiver │ Logitech │ ∅ │ 1-1 │ ∅ │
│ 2020-02-14 19:59:54 │ kubuntu │ 1d6b │ 0002 │ xHCI Host Controller │ Linux 5.0.0-25 generic xhci-hcd │ 0000: 00: 14.0 │ usb1 │ ∅ │
│ 2020-02-14 19:59:54 │ kubuntu │ 0bda │ 0129 │ USB2.0-CRW │ Generic │ 20100201396000000 │ 1-8 │ ∅ │
│ 2020-02-14 20:46:17 │ kubuntu │ 1d6b │ 0003 │ xHCI Host Controller │ Linux 5.0.0-25 generic xhci-hcd │ 0000: 00: 14.0 │ usb2 │ ∅ │
│ 2020-02-14 20:46:17 │ kubuntu 04ca │ 3016 │ ∅ │ ∅ │ │ 1-5 │ ∅ │
│ 2020-02-14 20:46:17 │ kubuntu │ 1d6b │ 0002 │ xHCI Host Controller │ Linux 5.0.0-25 generic xhci-hcd │ 0000: 00: 14.0 │ usb1 │ ∅ │
│ 2020-02-14 20:46:17 │ kubuntu │ 046d │ c52b │ USB receiver │ Logitech │ ∅ │ 1-1 │ 2020-02-14 20:47:22 │
│ 2020-02-14 20:46:17 │ kubuntu │ 1c7a │ 0570 │ EgisTec Touch Fingerprint Sensor │ EgisTec │ 000253CD │ 1-6 │ 2020-02-14 20:48:17 │
│ 2020-02-14 20:46:17 │ kubuntu │ 0bda │ 0129 │ USB2.0-CRW │ Generic │ 20100201396000000 │ 1-8 │ ∅ │
│ 2020-02-14 20:46:17 │ kubuntu │ 0bda │ 57f2 │ HD WebCam │ KS0HD050046430866CLM06 │ 200901010001 │ 1-7 │ ∅ │
│ 2020-02-14 21:00:06 │ kubuntu │ 046d │ c52b │ USB receiver │ Logitech │ ∅ │ 1-1 │ 2020-02-14 21:04:08 │
│ 2020-02-14 21:20:15 │ kubuntu │ 046d │ c52b │ USB receiver │ Logitech │ ∅ │ 1-2 │ 2020-02-14 21:40:45 │
└─────────────────────┴─────────┴──────┴──────┴─── ───────────────────────────────┴────────────────── ───────────────┴──────────────────────────┴──────┴ ─────────────────────┘
[*] Close by 2020-02-14 22:18:08
[*] It took time: 0: 00: 42.650509 

Step 4: Create a JSON file to filter trusted devices

Because most USB events are with devices you trust – your mouse, keyboard, flash drives and internal devices such as webcams or fingerprint scanners – event history can get messy with USB events of no interest. When you try to detect malicious activity on your computer, it creates mess and makes it harder to see a real threat.

One way to solve this problem is to create a whitelist of devices we trust so that we can suppress reports of reliable USB devices that we would otherwise have to ignore.

We can easily create a JSON file with reliable devices with USBRip. We can create a .json file called "auth.json" containing all USB devices connected to the computer on February 14, 2020 using the following command.

  ~ # usbrip events event__uthuth.json -d & # 39; 2020 -02-14 & # 39;

use: usbrip events [-h] {history, open, genauth, violations} ... 

If we open the "auth.json" file in our USBRip directory, we see the following.

  {
"manufacturer": [
        "EgisTec",
        "Generic",
        "KS0HD050046430866CLM06",
        "Linux 5.0.0-25-generic xhci-hcd",
        "Logitech"
    ],
"pid": [
        "0002",
        "0003",
        "0129",
        "0570",
        "3016",
        "57f2",
        "c52b"
    ],
"prod": [
        "EgisTec Touch Fingerprint Sensor",
        "HD WebCam",
        "USB Receiver",
        "USB2.0-CRW",
        "xHCI Host Controller"
    ],
"series": [
        "0000:00:14.0",
        "000253CD",
        "200901010001",
        "20100201396000000"
    ],
"vid": [
        "046d",
        "04ca",
        "0bda",
        "1c7a",
        "1d6b"
    ]
} 

We can now restrict a USBRip search to all USB events not found in authent.json using:

  ~ # usbrip events crime

_ {{4}} {v2.2.1-1}
_ _ ___ | | _ ___ [e] ___
| | | _ - | . | _ [N]. |
| ___ | ___ | ___ | _ | [5] _ |
x [i] _ | https://github.com/snovvcrash/usbrip

[*] Started 2020-02-14 23:06:02
[22:20:08] [INFO]   Trying to run journal ...
[22:20:08] [INFO]   Successfully run journalctl
[22:20:08] [INFO]   Reading journalctl output
100% | █████████████████████████████████ | 2101/2101 [00:00<00:00, 296000.56line/s]
[22:20:08] [INFO]   Open the list of approved devices: "/root/usbrip/auth.json"
[22:20:08] [INFO]   Search for violations
100% | █████████████████████████████████████████ | 3/3 [00:00<00:00, 15534.46dev/s]
[?] How would you like your violation list to be generated?

    1. Terminal stdout
    2. JSON-file

[>] Enter the number you selected (default 1): 1

[22:20:12] [INFO]   Preparing Collected Events 

Returns a table of all devices that are not on the list of trusted devices.

  BUSB Violation-Events─┬─────────┬─── ───┬──────┬─────────────── ───────────────────┬──── ──────────────┬─────────── ───────────────┬──────┬─ ────────────────────┐
│ Connected │ Users │ KNOW │ PID │ Product │ Manufacturer │ Serial Number │ Port │ Connected │
├─────────────────────┼─────────┼──────┼──────┼─── ───────────────────────────────┼────────────────── ┼──────────────────────────┼──────┼─────────────── ──────┤
│ 2020-02-14 • • - - - - - - - - - - - - - - - −−−−−−− │ −−−−− │ −−−−−−−−−−−−− -----
│ 2020-02-14 22:29:11 │ kubuntu │ 0930 │ 6544 │ DataTraveler 2.0 │ Kingston │ 00241D8CE51BC16029500C03 │ 1-1 │ 2020-02-14 22:33:55 │
│ 2020-02-14 22:38:55 │ kubuntu │ 03eb │ 2401 │ HID keyboard │ ATMEL AVR │ ∅ │ 1-2 │ 2020-02-14 22:40:44 │
│ 2020-02-14 22:40:44 │ kubuntu │ 03eb │ 2401 │ HID keyboard │ ATMEL AVR │ ∅ │ 1-2 │ ∅ │
│ 2020-02-14 22:41:18 │ kubuntu │ 1686 │ 0045 │ H5 │ ZOOM Corporation │ 000000000000 │ 1-2 │ 2020-02-14 22:44:48 │
│ 2020-02-14 22:44:51 │ kubuntu │ 0930 │ 6544 │ DataTraveler 2.0 │ Kingston │ 00241D8CE51BC16029500C03 │ 1-2 │ 2020-02-14 22:54:51 │
│ 2020-02-14 22:46:10 │ kubuntu │ 0930 │ 6544 │ DataTraveler 2.0 │ Kingston │ 00241D8CE51BC16029500C03 │ 1-2 │ 2020-02-14 22:57:10 │
│ 2020-02-14 22:50:54 │ kubuntu │ 1c7a │ 0570 │ EgisTec Touch Fingerprint Sensor │ EgisTec │ 00253CD │ 1-6 │ ∅ │
│ 2020-02-14 22:51:33 │ kubuntu │ 0930 │ 6544 │ DataTraveler 2.0 │ Kingston │ 00241D8CE51BC16029500C03 │ 1-2 │ 2020-02-14 22:59:39 │
│ 2020-02-14 23:05:23 │ kubuntu │ 0930 │ 6544 │ DataTraveler 2.0 │ Kingston │ 00241D8CE51BC16029500C03 │ 1-2 │ 2020-02-14 23:06:12 │
└─────────────────────┴─────────┴──────┴──────┴─── ───────────────────────────────┴────────────────── ┴──────────────────────────┴──────┴─────────────── ──────┘
[*] Close of 2020-02-14 23:06:12
[*] It took time: 0: 01: 17.904624 

All the devices on this list should be carefully inspected to determine if they are reliable or not.

Looking at the above data, it is clear that the HID keyboard would be a suspicious device that has been connected to a computer as a laptop without the need for an external keyboard. Research would show that the manufacturer, Amtel, is responsible for the chip inside the USB Rubber Ducky, which means that there is a high chance that this log record shows that a USB Rubber Ducky has been connected to the system.

Step 5: Sort by manufacturer to quickly find suspicious USB events

Now that we know that the manufacturer of USB Rubber Ducky is Atmel, we can quickly search the USB event history for devices that may be a USB Rubber Ducky. To do so, enter the command below.

  ~ # usbrip event history - manufacturing 'ATMEL AVR' 

It will return the list of USB devices with a chip manufactured by Atmel. It is important to remember that not all devices manufactured by Atmel will become a USB Rubber Ducky, but if you feel your computer may have been compromised, this is a good quick and dirty check of suspicious devices.

Logging suspected USB events is easy with USBRip

While USBRip is not a tool for collecting past data, it can enable advanced logging of USB activities, making it easy to detect future HID attacks. If a hacker with a USB Rubber Ducky or a Digispark connects a payload to your computer while left unattended, the logs that they leave will allow you to identify the manufacturer and the time the device connects and is removed. If you recognize a timestamp that matches the length of a USB Rubber Ducky payload, it may be obvious when a computer was compromised.

I hope you enjoyed this tutorial on capturing USB Rubber Duckies with USBRip. If you have more questions or an idea for a future article, check me out on Twitter @nickgodshall .

Don't Miss: Creating MacOS Files with USB Rubber Ducky

Begin your White-Hat Hacker journey with our Null Byte Beginner's Guide to a career in hacking.

Buy now for $ 49.99>




Source link