Windows Event Logs & Finding Evil - Skills Assessment


For the logs located in the “C:\Logs\DLLHijack” directory, determine the process responsible for executing a DLL hijacking attack. Enter the process name as your answer. Answer format: _.exe i can’t find it after executing Sysmon and searching for the wininet.dll.

If someone can help me.

Same for the logs located in the “C:\Logs\Dump” directory, determine the process that performed an LSASS dump. Enter the process name as your answer. Answer format: _.exe, i search for lsass.exe but still no more clue.


Thanks for ur previous post bro I was lost too and i ended up getting it due to someone pointing me in the right direction. I have no clue of the actual explanation of why I would specifically search for Wininet.dll in a whole .evtx log but that’s what one guy said in your last post. First start by going into event viewer then load ur saved dllhijack log into EventViewer. Filter current log - Enter ID # 7, then once that is done find Wininet.dll there should be three that are found. The answer is in the “Image:” field and ends with .exe

About to work on the next one :raised_hands: Let me know if you didn’t find the answer

I flagged it about 1 hour ago, i was just a dumb ahah, thanks for your response man

Same same haha

Thanks for this I was making it more complicated than it needed to be.

Hi, I’m still stuck here, i can find the wininet.dll but still cant find which dll is injected, can you pm me? thx

hi, if u have found the dll you just have to follow the Detection Example 1: Detecting DLL Hijacking i guess. dont give up

should i inject the calc.exe first?

The important is to understand. Trying things is a big part of it. You never waste your time. Keep up

This has been a very frustrating module. I understand the need to build critical thinking skills but some of this has been unnecessary. For example, they give you a resource for known DLL Hijacking candidates ( Hijacking DLLs in Windows) but the .exe program responsible for executing the DLL Hijacking attack was not there. You had to filter wininet.dll to find the .exe responsible but even after filtering it is guess work to decide which of the few .exe that loaded wininet.dll are responsible. The idea with wininet.dll was that it was a vulnerable .dll associated with calc.exe that was verifiable through the known DLL Hijacking candidates. Im not sure how other than guess work you would verify that this was the process responsible for the Hijack attack. To assume we would filter for wininet.dll without being able to verify a vulnerable .exe was in the log file is frustrating.


This challenge might be bugged or got wrong answer on it

Ive tried searched using signed: false in the event viewer cos this is the determiner wheter the dll is hijacked or not. similar to the exploiting to the wininet.dll hijacking in calc.exe. yet I couldn’t find the exact answer on it. hope it will be solved as soon as possible

How can it be bugged if people has flagged it ?

To answer the second question,
since we know there is a dump of lsass look for the produced file of this dump. Take into consideration the file extension commonly used for dumps. This will also give you a timestamp that may come in handy afterwards on the assessement.

I used get-winevent on powershell for the DLLHijack logs. Checked IOCs for DLL hijacking attack that is posted on the second page of the introduction of the module.

For anyone stuck on “determine the process that injected into the process that executed unmanaged PowerShell code”, remember MITRE ATT&CK is your friend.