Skype upgrade module not delivering payload

[GarrettVD]

Ive been playing around with the Skype module of EvilGrade v2.0.0. It doesn't seem to deliver the payload as expected. I've created a sandbox environment in which my "victim" machine is a Dell Inspiron 15 7000 Series running Windows 8.1 64-bit. I manually setup my IPv4 config on the victim PC to use two DNS servers which reside remotely on Amazon EC2 (Let's call them "Server A" and "Server B") for testing purposes. Server A simply runs dnsmasq and will resolve "ui.skype.com" queries to the "Server B" IP address. Server B is where I am running Evilgrade's skype module. I've configured the Skype module to deliver an EXE payload, which should create a reverse TCP connection to "Server C", which is listening on a specified port, and should spawn a Meterpreter session if all goes accordingly.

Now, everything works fine as far as resolving ui.skype.com to Server B, and I can see some interactions in the Evilgrade terminal, but after examining network TCP interactions between the victim PC and Server B, it doesn't appear as if the payload is being delivered.

Am I doing something incorrect here? Or perhaps the exploitability of this update-delivery method has been patched since this module was created? I am running Skype for Desktop v7.2.0.103, Windows 8.1 64-bit.

You can view the PCAP online here, which was recorded (and filtered for brevity) during the initial auto-update interaction, right here: https://www.cloudshark.org/captures/84f7ae21e341

Upon attempting the manually initiating an update via the "Help > Check for Updates..." menu item, EvilGrade terminal output was as follows: http://dumptext.com/ASDJ5xUL/raw

Thanks

[f-amato]

Hi @GarrettVD It possible that something change from skype side. Try to change line 44 from: 'string' => '4.5.0.615', to 'string' => '8.2.0.103',

Run again evilgrade, Let me know if this works for you.

[GarrettVD]

Hi @f-amato Upon further investigation in Wireshark, the inital ui.skype.com request just returns a 302 which will eventually lead to download.skype.com. So really, that's where the payload should be. A few dnsmasq- and Apache htaccess edits later, I was able to configure the delivery of the payload EXE just fine.

That's where the "fun" begins, though... I actually think the issue is more to do with the code-signing and verification of the update's file signature. Skype downloads the update EXE to "%temp%\SkypeSetup.exe", and likely checks to see if the app has been signed by a Trusted CA or not. I've not figured out how to determine exactly what/how Skype authenticates this download, but I suspect that it's a code-signing issue... For example, If I upload a legit SkypeSetupFull.exe to "Server B" then Skype will prompt to install, following the download. Otherwise, Skype will delete the file at %temp%\SkypeSetup.exe and a "retry download" message will appear.

[f-amato]

Did you try to use any valid authenticator EXE signed by any Trusted CA? or is it only works using exe's signed by skype ? If it's possible to run with any Trusted so you can signed your own payload, if only signed exe with skype so you should try with all versions of skype maybe it's possible to do some trick changing the arguments I have the same problem with java and i use for the payload the javaws.exe signed by java and changes the args i download my own jar take a look the java plugin. Let me know if this works for you.

[GarrettVD]

I've tried using the following:

1. Hosting an old version of SkypeSetup.exe (7.3.59.101), which had been signed by Skype and had a valid trusted certificate chain leading to a Trusted Root CA, on my spoofed download.skype.com server. This works fine.
2. Signing with my own spoofed cert issued by a Root CA I'd created + manually added to my Local Machine Trusted Root CA store beforehand. This doesn;t work.

So there is definitely a digital signature assertion going on here.