penetration testing

Top 10 Penetration Testing Decision Factors


 Top 10 for Choosing a Penetration Testing Company

How secure is your network? When is the last time you tested your cybersecurity defenses? Nearly $50k is the average cost for a small business to overcome a data breach—why not take steps now to protect your systems, your employees, and your clients from a cyberattack? You cannot fix what you do not know. A penetration test strengthens your defenses by revealing your weaknesses and recommending prioritized fix actions.

This article contains ten items you should consider when selecting an organization to perform a penetration test against your environment.

1. Use Certified and Experienced Personnel

The penetration testing team should have appropriate penetration testing credentials, such as the EC-Council Certified Security Analyst (ECSA), Licensed Penetration Tester (LPT), Offensive Security Certified Professional (OSCP), or Certified Ethical Hacker (CEH). The team should also have penetration experience with multiple industries and different environments. Make sure the penetration testing team has experience and knows what they are doing.

2. Deliver Clear Reports with Risk-Based Prioritized Recommendations

Reports should be easy to understand and include summary data for executives and detailed data for technical personnel. The penetration test report should contain a prioritized risk-based list of findings with detailed step-by-step recommendations. Any steps taken to exploit systems should include screenshots, where applicable. Your team should be able to reproduce the findings, given the steps in the report. The vendor should be able to provide a sample and redacted reports. If you can’t understand the report or take action on the findings, what’s the point of the penetration test?

3. Perform Both Manual and Automated Testing

Automated tools do not detect all vulnerabilities and are prone to false positives. Manual methods must be used as part of the penetration test to fill in gaps left by the automated tools, eliminate false positives, and ensure test completeness. Both manual and automated methods should be used for every penetration test. Many penetration testing organizations run automated tools, such as an automated Vulnerability Scanning tool, then try to pass those results off as a penetration test. A penetration test should involve many tools and many manual techniques.

4. Follow a Documented Process

A well-defined documented process should be followed before, during, and after the penetration test engagement. Documented processes ensure completeness, accuracy, and test repeatability. The documented process is also often referred to as a penetration testing methodology. A methodology is often very high-level though and should include detailed steps.

5. Use a Rules of Engagement (ROE) Document for Clear Expectations

Rules of Engagement are designed to ensure everyone is “on the same page” and there are no surprises during the test. The ROE ensures clarity on test expectations by documenting agreed-upon test parameters, such as times for the test, escalation procedures, targets in scope, targets out of scope, and limitations. The ROE document should be signed by you and the penetration testing vendor. It removes ambiguity from the test.

6. Communicate Clearly and Frequently

Routine communications during the penetration test should include when penetration testing begins and ends, what is being tested, whether any critical findings were discovered, any problems, etc. The communication frequency and medium should follow the agreed-upon terms in the ROE. Clear communications are vital during the penetration test.

7. Demonstrate Professionalism and Respect

This should be an obvious one, but it is important to emphasize. The penetration testing team should remember the focus of the test is to help you secure your environment; not provide an environment for them to practice skills or try out new exploits. Continuing exploitation beyond what is necessary is bad practice. The vendor should be able to provide references from previous clients.

8. Identify and Eliminates False Positives

A false positive is when the penetration testing team tells you there is a vulnerability or a problem when there really isn’t one. The penetration testing team should make every effort to eliminate false positives and label questionable findings. This is why manual analysis is critical. A report riddled with false positives wastes your time.

9. Offer “Retest” Options

Once you fix the penetration test report findings, it is critical to validate your remediation steps actually took care of the problem. Many organizations have taken steps to fix problems identified by penetration testers but never validated the steps worked. The penetration testing team should offer an option to rerun the test after you remediate the findings.  The last thing you want is to pay for a penetration test, take time fixing items, and then be hacked later on because you did not validate your fix actions.

10. Protect Your Data During and After the Test

The penetration testing team should follow a documented process to ensure your data remains secure. Penetration test reports often contain identified vulnerabilities, steps to exploit the vulnerabilities, cracked passwords, and other sensitive information. Reports should be labeled appropriately, handled with care, and distributed only to authorized personnel.

Interested in a penetration test? Connect with me.

Penetration Testing History

penetration testing - hoodie not requiredPenetration testing, or “ethical hacking,” is a method of exposing and purposefully exploiting the security vulnerabilities of a company’s systems.  Unlike security tests that use automated programs to identify these vulnerabilities, penetration testing requires highly-trained specialists to analyze the system, find their weaknesses, and use them to access protected information.

