A look at methods that can be used to hide private data inside images and a brief discussion on methods that could be employed to discourage these activities.

1. An Introduction to Mitigation for Data
Hiding in Loss-less Images
by Thomas Brown, CISSP
Prologue:
To the untrained eye the two image snippets below may appear to be the same. In reality one
of these two images is hiding a secret. A portion of the plain text of Edgar Allen Poe’s poem
“The Raven” cleverly disguised as image data. Although the trained eye may spot some
differences, it is likely that this is only because of the 8x zoom level that allows minute
differences to be detected. As the level of zoom is decreased, the differences become almost
impossible to detect. Once the images are viewed in their native format, the two full-sized
images appear identical. With the obvious understanding that the text in this example is not
sensitive, the same process could be used to hide sensitive data inside publicly available
sources through computer manipulation. As data breaches continue to shape the lives of
people across the globe, preventing the transmission of sensitive data outside of carefully
crafted fences within organizations will become an increasingly important activity that will
require increasingly sophisticated methods. This is the landscape that security professionals are
now faced in the continued war against malicious steganography.
The study of steganography can be traced back to at least the late 15th
century1, with practical examples existing for an indeterminate time
before. The playing card to the right is a part of a marked deck where
the suit and number of the card can be determined by a slight change
in pattern that is intended to escape the notice of other players. Other
deck styles (such as the Bicycle brand) can hide marks in the intricate
floral patterns in the deck’s design. Although marking cards can be a
tiresome and tedious task for the common cheater, the ability to easily
create documents and images with complex data items has come into its
own with the advent of the modern computer. In the current hyper-
connected society where data files are constantly being offered for
anyone in the world to view over the internet, the potential data that can be transferred
outside of corporate firewalls without anyone’s knowledge using data hiding techniques should
be a growing concern. It is the intention of this discourse to discuss some of the methods that
can be employed to hide sensitive data inside public data files and mitigations that may help to
prevent unauthorized distribution of data outside of corporate control.

2. The Nature of the Challenge:
The amount of data that can be stored in a single image without detection will vary by the
method of obfuscation, the presence of encryption and the number of attributes that are
modified per pixel to store the data. In the example given in the prologue (which does not
include encryption and which has the data stored at the rate of 3 bits per pixel) the full text of
The Raven with carriage returns and spaces took fewer than 9 rows of the 1080 available. In a
perfect case scenario this would allow just over 777,000 bytes of data to be stored in a single
high-res picture. The same parameters would allow for the transmission of over 45,000 credit
card numbers or over 8,800 credit card numbers with up to 70 characters worth of other useful
data fields such as name, zip code or phone number. Being able to hide data within an image is
all possible because of the way that colors are defined in lossless images and because of the
concept of most significant and least significant bits. Looking at the red colored blocks below,
which blocks appear virtually identical? Most viewers will admit that they appear to be the
same even though they have different color values.
Base Bit 1 Bits 1 & 2
255,0,0 254,0,0 252,0,0
11111111,00000000,00000000 11111110,00000000,00000000 11111100,00000000,00000000
In the more expansive example to the right,
single bit changes in red, blue and green are made
and yet it is apparent that the difference in shade
remains modest to imperceptible.
If the number of bits used to hide the sensitive data
is increased from one to two, the amount of data
storage available doubles as well. The pictures
below are included to show what the net effect is on an image when the two least significant
bits have both been set to zero. It is at this point that the differences can be seen on most
monitors as the lower picture on the left (original) appears lighter than the top picture. The
circled areas on the right hand are intended to highlight the area of the original picture that the
left hand shots were taken from. Without hyper-zooming into the picture, the change in
brightness is much less marked. If data (rather than zeroes) was encoded into the pictures, the
darkening effect would likely be significantly lessened as the embedded data would only add
minor brightening to some pixels and minor shading to other pixels while leaving some pixels
unchanged.
R+0
G+0
B+0
R+1
G+0
B+0
R+1
G+1
B+0
R+1
G+0
B+1
R=140
G=120
B=100
R+0
G+1
B+0
R+0
G+1
B+1
R+1
G+1
B+1

