BishopFox
Saves not changed?
Hello
I'm using last version of sliver, updated yesterday.
I'm using HTTP profile, I want to modify the communication behavior so I edited ~/.sliver/configs/http-c2.json as described in https://github.com/BishopFox/sliver/wiki/HTTP(S)-C2
However, no matter if I shutdown sliver and put it up again, the new implants generated always communicate with the default values when looking at wireshark. Is there a special command to force it read it? Just shutdown and start again is not working.
BTW, do you have any options to modify DNS traffic? Security solutions are a pain with traffic behavior
Happy new year
We currently do not have any way to manipulate DNS traffic, though we could potentially implement something for this in the future; we're looking into the HTTP C2 traffic issue.
~~Looks like we always call configs.GetHTTPC2Config().RandomImplantConfig() when we render the implant code in generate.renderSliverGoCode():~~
Nevermind, it's intended, the source is still the user's configuration file.
@albfflk would you mind sharing your http-c2.json file so we can have a look?
@albfflk can you confirm you restarted the server process (not just the client) after making the edits?
Sorry to revive this ancient issue but I'm having the same issue in v1.5.41, can confirm that I've reset sliver-server, regenerated payloads and restarted listeners.
In my custom c2 config I had changed the .html file extension and removed the rpc file name.
Quite relieved to see someone else has encountered this issue as I was in the middle of writing a feverish discussions post, felt like I was losing my mind.
I had modified http-c2.json quite heavily so there may be something causing a conflict. I'll strip back my config to just the bare essentials and see if I can figure out what's causing it, apprehensive about sharing the whole config as I'm hoping to use it on an engagement.
EDIT: I managed to solve my issue by monitoring the .sliver/logs/sliver.log file (I should have thought of this earlier really, again, sorry for resurrecting). Looks like the ".." behaviour occurs when there's some error parsing the http-c2.json file, the exact parsing issue can be narrowed down in the log. Hope this helps others.
