Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG]Implants only connecting via TLSv1 causing fatal negotation error. #278

Open
creationstation123 opened this issue Feb 16, 2023 · 3 comments
Assignees
Labels
bug Something isn't working

Comments

@creationstation123
Copy link

Description

I am having an issue wherein the implants which are generated are only connecting via TLSv1 despite setting for TLS.1.2 inside the C2Server.py file. Below is what I have placed in the server code:

if "https://" in PayloadCommsHost.strip():
if (os.path.isfile("%sposh.crt" % PoshProjectDirectory)) and (os.path.isfile("%sposh.key" % PoshProjectDirectory)):
#try:
httpd.socket = ssl.wrap_socket(httpd.socket, keyfile="%sposh.key" % PoshProjectDirectory, certfile="%sposh.crt" % PoshProjectDirectory, server_side=True, ssl_version=ssl.PROTOCOL_TLSv1_2)

The domain front we are using only accepts TLSv1.2 or higher. The implant will repeatedly only offer TLSv1 which eventually gets a fatal flag from the domain front.

Execution Environment:

All of this must be filled in
Data | Value
=============== PoshC2 v8.0 (5672077 2022-03-30 16:58:55) ===============

OS & version | Ubuntu
No docker.

Implant Info

Using the powershell implant generated at the top of payload generation

Defensive Technologies

No

To Reproduce

Steps to reproduce the behavior:
Set config file to domain front using help.webex.com and cloudfront address with certificates.
Set server to only accept TLSv1.2 or above.
Generate payloads.
Run powershell shell on windows with defender turns off.

Expected behavior

I would expect the implants to use the highest possible TLS available OR to renegotiate if lower TLS is not available.

Screenshots

Attach files if required

Additional context

Add any other context about the problem here.

@creationstation123 creationstation123 added the bug Something isn't working label Feb 16, 2023
@riskydissonance
Copy link
Collaborator

riskydissonance commented Feb 16, 2023

Hey @creationstation123 thanks for the input, could you try changing this line (you will need to create a new payload), the values you can set are defined here but essentially you want to remove 192 and 768.

I think setting it server-side doesn't work as it can't connect via cloudfront to negotiate the protocol, you have to set it on the side that initiates the connection.

Also you can edit the accepted protocols in cloudfront, have you tried that?

@riskydissonance riskydissonance self-assigned this Feb 16, 2023
@creationstation123
Copy link
Author

creationstation123 commented Feb 16, 2023

Your first suggestion has solved the issue for that specific dropper_cs.exe payload, thanks.

How do I go about changing this for some of the other payloads? For example

https://github.com/nettitude/PoshC2/blob/master/resources/payload-templates/csc.cs uses REPLACEME64 for a base64 string (which must hold some shell code).

Which file inside the project is this REPLACEME being taken from?

@riskydissonance
Copy link
Collaborator

Should just work (for other C# payloads at least), essentially dropper_cs.exe gets patched into the Sharp* shellcode .bin files and they get used in other payloads

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants