fbpx

hacking

3 Steps to Hide Data in an Image Using Steganography

image-containing-steganography
Image containing a hidden file using steganography techniques

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:

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 Source: http://hdgreatimages.com/wp-content/uploads/2016/04/Bridge-HD-Backgrounds.jpg

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

 Source: https://pbs.twimg.com/profile_images/466984253255729152/8yMo8O4K.jpeg

jphide and jpseek

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

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

 Selecting the Input (Cover) file in JPHS for Windows
Selecting the Input (Cover) file in JPHS for Windows

 

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

 Selecting the Hide file in JPHS for Windows
Selecting the Hide file in JPHS for Windows

 

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):

 Saving the Steg'd file in JPHS for Windows
Saving the Steg’d file in JPHS for Windows

 

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”:

stego'd images

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

 Original image on the left. Steg'd image on the right. Can you see any difference?
Original image on the left. Steg’d image on the right. Can you see any 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”:

 Saving the hidden file as
Saving the hidden file as “secret.jpg” in JPHS for Windows

 

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

 The extracted image
The extracted “secret.jpg” is the same as “kitten.jpg”. Our steganography example worked!

 

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”:

 Double-click Picture Compare
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:

 One example of where the pixels differ is shown above - the pixel on the left has RGB:47,109,184, on the right it is RGB:47,109,186
One example of where the pixels differ is shown above – the pixel on the left has RGB:47,109,184, on the right it is RGB:47,109,186

 

Resources

Files used/referenced in this blog:

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.

Leetspeak: The History of Hacking Subculture’s Native Tongue

leetspeakYou’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.

Hacking Medical Devices for Profit and Terror

hacking medical devicesIntroduction

This post focuses on four medical device cybersecurity attack objectives:

  1. Stealing Protected Health Information (PHI) (Motive: Financial Gain)

  2. Ransomware (Motive: Financial Gain)

  3. Harming or killing a patient (Motive: Terrorism or Assassination)

  4. Using the medical device as a beachhead for enemy advancement (Motive: Foothold to Expand Operations)

In this post, I will cover a little background on why medical device security is something to pay attention to, elaborate on the four attack objectives, and provide some solutions.

Background

Unsecured medical devices and the Internet of Medical Things (IOMT) are major cybersecurity concerns. These devices are typically deployed in hostile hospital and clinic environments. Yes, I said hostile. Why hostile? Most hospital environments, despite “HIPAA Compliance” remain vulnerable. I know this based on many penetration tests of both hospital and clinic environments. Compliance has little to do with security. Yet, compliance is often both the minimum and maximum effort organizations put towards cybersecurity.

Attacks against medical devices are either unintentional or intentional. Unintentional, often referred to as non-directed attacks, are broad, non-targeted attacks by malware that is spreading in the “wild” by broad phishing schemes or simply lateral movement. Lateral movement is when an infected system spreads the malware to other vulnerable systems on the same network or environment. Intentional attacks also referred to as directed attacks, are targeted attacks by an entity with a specific objective.

In cybersecurity, there are generally three areas we care about – confidentiality, integrity, and availability. These are often referred to as the CIA triad. The idea is if you increase one, the others may suffer, so there has a be a balance. For instance, if I focus on confidentiality and make everything super secure (encrypted, require multiple factors to log on, etc.), then availability may suffer. The balance should be based on risk.

Medical Device Hacking Objectives

1 – Stealing Protected Health Information (PHI) (Motive: Financial Gain)

Many medical devices contain PHI that can be stolen directly from the device, or a compromised medical device can be leveraged to obtain PHI. For instance, a medical device may be connected to an Electronic Medical Records (EMR) system. The trusted connection between the medical device and the EMR could be leveraged by an attacker to siphon PHI from the EMR.

PHI is often stolen using targeted attacks, but can easily be stolen by a non-targeted attack, where the malicious software (malware) happens to land on a vulnerable system containing PHI. A targeted PHI attack could be an attack to get “dirt” on a celebrity or politician to blackmail them or try to smear their reputation. An example of this would be to steal records for sexually transmitted diseases (STDs) at places celebrities may have received testing.

Type of Attack: Typically non-directed, although may be targeted.

CIA Triad Affect: Confidentiality.

2 – Ransomware (Motive: Financial Gain)

Ransomware is quite common in hospitals and clinics and has actually been linked to an increase in fatal heart attacks. According to a post on the krebsonsecurity.com:

“The researchers found that for care centers that experienced a breach, it took an additional 2.7 minutes for suspected heart attack patients to receive an electrocardiogram.”

Ransomware is typically a non-targeted attack, seeking as many vulnerable victims as possible. Many medical devices run older operating systems, such as Windows XP embedded, Windows 7 embedded, or an older version of Linux. These older systems make them vulnerable to these types of attacks.

Type of Attack: Typically non-directed, although may be targeted.

CIA Triad Affect: Confidentiality and Availability.

3 – Harming or killing a patient (Motive: Terrorism or Assassination)

As mentioned previously, ransomware can impose delays in treatment that can result in deaths, even though this is not the motive.

Harming or killing patients motivated by terrorism or a targeted assassination typically involves altering the logic of a medical device or controlling the device to create the desired effect. An example of terrorism is hacking into hospital patient monitoring systems to alter all the patient readings – to “flat-line” them all to create a panic and force the use of an alternative system or method.

An example of an assassination is what Dick Cheney was afraid of – someone hacking into his pacemaker to cause it to stop working or shock his heart to death.

Type of Attack: If Terrorism, could be non-directed. Assassination will be targeted.

CIA Triad Affect: Integrity and Availability.

4 – Using the medical device as a beachhead (Motive: Foothold to Expand Operations)

Many vendors only care about the cybersecurity of their device, focusing only on vulnerabilities that can directly affect the CIA of their medical device. Often a vulnerability in one device that may not directly affect that device can be leveraged as a beachhead to expand hacking operations by putting a sleeper cell in friendly territory. When needed, that sleeper cell can be called upon by the hackers to wreak havoc.

An example of this is an unnecessary service, such as FTP, that is running on a medical device. The service has a vulnerability that doesn’t directly affect the operation of the medical device, but could be leveraged for future attacks by providing a point inside a friendly network that an attacker can use to amass attacks from inside a perimeter.

Type of Attack: Typically non-directed, although may be targeted.

CIA Triad Affect: None.

Solutions

It’s best to move from uniformed optimism to informed realism. Medical device manufacturers are excellent at making their devices reduce diagnosis time, helping a physician, or solving a medical issue. Cybersecurity is usually not an area of expertise or a concern for a medical device manufacturer. It’s understandable to see the world through the uninformed optimism lens when there is limited awareness of what is possible from a cybersecurity attack and risk perspective.

The move to informed realism typically involves hiring the right cybersecurity experts that see the world differently, that look at the medical device through the lens of a hacker. They view the medical device not as a medical tool or aid, but as a system to exploit with the same objectives we discussed in this article. Hiring trusted, ethical hackers to proactively assess and test a medical device before it is deployed to a hostile healthcare environment is prudent and now mandated by the FDA.

Medical devices are behind the curve with cybersecurity but are slowly catching up. Thanks to the FDA, organizations like Archimedes and many security researchers, the real consequences to patient safety caused by vulnerable medical devices are starting to reach the right ears and be taken seriously.

Need help securing your medical device? Connect with me.

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


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