Today I found a virus which makes use of TLS callbacks. This technique has been known for quite sometime however it is not common to find it being used in malwares. In the recent past, we saw Win32/Napolar/Solarbot making use of it. Here are the details of the virus I discovered:
MD5 hash: 2015a6e37b951358cb5475de9a591444
Being circulated on the following URLs:
http://noobgirls.com/pussy.exe
http://noobgirls.com/pussy.php
TLS Directory of the binary shows the AddressOfCallbacks:
We can debug this binary using Olly Debugger. The version 2 of Olly has an option that allows you to break at the TLS Callback routine if they are present.
We break at the entry point of the first TLS callback. I have highlighted the AddressOfCallbacks array in the memory dump. We have only one TLS callback routine.
This binary also makes use of a lot of junk instructions. Since in the x86 instruction set, it is possible to synthesize NOP instructions in multiple ways, this binary makes use of a long sequence of such instructions between relevant code sections. This is done to deter reverse engineering.
Here is another example of the usage of junk instructions in a loop. The only relevant instruction executed is to save the ImageBaseAddress of the binary. The other instructions are inserted to increase the size of code section.
All the function names and module names are stored encrypted in the binary. Below is the decryption routine:
Once again you can see the usage of junk instructions in the decryption routine.
It makes use of undocumented functions like RtlRegisterSecureMemoryCacheCallback()
After executing the first TLS callback routine, it will attempt to execute the second TLS callback routine however since the address is set to 0x1 in the AddressOfCallbacks array, it will result in an exception.
We can set a breakpoint at the OEP of the binary (AddressOfEntryPoint in the PE Header) as shown below:
Once we pass the exception in the debugger, we break at the OEP of the binary.
We can continue debugging from here.
At present this binary is detected as malicious only by few AV engines on VT:
https://www.virustotal.com/en/file/38df495f694472029026d10296dc9e40608d638ca17bdbda7d3dd132b9b73007/analysis/
Disk activities performed by it are common:
1. Makes a copy of itself in the path: C:\Documents and Settings\Administrator\Application Data\\
2. Deletes itself from the original location.
3. Creates a new folder, "Address Book" in the directory: C:\Documents and Settings\Administrator\Application Data\Microsoft\ and drops the file, Administrator.wab in it.
4. Makes itself persistent by adding the path to replicated file in the Registry key: HKU\\Software\Microsoft\Windows\CurrentVersion\Run\
Network Communication:
It communicates with the callback IP addresses over UDP on different destination ports. All the data exchanged is encrypted:
121.6.46.119:5693
66.131.90.144:5646
58.1.157.12:4195
107.221.229.216:6240
125.4.34.229:6705
121.117.209.51:2500
81.149.16.130:4344
72.204.26.84:5783
71.2.148.162:8650
184.3.61.57:8477
60.244.81.6:6006
As can you see, both the destination IP addresses and port numbers are random. Makes it more difficult to detect the network callbacks and uniquely identify this traffic.
c0d3inj3cT
MD5 hash: 2015a6e37b951358cb5475de9a591444
Being circulated on the following URLs:
http://noobgirls.com/pussy.exe
http://noobgirls.com/pussy.php
TLS Directory of the binary shows the AddressOfCallbacks:
We can debug this binary using Olly Debugger. The version 2 of Olly has an option that allows you to break at the TLS Callback routine if they are present.
We break at the entry point of the first TLS callback. I have highlighted the AddressOfCallbacks array in the memory dump. We have only one TLS callback routine.
This binary also makes use of a lot of junk instructions. Since in the x86 instruction set, it is possible to synthesize NOP instructions in multiple ways, this binary makes use of a long sequence of such instructions between relevant code sections. This is done to deter reverse engineering.
Here is another example of the usage of junk instructions in a loop. The only relevant instruction executed is to save the ImageBaseAddress of the binary. The other instructions are inserted to increase the size of code section.
All the function names and module names are stored encrypted in the binary. Below is the decryption routine:
Once again you can see the usage of junk instructions in the decryption routine.
It makes use of undocumented functions like RtlRegisterSecureMemoryCacheCallback()
After executing the first TLS callback routine, it will attempt to execute the second TLS callback routine however since the address is set to 0x1 in the AddressOfCallbacks array, it will result in an exception.
We can set a breakpoint at the OEP of the binary (AddressOfEntryPoint in the PE Header) as shown below:
We can continue debugging from here.
At present this binary is detected as malicious only by few AV engines on VT:
https://www.virustotal.com/en/file/38df495f694472029026d10296dc9e40608d638ca17bdbda7d3dd132b9b73007/analysis/
Disk activities performed by it are common:
1. Makes a copy of itself in the path: C:\Documents and Settings\Administrator\Application Data\
2. Deletes itself from the original location.
3. Creates a new folder, "Address Book" in the directory: C:\Documents and Settings\Administrator\Application Data\Microsoft\ and drops the file, Administrator.wab in it.
4. Makes itself persistent by adding the path to replicated file in the Registry key: HKU\
Network Communication:
It communicates with the callback IP addresses over UDP on different destination ports. All the data exchanged is encrypted:
121.6.46.119:5693
66.131.90.144:5646
58.1.157.12:4195
107.221.229.216:6240
125.4.34.229:6705
121.117.209.51:2500
81.149.16.130:4344
72.204.26.84:5783
71.2.148.162:8650
184.3.61.57:8477
60.244.81.6:6006
As can you see, both the destination IP addresses and port numbers are random. Makes it more difficult to detect the network callbacks and uniquely identify this traffic.
c0d3inj3cT
0 comments: