Example essay

GUEST ESSAY: Threat Actors Use Effective Tactics to Probe and Compromise Vulnerable Networks

When new vulnerabilities are announced or flaws are discovered in public or “off the shelf” applications, several things happen. Word of the risks spreads as attackers and security professionals begin to seek out potential attack targets with the aim of exploiting or protecting them.

Related: How GraphQLs widened the attack surface.

When Log4Shell first hit the streets, we immediately saw attacks against almost every one of our customers.

When attackers started looking for targets, our research team redirected their techniques, resulting in a tool we used to help our customers find vulnerable API endpoints. This had some interesting results, so let’s take a look at several different aspects of modern apps, as well as what can be found by snooping around a large company.

Finding Viable Targets

When an attacker crawls a domain, the first thing they want to do is find as much information about it as possible. This often means inferring that something is available and testing it. As the list of possible targets within an organization grows, it becomes necessary to eliminate false positives, false negatives, and possible flaws in the inference engine.

Standard items, such as login endpoints, are easy to find because the request for any resource that requires authentication is going to be redirected to the login page. Redirecting apps will only advance recognition so far. In order to hit defaults, like GraphQL endpoints and pages, the scanner needs to search for them.

Likewise, API specification documents and third-party APIs are great targets because they offer rich data sets. Here is a breakdown of attack targets:


Connection endpoints. Often, these endpoints not only accept authentication credentials, but also help unauthenticated people by displaying the data that needs to be collected. Asking for anything that needs to be authenticated usually redirects to the authentication page, allowing an attacker to probe that service.

GraphQL Pages. Showing data from JavaScript large object notation, or JSON object, is something that can be scanned. JSON refers to a file formatting standard used primarily to transmit data between a web server and a web application.

Scanners looking for these endpoints often seek to extract data from a target by exploiting the very nature of “quick data display” that GraphQL is built around.

API specification documents. As more and more organizations write API specifications, they often upload them to the Internet to enable sharing with trusted parties. These documents can be very dangerous in the wrong hands. Think of this as a map of each API URL as well as whether or not the communication should contain certain data or authorization keys.

Leaky third-party APIs. Many applications are built with APIs specific to what their companies do – especially those built on top of a third-party framework such as health status endpoints that can tell an attacker that the service exists and is up. line. Default pages are often scattered in ready-to-use application packages. Just knowing what those endpoints are often yields great results.

For example, some domain search results gave me a common endpoint that returned an HTTP response code of 200. In the parlance of web attackers, that endpoint was online and responding.

Opening the endpoint communication, I realized that I was dealing with the corporate webmail API. The messaging service they use is a third-party service with an open API. In the mind of a striker, it’s interesting.

Recognize attack vectors

When something is interesting, the attacker can spend a few minutes tinkering with that discovery or spend the next month unlocking its secrets. If the target is large enough and the report is rich enough, it’s worth it. Mainly, I want the API to show me what I need to make it work.

Post-recognition means an attacker is onto something, which could be unimportant or it could mean they are ready for a vicious attack. The things that fuel the offense come from deep reconnaissance and the attackers have plenty of time. How do we defend our APIs against these attacks?

Discovering what is within our perimeter by acting as an attacker, programmatically, allows us to understand what is announced to the outside world. Once we have a good inventory, it is important to test server and application framework vulnerabilities and this will keep attackers in the reconnaissance phase much longer.

About the essayist: Jason Kent is a Hacker-in-Residence at security sequencean application security provider based in Sunnyvale, California.

*** This is a syndicated blog from the Security Bloggers Network of The Last Watchdog written by bacohido. Read the original post at: https://www.lastwatchdog.com/guest-essay-successful-tactics-threat-actors-leverage-to-probe-compromised-vulnerable-networks/

Source link