New Sliver release!
> Improvements to shell you can now manage multiple shells and swap between them!
> Windows PE metadata spoofing
> Improvements to MacOS shellcode loader
> Bug fixes
| Github | https://github.com/moloch-- |
New Sliver release!
> Improvements to shell you can now manage multiple shells and swap between them!
> Windows PE metadata spoofing
> Improvements to MacOS shellcode loader
> Bug fixes
Matthew Bryant's (@mandatory) @defcon 32 talk is amazing: Secret Life of Rogue Device: Lost IT Assets on the Public Marketplace: https://www.youtube.com/watch?v=QgeEHdAmJDg
Way more entertaining than anything currently on Netflix.
(thank you @jduck for the link!)
As a learning exercise I've decided to create an implant for sliver in C++.
After that, I decided to create a modified version of sliver server in order to support P2P beacons.
Finally, I decided to craft automation scripts that should help deploying both the modified version of sliver and the external builder in charge of building the C++ implant.
Everything for me was mostly a learning exercise, therefore you may find bugs and poorly written code.
Here the repositories:
- https://github.com/MrAle98/Sliver-CPPImplant2 (repository containing code of C++ implant)
- https://github.com/MrAle98/sliver-deployment (repository containing automation scripts for deployment)
- https://github.com/MrAle98/Sliver (fork refactor/teamserver-interaction. Containing code of modified sliver server)
- https://github.com/MrAle98/Sliver (fork cppimplant. Containing code of the external builder that builds the C++ implant)
Start with https://github.com/MrAle98/sliver-deployment for deploying and playing with the C2.
Of course credits goes to @moloch, @rkervell, @BishopFox and all the contributors to sliver!
A PSA since there's some confusion on this...
There is no vulnerability in Gorilla Sessions.
The vulnerability is in Palo Alto's internal SessDiskStore, which looks similar to FilesystemStore. Early analysis came to the mistaken conclusion that the vulnerable path was in FilesystemStore, but it's not. FilesystemStore authenticates the Session.ID with securecookie, SessDiskStore does not.