In this post we’ll explain a simple method to hide data (any type of data – text, image, malware, etc.) in a JPEG. This is a form of steganography. Steganography is the art and science of hiding something in plain sight. Why hide something in plain sight – overtly hide something? To not tip anyone off that there is a secret message or hidden data.

This post focuses on a technique, rather than a history lesson on steganography, so on to the gist…

1. Download and extract the JPHS (JPEG Hide and JPEG Seek) tool:

• gwdg.de site

2. Download a cover image (the image you will hide the data inside of) and a hide image (the image you will hide inside the cover image):

The cover image should be roughly 10 times the size of the hide image.  In our example, we will use a HD Background as the cover image and a picture of a cute kitten as the hide image.

• Cover Image – background.jpg (found doing a Google search for “hd backgrounds”):

Source: http://hdgreatimages.com/wp-content/uploads/2016/04/Bridge-HD-Backgrounds.jpg

• Hide Image – kitten.jpg (found doing a Google search for “lilbub”):

3. Run Jphswin. Accept the terms. Do the following:

Click on “Open jpeg”, select “background.jpg” and click “open”:

Click on “Hide”, enter a passphrase, click “OK”, then select the hide file (kitten.jpg), and click “Open”:

Save the steg’d file (the kitten.jpg file hidden in the background.jpg file) as another file name, so we can compare the new file containing the hidden data with the original file. Click “Save jpeg as” and use the file name “bridge.jpg” (or something different than the original name):

You should now see 3 files – the “background.jpg” should look the same (to the naked eye) as the “bridge.jpg” even though the “kitten.jpg” file is hidden inside “bridge.jpg”:

Open both “background.jpg” and “bridge.jpg” side-by-side in Windows Photo Viewer to see if you can tell a difference:

Congratulations! You’ve just practiced steganography.

Validation

Let’s validate our steganography demonstration actually worked by extracting the “kitten.jpg” from the “bridge.jpg”:

Using JPHS for Windows, select “Open jpeg”, select “bridge.jpg”, click “Open”:

Opening the image containing the hidden file in JPHS for Windows

After you opened the “bridge.jpg” file click on “Seek”, enter the passphrase you used to hide the file, click “OK”, then save the hidden file as “secret.jpg”:

Verify the “secret.jpg” file is the same as the “kitten.jpg” file by opening “secret.jpg”.

To validate which image pixels JPHS for Windows modified to hide the image in the cover image, you can use Beyond Compare to visually depict the differences. Download and install Beyond Compare.  If you receive an “Error creating registry key:” you need to install as an Administrator.

Run Beyond Compare. On the left side, select “New”, the double-click “Picture Compare”:

Open the original picture (background.jpg) on the left window in Beyond Compare and open the steg’d picture (bridge.jpg) on the right window.  The comparison should be in the bottom window:

Resources

Files used/referenced in this blog:

• JPHS for Windows (This application is included in the jphs_05.zip)

• background.jpg

• kitten.jpg

• bridge.jpg

• secret.jpg

The post 3 Steps to Hide Data in an Image Using Steganography appeared first on Christian Espinosa.

Penetration 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

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.

The post Penetration Testing History appeared first on Christian Espinosa.

You’ve probably seen leetspeak, also known as 1337 or “l33t,” somewhere on the Internet or in a movie about computer hacking. It’s essentially regular English, but with more hacker slang and with certain letters changed to numbers.

Leetspeak – An Origin Story

Developed in the early 1980s, leetspeak actually predates the World Wide Web by nearly a decade. It started on Bulletin Board Systems when the Internet was first developing and only people with elite status could access certain content.  That content often included information that those elites didn’t want anyone outside their circles to find.

Outsmarting the System

In those days, search functions scanned for specific keywords to identify their targets. Early hacker communities figured out that changing a few of the letters within a word could throw the search engines off the proverbial scent.  By using “h3ll0” for “hello,” for example, they could protect the privacy of their content while keeping it readable among themselves.

The Mark of an “3l33t”

As leetspeak became more well-known, gamers began to use it to present themselves as high status. The phrase “1 4m 3l33t!” (or, “I am elite!”) became a popular way for both gamers and hackers to show that they had reached the top of the pack.

Levels of L33t

Th1s s3nt3nc3 1s wr1tt3n 1n b4sic l33t. (“This sentence is written in basic leet.”)

It’s pretty understandable, even to someone who isn’t well versed in the world of computer hacking. All you do is get rid of vowels and substitute numbers that look similar.

The Next Step