The human element of penetration testing is the most important. While a computer program can only perform the tasks with which it has been programmed, a human being can analyze new information and think of solutions that haven’t been thought of before. What’s more, a human is able to want – to feel a drive and a motivation that fuels the search for a way in.

Penetration Testing History – A Timeline

The concept of penetration testing has been around since human beings first began trying to understand their enemies’ thought processes. Ancient armies all over the world conducted mock battles and games to figure out how other armies might undermine their strategies or get around their forces. This continued for centuries upon centuries until, inevitably, the tech world got in on the act.

The Tiger Teams

Penetration testing first became a concept in the 1960s. The burgeoning tech industry realized then that having multiple users on one system, as had become the norm, posed an inherent risk to the system’s security.

This realization gave rise to what became known as “Tiger Teams.” Unsurprisingly, the first of these worked for the government and military. In 1971, the US Air Force ordered security testing of time-shared computer systems.

The 1980s

 Vintage computers.

In 1984, the US Navy got in on the ethical hacking action when a team of Navy Seals worked to evaluate how easily terrorists could access different naval bases. Around the same time, the US government was starting to come down on illegal hackers. One result of this process was the Computer Fraud and Abuse Act, which specified that particular ethical hacking techniques were only allowed under a contract between hacker and client organization.

The 1990s

As hacking became more advanced, so did penetration testing.  In 1995, Dan Farmer of Sun Microsystems and Wietse Venema of the Eindhoven University of Technology released a paper entitled “Improving the Security of Your Site by Breaking Into It.

Farmer and Venema described the emergence of the “uebercracker,” a hacker who had evolved beyond the ordinary and had learned to develop his own hacking programs. This person can discover bugs in the most advanced security systems and can get in and out of a system without leaving a trace. They showed rather than told the importance of a system owner’s looking at his or her own system in the way a hacker might, thus laying the groundwork for contemporary penetration testing.
In the same year, John Patrick of IBM termed this process “ethical hacking.”

The 2000s

After the turn of the new millennium, penetration testing finally began to solidify as a discipline. In 2003, the Open Web Application Security Project (OWASP) published its Testing Guide, which delineated the industry’s first set of best practices. Six years later, the Penetration Testing Execution Standard (PTES) offered providers of penetration testing services with a set of common practices.

…And Today

In 2013, calculations revealed that spending on enterprise security had exceeded $6 billion. Skilled ethical hackers now have a marketplace that desperately needs what they are able to do, so long as employers continue to realize how important it is to stay secure against the smartest attackers.

Why Penetration Testing Matters

Systems and software are always changing, and new security protocols are evolving all the time. But a security system’s advanced nature doesn’t make it invulnerable; it just means that the system can now guard against attack types that have already happened.

Hackers are just as innovative and just as committed to effectiveness as the people who develop security systems. Companies need penetration testing to approach systems with this same determination and skill but without the intent to do actual harm to the organization.

Know Thine Enemy

Now that “data breach” has become a household term, threat detection, response, and prevention systems have become more in-depth across multiple industries. What is still missing from many such systems, however, is specific knowledge of what these threats look like.  We don’t know how to make our systems stronger if we don’t know where the weaknesses are.

This is where penetration testing comes in. By running simulated attacks and figuring out how a smart hacker could bypass existing security protocol, an organization can identify what parts of the system need strengthening, as well as how to respond effectively if a hacker does break through those barriers.

Identify the Real Threats

You may have heard about a certain attack vector or sequence of attack vectors. It might be possible to take that rumor as gospel and develop protections against those vectors, but who’s to say that the actual threat might come from a different vector? Or even a different sequence of the same vectors?

An ethical hacker can check on the sequence that a company feels is most threatening and either

  1. pinpoint where the threat is, or

  2. determine that you should be more worried about a different vector entirely.

The same ethical hacker can also take a look at vulnerabilities that the company thought were not as threatening and figure out if a traditional hacker could combine them in a way that accesses the system.

Identify Cause and Effect

Penetration testing can help a company not only to identify how a hacker might access the system but also to see what the impacts could be on business operations. This information is invaluable to the development of a company’s threat response and prevention strategy.

Penetration Testing Risks and Benefits

