¿Por qué la víctima es un servidor en lugar de un cliente?

No hay "reglas" difíciles de establecer cuando se crea una herramienta de acceso remoto. Depende del objetivo y el tipo de máquina víctima que desee controlar. Los diferentes tipos de arquitecturas tienen mucho que ver con NAT .

C2 Client - Victim Server

Este es el caso que se muestra en su diagrama. El C2 inicia la sesión llegando al servidor de la víctima. El servidor de la víctima debe tener una dirección IP enrutable públicamente y tener un puerto abierto para permitir las conexiones entrantes.

Las implementaciones de Cleaver requieren un tipo de puerto golpeando . De cualquier manera, el cliente (C2) está detrás de NAT e inicia la comunicación con el servidor (víctima).

Servidor C2 - Cliente víctima

Esto podría ser lo que la mayoría de la gente piensa cuando piensa en las RAT. Hay un servidor C2 que escucha las conexiones entrantes de los robots víctimas. La mayoría de los informes de malware que encuentre se referirán a algoritmos para producir direcciones dinámicas de servidor C2. Estos tipos de malware utilizan este tipo de arquitectura.

¿Por qué uno sobre el otro?

Bueno, el objetivo dictará la arquitectura que se elegirá. Si envías un montón de correos electrónicos de phishing y esperas a que las víctimas se conecten; Usted querrá un servidor C2 y cliente víctima. Sin embargo, si desea una puerta trasera en una organización, un servidor víctima y un cliente C2 significarán que los cambios en las reglas del cortafuegos, la arquitectura de la red interna, los restablecimientos de contraseñas, etc. no cerrarán su conexión, permitiéndole una puerta trasera persistente.

    

Esto tiene que ver con los roles de todos los involucrados. Si estás navegando en un sitio web o comprando un panecillo de ese café que conoces, el resultado es el mismo.

El servidor no es el dispositivo más poderoso, es el único que "sirve" las solicitudes. El cliente es solo eso, el que hace las solicitudes que deben ser atendidas. Usted es el cliente cuando solicita un muffin, un sitio web o, en este caso, acceso remoto.

Como cliente, pregunta "mueva el mouse aquí", "ábralo para mí" y "¿qué ve ahora?". Luego, el servidor le sirve al enviar lo que solicitó. Esta es la relación en todas las aplicaciones RAT.

    

No es mejor ni peor, depende de si las máquinas que comprometerá tendrán IP enrutables públicamente o no.

Si lo tienen, entonces la ventaja de que escuchen y sean el servidor es que puede conectarse a ellos desde cualquier lugar y su controlador / comando y computadora de control no necesitan estar siempre conectados a ellos: solo les habla cuando hay un comando real.

Si las computadoras de destino no tienen una IP enrutable públicamente, como la mayoría de las computadoras domésticas (están detrás de un NAT), es mejor que su computadora controladora sea el servidor y las máquinas comprometidas para conectarse a ella. sin embargo, eso tiene la desventaja de ser menos astuto (es más probable que se note una conexión saliente y permanente que una conexión entrante rara como en el primer escenario) y su computadora controladora debe estar siempre accesible a la misma IP, si de repente cambios, y no tiene forma de volver a la antigua IP para recuperar el control de sus bots y decirles la nueva IP, luego perdió sus bots a menos que tenga otra forma de contactarlos.

Sin embargo, personalmente recomiendo usar un protocolo P2P para esto, similar a Tor, donde los robots están interconectados y se retransmiten los comandos a sí mismos, de esa manera no tienes un punto central de falla y solo necesitas llegar a un solo robot para controla la botnet completa, ya que transmitirá tu comando a todos los demás. Asegúrate de usar firmas, criptografía y esteganografía, si es posible, para ocultar tu tráfico y evitar que alguien (como investigadores de seguridad) falsifique comandos válidos y tome el control de tu botnet.