Wasting Time Watching Nginx Logs

Wasting Time Watching Nginx Logs

This is going to be a short post just relfecting on one of my favourite hobbies - watching server logs.

This post isn’t supposed to be a great revelation or even something new, but rather just to detail how I spend my free time as I seemingly make a slow transition from a red teamer to a site reliability engineer lol.

Hunting Malicious Activity

When I started in security and, more generally, when Istarted to serve things (like C2) from servers, like Apache and Nginx, I had little to no desire to look at server logs, accept to ensure that mod rules were working correctly. Looking at logs feels “blue”, by which I mean blue team-y - it also made me blue (as in, it was depressing to sit there reading through boring log lines when I could be enumerating machines and watching my implants pour in).

But a careful analyssis of Nginx logs for something you are serving to the public internet is pretty interesting. You get to see what is scanning you, how often, what it scans for. You also see all sorts of malicious activity coming through, probably automated, and the IPs that this activity comes from is interesting from a threat monitoring perspective.

In fact, the more I look at logs for things I am serving publicly (not just C2 redirectors, but websites - like this one), the more I realise how much like a honeypot these public servers are. Automatic scanners are constantly proding for potential vulnerabilities.

Take the below screencap from a log out on server I am running:

This output is really interesting, and I immediately noticed it. The reason I noticed it is that it seemed to me to be an injection attack of some sort. Notice the cmd parameter in the second line - this is a huge give-a-way that the request is attempting to leverage a vulnerabiltiy that injects a system command that gets passed to the server.

I did a bit of research and, according to the Internet Storm Center (https://isc.sans.edu/diary/0) this command injection seems to be related to an exploitable vulnerability in D-link NAS devices. The ISC site provides the following example request with payload:

GET /cgi-bin/nas_sharing.cgi?user=messagebus&passwd=&cmd=15 system=<BASE64_ENCODED_COMMAND_TO_BE_EXECUTED>

After looking at this, I wanted to confirm, so I followed up with a little searching around for the IP the rslowlyequest cam from (103.245.236.120), and the IP is based in Vietnam, and many of the comments show the same or similar payloads. In the below screencap, I have highlighted someone’s report that this was targeting the D-link NAS device:

From Abuseipdb

In addition to this, Alienvault also showed that this IP attempted exploits againt a honeypot server:

Stopping undesirables at the door

So now that we have confirmed a malicious actor, we can go ahead and use an nginx rule to deny access to this IP in the future (of course, you can also use firewalls).

To do this we simply add a couple if lines to the server block under

/etc/nginx/sites-available/<YOU-SITE-FILE>

That deny rule looks like this:

Anyway, I hope you enjoyed reading how I spend my free time googling IP addresses and treating my public servers like honeypots.