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
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
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.
My own solution, i do not filter for anything. I find for lsass and traverse through some events, pay attention to Image and TargetFileName of each event you traverse. Then you may determine your solution.
Let me know if you didn’t find the answer