Giters

nettitude / PoshC2

A proxy aware C2 framework used to aid red teamers with post-exploitation and lateral movement.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[BUG] stager retry-timeouts [ CSharp dropper does not exit() after exceeding retry condition ]

polarlotus opened this issue · comments

commented

Description

The newly implemented "stager retry" functionality works and as expected, EXCEPT that the dropper process should die if the stager timeouts are exceeded as defined in the config.yml configuration file.

Prior versions such as 7.0, did not have easily configurable timeouts, but did exit "eventually" after 25 minutes of no C2 response at startup.
This does not effect C2 / turtle timeouts which is after stage initialisation. This is purely startup timeouts.

Execution Environment:

All of this must be filled in

Data Value
Full Posh version (all the text between the === at the top of the Implant Handler) PoshC2 v7.1.0 (39c4727 2020-12-01 14:40:06)
OS & version Debian 5.9.6
Using Docker/containerisation? No

Implant Info

  • What implant does the problem occur on? PowerShell/C#/Python
    C#

  • How was the implant created? Running a default payload? Inject-shellcode? Custom payload?
    EXE, DLL, shellcode same behaviour.

Defensive Technologies

  • Is the target environment running any particular defensive products? AVs/EDRs etc?
    None

To Reproduce

Steps to reproduce the behavior:

  1. Generate standard Csharp dropper payload with desired timeouts.

    Example:
    PayloadStageRetries: false
    PayloadStageRetriesInitialWait: 5
    PayloadStageRetriesLimit: 1

  2. DON'T start the Posh server.

  3. Execute the payload on target and observe the packets in Wireshark.

  4. Observe the payload in task manager. Wait for exit.

Expected behaviour

The stager process should exit() if the startup timeout values in the config.yml are exceeded.

Screenshots

N/A

Attach files if required

N/A

Additional context

N/A

commented

So I just tested the timeout and reduced the times slightly and the limit to 3 but it did three attempts then when to the end

image

commented

Are these limits not bound to the "new" configurable stager limits? Anyhow, the "process" should die after timeouts are exceeded. Unless i'm misunderstanding you here.

commented

image

Thats the code for the C++ dropper - it remains open

commented

Thanks for the feedback, i somehow missed the C++ aspect in the payloads starting with the name "Sharp" and "Posh" - Now the behaviour is indeed as expected and this non-bug can be closed.