Communication Protocol forged by remote control Trojan

Communication Protocol forged by remote control Trojan

Remote Control Trojans are always an important part of the malware family. It is important because it is not as functional as malicious software such as Trojans, Downloaders, and worms. The Remote Control Trojan function is "control". Once the victim's machine is successfully controlled, this type of Trojan almost does what they want.

Because of this, remote control Trojans have always been the weapon and favorite of hackers. After years of evolution, there have been many variants and numerous branches, but they have never been killed for a long time. Today, I will introduce the latest Remote Control Trojan variant captured by the 360 security center.

What does it look like?

Of course, there are all Trojans, and no Trojan horse will post a tag on his head to write the word "Trojan ...... The Remote Control Trojan we analyzed today looks like this:

Take a look at these files:

• Bbs.bmp is a hidden image file, which does not have any effect on the virus itself. It is just a blind eye-the virus will open this image to the user, so that the user can think that what he opens is just an image. Gldat is a virus entity in the real sense. We will talk about logmain later. the main work of dll is to call the virus body. We will also mention later that bmp 1 and bmp 2 are two lnk files (shortcuts). We know that bmp images are hidden, gldata does not even have an extension name. Although the dll file is executable, double-clicking is useless. Therefore, the user will naturally click these two lnk files under such careful arrangement. The main function of BMP 2 is to add the virus topic to the system for self-startup. The command line is as follows:
  

  C: \ WINDOWS \ system32 \ rundll32.exe advpack. dll, LaunchINFSectionEx % appdata % \ gbrztmip. inf, defainstall install, 32

  Call the LaunchINFSectionEx function to read the virus inf file (generated in BMP 1, which will be said later) to enable auto-start upon startup. The reason for this function to be taken out independently is probably because you know that this behavior of loading and enabling the self-starting item will be intercepted properly. In order not to affect the main function of the virus, you can only separate it.

  What we should focus on is this lnk file named BMP 1. All evil actions start from this lnk file ......

  What have you done?

  BMP 1 is actually very simple, just a shortcut. There is only one problem to be solved. There is no exe file in the whole virus, and the dll file cannot be run by itself. Therefore, the only function of this shortcut is to call the rundll32 of the system to execute the dll file:

  C: \ WINDOWS \ system32 \ rundll32.exe logmain. dll, gbrztmip

  The following figure shows what the gbrztmip function in logmain. dll does.

  At startup, the function will determine its current directory. If it is not in % APPDATA %, it will enter the first startup mode:

  Create a directory named "gbrztmip" under the % APPDATA % directory. dll) to this directory and rename it "bxipndlhm. dll, and copy the core gldat file. Generate a gbrztmip. inf file, and use it with the aforementioned BMP 2 for auto-start:
  

  [Version]

  Signature = "$ CHICAGO $"

  Provider = t@t.com, 2002

  [Defainstall install]

  ; DelReg = run_DelReg

  AddReg = run_AddReg

  [Run_DelReg]

  [Run_AddReg]

  Hkcu, "Software \ Microsoft \ Windows \ CurrentVersion \ runmip, updatelogs, and rundll32.exe" C: \ Documents and Settings \ Administrator \ Application Data \ gbrztmip \ Bitgbrztmip. dll ", gbrztmip"

  [Strings]

   

  After that, the virus will re-call the system's rundll32 to copy the previous Virus File-bxipndlhm. dll. This is the real beginning of evil.

  What have you done?

  As mentioned above, the dll file is only an intermediate scheduling, so his first action is to open the gldat file beside him.

  The next thing is a matter of course-open the file, get the size, apply for a piece of memory, read the file content ...... Yes, the gldat file stores a piece of shellcode, which is also the core code of the Remote Control Trojan.

  The shellcode loaded into the memory will be decoded twice with two keys:

  The decoding function is as follows:

  After two decoding operations, the final result is clear and the PE format is clear:

  Shellcode has been worked out, and the launch information of remote control has been put here:

  The launch address is the IP address of 183. ***. ***. 232, and the region above

  This meager ...... Haha ~ Pretty cute. Where did you buy it? Can it be sold?

   

  How do I transfer it out?

   

  I wanted to talk about the remote control part, but this part is indeed not good enough. The data collection and control part of the code is completely changed with the open-source remote control code, and it is a bit better than the analysis, there is no need to repeat it.

  It is worth talking about the online data packets he sent:

  Looking at the first two lines, I think it is an HTTP POST request (the path is somewhat strange ......), And the CONTENT-LENGTH and CONTNT-TYPE in the back of the network plus line feed, followed by a paragraph of 400 Bad Request corresponding page HTML code ...... Hodgedge ...... The real online data of remote control is only the part circled by me. The encoding and encryption parts are not mentioned, but in plain text, we can see that my system version, machine name, and current date have been sent out in three places circled in red circles.

  What about last?

  Block as usual

  In fact, the disguise of the Protocol was chosen wrong at the beginning. You can disguise one protocol as another. However, no matter what protocol is, as long as it is evil, it is hard to escape.

  At the same time, users are reminded to be cautious before opening the so-called "equipment diagram" or "Trade Order" files downloaded online or transmitted through chat tools.