Phishing redirectors

Redirectors for C&C servers are commonly known and used to hide C&C servers. We can apply a similar concept to the phishing sites - host all pages used in red team engagement on one server and redirect traffic from multiple redirectors using different domains.

Some benefits:

You can host all your phishing sites on one server and point multiple redirectors with phishing domains to that server. You don’t need to log into each VPS to modify or monitor your phishing site. You can easily configure each system with tools like Ansible.
You can redirect specific URL(s) to phishing tools like Gophish - you have better control over the content than simply pointing users directly to the Gophish WWW server. You can serve different pages depending on the path, hide HTTP headers, etc.
Phished credentials are not stored on AWS/Azure/etc. VPS. You keep everything on your phishing server (on-premise or in a trusted data center). Cloud servers only redirect traffic (using Nginx stream directive), do not keep SSL certificates, or decrypt the data at any point.

Socat redirector(s) and Nginx as a web server hosting websites

It is a pretty simple configuration - we set up a dumb socat redirector passing traffic to our phishing server hosting all websites. socat is running in GNU screen or as a service.

Nginx redirector(s) and second Nginx as a web server hosting websites

Cloud redirector with Nginx configured as stream proxy passing traffic to phishing server. Cloud redirector(s) do not have SSL certificates for a website. Phishing server stores all the data (the cloud provider sees only encrypted traffic). This redirector can also redirect all HTTP traffic to HTTPS.

Redirector configuration

Redirect all HTTP traffic to port 443:

server {
  listen 80;

  return 301 https://$host$request_uri;
}

Stream proxy:

stream {
  server {
    listen 443;
    proxy_pass target.server.com:8443;
  }
}

Phishing server configuration

The server with Nginx installed is hosting all websites. We can set up multiple phishing pages on that machine and manage them easily in one place. SSL certificates for websites are stored here as well.

Define a separate VHost configuration file for each domain, /phishing-url/ is redirected to a tool like Gophish that handles campaign (serves site, counts clicks, etc.)

server {
  listen 8443 ssl;

  ssl_certificate /etc/letsencrypt/archive/YOUR-DOMAIN/fullchain1.pem;
  ssl_certificate_key /etc/letsencrypt/archive/YOUR-DOMAIN/privkey1.pem;

  root /var/www/phishing-site.com;

  server_name phishing-site.com;

  index index.html index.htm;

  access_log /var/log/nginx/access.phishing-site.com.log;
  error_log /var/log/nginx/error.phishing-site.com.log;

  location /phishing-url/ {
    proxy_pass http://127.0.0.1:8888/;

    proxy_hide_header X-Server;

    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Real-IP $remote_addr;
  }
}

Ports that Nginx is listening on should be protected with a firewall and allow only connections from redirector IP addresses. We can do this easily with iptables:

iptables -I INPUT -p tcp --dport 8443 -j REJECT
iptables -I INPUT -p tcp --dport 8443 -s <REDIRECTOR-IP-ADDRESS> -j ACCEPT

Client IP address

The downside of this approach is that we don’t see a client IP address in our webserver logs - it will log the address of the redirector.

To solve this problem, we need to configure Proxy Protocol in Nginx configuration on both redirector and phishing server. By enabling it, the client IP address will be passed from the redirector to the phishing server, then Nginx will re-write the IP of the redirector to the one received in the Proxy Protocol header.

First enable proxy protocol in redirector stream configuration:

stream {
  server {
    listen 443;
    proxy_pass <PHISHING-SERVER-IP>:8443;
    proxy_protocol on;
  }
}

Then add new log format to nginx.conf of phishing server:

log_format proxy '$proxy_protocol_addr - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent"';

Enable proxy protocol on your phishing server virtual host and changelog format:

server {
  listen 8443 ssl proxy_protocol;
  [...]
  access_log /var/log/nginx/access.phishing.domain.com.log proxy;
  [...]
}

Now we should be able to see the client IP address in access.log of our phishing server.

Client-side logging

Another option to resolve that problem can be the usage of an external service like ipifly.org. We can call it from JavaScript and use XHR to pass the received IP address as a parameter back to our website. The downside is that we need to use an external service - a corporate web proxy may block it. There are also privacy considerations - we are passing the client’s IP address to the service provider.

<script type="application/javascript">
function getIP(json) {
var url = window.location 
var url = window.location.protocol + "//" + window.location.host + "/log?" + window.location.search.substr(1) + "&ip=" + json.ip;
Http = new XMLHttpRequest(); Http.open("GET", url); Http.send();
}
</script>
<script type="application/javascript" src="https://api.ipify.org?format=jsonp&callback=getIP"></script>

Now your web server should receive an additional request with a client IP address in the GET parameter.

Summary

Setting up an infrastructure for red team engagement might get complicated, especially when testers need to handle multiple servers for phishing websites, email and command and control infrastructure. Having the ability to manage and monitor every phishing website from single server while still using multiple VPS servers with different domains, IP addresses located across the world can make an engagement a little bit easier.

2021-03-25

infrastructure