Custom Exploits
Our custom exploits allow you to easily demonstrate the true risk of vulnerability via Proof-of-Concept scenarios.
We help you demonstrate risk through accurate proof-of-concepts
Our security experts use several tools to test a variety of payloads against the target to determine which parameters are vulnerable. Once all parameters were found and tested, if at least one of them was confirmed to be vulnerable, it will be used in order to perform a managed attack or extract the specified information from the database.
We create SQL Injections, extract data and demonstrate the risk of SQL exploits
Allows you to confirm SQL Injection vulnerabilities on your site, to see the vulnerable parameters and also to demonstrate the business risk by extracting data from the database.
Our tool uses the well known SQLMap, which is executed with the proper parameters in order to provide speed and accuracy.
We test a variety of payloads against the target to determine which parameters are vulnerable. Once all parameters were found and tested, if at least one of them was confirmed to be vulnerable, it will be used in order to extract the specified information from the database.
Our audit generates some HTTP requests which can be flagged as attacks on the server side (although they are harmless). For this reason we will ask you to whitelist our IP addresses when performing the exploit.
Detailed information about SQL Injection, including solutions on how to remediate this vulnerability can be found in the OWASP SQL Injection Page.
How this audit is performed
Scannning
We scan the URL of the website that will be scanned (http or https). We then select the HTTP method that will be used to send the requests and create a POST string (e.g.: “id=1”). We also add HTTP Cookie header to include in each request. Useful when you want to conduct tests on a page after login (e.g.: “PHPSESSID=a8fh54s..”). We then select which data you would like to extract from the database.
Diversity Levels
By default, we will test all GET and POST parameters specified / found. However, we can add additional entry points using the level option. For example, Level 2 adds HTTP Cookie testing, while Level 3 adds User Agent / Referer testing. The higher the level, the longer the our audit will take.
Risk
If you choose a higher risk, we will include more resource-intensive tests, which might make the database temporarily inaccessible to legitimate users (for the duration of the test). For example, Risk 2 will run heavy time-based SQL Injection queries alongside the default Risk 1 payloads. Also, the higher the risk, the longer the scan takes.
Detailed Reporting
We conveniently send you a detailed report with a summary of findings and risk ratings. Each finding has a detailed explanation in terms of risk and recommendations.
The Report includes:
- Summary of vulnerable parameters, together with the SQL Injection method they are vulnerable to
- Includes the data that was extracted from the database
- The original SQLMap output is also included
Advanced scripting and payloads for proving vulnerabilities via XSS attacks
We create Proof-of-Concepts and demonstrate the risk of XSS vulnerabilities in web applications.
Our XSS Exploiter exploits Cross-Site Scripting, one of the most critical vulnerabilities in web applications, according to the OWASP Top 10 project.
The XSS Exploits allows us to easily demonstrate the true risk of an XSS vulnerability by creating a Proof-of-Concept scenario. We use custom JavaScript files which are included as payload in the XSS attack.
The victim’s browser will execute the it, sending user data back to our tools. This way, we can harvest the user’s cookies, the page HTML content, the page screenshot, the keys pressed by the user.
We produce the elements necessary to exploit an identified vulnerability:
- The JavaScript payload that fetches data from the user’s browser
- The server-side component that receives the user data
- A valid SSL certificate on the receiving server which makes the browser trust the script
- A simple interface to generate the payloads and display the results
How this audit is performed
Script and Payload generation
We generate a JavaScript file that can be publicly accessed at a unique URL. That URL will be embedded in an XSS payload which, when accessed by a browser, leads to the script being loaded and executed, fetching the chosen data and sending it back to the server.
Fetching
We will fetch the following information: Source IP address, URL Parameters, User Agent, All HTTP headers, Operating system (deducted from User Agent) and Request date.
Handler
Each XSS Handler is unique. Only you can see the data extracted by your handlers. Nobody else can use your payloads or send data back to your handler unless they know your exact URL.
Expiry
The handler will be active for 60 days. After this time expires, you will still be able to view your results, but the handler will stop logging new requests. Additionally, there is a limit of 500 requests that can be logged per handler.
HTTP Request Logger
This is a useful pentest utility which logs all the HTTP/S requests received on a certain handler URL: source IP, User Agent, URL parameters, timestamp, etc.
This allows us to easily create Proof of Concepts in order to demonstrate vulnerabilities such as XSS, data exfiltration or to do social engineering.
The HTTP Request Logger was created from a practical need of our pentesting team to have an always-on HTTP/S server and an easy interface to visualize the HTTP requests received.
The advantage of using this tool is that you no longer need to configure your own HTTP server, it has a valid SSL certificate and it has a simple web interface which you can also show to your clients to present the results.
How this audit is performed
Unique URL Creation
The tool creates unique URLs (HTTP Handlers) which log all the requests received. The following information is recorded from the incoming request: Source IP address, URL Parameters, User Agent, All HTTP headers, Operating system (deducted from User Agent), and Request date.
Handler
The HTTP Handler is unique per user so no other user will be able to access it (unless he knows the exact URL).
Lifetime
The HTTP Handler has a lifetime of 15 days. After the remaining time expires, the handler will no longer log the requests received. Furthermore, there is a limit of 50 requests that are being logged per handler.