3. The Nature of the Challenge (continued):
If the characters are mapped to a more efficient encoding than the 8 bit ASCII table, the data
can be even further compacted and the result would resemble a rudimentary encryption.
Imagine for a minute a scheme to hide credit card information with names, numbers and
expiration dates. The data to encode would be the twenty-six letters (no need for both capitals
and lower case), ten numeric digits and a couple of separators (space, hyphen, tilde …). Using
just six bits (as opposed to the traditional eight), sixty-four values are possible from zero to
sixty-three. This change allows for 25% more data to be stored in the same file size. The
translation map could then be linear, or random as seen in the table below:
Character NumberValue
0 1 2 3 4 5 6 7 8 9 1
0
1
1
1
2
1
3
1
4
1
5
1
6
1
7
1
8
1
9
2
0
2
1
2
2
2
3
2
4
2
5
2
6
2
7
2
8
2
9
3
0
3
1
Lin
ea
r
0 1 2 3 4 5 6 7 8 9 A B C D E F G H I J K L M N O P Q R S T U V
Ra
nd
o
m
3 B I N 8 C 0 O H S 2 A X 9 7 J Z 1 W Q L D P Y U 4 G M R 5
In the practical example to follow, the data is turned into a bit stream of 1s and 0s which are
then inserted into the color information. How the information is encoded prior to insertion into
the media is irrelevant to the insertion process. As long as both the encoder and the decoder
use compatible methods, the data can be retrieved. This degree of modularity allows data to be
stored with changing parameters to escape detection and may allow multiple data threads to
be interlaced into the same image.
Two bit change
Original image

4. A Practical Example:
A theoretical discussion about changing individual bits might be interesting from a cerebral
standpoint but, without a practical solution that simplifies implementation of the data breach,
the risk would remain low and the need to seek mitigation would remain small. Unfortunately,
any programming or scripting language that can directly access image color data on a per pixel
basis can be used to create both the encoding and decoding procedures. As a part of this study,
the Python programming language was used with the Pillow implementation of the Python
Image Library (PIL) to perform testing (usage of the Pillow library is not a requirement, but does
make the encoding significantly easier). The Python code for both the encoder and the decoder
was cobbled together in a few hours with neither piece requiring more than 40 lines of code.
Although different procedures could be used for encoding, the following method proved
effective:
1) Read in the desired information as a byte string.
2) Convert the byte string to a bit string (1’s and 0’s).
3) Open the image using the Pillow module.
4) Using a predetermined pattern, read the color data as a four-part tuple (R, G, B, A).
5) For each pixel / desired color or alpha layer
a. Shift the bits to the right by the number of bits that will be used and then
shift them back to the left the same number of bits (this sets the bits that will
be modified to zero).
b. If the next bit from the bit string is one, overwrite the bit with the bit from
the string.
6) Save the modified image.
The decoder basically performs the actions above in reverse order:
1) Data bits are read from the color data into a bit string.
2) The bit string is converted into a byte string.
3) The subsequent byte string is saved or displayed.
Observing that the coding required to hide data is not difficult to create or obtain and that the
amount of data that can be stored is sufficient enough to merit the effort, performance
considerations would appear to be the remaining technical barrier. Unfortunately, a quick
check of performance shows that a full-size HD image (1920 x 1080) can be completely filled
with encoded data in under 3 minutes using a standard corporate-level workstation running
interpreted code.
In summary, as there are few (if any) technical barriers to protecting data from being shared
with unauthorized individuals through steganography and as mitigation through human factors
such as desire, opportunity and determination are often beyond realistic controls, it is
important that other strategies be considered to help mitigate this risk.

5. Mitigating the Risk:
In a well-managed corporate infrastructure where operators do not have elevated rights on the
systems they use, access to privileged data files is controlled and storage devices are not
allowed to be connected to workstations, there may still be opportunities for users to take
advantage of steganography to distribute classified information to unauthorized individuals. To
prevent this type of data breach, the following methods may provide additional protection.
Web servers:
Almost every page and graphic served from a company website to the internet was unpublished
company data at one time. The act of publishing data to a web accessible location exposes that
data regardless of whether the page or graphic is indexed or linked. If the data is acceptable for
public disclosure there is likely no harm in this exposure, but care must be taken to avoid
disclosing sensitive information that has been hidden in these publicly facing sites through web
servers. Below are some of the ways that this threat might be mitigated:
1) Limit the data in published web folders to files that are needed for the website to
function. Previous versions of html files, outdated data files and unused images should
be moved to a location that is not published. UAT and development sites should be
limited by firewalls or other controls to specific individuals or internal networks.
2) Limit the use of lossless picture formats such as png, bmp and lossless jpeg (jpeg 2000).
Compressed formats can be more difficult for storing hidden data as the act of
compressing the data changes the color values to approximations. On the IIS web server
(version 7 and above) this can be enforced by configuring forbidden files at the
application level in the web.config file or on a global level in the applicationHost.config
file2. In Apache the same configuration can be set using the httpd.conf file3.
3) Clear EXIF data from images as they are served from web servers or force all images to
have the same EXIF data. EXIF data is text data that is intended to include information
about a jpeg picture. This information can be overwritten without significant difficulty to
include sensitive data. On png files, keywords provide the same functionality and pose
the same concerns.

