Freaked out by "impossible click" in logs

Question

I was staging an isolated production environment and accessing it's remote PHP script from my local mac on http://example.com/XbAM7Kt7SJj3M8ytJfEQZbwcBLzg0gNWGfyCHL2b0f0

I saw my click in the log as follows:

{
  "id":"XbAM7Kt7SJj3M8ytJfEQZbwcBLzg0gNWGfyCHL2b0f0",
  "timestamp":1535672410,
  "ip_address":"MY.IP.AD.DR",
  "user_agent":"Mozilla\/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/68.0.3440.106 Safari\/537.36",
  "referer":null,
  "parameter":"XXX"
}

And I couldn't believe my eyes when I saw the following in the next line of the log:

{
  "id":"XbAM7Kt7SJj3M8ytJfEQZbwcBLzg0gNWGfyCHL2b0f0",
  "timestamp":1535672411,
  "ip_address":"159.203.81.ADDR",
  "user_agent":"Mozilla\/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko\/20100101 Firefox\/33.0",
  "referer":"83.222.249.ADDR",
  "parameter":"XXX"
}

Just one second later (see "timestamp"), there was a Click from a Digital Ocean IP "159.203.81.ADDR" using a fake user agent and fake referer, with the same exact GET parameter ("XXX"). There is no way on earth that they could have known about the ID "XbAM7Kt7SJj3M8ytJfEQZbwcBLzg0gNWGfyCHL2b0f0" which my local machine generated randomly just a few minutes earlier.

I assume that this means that my local network is somehow compromised? My network activity is being sniffed by Malware and since the request was non-HTTPS the malware was able to replicate it in order to spy for sensitive information?

I have scanned my local mac for Malware using ClamAV and Malwarebytes, both didn't find a single thing. How can I get to the bottom of this? Could it be that my home router is infected with malware?

I'm not sure if this is relevant, but as of recently I have experienced wired things on my mac and mobile devices. For example when surfing random websites, I sometimes suddenly get redirected to a scam ad website ("Congratulations you have won, please enter your information..."). I took a screenshot of one of those on my mobile device: https://i.stack.imgur.com/WaRn8.jpg

Answer 1

We've seen behaviour like this on our servers (some years ago): some automated process attempted to replay each request made by a logged in user.

In our case the service required TLS for the login-pages, but allowed logged-in users to continue their session on non-HTTPS pages. However, the session identifier changed on every request, while used session identifiers remained valid for some seconds after the first time they were sent back to the server (to mitigate latency problems).

When the pattern you describe was noticed, we did some investigating on who or what was the source of the repeat request. When we lowered the invalidation timeout for re-used session identifiers, it quickly became clear that all requests for certain users were repeated, but that the pattern only came up for a distinct subset of users.

It turned out that the common factor for this distinct subset of users was that they all were in China. We assumed it was a feature of China's great firewall, switched the whole service to (mandatory) HTTPS and the repeat requests stopped.

So, long story short, since you're connecting to your remote PHP-script over a non-TLS connection, anyone, including many automated processes, could be listing in on your request. This could be nefarious, but could just as easily be a security feature (such as anti-malware detection, etc.) somewhere.

Switch to HTTPS and see if it continues. If it stops, you solved the issue. If it continues, your requests are being intercepted at one of your endpoints (your server or your local machine).

Answer 2

It might be some security software on your system or in your network which inspects if the URL's you visit are harmful. They often do their visits from systems which are not obviously associated with security companies, since attackers often try to serve innocent content if they detect a bot from a security company. Thus, instead of trying to find any malware, try to disable all security software on your system or inside your network and see if the problem vanishes.

Answer 3

There may be several causes to this. The most likely from my perspective is some form of malware but it is not necessarily on your mac.

One of the major problems with malware is: Even if you manage to detect one infected file (or one instance of the malware), deleting or destroying it won't necessarily remove the source of the malicious activity. It might just be a child file. So maybe you were infected with something, maybe your mobile devices were infected or also infected and maybe its additionally or just your router.

So here comes the sad truth: Without resetting your whole device(s) there is little chance you will get rid of this. If you have an old or badly maintained router (concerning updates and security) maybe you will have to reset that as well. If you want to take a deep dive into forensics I can also recommend you not to do this on your live systems depending on if you want to use them in other ways as well. Sorry to bring bad news.

Answer 4

Did you notice this fact?

Did you firewall and restrict your staging environment. If not the contract and NDA you may have signed with your enterprise is now null and void or they might file a law suit against you if someone else had access to your staging environment which generally has business secrets. These are the implications you run into without hiring or seeking professional security service.

If you are as skilled in appsec as I am pretty much with my experience as a security engineer. Staging environments should always be using TLS protocol as well as be firewalled, use iptables and only allow certain subnets belonging to your corporate intranet or VPN to access this staging instance.

Did you implement Basic Auth or firewall your staging instance or atleast did you use TLS while communicating with that staging instance?

yes/no?

The core problem

I am damn sure you weren't using a corporate VPN and not restricting access to staging instance by IP. First point to note.

Second, TLS protocol not implemented leading to interception of network requests.