Is this Expected Behaviour? handledup uses lsass process to get handle

[m-j-w-69]

Reading your medium.com article I decided to give handledup a go. Ran it against a fully patched Win10 box running 3rd party AV and cool it worked :)

python -m pypykatz -v live lsa --method handledup

Decided to do a bit of digging and discovered the following output:

DEBUG:pypykatz:Failed to duplicate object! PID: 744 HANDLE: 0xdb8 DEBUG:pypykatz:Failed to duplicate object! PID: 744 HANDLE: 0xdd4 DEBUG:pypykatz:Failed to duplicate object! PID: 744 HANDLE: 0xe10 DEBUG:pypykatz:Found open handle to lsass! PID: 744 HANDLE: 0xee8 DEBUG:pypykatz:Failed to duplicate object! PID: 744 HANDLE: 0xefc DEBUG:pypykatz:Failed to duplicate object! PID: 744 HANDLE: 0xf00

There were a few other 744 handles but no other PIDs referenced. 744 was the LSASS process. I found this a little surprising as i thought (willing to be corrected on this) the idea was to evade touching this somewhat monitored process. Have I misunderstood the point of this flag and all is fine, or is this a bug?

Feel free to look at this in slow time, always grateful to open-source devs & i realise you are probably super busy.

Regards MJW

[skelsec]

Hello,

This is expected behavior, I will expand the wiki about it probably with the text below:

The handledup method will search for all open process handles in all processes and tests if the given handle is a process handle to LSASS. If it is then it will try to use that handle and if it succeeds then hurray, if not then it will continue with the next available handle. The handle searching does not know upfront which process has which handles, it simply requests ALL possible handles via windows API call, therefore some "bruteforcing" is needed. This method can succeed because of two possible reasons:

• a random process has an open handle to LSASS, and you can access this random process via your debug privs
• LSASS itself has an open handle to LSASS by default. You might ask: but then how is this different then the normal method. Well, Timmy, the reason is: to access only a process handle object in a given process you need different flags to open the process than if you'd like to read the same process' full memory. Antiviruses tend to focus on WE DEFEAT MIMIKATZ WARRGGGRGAHHH approach, so they (not all, hence you can't always win) specifically filter/block OpenProcess calls with that one specific flag value mimikatz uses. This method doesn't use that specific flag value therefore bypasses this filtering.

I hope this clears it up

[m-j-w-69]

Many thanks for the super quick response. Really understand the use case now and when this could be useful and when it will trigger/flag. Will close now.

Regards