6. Mitigating the Risk (continued):
4) Limit the size of banners, logos and other pictures to the maximum size they will be
displayed on the web page. By limiting the size of pictures served through web sites, the
amount of data that can be stored is proportionally limited as well. Although large
images can be dynamically resized using HTML, the entire image is download to the
client system and then resized. As an example, on one website an employee-provided
head-shot is displayed at 156x201 pixels. A correctly-sized image would only allow about
16000 characters to be exposed using a single LSB and all three colors. The image is
stored on the web server and served to clients using a resolution of 2000x3000 pixels.
This image can be downloaded by right-clicking the image and saving it to disk. Using
the conservative encoding methods, 2.25 million characters could be hidden in the
image. NOTE: not only is the smaller image more secure and uses far less bandwidth (46
KB vs 2.1 MB), but, in this example, the proportions of the picture as specified in the
HTML do not match the proportions of the image file. This distorts the picture that the
client system displays in an unfavorable manner.
5) Don’t use images to display information that could easily be created as text on a page. In
one example, a 198x124 graphic was enlarged to 993x300 to allow for text and buffer
space to be included. Using actual text instead of the graphical approximation of text
produces characters that are easier to read and reduces the size of the images (which
reduces exposure).
6) Perform a periodic sanity check on image file sizes. It is possible that data can be stored
in multiple locations in an image file including the color index. If an image is significantly
larger than expected, the EXIF data or color index may have been altered.
7) Only allow specific servers to host websites. Block common internet ports on all other
servers (especially if they reside in the DMZ). Web hosting offers a one way portal into a
business and should be regarded as a potential delivery method for obfuscated data.

7. Mitigating the Risk (continued):
8) Some other mitigations actions that may not be as feasible, but which could offer a
greater level of security:
a. Keep track of the hash values of larger images that are served on the site to
monitor for changes.
b. Re-encode images before serving them. Literally, run an image conversion on
the graphic files (png to jpg, lossless jpg to standard jpg, gif to jpg, etc.) and then
strip or reset the exif data and re-index any color pallets. Below is an example of
the output of a file that was encoded as png and then converted to jpg (the
original embedded text was an excerpt from “The Raven”)
c. Set the two least significant bits for all colors and alpha channels to zero on
images served across the internet.
Email clients:
Nothing seems more natural today than sending a picture through email. In companies where
USB connectivity is restricted, FTP is blocked and internet browsing is limited, emails can be
used to circumvent almost every restriction. This is especially true with pictures. In order to
prevent the leaking of data through steganography, images must be viewed with the same
critical suspicion as any other data file. Below are some of the ways that this threat can be
mitigated:
1) Block the sending of lossless picture formats such as png, bmp and lossless jpeg.
Compressed formats can be more difficult for storing hidden data as the act of
compressing the data changes the color values in minor ways (alters the values in the
least significant bits). Forcing the users to jpg will not only help to prevent data
breaches, but will also reduce the size of sent messages and message stores.
2) Employ a client-side tool to optimize image files before they are sent.
3) Employ a server-side tool to optimize image and data files before they are sent and after
they are received.
4) To prevent the coding of pictures before a user tries to email the picture out, limit the
programs that are allowed to write images to known and trusted applications using an
IPS. Generally speaking, a windows script or Python-based application has very little
need to write a graphic file.
F j 9 m ' I8 InF 8 J 3U V * d f G MDe &l PI @

8. Prologue
This paper is not intended to be the complete and authoritative guide to protecting against
malicious steganography. As with most security issues, the landscape changes on a daily basis
with new methods used to hide and transmit data continuing to evolve and change as
technology improves and as malicious actors refine their skills. Only a holistic approach to
security with properly applied defense in depth strategies that are regularly reviewed can be
expected to provide reasonable protection against a properly motivated perpetrator. With this
in mind, ignoring the possibility of data transmission through steganography and failing to apply
reasonable controls will only benefit the criminals in our midst and the news outlets that report
their exploits.

9. Works Cited
1"Steganography." Wikipedia. Wikimedia Foundation, 1 Apr. 2016. Web. 15 Apr. 2016.
<https://en.wikipedia.org/wiki/Steganography>.
2Freitag, Pete. "Request Filtering in IIS 7 Howto." Request Filtering in IIS 7 Howto. Pete Freitag,
16 Feb. 2010. Web. 19 Apr. 2016. <http://www.petefreitag.com/item/741.cfm>.
3Ducea, Marius. "Apache Tips & Tricks: Deny Access to Certain File Types." MDLog:/sysadmin -
The Journal Of A Linux Sysadmin. 21 July 2006. Web. 19 Apr. 2016.
<http://www.ducea.com/2006/07/21/apache-tips-tricks-deny-access-to-certain-file-types/>.