Many penetration testing providers deliver clean reports, well-structured findings, and clear risk classifications. Yet they often fail to answer the one question that actually matters. What happens when an attacker does not stop after the first vulnerability? This is exactly where Exfilion positions itself.
Exfilio is a specialized offensive security boutique focused on exploit development, red teaming, and deep technical penetration testing. The approach is built on a simple premise. Security must withstand real attacks. That means no checklists, no automated scans, and no generic reporting.
Every engagement is performed manually, with precision, creativity, and the mindset of a real attacker. The goal is not theoretical risk assessment, but practical validation. What can actually be exploited? How far can an attacker really go?
Exfilion simulates real threat actors across the entire kill chain. From initial access and privilege escalation to full compromise. The focus is not on isolated vulnerabilities, but on how systems, processes, and people interact under attack conditions.
The difference lies in depth. Vulnerabilities are not just identified, but actively exploited. Where necessary, functional exploits are developed. Security controls are not only assessed, but deliberately bypassed. The result is not abstract risk, but clear evidence of what is truly possible.
The service portfolio reflects this approach:
Elite Penetration Testing Focused engagements on clearly defined targets with maximum technical depth and emphasis on real exploitability.
Red Team Assessments Realistic attack simulations against the entire environment, including technical systems, physical security, and the human factor.
Exploit Development Development of reliable, reproducible exploits to validate real-world impact.
Advanced Persistent Threat Assignments Long-running, complex operations modeled after real-world threat actors and their techniques.
Exfilion works with organizations that expect more than standard testing. Enterprises, critical infrastructure, and high-value environments where security is not about compliance, but about actual resilience.
Exfilion does not deliver reports for the shelf. Exfilion answers what really happens when someone attacks.
OWASP ZAP is one of the most well-known tools in web pentesting. Sooner or later, most people come across it. In trainings, labs, or early hands-on experience, it is often one of the first tools used.
In professional pentesting, however, it tends to play a smaller role.
What is OWASP ZAP?
OWASP ZAP is an open source proxy for analyzing and manipulating HTTP and HTTPS traffic. Functionally, it combines several typical components of a web pentesting toolkit. It acts as an intercepting proxy, includes both passive and active scanning capabilities, can crawl applications via a spider, and provides fuzzing features. It also exposes an API for automation.
This makes ZAP capable of covering many common web pentesting tasks, at least on a basic level.
Why ZAP is often the starting point
ZAP has several characteristics that make it especially appealing for beginners. The most obvious one is availability. As an open source tool, it can be used without licensing costs, which significantly lowers the barrier to entry.
Another factor is how quickly it produces results. A scan can be launched within minutes and immediately highlights common vulnerabilities. This helps build an initial understanding of web security issues.
Its usability also plays a role. Many features are accessible without extensive configuration, which is particularly useful in training environments or early experimentation.
Why ZAP is less common in professional environments
In professional pentesting, the focus shifts significantly. The emphasis is less on automated results and more on tailored, manual analysis.
Scanners still have their place, but they typically serve only as a starting point. The real work happens manually. In this area, ZAP often provides less value compared to specialized tools that are better optimized for workflow, reproducibility, and efficient manual testing.
Another aspect is the quality of findings. Automated results always require validation. In many projects, the effort involved outweighs the benefit.
Performance and usability can also become limiting factors. These issues are rarely noticeable in training scenarios but become more apparent in larger or more complex real-world applications.
ZAPScanner from binsec.tools
The ZAPScanner from binsec.tools follows a slightly different approach. It uses OWASP ZAP in a preconfigured way for standardized scans.
The focus is on pragmatic usage. Predefined configurations allow for quick and reproducible results. This is particularly useful for initial security assessments, simple automated checks, or training environments.
It is not intended to replace manual pentesting, but rather to provide a structured entry point into automated testing.
Positioning in pentesting
ZAP is not a tool for deep analysis of complex applications. Its strength lies in making fundamental concepts tangible and delivering initial technical findings.
In practice, it is often used as a supporting tool. Typical use cases include initial crawling, quick checks, or training scenarios. For in-depth analysis, most pentesters rely on other tools and manual techniques.
Conclusion
OWASP ZAP is a solid tool for getting started in web pentesting. It helps users understand core concepts and produces quick results with minimal setup.
In professional environments, it is less commonly used as a primary tool. Manual analysis, experience, and specialized tooling take priority.
Used with the right expectations, ZAP is a useful addition to the toolkit. Expect more, and its limitations become apparent quickly.
In application security, two references appear particularly often: the OWASP Top 10 and the CWE Top 25 Most Dangerous Software Weaknesses. Both lists are frequently mentioned in security guidelines, training materials, and penetration testing reports and aim to highlight common security problems in software.
At first glance, both lists appear to describe the same thing: common weaknesses in software. In reality, they follow different approaches. While the OWASP Top 10 describes security risks in web applications, the CWE Top 25 lists concrete technical weaknesses in software in general.
The OWASP Top 10
The OWASP Top 10 is published by the Open Web Application Security Project and describes the most significant security risks for web applications.
Well-known categories include:
Broken Access Control
Cryptographic Failures
Injection
Security Misconfiguration
The categories are intentionally formulated at a relatively high level. They describe risk areas in web applications that arise from common weaknesses, potential attack vectors, and their resulting impact.
The OWASP Top 10 clearly focuses on web applications and web-based architectures. Many of its categories reflect typical problems found in modern web applications.
For this reason, the list is often used as a reference for web application security. Many organizations rely on it for secure development guidelines or security awareness training.
However, it is important to note that the OWASP Top 10 is not a testing methodology. It describes risks rather than specific testing procedures or technical checks.
The CWE Top 25
The Common Weakness Enumeration (CWE) is maintained by MITRE and represents a comprehensive classification system for software weaknesses.
From this collection, the list of CWE Top 25 Most Dangerous Software Weaknesses is regularly derived.
Unlike the OWASP Top 10, the CWE Top 25 describes concrete technical weakness classes in code, for example:
Out-of-bounds Write (CWE-787)
Use After Free (CWE-416)
Improper Input Validation (CWE-20)
Many of these weaknesses originate directly in the code and often affect memory-unsafe programming languages or low-level system software.
In contrast to the OWASP Top 10, the CWE classification is not limited to web applications. It describes weaknesses in software in general and can therefore be applied to web applications, desktop software, system software, or embedded systems.
Risk vs. Technical Cause
The most important difference between the two lists lies in their level of abstraction.
The OWASP Top 10 describes security risks in web applications. The CWE Top 25 describes concrete weaknesses in software code.
An OWASP category can therefore include several underlying weaknesses.
A simple example illustrates this relationship. The risk category Injection can arise from different technical causes, such as insufficient input validation or insecure database queries. These causes can in turn be mapped to specific CWE identifiers.
OWASP therefore answers the question:
Which security risks occur most frequently in web applications?
The CWE classification, in contrast, addresses:
Which specific coding errors lead to these problems?
Comparison of OWASP Top 10 and CWE Top 25
There is no direct one-to-one mapping between the two lists. However, typical relationships can be illustrated. The following table shows a simplified comparison of commonly related issues.
At the same time, the CWE Top 25 includes several weaknesses that cannot be directly mapped to OWASP categories. These include classical memory-related issues such as:
CWE-787 Out-of-bounds Write
CWE-416 Use After Free
CWE-125 Out-of-bounds Read
CWE-190 Integer Overflow
Such weaknesses typically occur in system-level software rather than in typical web applications.
Relevance for Penetration Testing
For penetration testing, the OWASP Top 10 is a frequently used reference. The list highlights major security risks that are typically considered when testing web applications.
Some penetration testing reports structure their findings according to OWASP categories. More commonly, however, the categories are used to contextualize vulnerabilities or communicate risks.
The CWE classification often plays a complementary role in penetration testing. It helps to technically classify discovered vulnerabilities more precisely. Many vulnerability reports therefore include the corresponding CWE identifier.
A typical mapping may look like this:
OWASP risk → concrete vulnerability → corresponding CWE ID
Example:
Broken Access Control → missing authorization check → CWE-284 Improper Access Control
Such a mapping can facilitate both risk communication with stakeholders and the technical classification of a vulnerability. In practice, however, it is often performed only upon customer request. The actual added value of an additional classification usually remains limited.
The Penetration Testing Execution Standard (PTES) describes a structured methodology for conducting penetration tests. The goal of the standard is to define the typical project phases of a penetration test and thereby create a transparent process from planning to reporting the results.
The standard emerged around 2010 as a community-driven initiative by security professionals. To this day, PTES is frequently referenced when discussing the general workflow of a penetration test. In practice, however, it is usually used more as a conceptual framework than as a complete technical methodology.
The PTES Phases
PTES divides a penetration test into seven typical project phases.
Pre-Engagement Interactions
In this phase, the organizational and legal framework of the engagement is defined. This includes in particular the scope, test objectives, communication channels, and the so-called rules of engagement.
Intelligence Gathering
This phase focuses on collecting information about the target environment. Examples include publicly available data, DNS information, subdomains, or indicators of the technologies in use.
Threat Modeling
Based on the collected information, potential attack scenarios are evaluated. The goal is to identify realistic attack paths and particularly critical systems.
Vulnerability Analysis
In this phase, potential vulnerabilities are identified. This is usually done through a combination of automated scans and manual analysis.
Exploitation
Identified vulnerabilities are then tested in practice. The objective is to determine whether and to what extent exploitation is possible.
Post-Exploitation
After successful access has been achieved, the potential impact is analyzed. This may include privilege escalation, access to sensitive data, or lateral movement within the network.
Reporting
At the end of the project, all findings are documented. The report describes the identified vulnerabilities, their potential impact, and possible remediation measures.
Taken together, these phases provide a meaningful structure for the workflow of a penetration testing project.
Critical Assessment
Despite its recognition, PTES is rarely used today as the sole methodological basis for penetration tests.
One important reason is the limited technical depth of the standard. While the defined phases describe the overall workflow of a penetration test, they provide only few concrete testing procedures. Additional technical guides and internal methodologies are therefore typically required for practical execution.
Another limitation is that the standard has seen only limited development since its original publication. Some technical examples in PTES refer to platforms and tools that are now outdated. For instance, older Windows versions such as Windows XP or Windows 7 are mentioned as reference systems in the technical sections.
Modern IT architectures are also barely addressed in the original PTES. Topics such as cloud infrastructures, containerized platforms, or complex identity systems play only a minor role in the standard.
Furthermore, PTES is not a formally maintained industry standard with clearly defined governance. There is no regular update process by a standardization body. As a result, the standard does not evolve over time and does not adequately reflect current technological developments.
No agency. No buzzword bingo. No compliance theater. Just a team of real ethical hackers who think about security from the perspective of real attackers:
The focus is clearly on manual security testing: web applications, APIs, infrastructure, and cloud environments. Automated tools are only the starting point. The relevant findings come from experience, creativity, and thinking like a real attacker.
Hackeroo is built for companies that want more than a scan report. No checklists, no false positives — just understandable vulnerabilities with real-world impact, exactly how attacks would happen in practice.
In short: Automated tools report a lot. Hackeroo finds what really matters. At a fair price.
Until now, the global security community believed that TCP ports end at 65535. This assumption was widely accepted, documented, and implemented in virtually every scanner on the market. It is rooted in a simple math problem involving only 0 and 1. The calculation appeared sound, was easy to implement, and therefore became an unquestioned industry standard. For decades, scanners, specifications, and compliance frameworks have relied on it.
After extensive research and multiple confirmed sightings during manual security assessments, I can finally disclose what many suspected but could never prove:
Port 65536 appears precisely at the moment when automated tooling confidently reports “no findings” and moves on. In many cases, the most critical issues were discovered shortly after traffic on this port was “observed”.
Administrators attempting to block 65536/tcp via firewall rules have reported no success, as firewalls consistently claim that the port is out of range.
binsec GmbH is currently looking for reinforcement (as a part time position)in the area of penetration testing – and we’re taking an approach that is quite rare in the industry:
A true 3-weeks-on, 1-week-off work model.
What does that mean?
You work three weeks as usual on client projects – and then you get a full week off, in addition to your regular vacation days. No on-call duties, no meetings, no “just quickly hopping on a call”: a real off-week. Why do we do this?
Why are we doing this?
Penetration testing is cognitively demanding. High-quality work is only possible when you have regular space to rest and recharge. We want an environment where people can stay effective long-term while still having a life outside of work. For us, that’s simply part of a professional work culture.
We’re looking for experienced Penetration Testers (m/f/d) who enjoy:
Every few weeks, someone asks me the same question: “What do you actually find in a typical web penetration test?”
Instead of answering anecdotally, I pulled the aggregated data from the last 12 months of web application tests (including APIs) performed by binsec GmbH. The result is the graphic below – and it reflects the same pattern I’ve been seeing for years.
Configuration Mistakes: The Everlasting Low Hanging Fruit
A large proportion of findings originate from simple configuration issues: insecure web server defaults, missing security headers, outdated TLS versions or weak cipher suites. These issues are easy to detect and usually not catastrophic, but they highlight a recurring pattern: deployments often lack a basic security baseline. A single security checklist would prevent most of them.
Session Management: Old Problems in Modern Applications
Session handling issues appear surprisingly often. A typical example is that logging out invalidates the session only in the browser, while the server-side part of the session remains active. If someone compromises the session token, they can continue using it even after the legitimate user has logged out.
Where the Critical Issues Hide: Authorization
The majority of critical findings occur in the area of authorization testing, especially regarding:
missing object-level access control,
insufficient role enforcement,
privilege escalation paths,
weak tenant isolation in SaaS environments.
Modern, frontend-heavy applications make this problem more visible. Browsers call dozens of API endpoints, and each endpoint requires explicit authorization logic. Frameworks rarely enforce this automatically. Developers have to implement it manually. A manual process that inevitably lead to inconsistencies.
The Classics That Refuse to Die
SQL Injection and Cross-Site Scripting (XSS) are far less common today, but they have not disappeared. ORMs, prepared statements and validation functions prevent many of these issues, but the moment someone bypasses them “just for a quick fix,” the classic vulnerabilities return.
Business Logic: Rare, but Serious When Found
Business logic issues appear less frequently, but when they do, the impact is typically significant. Examples include bypassing approval workflows, manipulating price calculations, or skipping required validation steps. These vulnerabilities do not show up in automated scanners and require a deeper understanding of how the application behaves.
Conclusion
The data confirms what many security professionals already know:
Most vulnerabilities are avoidable with consistent configuration baselines and hardened deployments.
Critical findings concentrate in authorization logic, not in exotic attacks.
Legacy bugs persist whenever shortcuts or rushed deployments bypass the protections provided by frameworks.
If you build or maintain web applications, focus on secure defaults, structured API authorization, and proper session handling. These fundamentals prevent the majority of real-world issues.
TISAX (Trusted Information Security Assessment Exchange) is the industry-specific security standard of the automotive sector – developed by the VDA and operated by the ENX Association. It ensures that companies demonstrably meet a high level of information security and can reliably share this status with their partners.
As part of TISAX, the regular execution of penetration tests is a key component of the technical security verification process. They serve to practically test the effectiveness of implemented security measures and to identify vulnerabilities at an early stage. This ensures that companies do not merely comply with policies but are genuinely protected against real-world attacks.
In the VDA’s Information Security Assessment Catalogue 6.0.2 (ISA6 DE 6.0.2), penetration testing is explicitly mentioned in two sections. The first reference appears in section 5.2.6 – To what extent are IT systems and services technically reviewed (system and service audits)?
In general, system and service audits must be conducted, planned in advance, and coordinated with all relevant parties. Their results must be transparently documented, reported to management, and used as a basis for appropriate improvement measures. In addition, such audits should be performed regularly and risk-based by qualified professionals using appropriate tools – both from the internal network and from the Internet. After completion, an audit report should be prepared promptly. While penetration testing can help to fulfill these requirements, an explicit demand for such testing only appears in the additional requirements for systems with a high protection need:
Additional requirements for critical IT systems or services have been identified and fulfilled (e.g., service-specific tests and tools and/or penetration tests, risk-based testing intervals).
The next reference appears in section 5.3.1 – To what extent is information security considered in new or further developed IT systems?
In principle, information security requirements must be identified, considered, and verified through security acceptance testing during the planning, development, procurement, and modification of IT systems. Specifications should include security requirements, best practices, and fail-safety measures, and they must be reviewed before systems go live. The use of production data for testing should be avoided or protected by equivalent safeguards. For systems with a very high protection need, the catalogue again explicitly refers to penetration testing:
The security of software specifically developed for a particular purpose, or extensively customized software, is verified (e.g., by penetration testing) during commissioning, in the event of significant changes, and at regular intervals.
The requirements for penetration testing under section 5.2.6 are relatively unspecific. If no proprietary software development is carried out – either internally or by contractors – testing usually focuses on conducting an external penetration test to assess publicly accessible services (e.g., websites) and analyzing the internal network. In traditional IT environments, the primary focus is typically on the Active Directory, the firewall, and internally reachable systems.
The execution of extended penetration tests – such as those including social engineering, phishing, physical security assessments, or DDoS testing – is generally not necessary for typical, limited-scope environments.
The idea for PTDoc emerged during the growth of the binsec team: How can quality remain consistently high when individual penetration testers have different personal focus areas? And how can we ensure that the outcome of a test is always identical – regardless of which senior penetration tester carries it out?
Before PTDoc, binsec faced the typical challenge: Should reports be written in Word or created with LaTeX? Initially, the decision was made for LaTeX, which produced technically clean but rather “typical” LaTeX documents in terms of design. With PTDoc, this changed fundamentally – today, it delivers professionally designed reports that are still powered by extensive LaTeX code in the background but managed through a user-friendly interface.
The core idea of the tool is to provide a uniform and standardized methodology for different targets – such as Active Directory, mobile applications (e.g., Android apps), or networks. The binsec team continuously maintains and extends this methodology, integrating well-established standards such as the OWASP Testing Guide, MASVS, and OSSTMM. This ensures consistently high quality and the exact repeatability of penetration tests.
In recent years, it has become clear that this structured approach regularly reveals vulnerabilities that were missed in previous tests. One client even stated that they no longer consider earlier assessments from other providers to have been “real” penetration tests.
PTDoc covers all three phases of pentest documentation:
Execution of the test – systematically working through the defined methodology.
Creation of findings – including management-level descriptions, detailed technical analysis, risk ratings (qualitatively via traffic-light system or quantitatively via CVSS), and management of screenshots and evidence.
Report generation – automated creation of a consistent, audit-proof report.
Retesting is also integrated: Once a tester verifies that a client has fixed a vulnerability, they simply document the proof of fix in the finding. When rebuilding the report, the issue is automatically marked as remediated, and the management summary is updated accordingly.
In addition, PTDoc supports the creation of both German and English reports, making it easy to provide clients with deliverables in either language – or even in both.
Conclusion: With PTDoc, penetration testers can fully focus on their actual work – conducting the test. At the same time, report creation becomes quick and efficient, ensuring that clients receive their results shortly after the test is completed.
