Home internet traffic being traced on AWS?

[lindros2]

Just noticed this yesterday.
Within minutes of going to my control panel or statistics, an AWS address goes to the same place. Does not login (see: 401 status code). Hosting provider doesn't have an answer.
Anyone here?

Note that this is browser- and OS-independent, so it's got to be at my ISP, I would think?
AWS addresses are all over the place - 54.89.233.121, 3.87.216.214, 54.200.79.41, 100.26.205.197, 52.55.25.166, 34.222.242.198.

 

[neg7]

I've been seeing the same pattern for several internet-facing services for the last 3 weeks. A random IP from AWS tries to access the same URL that was requested by a legitimate user (the URLs have unique IDs so we can trace them well). The IPs are different for every request, but the User-Agent is always the same for us. Do you know the UA specified in your "follow-up" HTTP requests?

 

[MichaelCG]

What are you trying to prove? What port are the connections on? Are you watching your DNS requests? Is this a request from your network out to AWS? Or is this AWS trying to connect to your network? Gobs and gobs of services are hosted within AWS by many different companies.

 

[lindros2]

@neg7 - UA for follow-up requests is generic/fabricated:

Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.109 Safari/537.36

 

[neg7]

@lindros2 That's exactly the same UA I'm seeing. These secondary requests started ~Mar 20, and happen at the same time interval - 30 seconds-10 minutes after the original request, as secondary HTTP call comes from that UA, always from AWS IPs, and ver rarely from these same IP. We collected ~50 IPs, and many of them had already been reported on https://www.abuseipdb.com by the time we see them in our logs. In our case, we generate unique URLs for users, and these URLs are short-lived, so the only way replaying makes sense is if the user agent is leaking the URLs somehow. Is there any chance you might have a compromised browser extension installed or something else that could be snooping on your URLs?

 

[lindros2]

@lindros2 That's exactly the same UA I'm seeing. These secondary requests started ~Mar 20, and happen at the same time interval - 30 seconds-10 minutes after the original request, as secondary HTTP call comes from that UA, always from AWS IPs, and ver rarely from these same IP. We collected ~50 IPs, and many of them had already been reported on https://www.abuseipdb.com by the time we see them in our logs. In our case, we generate unique URLs for users, and these URLs are short-lived, so the only way replaying makes sense is if the user agent is leaking the URLs somehow. Is there any chance you might have a compromised browser extension installed or something else that could be snooping on your URLs?

No. It spans devices, and browsers.
It's my belief AT&T security is capturing this data through their tools, using AWS-hosted apps.
If clients go to VPN or cellular data, it stops.
I'd say "the IP must be flagged", and AT&T refuses to release IP's for Fiber customers.

 

[neg7]

No. It spans devices, and browsers.
It's my belief AT&T security is capturing this data through their tools, using AWS-hosted apps.
If clients go to VPN or cellular data, it stops.
I'd say "the IP must be flagged", and AT&T refuses to release IP's for Fiber customers.

We've seen the same pattern happen for enterprise users connecting over a VPN (in this case ZScaler) based in several countries. It's random, and only for some users, but not constrained to AT&T. One interesting point is that these tracing connections never include any cookies or headers from the original request, so this is not a traditional MITM vector. That is, whatever is doing this is not trying to hijack the user session, and probably doesn't have access to HTTP headers in the request, but only the URL.

From the users' point of view, what would make sense is if the web service is compromised, for exampling leaking out HTTP access logs to a 3rd party, and this 3rd party is trying to replay URLs from access logs. As a service provider with an aggressive infosec stance, we triple-checked every layer in the stack and rebuilt our entire infrastructure from scratch within a new cloud account, and these tracing requests still show up. All our users connect over TLS (rules out most MITM), using current versions of Chrome/Firefox (rules out insecure clients and most extensions), they connect from different parts of the world (rules out ISP-level issues), and sometimes over VPN. We're actively investigating this and figuring out how to setup honeypots, but I haven't been able to find much intel on this online.