VulturSec Web Methodology

Web applications are the core of today’s software.

From webapps in highly scalable AWS environments with multiple microservices running to legacy apps in more traditional infrastructures, the VulturSec team helps to secure data across the world.

We’ve got the knowledge and experience needed to assess any web application and find the highest-risk vulnerability in your code.

In a source code security review, our VulturSec experts will manually analyze your application source code for security flaws, using an hybrid approach including automatic tools to scan the codebase and a deep manual examination to dig deeper and find what others usually don’t find.

While black-box penetration test results can be useful to demonstrate vulnerabilities exposed in any environment, they are not the most effective and efficient way to discover any flaws in an application. It is difficult to reach a 100% coverage of the codebase using only dynamic testing, particularly if many conditions and complex code/communications exist. Meanwhile with a gray-box approach, it is possible to discover vulnerabilities within the application source code that would be missed during a black-box assessment.

Our Web Pentest Methodology

VulturSec team operates under a structured, precise and repeatable methodology. We use this methodology in each assessment to assure our assessments are reliable, reproducible, and state-of-the-art in quality.

We follow these steps:

1 – Define Scope

Before a web application security assessment, we define a clear scope of what to assess. Some of the tasks that our team will execute are the following:

• Determine which applications, domains and environments are going to be scanned/tested.
• Specify if there is going to be any exclusion of pages, subdomains, roles, categories of attacks, etc.
• Decide on the official testing dates and confirm time zones.

2 – Enumeration

At this stage, the VulturSec team uses automated scripts and tools, including other tactics to collect information about our target. This information will be essential for our next exploitation phase:

• Exposed robots.txt files, git repositories, applications container images, etc.
• Previous breached credential on public websites.
• Enumerating directories/subdomains.
• Information leaked by application developers on public documentation.
• PDF, DOCX, XLSX, and other files leaked by Google or any other search engine.
• Verifying all the available cloud services for any possible misconfigurations.
• Correlating known vulnerabilities with the application and relevant services in use.
• Reading the source code manually to find any vulnerability present in it.

3 – Attack Phase

On this phase, our team begins to exploit vulnerabilities found within the webapp on the enumeration phase. At this stage, we may perform attacks such as:

• SQL, NoSQL, LDAP and GraphQL injections.
• Any Cross-Site Scripting categories.
• Employing breached credentials and brute force tools against authorization mechanisms.
• Monitoring web app functionality for insecure protocols, functions and components.
• Review any third-party dependences that could compromise our customer’s application security.
• Server Side Request Forgery (SSRF) vulnerabilities to communicate the external attacker with internal-network-only available sensitive services.
• Logging and Monitoring vulnerabilities affecting future forensic capabilities.
• All the OWASP Top 10 vulnerabilities that were not mentioned before.

4 – Reporting

Reporting is the final phase of our assessment process. During this process, our VulturSec consultants gather all the obtained information and provide the customer with a comprehensive detailed-oriented description of any findings found. The report begins with a high-level breakdown of the overall risk about each issue found, after that, we break down each vulnerability in technical detail, including remediation steps recommendations for the development team to help them in the remediation process. Easy to read, detailed, executive-level and technical-level explained.

5 – Remediation Testing

Additionally, if the customer request it, we can shedule a re-test after the customer has patched the vulnerabilities. We will make sure that the changes were implemented properly, and the risk has been eliminated.