No process is perfect, and penetration testing does have its risks.  Most of the risks, however, come from poorly conducted ethical hacking.

Readiness for Tests, Not Attacks

It’s great for staff members to feel safe, but the company doesn’t want them to get complacent. If their supervisor announces that they are doing penetration testing, the staff might fall into the trap of preparing for the test and then feeling overly secure when they pass.

The company could get around this by offering unannounced pen-testing. These kinds of tests are only on the radar of upper management, so they get a better sense of how prepared a security staff actually is.

Potential Damage to a System

If a penetration testing professional doesn’t have the proper training and experience, his or her attempts to access a system could cause the same damage as an actual attack. This includes:

  • sensitive data becoming compromised

  • servers crashing

  • systems becoming corrupted

These risks are also present if an ethical hacker isn’t actually ethical at all. These people do exist, so companies have to be careful and hire only credentialed professional penetration testers.

Start a Career in Penetration Testing

If you’d like to be one of the people that companies trust to perform penetration testing services, your first step is to pursue penetration testing training and secure a well-respected industry certification.

Black Box Penetration Testing Explained

Black Box Penetration TestingThis blog post is a transcript of Christian Espinosa’s explanation of Black Box Penetration Testing, which covers the following:

  • Differences between Black, Gray, and White Box Penetration Tests
  • Internal vs. External Black Box Penetration Tests
  • Blac Box Threats Emulated
    • External Hacker with little or no insider knowledge
    • Rogue Device
    • Internal Intruder

Check out my latest book: https://christianespinosa.com/books/the-smartest-person-in-the-room/

Need a black box penetration test, check out my company Blue Goat Cyber’s Black Box Penetration Test Services.

Complete Black Box Penetration Testing Video Transcript

Hi, this is Christian Espinosa with Alpine Security. In this video, we’ll cover black box penetration tests. In a previous video, we covered gray box penetration tests. I’ll put the link to that video beneath this one. With a black box penetration test, we have the least amount of knowledge from the scale of black, gray and white. A black box penetration test, you typically know very little about the target, maybe the IP address or the URL. With a gray box, you have a little bit more knowledge, typically user-level knowledge. In a white box, you typically have administrator-level knowledge or access to the schematics, the source code, the design documents, et cetera. Also with black box, this is called unauthenticated often because we do not have any level of access from a user perspective, like gray box or an administrator route level perspective like white box.

A black box penetration test can be used both internally and externally, and we’ll go over more detail of that in a second on the next slide. The threats we’re trying to emulate with a black box penetration test are an external attacker with very little knowledge about your environment, a rogue device, or an internal intruder. We’ll cover those in more detail here in a second. With an external black box penetration test, we’re looking at the perspective from outside your network. We’re testing your public-facing systems. If you’re in an organization where testing the systems that are exposed to the internet … so this could be a firewall, a router, a VPN concentrator, your web server. Anything you have exposed to the internet that your employees can access or your clients can access is what we’re testing from an external black box penetration testing perspective.

What we’re trying to emulate is an external attacker. This could be a script kiddie, somebody in China just scanning and looking to see what they can get into. It can be a botnet that’s just trying to scan for vulnerable systems, or it could be an active attacker trying to get into your environment. An example of what we might test could be your external firewall. If you’re a small organization, and all of your internal systems are Natted through a firewall for instance, you want to make sure that those firewall rules are set up properly, and you’re not allowing inbound traffic. You’re only allowing outbound traffic, and you have some rules in place. As an example, if you type in from the internal network, what is my IP, in Google, you can figure out what your public facing IP address is. This is something we would want to test because if your public facing IP address, which is often your external router or firewall, has a hole in it then the attacker may be able to exploit that hole and get access to your internal environment.

Here on the picture we have, what is my IP, we have As a quick example, if I go to Zenmap, which you can see right here, which is basically Nmap, but a graphical user interface for Nmap. This is just a quick example of reconnaissance. They put it in that IP address here, which we put in, Let’s say I do a regular scan, so I’m looking for holes on your external facing router or firewall, or you could have a next-gen firewall, you could have a UTM, et cetera. Go ahead on click on scan here. This is the first step with penetration testing. We’re trying to identify holes you may have. Right now, I’m just using Nmap with a default setting, which looks for the top 1000 ports.

