HitmanPro.ALERT Support and Discussion Thread

@erikloman @markloman

Could you perhaps post a Video on your YouTube Channel as to how Alert is handling weaponized MS Office documents?

 

Is this such a video you are looking for?
https://www.youtube.com/watch?v=0sZnLr6Qsbw

Note: build 360 is handling the rename restore flawless.

 

W7-x64 with HitmanPro.Alert build 361, no issues so far!

 

Thanks Erik!

Now running HitmanPro.Alert 3.1.9 Build 361 PreRelease.

Virtualbox Version 5.0.16 r105871, latest release (with hardening), is running OK now on my Windows 7 Pro (32-bit) host.

No other issues for me with the update that I am aware of at this time.

 

Build 361 looks good here.

 

Installed 360 today and ran into the same vbox problem discussed here, but 361 has fixed it. Thanks!

 

@erikloman
@markloman

HMP.A Build 361

When the user creates a permanent copy of HMP on their system by using HitmanPro_x64.exe from AppData temp directory, it is installed to Program Files. This is correct behavior.

However, the HMP executable installed to Program Files in prior builds used to be named hitmanpro_x64.exe, whereas in 361 the file is named hitmanpro.exe. This might cause confusion for some users. They might think that the 32 bit version was installed, when in fact, it is really the 64 bit.

Also, there are some misspellings in the file properties; hitmanpro is spelled himanpro.

No big deal, just file name issue. I understand, beta - but it could get missed for stable release.

* * * * *

Also, with protection border displayed, sometimes when close a browser, the protection border will remain\display for a few seconds after the browser has been closed. I think it is because some browser processes do not immediately terminate when the browser is closed. I see this on Internet Explorer, Edge, Cyberfox, etc.

It is just a very minor issue.

 

HMP.A 361 running smooth here on W7 Pro SP1 x64.

 

HitmanPro.Alert 3.1.9 Build 361 PreRelease

 

@ Erik Loman

Does the HMPA Test Tool inject code into a exploited process, and if so, what's the name of the DLL file? And does the exploited process always need to be a child process? I noticed that the exploits won't work when the targeted process is already running. I'm using Win 8.1 64 bit, and have tested both the 32 and 64 bit versions of the tool.

 

HMPA Build 361 appears to give false alarms on Office 2013. This occurs when I open Word or Excel or PowerPoint, even with a blank document. When I do a scan with HMP it doesn't find any infected files.
When I turn ROP detection off, Word and Excel start normal.

Code:

Mitigation   ROP

Platform     6.1.7601/x64 06_3c
PID          2956
Application  C:\Program Files\Microsoft Office 15\root\office15\WINWORD.EXE
Description  Microsoft Word 15

Branch Trace                      Opcode  To                            
-------------------------------- -------- --------------------------------
0x5CB91FCC MSO.DLL                   RET  0x5CB91EDD MSO.DLL            

0x5E1B115B MSO.DLL                 ~ RET  0x01151347 (anonymous; WWLIB.DLL)

0x5E12B1F4 MSO.DLL                   RET  0x5E1B1145 MSO.DLL            

0x5CB826BC MSO.DLL                   RET  0x5E12B1F3 MSO.DLL            

0x5DAE4790 MSO.DLL                 ~ RET  0x01151DCF (anonymous; WWLIB.DLL)

0x5D553BC5 MSO.DLL                   RET  0x5DAE477A MSO.DLL            

0x5CB826BC MSO.DLL                   RET  0x5D553BC4 MSO.DLL            

?AuthHandlerSupportAutoLogonBasedOnURL@Http@Mso@@YAXXZ()     RET  0x0115140D (anonymous; WWLIB.DLL)
0x5CB8A469 MSO.DLL                                                      

0x5DB78773 MSO.DLL                 ~ RET  0x011513FD (anonymous; WWLIB.DLL)

0x5DF58D8E MSO.DLL                 ~ RET* 0x5CBE1B10 MSO.DLL            
            837d0800                 CMP          DWORD [EBP+0x8], 0x0
            8907                     MOV          [EDI], EAX
            7549                     JNZ          0x5cbe1b61
            57                       PUSH         EDI
            8bce                     MOV          ECX, ESI
            e8ed62f900               CALL         0x5db77e0d
            a21e8ac044               MOV          [0x44c08a1e], AL
            0000                     ADD          [EAX], AL
            d084c074358bce           ROL          BYTE [EAX+EAX*8-0x3174ca8c], 0x1
            e805d0d400               CALL         0x5d92eb38
            8bc8                     MOV          ECX, EAX
            e81c4fd500               CALL         0x5d936a56
            85c0                     TEST         EAX, EAX
            7813                     JS           0x5cbe1b51
            6a00                     PUSH         0x0
            8bce                     MOV          ECX, ESI
                                 (87D23257ABEF258B)


