Frequently Asked Questions

If the intention of the test is to evaluate the ability of the defensive team, then it may be in the best interest of the organization to limit the knowledge of the testing. If the security team is aware of the testing well in advance, we find most teams will spend their time days in advance updating all operating systems and applications, and even disabling some services that are being used on a regular basis to avoid the chance of the test results being detrimental to their work performance.

This may sway the outcome of testing results and not provide an accurate representation of your architecture, while also not providing the full value of the test. A typical attacker has the option to attack your networks on their schedules, waiting patiently until they feel you are the most vulnerable, not when you are the most prepared. If the intention is to work with the organization’s security team to identify and mitigate findings in real time, then it’s beneficial to have the team aware of our presence and we recommend sending start and stop notifications to all relevant parties so they’re aware of any interruption to services.

Our consultants are trained to follow our own specialized security testing methodology based on industry standards primarily aligned with NIST SP800-115 to ensure compliance with most regulatory requirements, but are also fine-tuned to fulfill the needs of each individual client’s security concerns.

The reason for this organizational-specific testing methodology is to create an effective attack plan that produces data results that are valuable, but also have a high level of validity associated with them. False-positive results are a waste of time for everyone involved. Our consultants take the time to create POCs (proof of concepts) that are easy to understand and follow, but also show exactly how we came to the results, so our clients can use this information to mitigate the vulnerabilities and create a more secure infrastructure.

In most situations, our clients choose to identify a list of assets they want our consultants to focus on within the scope of the engagement. After the client has established this, they would simply contact our team to set up a meeting to go over the details.

As a penetration company, our team of highly-skilled security consultants customize every engagement by adjusting our focus to fit the client’s needs. We understand that no one client’s architecture or application fits into a predefined box and requires an adaptive testing methodology to develop a solution that works best for your organization. Our consultants are proficient at adapting to our clients’ environments and have familiarity with a variety of tools, services and targets.

Packetlabs’ AI/LLM Pentesting methodology is based on the OWASP Top 10 for LLM Applications and is regularly updated to reflect new attack vectors and model behaviors.

Testing covers both manual and automated techniques, leveraging tools such as Garak and Prompt Fuzzer, followed by extensive manual validation to uncover hidden risk.

Traditional web or API tests focus on server-side vulnerabilities and network misconfigurations.

In contrast, LLM pentesting targets the behavioral and linguistic layers where malicious prompts, manipulated data, or insecure output may compromise application logic or data integrity. It bridges software security and AI safety by testing both code and cognitive behavior.

Each engagement includes:

• A detailed report mapping findings to the OWASP LLM Risk Top 10

• Step-by-step reproduction instructions for each vulnerability

• Root cause analysis and remediation guidance for developers

Web applications would only require the website URL and the user accounts to access the website. We always recommend testing against a non-production environment to ensure availability is maintained for your production website. No denial of service attacks are ever conducted but each application is built differently resulting in different responses to attacks. If production is your only environment, we take the proper precautions and work with your team to reduce the likelihood of any downtime.

While ideally every aspect of a web application should be tested, realistically time and budget are two important factors. The web application itself needs to be tested for common vulnerabilities such SQL injection, cross-site scripting (XSS) items in the OWASP Top 10, the servers and infrastructure hosting the web application also need to be tested as the application is only as secure as the server(s) it is hosted on. Authentication and session management, payment processing and business logic are all critical areas that should be tested.

While web application firewalls (WAF), rate-limiting, DDOS prevention and countermeasures, when properly implemented, configured and tuned, are great solutions in preventing or increasing the difficulty of attackers exploiting vulnerabilities in web applications they do not fix the underlying vulnerabilities. Whitelisting testing activities allow thorough and unimpeded assessment of the application itself in order to identify underlying vulnerabilities. Once vulnerabilities have been identified they can be addressed and remediated.

Web applications come in all shapes, sizes with different intended purposes and technologies they are built upon. As such, applications with large amounts of functionality, and multiple different user roles/permissions can generally take a greater amount of time to test than small applications with limited functionality and minimal user roles. Certain web application technologies can require different tool sets, and research in order to effectively evaluate. Some vendors take less time to perform a test because they run an automated tool and pass the generated report off as a penetration test, however, this is far from a proper penetration test and is sure to miss vulnerabilities. For more on automated vs manual testing read here, and for more on choosing the right pentesters click here.

The majority of penetration tests we perform against web applications lean more towards a white-box test than a black-box test as developers and admins can often help answers about the application that arise during testing such as how certain features works, and help to unlock accounts if they get locked. This can lead to more effective and efficient testing. Some of the best admins and developers we work with have provided snippets of source code where needed and even script tasks such as unlocking the test accounts every hour in order to prevent testers from being locked out, which often happens for one reason or another.

Web applications vary widely in their intended usage and service offering, we often develop key test cases working alongside our clients, often our clients draw attention to key test cases they would like to be tested such as altering the check-out price on goods on an e-commerce site, viewing bank statements and records that belong to other users, or making sure low privilege roles cannot perform admin functions such as modifying or resetting user accounts. In addition to key test cases clients bring up, Packetlabs relies on years of experience and expertise to develop thorough test cases that cannot be tested with automated tools, and that is often overlooked by clients or other penetration testers.

