Frequently Asked Questions

We provide a myriad of services and know getting the right support is overwhelming. Sourcing our frequently asked questions, we want to help and provide you with the service that is right for you.

Consider using keywords like “data”, “storage”, “DDOS”, etc.

  • All Services
    • Infrastructure Penetration Testing
    • Ransomware Penetration Testing
    • Objective-Based Penetration Testing
    • Application Security Testing
    • DevSecOps
    • Cyber Maturity Assessment
    • Compromise Assessment
    • Purple Teaming
    • Red Teaming
    • Cloud Penetration Testing
    • ICS/OT Cyber Security Assessment
  • All Industry
    • Retail & Ecommerce
    • Finance
    • Government
    • Education
    • Technology
    • Healthcare
    • Utilities and Energy


  • What is the difference between Penetration Testing and a Vulnerability Assessment?

    When conducting a penetration test, Packetlabs consultants simulate the steps that a typical attacker would most likely take to successfully infiltrate your network. Through this process, we gather the relevant data to analyze and identify the weaknesses that exist within the defenses of an organization, so that they can be addressed to prevent further exploitation in the future. When a client is interested in a security test, our consultants will first take the time to work with them to identify what type of penetration test they require and how to get the most value from the results.

    A vulnerability assessment is a far less intrusive testing process of live systems within the network that does not focus on the final step of exploitation. This type of assessment gives the client an opportunity to gain insight into the potential vulnerabilities that exist within the architecture, but does not truly attempt to utilize the full impact of the attacker’s techniques that are commonly simulated. This often results in vulnerabilities being missed, and false positives.

By Solution