0x5E2110FC MSO.DLL                 ~ RET* 0x5DF58D8E MSO.DLL            
            c20400                   RET          0x4


_MsoRegOpenKeyExW@16 +0x13a          RET  0x01159524 (anonymous; WWLIB.DLL)
0x5CB82973 MSO.DLL                                                      

0x5CB826BC MSO.DLL                   RET  _MsoFreePv@4 +0xc0            
                                          0x5CB881DA MSO.DLL            

Stack Trace
#  Address  Module                   Location
-- -------- ------------------------ ----------------------------------------
1  5CB91EE8 MSO.DLL                
            8bce                     MOV          ECX, ESI
            8986ac000000             MOV          [ESI+0xac], EAX
            e8d8000000               CALL         0x5cb91fcd
            8bc6                     MOV          EAX, ESI
            5e                       POP          ESI
            c3                       RET        

2  0115134C (anonymous; WWLIB.DLL)
3  5CBE1B28 MSO.DLL                
4  5CDA2F1A MSO.DLL                
5  01158A6B (anonymous; WWLIB.DLL)
6  5CDCF1E9 MSO.DLL                
7  5CDCD534 MSO.DLL                
8  5CBAEB95 MSO.DLL                
9  5CB9EBB9 MSO.DLL                
10 5CB9C929 MSO.DLL                

Process Trace
1  C:\Program Files\Microsoft Office 15\root\office15\WINWORD.EXE [2956]
2  C:\Windows\explorer.exe [2980]
3  C:\Windows\System32\userinit.exe [1640]

 

It is injecting code in a new process only. You need to close any existing browsers when injecting into for example iexplore.exe because IE will close newly started processes when it is already running. The current tool does not use a physical DLL on disk, but it is injected into the new process memory. Hence, the DLL is loaded reflectively.

 

As you can see, ROP is sometimes used by legitimate software (mostly DRM software). Really annoying, but we'll address this in build 362.

 

Interesting. I also use Office 2013 and HMPA Build 361 intercepted Outlook the first time I started it, but since then no problem with Outlook or any of the other Office apps. Does 361 intercept consistently on your system?

Edit: Just had another intercept/termination when starting Outlook. I'll try disabling ROP.

 

OK I see. But when I want to exploit Winamp, why does it have to be started by the HMPA Test Tool, is there any special reason for this? Why not just inject code into an already running Winamp process and then run the memory corruption method?

 

No, not yet. But I'm trying to figure out how the HMPA Test Tool is working. I don't understand the logic behind it.

 

Because it works like this and AV solutions are not in your way. Injecting in running process can trigger AV.

 

OK, I now get it, so it's designed this way to avoid HIPS or AV interfering with it? Would be cool if you could exploit an already running process though, plus you would also be able to test HIPS against reflective injection. And I wonder why the hollow process test is not available anymore?

 

The Hollow Process test is only visible/available on 32-bit versions of Windows.

 

Upgraded today from HMPA version 3.1.8.360 to 3.1.9.361. In contrast to earlier upgrades Avast Free Antivirus kicks in immediately after I started the upgrade and displays a warning that:

Avast [...]: bestand "C:\Program Files\HitmanPro.Alert\Update Files\hmpnet.sys" is besmet met het virus "Win32:Malware-gen".
Gebruikte taak: "Bestandssysteemschild" taak
Versie van huidig VPS-bestand: 160319-1, 19-03-2016

After ignoring the warning and restarting the computer, the upgrade is successfully installed.

However performing a full system scan with Avast Free Antivirus results in the following result:

Avast [...]: bestand "c:\windows\system32\drivers\hmpnet.sys" is besmet met het virus "Win32:Malware-gen".
Gebruikte taak: "Volledige systeemscan" taak
Versie van huidig VPS-bestand: 160319-1, 19-03-2016

It seems Avast doens't like the new version of hmpnet.sys.

I'm not running the most recent version of Avast Free Antivirus (10.4.2233) but that probably doesn't make a difference for this situation.

 

OK, I guess because it's not that easy to implement a working test on Win 64 bit? I do believe that almost all ransomware variants use process hollowing nowadays, I assume also on 64 bit systems.