Intermediate-level leet starts to get the consonants involved, and it looks “50meth1n9 l1k3 th15.” It’s more challenging to read than basic leet but still decipherable, particularly to eyes and brains that are already familiar with the basic form. A 5 looks enough like an S, for example, that a reader can go from “is” to “1s” to “15” without excessive confusion.

Advanced Leet

Advanced leet brings in yet more replacements, including more replacements per letter.

If you read a message in basic or intermediate leet, the replacement for the letter E will almost always be the number 3. Once you get into advanced leet, however, you have a lot more options. You can still indicate E using 3, but you can also use &, €, ë, and even |=-. Just the word leet has dozens of possible translations, from the classic l33t to |_&€”|”.

Your Basic L33t Vocabulary

As with any dialect, there are words that anyone who is “in the know” has to have in their vocabulary. Many of them have to do with status. (Specifically, the speaker being of a higher status than others.)

“Pwn”

“Pwn” is one of the most popular leetspeak words in hacker culture. It’s an intentional typo of “own,” a word that the early hackers of the 80’s used to mean taking over control of another computer.

Urban legends offer a number of explanations for how the shift from “own” to “pwn” happened. Some say that it has always been an intentional misspelling, while others say that it was an honest mistake that took off in common usage.

In either case, it’s become a popular way to express your victory or defeat. While you can definitely “pwn” someone, it’s also common to admit that you “g0t pwned.” It’s usually pronounced “got poned.”

“N00b”

N00b, or “noob” in non-leetspeak, is a shortened form of “newbie.” Programmers and hackers started calling people “newbies” around the same time that they started “owning” each others’ systems. And like “own,” the word newbie evolved into noob and n00b.

The new spellings are specifically derogatory. Being a “newb” simply means that you’re new at something, which is perfectly fine in and of itself. If someone’s calling you a “n00b” or “noob,” however, that usually means that they think you’re not only new or unskilled but also disrespectfully content to be ignorant.

Haxor

Like the first leetspeak words, “haxor” expresses the speaker’s claim to the hacking community. It literally means “hacker” or even “to hack.”

The term “haxor” usually refers to a particularly advanced hacker (or haxor) and may even be used in reference to leetspeak itself. For example, “that haxor always types haxor.”

Leetspeak Out in the World

Even now, leetspeak continues to evolve and make its way into new corners of our perpetually connected society. Google even uses it to communicate with members of the general public, but with an insider nod to hacker culture.

Google’s Bug Bounty

The Google Vulnerability Reward Program (VRP), known colloquially as its “bug bounty,” offers rewards to users who can identify and draw Google’s attention to security vulnerabilities that can compromise user data.

If a user finds such a vulnerability in a qualifying Google site, the specifics of which are detailed on the VRP website, Google will offer a financial reward. Reward amounts range from $100 to $31,337. Remove the comma and the dollar sign from that maximum amount and you have “31337.”

Or, in non-leetspeak, “eleet.”

Hacker Movies

Hacker culture even has its own filmography. A quick Google search for “hacker movies” will give you lists of what dozens of people believe to be the best. Popular titles include:

• Untraceable (2008)
• The Italian Job (2003)
• The Matrix (1999)
• Hackers (1995)

One recent example is the movie adaptation of the novel Ready Player One, the story of one gamer’s search for the industry’s biggest “Easter egg.” The book and the movie both include characters with leetspeak names.

These characters are employees of the big bad corporation, IOI. They are known as the “suxorzs,” or the “sux0rz.” The word is a leetspeak translation of “sixers,” a nickname given because of their avatar names are also their six-digit employee numbers. It is also the leetspeak term for “this sucks.”

Leetspeak and You

Some people take to leetspeak like a natural second language. These are the people who might go on to pursue a career in hacking – and yes, it is possible. Even legal.

The first step is training in cybersecurity and penetration testing. Through professionally designed courses, like those offered by Cerberus Sentinel, you can learn the techniques that hackers – sorry, haxors – use to access today’s systems.

Go ahead – build a career that will let you pwn the h4x0rs. Also, develop some people skills while you’re at it – read my book “The Smartest Person in the Room” to learn how.

The post Leetspeak: The History of Hacking Subculture’s Native Tongue appeared first on Christian Espinosa.

The post Hacking Medical Devices for Profit and Terror appeared first on Christian Espinosa.

This 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 71.14.247.83. 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, 71.14.247.83. 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.

The post Black Box Penetration Testing Explained appeared first on Christian Espinosa.

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

The post Gray Box Penetration Testing Explained appeared first on Christian Espinosa.

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

The post White Box Penetration Testing Explained appeared first on Christian Espinosa.