Question 1

Should the security testing be performed in production or pre-production environments?

Accepted Answer

The advantage of performing security testing in production environments is that it allows the testing to be conducted within the actual network conditions using the latest developments the staff has configured. This also helps to discover how attacking certain parts of a network or individual systems may affect other areas of the architecture. In many of our engagements, we have found that there are multiple ways to successfully infiltrate a network or laterally move within a network based on how well the services were connected to each other. By performing a test in a production environment, these paths can be explored and provide a level of insight not possible in situations where pre-production isolated systems exist.

Question 2

Is it best practice to make our security operations team aware of the penetration test?

Accepted Answer

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.

Question 3

What type of methodology is used for infrastructure security testing?

Accepted Answer

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.

Question 4

What is the best way to prepare for infrastructure security testing?

Accepted Answer

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.

Question 5

What standards and frameworks guide AI/LLM Pentesting?

Accepted Answer

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.

Question 6

How does LLM Pentesting Differ From Web or API Pentesting?

Accepted Answer

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.

Question 7

What deliverables are provided during an AI/LLM Pentest?

Accepted Answer

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

Question 8

How do I prepare for a web application penetration test?

Accepted Answer

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.

Question 9

What should I test in a web application?

Accepted Answer

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.

Question 10

Why do you recommend whitelisting on Web Application Firewalls and similar countermeasures?

Accepted Answer

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.

Question 11

Why does testing take so long?

Accepted Answer

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.

Question 12

What can our developers and admins do to help streamline testing?

Accepted Answer

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.

Question 13

How do you write effective test cases for Web applications?

Accepted Answer

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.

Question 14

How can I verify the vulnerabilities are fixed?

Accepted Answer

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.

Question 15

Why is IoT Testing Critical in 2025?

Accepted Answer

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.

Question 16

What are the most common IoT vulnerabilities found?

Accepted Answer

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

Question 17

How often should IoT devices be tested?

Accepted Answer

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.

Question 18

What’s included with the Packetlabs Portal platform?

Accepted Answer

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.

Question 19

How soon can I get started?

Accepted Answer

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

Question 20

How many users can sign into the Packetlabs Portal platform?

Accepted Answer

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.

Question 21

How does Mobile Pentesting support compliance?

Accepted Answer

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.

Question 22

How often should mobile applications be tested?

Accepted Answer

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.

Question 23

Who performs Packetlabs' Mobile Pentesting?

Accepted Answer

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.

Question 24

Can you complete purple teaming without a blue team?

Accepted Answer

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.

Question 25

What methodologies and tools are used for Attack Surface Pentesting?

Accepted Answer

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

Question 26

What is analyzed in an Attack Surface Pentest?

Accepted Answer

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.

Question 27

What are the most common findings from Attack Surface Pentesting?

Accepted Answer

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.

Explore By Service

Explore By Reports

Explore By Threats

Explore By Trending

Pentesting That Goes Beyond Automated Scans

Read Our Sourcing Guide

Pentesting That Goes Beyond Automated Scans

Get a Quote

Trusted by Leading Security Teams

Read Our Sourcing Guide