Orer.exe is the after-infection result of W32/Huhk.a. It’s name derives from explORER.exe, in other words it cuts explorer’s name.
The Malware, attacks indeed explorer executable by appending itself with the technique of Split Cavity, and makes an infected copy of explorer into Temp directory; so as you can understand is relatively easy to detect (but not to remove), please note that Executable’s date/time will correspond to the original explorer.exe.
- Desktop’s icons disappear for instants
- RADmin and other Net-Monitoring tools will be unable to enstablish connections
- Frequently, Win will report Memory Access Violations
- MS Word is killed after some seconds that is opened
- Particular programs, as FileMaker will be destroyed
Three Threads Created:
- The first one hooks the API function CreateProcessW in order to redirect the execution to the virus code.
- The second one infects files with the extension .exe located on removable disks and on the C drive.
- The last one infects files with the extension .exe on network shares.
.:: First Look Analysis ::.
Executable is not packer or crypted, important to mantain the same explorer size, except some easy and little portion of Self Modifing Code, debug informations are not stripped (remember that orer.exe, derives from explorer.exe) so RCE it’s truly easy.
At a first look of the Dead List, code seems perfectly equal to explorer:
01019634 call loc_10460D0 ; Entry Point Lands Here..
01019639 sub esp, 44h
0101963C push esi
0101963D push edi
0101963E push 10h ; nInBufferSize
01019640 push offset aExplorerstartu ; “ExplorerStartup”
01019645 call sub_10146D4
0101964A call sub_1019708
0101964F push 1 ; uMode
01019651 call ds:SetErrorMode
The code listed above corresponds to the Entry Point of orer, and suddlenly we can see a foundamental difference from explorer’s code, the call 010460D0 that contains a RunTime decrypt routine.
Soon the Second part of W32 Hunk.a RCE will be available🙂
Have a Nice Day