In the third part of our “Reports from the Field” series, we’ll explore how attackers utilize all tools available (including open source) to dig for an exploit.
URLHunter Exposes VPN Credentials Used to Gain Access
The quick take: Attackers leverage every resource they can find, including open-source URL shortening tools.
The full story: While conducting some research on URL shortening services, one of our analysts came across a tool called URLHunter. This publicly available open-source tool allows users to automate the download and search of large indexes of shortened URLs and their fully resolved counterparts (i.e., bit.ly/BF -> https://www.bishopfox.com).
The nitty gritty: After mass collection and careful review, our team quickly realized that they were in possession of VPN configuration profiles generated by an employee of a large financial firm. These VPN profiles contained user email addresses and passwords as well as the certificate needed to authenticate with the organization’s VPN server. Privileged access was achieved by chaining this new information exposure with comprehensive knowledge of the company's attack surface. Low or informational risk exposures can offer key missing pieces when combined with other, higher-severity exposures – and together can result in a critical vulnerability.
With access to VPN user profiles, the case was turned over to our expert testers for further investigation. They quickly determined a set of active user accounts and gained access to the internal company network without much effort. Using each active account, VPN access levels were determined for each of the user profiles.
The power of social media: Looking for the highest level of access on the internal network, our teams scraped LinkedIn profiles of users and tried making educated guesses on the level of access each user may have been given based on their job title and role. Upon completion, the team had found less than a handful of profiles with unlimited access to the organization’s internal network via this VPN connection.
The microservice map: Once on the VPN, the team had access to multiple subnets on the internal network. Based on the subnet sizing, the team determined it would be infeasible to visit every IP and every open port to discover what was available to them internally. However, a quick ping scan on one of the subnets revealed a service discovery endpoint – which listed every other microservice in the internal network. This service acted like a map for our team for the rest of the investigation.
The keys to the infrastructure kingdom: During the post-exploitation phase one of the teams identified an outdated Elasticsearch instance against which they were able to achieve remote code execution on the service’s host. At that point, the testers retrieved AWS credentials from the service’s metadata endpoint as well as an SSH deploy key with read/write access to deployment scripts.
Using the SSH key obtained from the previous step, the team was also able to fetch a repository that contained deployment scripts for the organization’s entire infrastructure including their development and production environments. To validate the severity of their discovery, our team communicated their findings with the customer who responded back with surprise at how much information we were able to obtain.
Bottom line: Our customer commended our efforts and said we’d achieved a “full compromise of their environment.” For an offensive security team, compromise is always the goal.
More tools doesn’t mean better intel.
Anyone who’s worked in security knows that tools add noise – data that can distract a security team from what really matters. If you have various tools scanning your attack surface and a bug bounty program hacking away at your perimeter, your security team is likely stuck manually sifting through reports to prioritize which mitigations make the biggest impact for risk reduction. What’s more, many tools offer conflicting data or remediation guidance, so most teams end up just ignoring it all to fight other fires rather than try to sort out the conflicts. Low-level issues that lead to bigger critical risks – like the presence of a .git/config file – are missed by most scanning tools (since they aren’t seen as a vulnerability). At the end of the day, we recommend augmenting tools with human expertise for the true picture of your attack surface.
To see all of our real-world examples, read parts one and two:
Subscribe to Bishop Fox's Security Blog
Be first to learn about latest tools, advisories, and findings.
Thank You! You have been subscribed.