nginx WebSocket proxying — payload detection

Proxying WebSocket nginx — payload detection 👀

Checking configurations of various services sometimes helps find unknown malware that is not detected by antivirus and other security tools.

❗️ For example, in one case we found traces of an attacker’s presence in a system by examining the nginx web server configuration.

In the configuration file /etc/nginx/webserver/server.conf.d/payload.conf of the target server, certain lines raised our suspicion.

location /ws/b3a4d3a2 {
  proxy_http_version 1.1;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection "upgrade";
  proxy_set_header Host               $host;
  proxy_set_header X-Forwarded-For    $remote_addr;
  access_log    off;
  log_not_found off;
  proxy_pass http://unix:/var/run/shm/evil.sock;
}

These lines use the protocol upgrade mechanism. Starting from version 1.3.13, nginx implements an operating mode that allows creating a tunnel between the client and the proxied server — WebSocket proxying.

WebSocket proxying is activated when the server receives an Upgrade header from the client in the request.

A specific feature of this mode is the presence of the following lines in the configuration file:

 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection "upgrade";
 proxy_pass http://unix:/var/run/shm/evil.sock;

The proxy_set_header lines are used to explicitly forward the Upgrade header from the nginx web server to the proxied server. Their presence in the configuration file is due to the fact that this header belongs to the category of hop-by-hop headers, which are not forwarded by proxy servers.

The proxy_pass line contains the path to the socket file on the target system — /var/run/shm/evil.sock.

To obtain information about the process using the specified socket, we used the lsof command:

lsof | grep /var/run/shm/evil.sock

And we found a process with PID 18653:

payload      18653              root    4u     unix 0xffff74146a3b3743       0t0   25637138 /var/run/shm/evil.sock

Next, we found the executable file of the process:

lsof -p 18653 | grep cwd

The file was located in /usr/bin/, and it turned out to be a backdoor.

💡 What we can do now:

• catch WebSocket in traffic;
• look for activities in systems around the time of the backdoor deployment (backdoor creation date or nginx config modification);
• check other web servers in the infrastructure for “extended functionality” of your services.

#tip #detect #hunt #dfir
@ptescalator