Infrastructure Penetration Testing
  • What is the difference between a depth-based penetration test and a coverage-based penetration test?

    Unlike depth-based penetration testing, coverage-based penetration testing has a broader, “let’s keep looking” focus. With this approach, testers look for multiple ways to compromise an environment and exploit its vulnerabilities. In fact, they look for as many ways in, not just the easy ones, and don’t simply stop after the first exploit. Depth-based, in contrast, focuses on finding the path of least resistance, or the easiest way in. This is the path attackers will often take, but it doesn’t consider that there are multiple other ways, which may be a little bit more challenging to exploit.

  • What does my organization gain from security testing its infrastructure?

    The simple answer is reassurance. Our team of consultants will ensure that we have done everything possible to evaluate the security defenses you have in place at your organization. It is impossible to assess how well an organization’s defensive measures are working, unless they have been tested to react the way a vendor has claimed they are intended to perform. Many of our clients have discovered that their defensive 24/7 Security Operations Centre awareness teams failed at discovering an intruder in a timely manner, or fail to identify a breach of security. In addition, many Anti-Virus and Intrusion Detection System frameworks have failed at detecting malware.

    Unfortunately, other clients called us only after they experienced a breach. At that point, the damage had already been done, which lead to a forensic assessment to discover how the breach occurred. By taking a preventive strategy your organization will gain access to our comprehensive reports, which are among the most inclusive in the industry. Our reports detail findings in an easy-to-read layout for executives, but also provide the necessary results, guidelines and suggestions that can help the technical staff mitigate the exploitable vulnerabilities found going forward. This allows management to share results with all organizational stakeholders involved to address the weaknesses in all related operations, and to help focus on the costs needed for investing in securing your entire IT architecture.

  • What is the difference between internal and external security infrastructure testing?

    Both of these areas of assessment focus on different assumptions and attack surfaces. External infrastructure testing is concerned with what services, protocols, and applications are being exposed to the internet, e.g. web servers, log-in portals. These systems are considered the most vulnerable, as the constant bombardment of attacks from external threat actors create a high level of risk to all exposed areas. The systems that are exposed must have impeccable configurations focusing on hardening techniques, leaving no room for error, and must also be concerned with denial of service attacks.

    The assumption with Internal infrastructure testing is that external threat actors have already penetrated external defenses to find a way inside or the threat is being sourced from an internal actor, which some consider a company’s greatest threat, or a vendor that has already been authorized for access. The primary focus areas for this type of testing are lateral movement and privilege escalation. The goal of this type of testing is to identify how difficult it is for an internal attacker to move around the internal network and to discover what type of sensitive data may be obtained in the process. This is also an effective way to test the awareness of the defensive team by identifying how quickly it takes for a defensive team to discover the presence of an intruder and if they were able to isolate how the intruder gained entry.

  • Why perform security testing on infrastructure already protected by a firewall?

    From our experience, we have found that intruders continuously find the weakest link and utilize the path of least resistance to enter an organization’s network. This path circumvents a firewall’s configuration and implementation. The purpose of a firewall is to only allow specified traffic in or out as authorized – but if an attacker can hide within permitted traffic, they can undoubtedly use it to enter and exit as required. Common examples can include utilizing web, DNS, or email traffic to keep from being discovered. In most cases, the common weakest link in organizations are the staff that fall victim to phishing-based attacks that can be used to gain a foothold into the internal network that may lead to an intruder exploring sensitive assets.

  • Is it necessary to plant a device within the test network so you can have access? Why can’t you just “hack in”?

    Depending on the scope and size of the engagement, most security testing engagements fall between the range of weeks to months. In that time, the assessment of the network infrastructure involves testing all assets in scope, which can include a large number of services, applications and protocols being used by those assets. Given the budget of the client, time restrictions, and scope of allowable testing rules, in most cases the time and budget spent would be better utilized on the actual testing of the assets. Our team of consultants can spend the entire allocated time and budget on trying to bypass external defense mechanisms or create a sophisticated phishing campaign (as is done in objective-based penetration testing) until we gain entry, but by that time the budget may be well spent, leaving little opportunity for the actual security assessment. As such, in most situations, providing our consultants with VPN credentials or planting a device inside the network to ensure the network infrastructure can be thoroughly tested in its entirety will provide the most value.

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

    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 with 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.

    One of the small, possible disadvantages to full production environmental testing is that live systems may experience interference during normal operations. In most cases, this interference is minimal and is usually not even detected, but capturing relevant data can be absolutely critical to the result outcome. If special circumstances exist where these systems are inherently sensitive, it is possible to perform testing in pre-production environments. The difference being that the consultant would not have the opportunity to evaluate how the regular services accessed by this system would typically run for the organization’s users, customers or vendors. The pre-production test would simply focus on assessing the pre-production infrastructure integrity on its own.

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

    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.

  • What type of methodology is used for infrastructure security testing?

    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.

    An example of a security testing process used in our infrastructure testing includes:

    Information Gathering

    During this stage, our consultants will take the time to do reconnaissance on your organization to discover every possible detail that can be utilized. This can include online services, exposed portal systems, published documents, social media, identifying valid employee accounts and more. Collecting this information can be used to help create a custom phishing attack as most attackers will use this information to boost their attack efforts.

    Discovery and Vulnerability Scanning

    Next, a comprehensive manual and automated testing process will occur utilizing various commercial automated scanning tools & technologies while combining manual custom vulnerability testing techniques to identify, fingerprint and validate findings. Multiple attack areas and vulnerabilities will be evaluated in the stage. Our consultants are not satisfied until every potential attack path has been considered.


    Once the vulnerabilities have been identified, the consultant will utilize this opportunity to exploit them. This requires the testing team to creatively circumvent defensive measures that may try to prevent the exploitation from being successful (e.g. Anti-virus). Our consultant will test the areas of confidentiality, integrity, and in some cases, availability to verify that the vulnerability is actually exploitable. Attempts to escalate privileges, gain unauthorized access, and laterally move across the network will be explored.


    After all the results and data have been collected, our team will create an industry-leading comprehensive report that is custom tailored to our clients. The report contains an executive summary with a high-level overview of the critical issues identified, the methodologies we used to conduct the test, the scope of the assessment, a technical finding section that describes each of the findings, with steps to reproduce, evidence where required, and steps on how to remediate the vulnerability. Finally, the report is concluded with a unique list of strategic and tactical security recommendations, and appendices are included when necessary.

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

    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. In more specific objective-based security testing, clients establish various goals they would like accomplished to verify whether it was possible for a potential attacker to complete a similar task such as extracting financial records or other sensitive information.

    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.

    A penetration test is an excellent strategy to evaluate the safeguards and controls of your organization’s information management systems, by allowing us to identify vulnerabilities and technical flaws in your security architecture. At Packetlabs, our first priority is to locate and mitigate our clients’ security vulnerabilities before they are potentially exploited.