It looks like we have four ports open, 53, 80, 1111 and 2111. If somebody performed an external black box penetration test against your firewall or external router, this is what they would see. Granted, they should scan all 65,535 ports. But this is the top 1000, and we have four ports open out of the top 1000. We can see here that there’s a web server running, DNS running, a few other things. And now the next step would be to identify a vulnerability and then exploit that vulnerability if possible. The reason this is important because if you have a publicly exposed IP address with a vulnerability, somebody could exploit that vulnerability and potentially pivot from the external facing system. From there, they could pivot to your internal environment and get access to your internal environment or get access to a sequel database or something else. You want to make sure you test your environment from an external perspective.

With an internal black box penetration test, we’re looking at the environment from inside your firewall. Really, we’re trying to emulate two threats, two main threats here. One of them is a rogue device, and one of them is an internal intruder. Basically, and these could kind of bleed together as the same thing because an internal intruder could plant a rogue device. But the idea is what if somebody walks into your environment and they plant a rogue device? As we see here, this is a phone plug on the screen in the picture. Let’s say they plant this device on your network. This device is a rogue device which intercepts your traffic, and can send it out via a cellular network to somebody else. Or it could actually phone home through your network and duplicate the traffic that way. Or it could serve as a pivot point.

There’s a number of things it can do, but basically the idea is can you detect or are you protected against a rogue device or an internal intruder? An internal intruder example that might be, let’s say I walk into a dentist office, I’m waiting for my appointment, I’m sitting in a chair in the waiting room and I’ve got my laptop. I’m kind of bored because I’m waiting a long time, but I noticed there’s an ethernet jack exposed in the wall behind me. Let’s say I plugged my laptop into that jack, and I just started screwing around and see what I can see on the network. If I can scan the network and maybe exploit a device on the network, on that dentist’s network, that’s from an internal intruder perspective.

Those are why we would do a black box penetration test. In summary, what we talked about are black box penetration test. The black is the least amount of information between from gray to white. You have limited knowledge, unauthenticated. A black box penetration test can be used to emulate an external attacker as well as an internal attacker or internal rogue device. That’s basically it. The black box is really the simplest type of penetration test, and it should definitely be something you consider. If you have any questions about black box penetration tests, you can leave them beneath the video. You can also subscribe to our channel. And if you’re interested in a black box penetration test against your environment, you can contact us at www.bluegoatcyber.com. Thanks. Have a good one.

Gray Box Penetration Testing Explained

Gray Box Penetration TestingThis blog post is a transcript of Christian Espinosa’s explanation of Gray Box Penetration Testing, which covers the following:

  • Differences between Black, Gray, and White Box Penetration Tests
  • Gray Box = Authenticated “User” level tests
  • Internal vs. External Gray Box Penetration Tests
  • Often includes Black Box Testing
  • Gray Box Threats Emulated
    • Compromised User Account
    • Malicious Insider

Check out my latest book: https://christianespinosa.com/books/the-smartest-person-in-the-room/