Most penetration tests have retest agreements in which time is dedicated specifically for testing if vulnerabilities identified during testing have been remediated. Before finalizing an agreement to conduct a web application penetration test, retesting will be discussed to figure out how much time can be allotted to retesting, and when retesting may occur.

By 2025, there are an estimated 75 billion connected IoT devices worldwide, with 57% of organizations reporting at least one IoT-related security incident in the past year. IoT penetration testing helps uncover vulnerabilities such as:

• Hardcoded credentials

• Insecure communication protocols (MQTT, BLE, Zigbee)

• Weak firmware encryption or signature verification

• Cloud misconfigurations

• API and mobile app exposure

• Testing provides both technical assurance and regulatory compliance validation, which are critical in industries like healthcare, manufacturing, smart infrastructure, and consumer electronics.

Common findings from recent Packetlabs engagements include:

• Hardcoded credentials in firmware or source code

• Unencrypted firmware updates

• Insecure OTA (Over-the-Air) update mechanisms

• Default administrative passwords

• Weak API authentication tokens

• Exposed debug interfaces (UART, JTAG)

• Lack of TLS encryption in device-cloud communication

• Insecure mobile companion applications

IoT devices should undergo security testing:

• Before production release (as part of the SDLC)

• After major firmware or cloud architecture changes

• Annually, to ensure no new vulnerabilities arise due to updates or supply-chain shifts

• Continuous testing or red teaming may also be recommended for organizations operating critical infrastructure or large-scale deployments.

In addition to our comprehensive testing, using the Packetlabs Portal offers access to real-time insights and progress monitoring, instant retest request capabilities, a collaborative environment, and integration with your organization’s ticketing systems.

Once you’ve signed on, your account will be accessible within 48 hours.

You can invite as many users as you would like to access the data. These users can include your developers, security teams, project managers and even stakeholders.

Mobile Pentesting helps organizations meet several compliance and regulatory mandates:

• OWASP MASVS/MASTG: mobile app security standards

• PCI DSS v4.0: secure mobile payment applications

• SOC 2 & ISO 27001: information security and privacy assurance

• HIPAA & GDPR: protection of personal and health information

• Routine testing provides evidence for auditors and strengthens cyber insurance eligibility.

Mobile applications should be penetration tested:

• Before every major release or version update

• After adding new features, third-party SDKs, or backend integrations

• Annually, as part of continuous vulnerability management

• Continuous testing is also recommended for critical mobile platforms in finance, healthcare, and e-commerce, where exposure risk is high.

Packetlabs’ Mobile Penetration Testing engagements are executed by certified ethical hackers (OSCP, OSWE, GXPN, CEH) specializing in iOS and Android security.

All testing is performed in-house with zero outsourcing, ensuring consistency, confidentiality, and 100% verified results.

No. Purple Teaming requires the ‘red team’ or the attackers (us), and the ‘blue team’ or the defenders (SOC vendor) to work together to first demonstrate the attacks, and ensure the blue team is capturing the relevant logs and alerting on suspicious activity. There must be an active blue team working with Packetlabs during a purple team exercise.

This enabled Packetlabs to help elevate the monitoring within your organization, and alert on tactics, techniques, and procedures (TTPs) that attackers implement during their attacks. Our Purple Teaming exercises are led by the MITRE ATT&CK framework for enterprise.

Packetlabs uses a 95% manual approach, aligning with:

• MITRE ATT&CK Framework

• OWASP Top 10 (Web & API)

• NIST SP 800-115 for penetration testing

• CIS Critical Controls (1, 2, and 14) for asset management and vulnerability reduction

On a per-engagement basis, tools and techniques may include, but aren't limited to:

• Passive reconnaissance (Shodan, Censys, Amass, FOCA)

• OSINT and credential harvesting (Have I Been Pwned, GitHub Dorking, Pastebin)

• Subdomain and DNS enumeration (Subfinder, DNSRecon)

• Web and API probing (Burp Suite, Nmap, Aquatone, HTTPx)

• Exploitation validation through custom scripts and Packetlabs proprietary toolkits

Attack Surface Pentesting covers:

• Internet-facing IP addresses and subnets

• DNS records, subdomains, and mail servers

• Cloud assets (AWS, Azure, Google Cloud, SaaS platforms)

• Public repositories (GitHub, Bitbucket, GitLab)

• External applications and APIs

• Third-party and vendor-exposed endpoints

• This holistic review ensures that both known and unknown entry points are tested.

Common vulnerabilities identified include:

• Misconfigured cloud storage (S3 buckets, Azure Blob)

• Forgotten or unpatched subdomains running legacy apps

• Credential exposures in code repositories or public paste sites

• Open RDP, SSH, or management ports

• Outdated CMS or plugin vulnerabilities

• Weak SSL/TLS configurations and expired certificates

• API endpoints without authentication or rate-limiting

• In several 2024–2025 engagements, 60% of discovered assets were previously unknown to the client, representing substantial hidden risk.