-
Notifications
You must be signed in to change notification settings - Fork 13
/
architecture.txt
54 lines (36 loc) · 3.03 KB
/
architecture.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
#############
Architecture
#############
PoshC2 consists of a **C2 Server** process that listens for connections from implants and provides a log for task output, new implants, messages and so on, and one or more **Implant-Handler** processes that are used to issue commands to the C2 Server and Implants.
The files responsible for running PoshC2 are stored in `/opt/PoshC2` by default, and project specific files such as the configuration file, logs, generated payloads and (if using SQLite) a local database are stored in the project directory in `/var/poshc2/<project name>`.
The database is used to store and log data and facilitates communication between the two processes. For example, every task that is issued to an implant from an Implant-Handler is stored in this database with a timestamp, the user who ran the command, the implant details and more.
Tasks are then picked up from the database by the C2 Server process and issued to Implants when they check in, ensuring that no tasks go unlogged.
.. image:: ./processes.png
:width: 435
:align: center
The Implant Handler writes tasks to the database which are picked up and updated by the C2 Server.
It is recommended to use a C2 Proxy to maintain operational security by proxying all traffic to the C2 Server. A simple VPS running Apache can be stood up and **mod_rewrite** used to silently redirect traffic from the proxy to the C2 Server without the client knowing, allowing the red team to keep their C2 infrastructure hidden and allowing flexibility should the proxy IP be compromised.
A typical example could look like this:
.. image:: ./proxy.png
:width: 777
:align: center
See the Apache page for more details.
***************
Domain Fronting
***************
PoshC2 can also use `Domain Fronting <https://en.wikipedia.org/wiki/Domain_fronting>`_ for C2 communication.
Domain Fronting provides multiple additional benefits, such as:
* Outbound C2 traffic is in requests made to a legitimate website.
* That website's domain reputation is what is checked by the target.
* Domain Fronting cannot feasibly be detected unless SSL Inspection is in place.
* Additional layers of security are added between the target and the C2 server.
The way we perform domain fronting in PoshC2 is by adding the Host header to the web requests made by the C2 traffic.
.. image:: ./domainfronting.png
:width: 1256
:align: center
To configure PoshC2 to use Domain Fronting, when editing the configuration ensure the **PayloadCommsHost** parameter points at the site being initially connected to by the target, i.e. the Domain Frontable site.
The **DomainFrontHeader** parameter should then have the value of the CDN endpoint that will go in the HTTP Host header. This value should be the domain name only.
.. code-block:: python
PayloadCommsHost = "https://frontable.com"
DomainFrontHeader = "endpoint.cdn.com"
Note that the host must have .NET v4.0.30319 installed and available to the Implant process. **If this is not the case, the implant will fall back to a direct connection to the CDN endpoint.**