PORTIONS OF THE BELOW EXPLANATION HAVE BEEN SOURCED FROM DLL HIJACKING DEFINITION AT MARAVIS.com AND HAVE BEEN GRANTED PERMISSION TO USE HERE AS A MEANS TO PREFACE THE ABOVE VIDEO
"Thanks for letting me know. I will be fine with a link to my post. You
don't have to take it down..I have others copying entire posts and
putting them on their sites without even changing the title or links.."
Siva Ram CISA, PCI-QSA, PA-QSA
Web: http://www.maravis.com
In this video, we are going to demonstrate how DLL Hijacking works.
DLL Hijacking is an attack that exploits the way some Windows applications search and load Dynamic Link Libraries.
Most Windows applications will not use a fully qualified path to load any required DLLs. A bad guy can place a fake DLL for a known program in a location that is searched before the real DLL’s location and almost guarantee that the malicious DLL is loaded, resulting in whatever code the attacker wants to run running!
When programs are not written to specify the exact location of a required DLL, Windows will search for the DLL by name in a specific order. For instance, let’s say that the application, infosec.exe requires a DLL named learn.dll that is usually in the Windows system directory. If the application does not specify the exact path for learn.dll, Windows will search for the dll in the directory from which the application has been loaded first.
If a malicious hacker has placed his own version of learn.dll in the same directory as infosec.exe, then that DLL will be loaded instead of the real DLL. Windows just tries to find the first file that has the same name and does not verify if the file is actually the one that is required.
The vulnerability requires an attacker to convince someone to open a file using a vulnerable program such as Microsoft Word, PowerPoint or others from a remote network location (usually an smb share). If the vulnerable application tries to load an external DLL from the same location, the attack will most likely be successful.
The list of vulnerable programs seem to be growing daily. Even some anti-virus and security products are vulnerable. Imagine that! In this video, we’ll be using Windows Address Book program as our exploitable application. We’ll create a WAB file and share it out, then browse to the share from a patched Windows 7 machine. Just from that smb browsing activity (or in the real world, maybe someone clicking on a link), we’ll own that box instantly.
Enjoy.
Incoming search terms:
- dll hijacking
- hijacking dll windows 7
- msfencode by pass avg 2012 juin 2012
- siva ram qsa
- what is dll
- What Is DLL Hijacking
That’s fascinating Keatron – thank you for such an interesting demonstration. I’ve seen other videos about this but none with the clear explanation that you gave. You dropped some tantalising morsels and I’m looking forward to your future videos about this topic. I have a few comments/questions:
1. Did the fully patched Windows 7 PC have AV? I suspect that AVs will pick this up, if they don’t already. Can this be encoded in some way? I know that AVs can pick up meterpreter encoding, whether multiple passes of the same encoder or sequential encoders.
2. You said that you would cover other ways of getting someone to click on a file … I’m intrigued. You said that there was a more advanced technique that doesn’t need the end-user to click on the file … I’m even more intrigued!
Please keep up your enthusiasm in producing such high quality material.
Great video. I’ve tried with WinXPSP3 and it works fine. Thanks for the information.
very good thing, thank you, a huge database can be found at dll-files.org or dll-files com
@Iian. Thanks for watching. Since the payload I used was indeed meterpreter in it’s default state, it could be picked up. However, in the advanced class we show you how to use msfencode using multiple passes (the exact right amount and combination of different encoders). For example, I’ve found that sometimes encoding something 10 times still leaves the payload detectable by say Symantec, McAfee, CA, and AVG. But maybe using the same encoders but only passing through them 4 times will then maybe elude two of the 4. Passing it 5 times may elude 1 of the remaining 2 AV’s but then it’s again detectable by the first 2. Remember, you only need to evade typically one AV (the one your victim happens to be using), not an entire host. Alternatively, I’ve had a lot of success running my payloads through msfencode, then running them through “other” encoders afterwards. It’s a trial and error process, but it’s fun! Often times, if you encode it too much it evades all AV, but now the payload doesn’t work properly anymore. The possibilities are endless though.
Concerning the “clicking”. Just image how Win7 and Vista has the new feature of trying to preview any file type as long as you have the associated program installed. For example, when you have preview enabled and you browse to a folder, there’s a right pane that shows you the content of the files without actually “opening” them. For this preview process, some of those same DLL’s that are used to open the file may be called to preview the file :). I’ve got something coming soon on that. Stay tuned.
@Pellucida. Everything pre 7 is vulnerable to an extent. Thanks for watching.
@ Justin. Thanks for the reference.
Thanks Keatron. Nice explanation!! U Rulzs!!