In Dec 2020, Alpine Security was acquired by Cerberus Sentinel (https://www.cerberussentinel.com/)

Need a penetration test? Connect with me: https://christianespinosa.com/cerberus-sentinel/

Complete Gray Box Penetration Testing Video Transcript

What’s going on. This is Christian Espinosa with Alpine Security. In this video, we’ll go over gray box penetration tests. These are the topics we’ll discuss. The differences between black, white and gray box. A gray box falls between black and white box penetration tests. So with a black box penetration test, you typically don’t know much about the target other than maybe the IP address or the URL. That’s really about it. A black box is considered unauthenticated. You don’t know much about the target. With a gray box, you know a little bit about the target, pretty much from the perspective of the user, your user on the target. So you have user-level access to the target. With white box, you know quite a bit about the target. So you may have access to the network diagram, schematics, design documents, source code, administrator-level access, et cetera. Black have pretty much little limited access, gray in the middle, then white.

As the next bullet there says, gray box, you have authenticated or credentialed user level access to the system. There’s really two broad categories for gray box penetration testers, internal and external. We’ll go over those in the next couple of slides. The threats we’re trying to emulate, which with a penetration test, you’re trying to emulate some sort of threat. The threats we’re trying to emulate with gray box typically are these two threats we have listed on the slide there. A user account is compromised. So let’s say I’m Larry. I’m a user on your web application. What can the attacker do from Larry’s account’s perspective? Or I’m Nancy, a user on your active directory domain, and my account is compromised via a phishing email. So what can the attacker do from Nancy’s perspective on the internal network? What if Larry is just malicious, or what if Nancy, she’s malicious as well? Those are the threats we’re trying to emulate.

For external gray box penetration tests, typically, and this is where the categories I’ve mentioned, we have external and internal. Typically with external gray box penetration tests, it’s against some sort of web application. A common example as we have here on the slide is a patient portal. So a lot of hospitals and clinics have a patient portal. This is if you’re a patient, you can log on, pay your bill, look at your last visit, look at the details, maybe schedule an appointment, et cetera. With a gray box penetration test, what we’re trying to do is test the patient portal in this scenario from the perspective of, like I mentioned earlier, a compromised user or a malicious user. So if I am Larry and I’m logging on to the patient portal as Larry. From Larry’s account, what can I get access to on the patient portal? If there’s a vulnerability, can Larry, for some reason, exploit that vulnerability and somehow get access to Pam’s account, for instance? Because it would not be good if Larry can horizontally get access to Pam’s account and then read Pam’s medical history. That’s an example of a horizontal privilege escalation.

The other scenario is what if Larry can somehow exploit a vulnerability on the patient portal and get admin or root level permissions? Larry can see everybody’s information, including Pam’s, Sam’s, Dan’s, et cetera. So that would not be good. With a gray box penetration test, we look at the vulnerabilities of the application from the perspective of the user.

Let me give an example here. I’ll bring over a patient portal here. This is just an example. If I go to Google and search for patient portal, you’ll see quite a few of them pop up here. I just went to the first one right here. This is a whatever, NextGen Healthcare, it doesn’t really matter. But right now, if we’re looking at the patient portal and we’re not logged in, and let’s say we do some testing, this would be black box penetration testing. Once we’ve logged in as a user such as Larry, then we would be testing it from a gray box perspective. An example like let’s say from a black box perspective, if I type in tick or one equals one dash dash and I just put whatever here as a test for a SQL injection, that’s a black box test. With a gray box, we would test a lot of different things, but logged on as Larry, as I mentioned.

With Alpine security, we include the black box portion of testing with our gray box because we tested from both an unauthenticated perspective and an authenticated perspective. So that’s an example of an external gray box penetration test.

The other type of gray box penetration test is an internal gray box penetration test. With an internal box penetration test, what we’re looking at is what sort of damage could an internal user do with user level permissions on an internal network inside a firewall such as an active directory domain? If Sally’s computer was compromised or Sally clicked on a phishing email and her account was compromised, from the perspective of Sally’s credentials, which are user level credentials, what could the attacker do? Could the attacker somehow get access to sensitive data? Could they get access to Bruce’s account? Could they somehow find a vulnerability and exploit it on the network that gave them administrator level permission, such as domain admin, et cetera? So we’re looking at it from that perspective, and we’re also looking at from the perspective, like what if a Rodrigo, let’s say, is malicious and Rodrigo wants to steal secrets and send them to China? If Rodrigo is a malicious user, what can Rodrigo get access to using his user-level permissions? That’s the other sort of use case or threat we’re emulating.

Another use case is, let’s say a user’s laptop was compromised. Let’s say Jessica takes her laptop home and her boyfriend who was a spy for Russia, let’s say, gets his hands on the laptop. If the boyfriend, the spy from Russia, gets the hands on Jessica’s laptop and that boyfriend can get into Jessica’s laptop, let’s say the boyfriend’s name is Ivan. Ivan can get into Jessica’s laptop as Jessica, or Jessica leads the laptop unlocked. What sort of damage could Ivan do to that laptop or to the systems the laptop has access to? So if the laptop can VPN into the corporate network, what can Ivan get access to as Jessica? Also, Ivan can try to get access to secret stuff on the laptop. Can he escalate privileges to local admin on the laptop? Can he circumvent controls, et cetera? So again, that is an internal gray box penetration test, and we’re looking at it from the perspective of really two broad categories of threats. A malicious user or a compromised user that really didn’t mean to be malicious but their account was compromised.

As a summary, we talked about these main points here, the differences between black and white and gray. Gray is in the middle, black you have limited information, maybe just an IP address or URL. White, you have a lot of information. Gray, you have user level information and user level access. Which is also authenticated or credentialed. We explained a little bit the differences between internal and external. External is typically with a web application such as a patient portal. We’re testing if we can escalate privileges horizontally or vertically. With internal, we’re testing from a domain user or internal user, typically inside your firewall, and we’re seeing what we can do. Same concept from escalating privileges, horizontally or vertically, and what data an insider or internal user can get access to.

If you have any questions about gray box penetration testing, you can leave them beneath the video. If you are interested in us performing a gray box penetration tests against your environment, either externally or internally, you can contact us at alpinesecurity.com. You can also subscribe to our channel. If you just want to learn more about penetration testing, feel free to reach out to us or take one of our classes.

Check Out The Smartest Person in The Room

White Box Penetration Testing Explained

white box penetration testing - christian espinosaThis blog post is a transcript of Christian Espinosa’s explanation of White Box Penetration Testing, which covers the following:

  • Differences between Black, Gray, and White Box Penetration Tests
  • White Box = Full knowledge about the target
  • White Box is typically used during development or system integration
  • Often includes Black and Gray Box
  • Threats emulated:
    • Poor coding practices
    • Supply chain issues

Check out my latest book: https://christianespinosa.com/books/the-smartest-person-in-the-room/

In Dec 2020, Alpine Security was acquired by Cerberus Sentinel (https://www.cerberussentinel.com/)

Need a penetration test? Connect with me: https://christianespinosa.com/cerberus-sentinel/

Complete White Box Penetration Testing Video Transcript

Hello. This is Christian Espinosa with Alpine Security. In this video, we’ll cover white box penetration tests. This completes our series, the three video series of the different colored boxes of penetration tests. We already did a video on both the black and gray box penetration tests. With a white box penetration test, we know the most about the target. Just a quick review. With a black box, we know very little about the target other than maybe the target’s IP address or URL. With a gray box, we know a little bit more than a black box. We often have user-level access to the target such as a user-level account on a web application, or maybe an active directory user-level account. With white box though, we know the most about the target. Sometimes with white box, we have root-level or administrator-level permissions.

We also often have access to data-flow diagrams, entity-relationship diagrams, maybe even the source code, maybe even access to the developers that are actually producing the software, or developing the software, or the product. Typically, with a white box penetration test, this is most often used during development of software or a product. It’s much more beneficial to have somebody from a penetration testing team working with your developers during the development process than waiting until your product is released and then hiring a penetration testing team to poke holes in it after it’s already been released. It costs a lot more money to fix it, and it’s much more difficult to fix after it’s been released. That’s why a white box is typically done as part of the development cycle for a product or software.

It could also be performed during system integration. Let’s say you’re a systems integrator, and you integrate different subsystems from different suppliers. You integrate all that into your overall system. You have to have some degree of trust that your suppliers are actually designing their components to your specifications, and that what you’re getting from them is secure. So before you integrate that, or as you’re integrating that into your overall system, you should do some white-box testing to make sure this component you get for instance, only has the inputs you specify, and the outputs you specify. There’s no extraneous data going through that component or originating from that component.

That would be an example of when we would do a white box penetration test for systems integration. Also, a white box penetration test typically includes a gray box and a black box because as we’re going through this process, and we’re looking at what’s being developed, we often do the test from both the aspect of unauthenticated and user-level access, which is gray. The threats we emulate for a white box, typically we’re trying to discover poor coding practices. A white box perpetration test, as I mentioned, is typically performed during software development. This is the prime time to discover a input validation problem or a balance checking problem. The perfect opportunity is during the development.

As I mentioned earlier, if we wait to hire the penetration testing team until after development’s done, and they find out we have a problem such as a input validation or a buffer overflow attack that our software allows to happen because of a vulnerability, that is much more costly to fix than if we could have identified it upfront. The other threat that the white box penetration test helps with is any issues in the supply chain. As I mentioned earlier, we often do white box penetration tests to a systems integrator, so if one of your suppliers in the supply chain has a vulnerability that is introduced somewhere along the supply chain, and that component makes it into your overall system, this is the perfect opportunity to test this before it’s released again, out to your customers.

If you have any questions about white box penetration testing, you can leave them as a comment beneath this video. If you’re interested in a white box penetration test, you can contact us at www.alpinesecurity.com. I hope you enjoyed this video, and I’ll talk to you later on. Cheers.

Check Out The Smartest Person in The Room