Find the spot where they are blind and bypass Access Denied

A casual routine for opening a website for paying bills turned into an issue. We were stuck at the screen displaying that access to this website denied. The matter was urgent as there was brief time before the payment was due. Skipping the whole thing was not an option at all. With ticking clocks, the show began.

The task at glance seemed to be straightforward as there was an assumption about how the blocking happens. Knowing this, it would be easier to develop the mechanics of bypassing it. However, next steps show that it is not that trivial and would take more time than expected to address it and get a solution.

Second thought was that by digging deeper, we would extract valuable knowledge that would allow us to use it in different situations. When travelling often, conducting research, or visiting non-usual places, we saw that there were various digital walls there, preventing us from getting to access the services we need.

Sad truth, the world is shrinking slowly in multiple dimensions. Think of it as you on the piece of ice that is constantly melting. If you cannot swim, jump or stop melting – you done. We do not see these changes as they happen slowly. Being prepared means looking into the future, developing plans, making next move.

Practically speaking, it is matter of fact that it is getting harder to get a piece of data, especially when you need it most. You must register, go through KYC, provide extra information, then there could be explicit or implicit discrimination. And at the end of the day, you find yourself competing with giants.

The only one advantage that we have and will use is agility. An ability to learn fast, process and apply information, create a unique way to overcome, avoid, or remove the obstacles even before they appear. The case was a perfect exercise to train in a situation where you`re completely blocked by the system.

First thought was to review the distinct parts of the website to see if only this page is blocked by admins. Adding a simple keyword and the name of the website furnished us with variety of options. The hope was to find the part or module that was not blocking us from letting in. All the URLs provided the same output:

Just to make sure we are not getting any black mark on us to carry we checked the cookies, didn’t find anything unusual, but deleted them just in case. Other items, such as local storage or cache were empty. Network tab didn’t contain useful data either. The moment we hit the URL address we are being blocked.

There were couple of VPN servers for disposal. We tried all of them but with the same luck – regardless of the country, or protocol, there was the same outcome. Somehow, the recipient part was detecting certain things on our side that would make them shut down connections immediately. We decided to dig deeper.

The clocks keep ticking. We produced few more assumptions. Main one – it is not a direct IP address that is not accepted but could be something else. Either certain property, or something that would expose the real location of our host and put connections to ban. Alternatively, it could be a combination of few items.

From another point of view, there could be a system, which goal was not to prevent users visiting a website, but, for instance, fighting with DDoS attack or detecting malicious activity. Assuming that this is the case we skipped the idea of getting few more VPS servers – their IP addresses ranges could be in the stop-list.

Going over the list of other dimensions, we discovered that there could be a thing called DNS leakage. It happens when DNS queries from your browser – the requests your device makes to translate domain names into IP addresses – escape the secure tunnel you expect them to use, for example, a VPN.

Even if your web traffic is encrypted, leaked DNS queries reveal which sites you are visiting because they still go to an outside resolver such as your Internet Service Provider – ISP. That visibility defeats the primary privacy guarantee of a tunneling tool and can expose you to logging, filtering, or surveillance.

Common causes include misconfigured VPN clients, operating systems that prefer local or IPv6 resolution paths, and browsers that implement alternative methods outside the tunnel. Detection is straightforward: run a DNS leak test from inside the tunnel and compare the resolver IPs to the VPN. Look for mismatches.

Passing this test did not bring any positive outcome. Next item in the list was WebRTC leakage. It occurs when a browser exposes your real IP address through its real-time communication features. The WebRTC API allows direct peer-to-peer connections for things such as voice, video, and data transfer.

It is bypassing intermediaries for speed and latency. However, in doing so, the browser must query local and public network interfaces – revealing network details even when a VPN is active. Imagine you told everyone to be quiet while hiding, but there is one guy who turned the lights on revealing the entire group.

A simple JavaScript running on a website can trigger these WebRTC requests and capture the true IP address assigned by your ISP. This undermines anonymity: a tracking script, advertising network, or corporate filter can correlate your VPN session with your identity or location. Hence, it should be blocked.

Preventing such leaks involves disabling WebRTC entirely or restricting its behavior. Firefox allows manual deactivation through the about:config page, while Chromium-based browsers require extensions like WebRTC Network Limiter or WebRTC Control. It has true states and could be enabled for such operations.

Disabling these two would not crack the case, as it seemed that our location still would matter. We investigated residential proxies – they route your web requests through IP addresses assigned to home users by ISPs. Because those IPs look like regular consumer traffic, websites treat them as real visitors.

That makes residential proxies useful for geo-testing, ad verification, retail price scraping, and managing multiple accounts with lower detection risk. Still, residential proxies have notable downsides. They are costlier than data-centre proxies, slower, ethically questionable, depending on how the IP pool is sourced.

Some networks rely on users who voluntarily share their connections, while others have exploited compromised devices. This uncertainty creates privacy or legal risks, as control over endpoints can’t be verified. Residential proxies should be used cautiously, never for sensitive information, authentication data.

There were couple of candidates to pick from. For the sake of speed, we choose the one that would not need any of the KYC, as the process may take longer and did not have the block list of domains that cannot be used for scrapping. But to make sure we are playing on the right ethical side, we picked the legit one.

To make sure the key works, we quickly checked it via curl through command line. What it does is to connect to the host using credentials and then send a request. We checked that this thing could see our proxy address and hence get the data from ipify.org. It returned the proper value meaning the server is on:

Next step was to curl the data from the source without using browser just for a quick check. This would help us to see the raw responses and debug, if needed. It was successful as the webserver returned the code 200 and the body of basic HTML which had normal content, and nothing more about denied access:

Now, it was time to prepare the browser. As our Chrome already has an RTC blocker, we installed an additional extension called Foxy Proxy to route all the traffic through the SOCKS connection and bring us what we need. It has multiple settings allowing granular filtering, so we decided to keep it in a default state.

First attempt failed though, as we realized that proxy itself would also ignore connections from certain IP addresses. Enabling VPN in a proper location solved the issue. The final chain of nodes looked like this: Host machine in incognito mode -> VPN -> Proxy Server with 30 min rotating window -> Targeted website.

At last, we were able to open the URL with no issues and made payment on time. As a matter of precaution, a new virtual card was issued from Revolut. The reason is that proxy, provider, or VPN server gets compromised. This is a common thing with long chains – every single node could be a point of attack.

There was another type that we wanted highlight: mobile proxies. They route traffic through IP addresses assigned to real devices. Each one tied to a network, regularly rotating addresses, making detection almost impossible. Websites see this traffic as coming from genuine phones, giving it the highest trust level.

Worth mentioning, we contemplated using built-in anonymized browsers. It is like a window that would put you in somewhere else, allowing you to enter URL and see its contents. This did not work either because an IP address was incorrect or the things like User Agent, version number, or anything else were wrong.

If someone wants to build a more sophisticated tracking, it is doable. While we think that our address is only thing to hide, there is more. Building a digital footprint for users and legitimately sharing it with big institutions or corporations is something that is already not part of the anti-utopia books. It exists already.

Learning lessons, there are always multiple things to carefully consider if you are hitting the wall. Understanding how things work helps to accomplish the task with minimum efforts. However, this is a non-ending process because nothing is static. But what it only means that you should think of tomorrow today.