Ransomware Penetration Testing
  • What is the difference between the ransomware assessment included in Objective-Based Penetration Testing and the Ransomware Penetration Testing service?

    The ransomware assessment included in OBPT is limited to only assessing the technical aspects. The ransomware risk assessment service offering not only assesses the technical aspects but also looks at the non-technical side to gain a deeper understanding of the risks and preparedness of an organization.

  • What does the ransomware penetration test include?

    The ransomware penetration test includes:

    • An analysis of the security program against the Cybersecurity Framework Profile for Ransomware Risk Management (NISTIR 8374) to identify gaps in people, processes, and technology.

    • A technical assessment of security controls to identify the likelihood and readiness for a Ransomware attack.

Objective-Based Penetration Testing
  • What is an Objective-based Penetration Test, and at what stage is the organization ready for this approach?

    An objective-based penetration test begins with a comprehensive, coverage-based infrastructure penetration test. It layers on additional components to round off the assessment, and make it far more realistic and thorough to ensure we actually move the needle on security. The objective-based penetration test includes Infrastructure Penetration Testing, an Active Directory Password Audit, Active Directory Bloodhound Audit, e-mail phishing, advanced simulation of your top five objectives (e.g., obtain access to ERP, obtain administrative control over the target network, etc.) and more.

    We recommend the objective-based penetration test as the initial approach for most organizations because it helps prioritize your path to low risk across people, processes and technology. It also helps evaluate the responsiveness of your blue team!

Application Security Testing
  • How do I prepare for a web application penetration test?

    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.

  • Why perform security testing on web applications?

    Nearly every organization has an online footprint which often includes a web application, data breaches and hacks are all over the news each and every week, when it comes down to business securing your online presence means protecting your brand. Web application security testing is performed to help identify security weakness, ideally before an attacker can, and then fix the weaknesses to prevent an attacker from doing harm. Read more on 5 Reasons Why Hackers Target Your Website here.

  • What should I test in a web application?

    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.

  • Why do you need credentials to the web application? Why can’t you just “hack in?”

    Assessing a web application's security involves testing the entire features and capabilities, not just if a hacker can access the application without authorization. While it is rare or nearly impossible to find a perfectly secure web application, there is no guarantee that an application’s authentication process can be hacked, or the methods might be out of the scope of the test, such as phishing users and/or developers. As such, providing testers with credentials ensure the application can be tested in its entirety.

  • Why do you need so many accounts?

    Often web applications will have more than one type of users such as a read-only or regular user and a super-user or admin. Typically a minimum of two sets of credentials for each user role is provided for testing. This allows the tester to accurately test that the vertical permission controls (e.g. preventing read up’s) and horizontal permissions controls (e.g. impersonating other read-only users) are functioning as intended.

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

    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.

  • Why does testing take so long?

    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.

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

    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.

  • How do you write effective test cases for Web applications?

    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.

  • What types of results can I expect?

    Packetlabs creates a professional, custom-tailored report for each client with the unique results of the web application assessment. The report contains an executive summary with a high-level overview of the critical issues identified, the methodologies we used to conduct the test, the scope of the assessment, a technical finding section that describes each of the findings, with steps to reproduce, evidence where required, and steps on how to remediate the vulnerability. Finally, the report is concluded with a unique list of strategic and tactical security recommendations, and appendices are included when necessary.

  • How can I verify the vulnerabilities are fixed?

    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.

  • Which organizations need DevSecOps?

    Packetlabs recommends DevSecOps to organizations that have multiple releases per year which have significant code/feature releases that require security validation before being promoted to production. Application Security Testing is a single, thorough pass through the application and is recommended for applications that have infrequent changes or have never had an assessment before.

Compromise Assessment
  • Ransomware is deployed in my environment, do I need a Compromise Assessment?

    A Compromise Assessment is a service to identify past/present compromises. It is a validation exercise to identify whether you have been breached and includes high-level testing across security controls to identify the likelihood of a breach. If you have been breached, it is our recommendation to trigger your Incident Response process and invoke your Breach Response, potentially with the support of a third-party vendor with forensic capabilities.

    A Compromise Assessment can be an add-on to your annual penetration test and is often part of due diligence exercises during any M&A activity. Packetlabs recommends completing a Compromise Assessment before integrating networks with an acquired entity.

Purple Teaming
  • Can you complete purple teaming without a blue team?

    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.