[Network Security] How to Counter Red Team “Hardware” Attacks

Foreword

With the increasingly fierce confrontation between red and blue, the red team’s attack point has also involved many directions from the original web method, such as hardware attack.

The most notable hardware attack is Badusb. Talk about this stuff. Presumably everyone knows that there are a lot of production articles on the Internet.

Another way to burn BadUsb

There are indeed most of the BadUsb burning methods on the Internet, but they are all based on the burning of the arduino interface, but after my own research

Arduino can also be burned through command line parameters, as follows:

C:\Users\Administrator\Desktop\Arduino\arduino_debug.exe --port COM port --upload the burned content file

For the file path, you can see the following figure. When saving the content, detailed information is given, and the suffix is ino. After the author compiles and tests with the command line, the path should be:

C:\xxx\sketch_apr01a\sketch_apr01a.ino

sketch_apr01a is the project file, and there must be a directory named sketch_apr01a in the upper layer

Code Analysis Process

In Windows sdk development, any window can receive messages and respond. Similarly, there will be corresponding messages and responses when BadUSB or U disk is inserted or pulled out.

The message used is: WM_DEVICECHANGE

(Notify an application of changes to a device or computer’s hardware configuration, receive messages via the WindowProc function)

The function prototype is as follows:

LRESULT CALLBACK WindowProc ( HWND hWnd,
                              UINT message,
                                WPARAM wParam,
                                LParam);

The third parameter wParam in WindowProc points to the event that occurs, and the value of this parameter can be found in the Dbt.h header file. Let’s talk about the macros we want to use, in Dbt.h:

DBT_DEVICEARRIVAL //Device insertion will respond
DBT_DEVICEREMOVECOMPLETE //response when the device is pulled out

Code implements message response

First look at the WndProc function. The specific implementation is to respond to the message through a case

Add your own message response. When the following code is inserted into BadUSB, a pop-up window will display that the device is inserted.

case WM_DEVICECHANGE://Catch the message when the device changes
    switch(wParam){
    case DBT_DEVICEARRIVAL://capture device inserted
      MessageBoxA(NULL, "device inserted", "test", NULL);
      break;
    case DBT_DEVICEREMOVECOMPLETE://capture device eject
      MessageBoxA(NULL, "device unplugged", "test", NULL);
      break;
    }

Here, when I plug in the BadUSB, the message is successfully captured and a window pops up.

Core code implementation

Since the message function will respond when the BadUSB is plugged in, let the message function execute the arduino command line and perform automatic programming. When the red team makes changes to BadUSB later, it will execute the code we burned

BadUSB will burn the content as follows, the setup function is the initialization function. When the BadUSB is plugged in, open Notepad and enter the string By: Met32. You can change it here… I wrote it here for the convenience of demonstration.

void setup() {
  // put your setup code here, to run once:

Keyboard.begin();//Start keyboard communication
 
delay(1000);//The delay is 1000 milliseconds, not too short, because the computer runs at different speeds every day
 
Keyboard.press(KEY_CAPS_LOCK); //Press the caps key Here we'd better write like this, otherwise most computers will have problems in the case of Chinese input
 
Keyboard.release(KEY_CAPS_LOCK); //Release the caps key
 
delay(500);
 
 
Keyboard.press(KEY_LEFT_GUI);//Press the logo key, which is the win key
 
delay(500);
 
Keyboard.press('r');//Press the r key
 
delay(500);
 
Keyboard.release(KEY_LEFT_GUI);//loose win key
 
Keyboard.release('r');//loose the r key
 
delay(500);
 
Keyboard.println("notepad");//Enter notepad to open Notepad
 
delay(500);
 
Keyboard.press(KEY_RETURN); //Press the Enter key
 
Keyboard.release(KEY_RETURN); //Release the Enter key
 
delay(500);
 
Keyboard.println(" By: Met32");//Enter the information we want to display
 
Keyboard.press(KEY_RETURN); //Press the Enter key
 
Keyboard.release(KEY_RETURN); //Release the Enter key
 
delay(500);
 
Keyboard.press(KEY_CAPS_LOCK); //Press the caps key
 
Keyboard.release(KEY_CAPS_LOCK); //Release the caps key We turn off the opened caps key again
 
delay(500);
 
Keyboard.end();//End keyboard communication

}

void loop() {
  // put your main code here, to run repeatedly:

}

The entire implementation code of WndProc is as follows.

LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
  int wmId, wmEvent;
  PAINTSTRUCT ps;
  HDC hdc;

  switch (message)
  {
  case WM_COMMAND:
    wmId = LOWORD(wParam);
    wmEvent = HIWORD(wParam);
    // Analysis menu selection:
    switch (wmId)
    {
    case IDM_ABOUT:
      DialogBox(hInst, MAKEINTRESOURCE(IDD_ABOUTBOX), hWnd, About);
      break;
    case IDM_EXIT:
      DestroyWindow(hWnd);
      break;
    default:
      return DefWindowProc(hWnd, message, wParam, lParam);
    }
    break;
  case WM_PAINT:
    hdc = BeginPaint(hWnd, &ps);
    // TODO: Add arbitrary drawing code here...
    EndPaint(hWnd, &ps);
    break;
  case WM_DESTROY:
    PostQuitMessage(0);
    break;
  case WM_DEVICECHANGE:
    switch(wParam){
    //code here
    case DBT_DEVICEARRIVAL:
      system("C:\Users\Arduino\arduino_debug.exe --port COM5 --upload C:\Users\Administrator\Desktop\sketch_apr01a\sketch_apr02a\sketch_apr02a.ino");
      break;
    case DBT_DEVICEREMOVECOMPLETE:
      MessageBoxA(NULL, "device unplugged", "test", NULL);
      break;
    }
    break;
  default:
    return DefWindowProc(hWnd, message, wParam, lParam);
  }
  return 0;
}

Usage process

Now let’s see the effect, when the BadUSB is plugged in, copy the burning content to the other party’s BadUSB by yourself.

Then exit the program, re-insert the BadUSB, and it will be displayed successfully, which proves that we have successfully burned to the other party’s BadUSB

Notes at the end

Don’t worry about the path of Arduino, because it’s all on your own machine, you can write it to death. The problem lies in the COM port. When the BadUSB is plugged in, we are not sure which port to use. Therefore, you can execute all the commonly used COM port numbers through a loop.

If you want to be more perfect, you can detect that the keyboard is disabled after the BadUSB is plugged in (forbid the other party’s code operation), and then execute our system command.

?Last

In order to help you better learn about network security, the editor has prepared a set of introductory/advanced learning materials for network security for you. The contents are all notes and materials suitable for zero-based beginners. I understand, all the information is 282G in total. If you need a full set of network security introduction + advanced learning resource package, you can click to get it for free (if you encounter problems with scanning the code, you can leave a message in the comment area to get it) ~

CSDN spree: “Network Security Introduction & amp; Advanced Learning Resource Pack” free sharing

?

Network Security Source Code Collection + Toolkit

Internet Security Interview Questions
Finally, there is the network security interview question section that everyone is most concerned about.


All the materials are 282G in total. If you need a full set of network security introduction + advanced learning resource package, you can Click to get it for free (if you encounter problems scanning the code, you can leave a message in the comment area to get it)~

Network security gift package: “& amp; Introduction to Network Security & amp; Advanced Learning Resource Pack” for free sharing

? Video supporting materials & amp; domestic and foreign network security books and documents

Network Security Gift Package: “Network Security Introduction & Advanced Learning Resource Package” for free sharing

?