GENERATING HIGHLY REALISTIC DECOY EMAIL AND DOCUMENTS

Abstract

A system that generates decoy emails and documents by automatically detecting concepts such as dates, times, people, and locations in e-mails and documents, and shifting those concepts. The system may also generate an email or document reciting a URL associated with a fake website and purported login credentials for the fake website. The system may send an alert to a user of the system when someone seeks to access the fake website.

Description

BACKGROUND

The systems and methods of the present invention may be used to detect and thwart hackers or other unauthorized users of computer systems.

SUMMARY OF INVENTION

The system may process e-mails in son format plus attachments and standalone files within directory structures matching certain specifications. E-mails and files may be processed one user at a time, in sorted order according to timestamps. Within each e-mail or file, dates and times may be detected and shifted according to user-specified deltas, and people's names are detected and shifted according to user-provided templates Formatting may be preserved exactly for .docx files and approximately for .pdf files. Text files and html-formatted e-mails may also be handled similarly. The accuracy achieved for detecting recognized concepts may be high, based on a Bayesian machine learning algorithm for named entity recognition followed by a second phase to exclude false positives. During processing, fake e-mails including enticing content may be occasionally inserted to lure an unauthorized user to reveal themselves by visiting a fake website and entering generated credentials. The system may also be converted to a daemon that runs in the background and automatically detects and processes new users, e-mails, or files as they appear.

BRIEF DESCRIPTION OF THE DRAWINGS

A further understanding of the invention can be obtained by reference to exemplary embodiments set forth in the illustrations of the accompanying drawings. Although the illustrated embodiments are merely exemplary of systems, methods, and apparatuses for carrying out the invention, both the organization and method of operation of the invention, in general, together with further objectives and advantages thereof, may be more easily understood by reference to the drawings and the following description. Like reference numbers generally refer to like features (e.g., functionally similar and/or structurally similar elements).

The drawings are not necessarily depicted to scale; in some instances, various aspects of the subject matter disclosed herein may be shown exaggerated or enlarged in the drawings to facilitate an understanding of different features. Also, the drawings are not intended to limit the scope of this invention, which is set forth with particularity in the claims as appended hereto or as subsequently amended, but merely to clarify and exemplify the invention.

FIG. 1 depicts a directory structure in accordance with an embodiment of the invention;

FIG. 2 depicts a screenshot in accordance with an embodiment of the invention;

FIG. 3 depicts a screenshot in accordance with an embodiment of the invention;

FIG. 4 depicts a flowchart for processing an e-mail or file according to an embodiment of the invention;

FIG. 5 depicts an example of a .pshift file according to an embodiment of the invention;

FIG. 6 depicts an e-mail generated in accordance with an embodiment of the invention;

FIG. 7 depicts a screenshot in accordance with an embodiment of the invention;

FIG. 8 depicts a screenshot in accordance with an embodiment of the invention;

FIG. 9 depicts an original email and the email modified in accordance with an embodiment of the invention;

FIG. 10 depicts a screenshot in accordance with an embodiment of the invention;

FIG. 11 depicts an excerpt from a .docx file and the excerpt modified in accordance with an embodiment of the invention; and

FIGS. 12A and 12B depict an excerpt from a .pdf file (FIG. 12A) and the excerpt modified in accordance with an embodiment of the invention (FIG. 12B).

DETAILED DESCRIPTION OF THE INVENTION

The invention may be understood more readily by reference to the following detailed descriptions of embodiments of the invention. However, techniques, systems, and operating structures in accordance with the invention may be embodied in a wide variety of forms and modes, some of which may be quite different from those in the disclosed embodiments. Also, the features and elements disclosed herein may be combined to form various combinations without exclusivity, unless expressly stated otherwise. Consequently, the specific structural and functional details disclosed herein are merely representative. Yet, in that regard, they are deemed to afford the best embodiments for purposes of disclosure and to provide a basis for the claims herein, which define the scope of the invention. It must be noted that, as used in the specification and the appended claims, the singular forms “a”, “an”, and “the” include plural referents unless the context clearly indicates otherwise.

Use of the term “exemplary” means illustrative or by way of example, and any reference herein to “the invention” is not intended to restrict or limit the invention to the exact features or steps of any one or more of the exemplary embodiments disclosed in the present specification. Also, repeated use of the phrase “in one embodiment,” “in an exemplary embodiment,” or similar phrases do not necessarily refer to the same embodiment, although they may. It is also noted that terms like “preferably,” “commonly,” and “typically,” are not used herein to limit the scope of the claimed invention or to imply that certain features are critical, essential, or even important to the structure or function of the claimed invention. Rather, those terms are merely intended to high-light alternative or additional features that may or may not be used in a particular embodiment of the present invention.

For exemplary methods or processes of the invention, the sequence and/or arrangement of steps described herein are illustrative and not restrictive. Accordingly, it should be understood that, although steps of various processes or methods may be shown and described as being in a sequence or temporal arrangement, the steps of any such processes or methods are not limited to being carried out in any particular sequence or arrangement, absent an indication otherwise. Indeed, the steps in such processes or methods generally may be carried out in various different sequences and arrangements while still falling within the scope of the present invention.

The Decoy Generating System (“DGS” or “RAGS”) of the present invention processes e-mails along with their attachments and other user files in one user directory at a time. The user directories may exist within a specified base directory that is provided to the system. Each user directory may contain a subdirectory called “Email” containing e-mails and (as separate files) attachments; another subdirectory called “Files” may contain other user files. Processed (i.e., shifted) e-mails may be placed in a subdirectory called “Changed Emails,” and processed files may be placed in a subdirectory called “Changed_Files.” This is summarized in FIG. 1. The DGS system may be implemented in Python and may make extensive use of the Natural Language Toolkit (NLTK), a popular platform for building Python applications that process natural language.

All e-mails may be stored in .json format. When the DGS system processes e-mails and files, it may detect dates and times, and shift them according to deltas specified by the user. The current state of the system may also detect people and shift them according to templates specified by the user. Other areas of investigation include the detection of other nouns including locations and organizations.

The system may process one user directory at a time, and within each user directory, the system may process e-mails and files in sorted order according to their timestamps. The system may randomly insert a fake e-mail including enticing content. The content may include the URL of a fake website and login credentials for the website. The user may be alerted, for example via e-mail, if anyone tries to log in to the fake website using credentials associated with the user's account. The system may also run as a daemon that can detect when new user directories, e-mails, or files are added or created, and process them automatically at such times.

A. Training the DGS System

The system may automatically detect concepts including dates, times, people, and locations in e-mails and files, using an approach known as named entity recognition. A “chunker” predicts a category for every token (i.e., word) in a document using a Bayesian machine learning algorithm. Each token may begin a concept (e.g., label B-PERSON), continue a concept (e.g., label I-PERSON), or not be part of any recognized concept (label O). General features used for learning include the token itself, the token's part-of-speech, the next and previous token and part-of-speech (POS), and the previous token's label. Several concept-specific features have been added to improve accuracy (e.g., Boolean features representing the inclusion, or not, in lists of months, lists of names according to the U.S. Census Bureau, etc.). A second phase using hand-crafted rules is applied to eliminate some false positives. For example, predicted dates are excluded if they are not verified by Python's dateutil module, and names of people are excluded if they contain ‘@’, since these are probably e-mail addresses.

The chunker is trained on files that have had instances of each relevant concept manually labeled. A sample training corpus may consists of 94 news documents from the publicly available Information Extraction: Entity Recognition (LEER) corpus, and 100 randomly selected e-mails from the Enron e-mail dataset. Cross-validation experiments may be performed within the training set to evaluate the chunker's accuracy detecting dates, times, and people using standard metrics from the field of natural language processing (NLP). The metrics used may include recall, which indicates the percentage of actual tokens from the category that are correctly predicted to belong to the category; precision, which indicates the percentage of predicted tokens assigned to the category that actually do belong to the category; and F1, which combines recall and precision into a single metric that is closer to the lower of the two. Based on cross-validation experiments, it is possible for the system to achieve F1 scores for dates averaging about 94%, F1 scores for times averaging about 91%, and F1 scores for people averaging about 70%.

A typical user should never need to retrain the chunker. However, the system allows the user to train their own chunker, and to specify that chunker to be used by the system in place of a default chunker (which, for example, may have been trained using the training set and methodology indicated above). A graphical user interface may be implemented and shall be referred to herein as the Named Entity Labeler. In the NLP literature, the term “named entity” is used to represent the concepts that are detected by this sort of approach, including concepts such as dates, times, etc.

A screenshot of our Named Entity Labeler being used to label one of the e-mails in a training set is shown in FIG. 2. The user can select the type of chunk from a “Chunk” menu, and then select portions of text that match that chunk. The user may click the left button of a computer mouse to label a selection as an example of the chunk, and the graphical user interface (GUI) may automatically expand the selection to make sure it includes complete tokens. The user may click the right button of a computer mouse to select a previously labeled chunk to delete the label. When the user saves the file, the file may be saved in two formats. One format may have the extension .nel, and comprise a text file with metadata that the GUI uses to indicate current labels. Another format may be a .train file, which has the appropriate format for training the chunker.

Once enough documents have been labeled to constitute a training set, a user can train a chunker using a Python script. This can easily be performed from the interactive Python shell. FIG. 3 shows a screenshot of part of a computer screen indicating how the chunker may be trained. The first parameter indicates the name to give a pickled chunker, wherein “pickling” is how Python applications typically implement object serialization. The second parameter is a text file that contains the full paths and filenames of documents to be used for training. The applied function disclosed in FIG. 3, “create date chunker,” may be used to recognize dates. In the alternative, the function may create a chunker that is capable of predicting all concepts labeled in the training files. On a typical machine, the entire training process may take only a few seconds. Additional Python scripts may be implemented to perform cross-validation experiments within the training set to automatically compute and display evaluation metrics for all concepts (not shown here).

B. Detecting and Shifting Concepts

When the DGS system processes e-mails, attachments, or other files, it may first extract the textual content from the document, then segment the text into sentences, then tokenizes each sentence (i.e., split the sentence into words plus important punctuation), then compute the part-of-speech (i.e., syntactic category) for each token, then compute other features used for learning, then apply the chunker to detect recognized concepts (e.g., dates, times, names of people, locations). For each predicted concept, a second phase may be applied to eliminate false positives. Then each date and time may be shifted according to deltas specified by the user (this makes use of Python's datetime module). Matching .pshift files provided by the user may also be modified according to user-provided templates as explained below. After all shifts are applied, the document may be reconstructed and saved in the proper destination folder. A simplified outline explaining the system workflow for processing a single e-mail or file is shown in FIG. 4.

Retrieving the text from a file, represented by the first box in the outline, may be more complicated for some file types than others. For e-mails represented as .json files, the Python json module can be used to obtain and potentially modify the various fields. Text files are also simple to deal with. The system may handle HTML-formatted e-mails (and other .html files, if any), .docx attachments and files, and .pdf attachments and files. Handling HTML and .docx files are similar, because .docx files are stored as compressed XML documents, and specific tags indicate textual fields; Python's lxml module is useful for handling both formats. Complications can still arise as sentences may be split between HTML or XML nodes. The system may restore all modified tokens to their original nodes to preserve formatting. It is difficult, however, to manipulate .pdf files directly. The system may therefore rely on publically available utilities to convert .pdf files to .html, process the .html, and convert the file back to pdf. The conversion is not perfect, so formatting of .pdf files is only approximately preserved. Any other file type, either as an attachment or standalone file, is copied to the destination directory unmodified.

Shifting dates and times, once predicted and verified, may be achieved using Python's datetime module (examples are described below). To specify names of people to shift, and how to shift them, the user can specify one or more templates in the form of .pshift files. Each template specifies a person to shift, if detected, and how to shift the person. Each template must include: (1) all allowable variations of the person's first name, middle name, and last name; (2) how each allowable variation of any part of a name should be modified; and (3) which parts of the person's name is required to count as a match.

An example of a .pshift file specifying rules for shifting variations of the name Ken Lay is shown in FIG. 5. Note that to be considered a match for this template, a detected name predicted by the chunker must match at least the first and last name as specified in the template. Matches for the middle name are allowed but not required (but a middle name that is present and does not match the template would exclude the match). When the template is matched, each part of the name would be shifted as indicated in the template. Templates may be case insensitive and flexible with respect to whitespace. The system may attempt to use the same style of capitalization for shifted tokens as for original tokens. Therefore, in the example embodiment shown in FIG. 5, “Ken Lay” would become “John Public”, “KENNETH L. LAY” would become “JOHNNY Q. PUBLIC”, “Lay, Kenneth Lee” would become “Public, Johnny Quin”, etc. Names such as “Ken” or “Lay” by themselves would not be shifted, since they do not match all required fields according to the first row of the template. Also, a name such as “Ken A. Lay” would not be shifted, since the middle initial “A” does not match the allowable middle names in the template, even though that field is not required.

C. Generating Fake E-Mails

At random points with configurable frequencies, believable fake e-mails are generated and inserted into a user's destination e-mail directory. The system may be limited to at most one fake e-mail generated per user. The content of the fake e-mails is based on configurable templates, and each template is applied at most once during a single run of the DGS system. Each generated fake e-mail may contain fake credentials. The fake e-mails are designed to entice a hacker who steals data into using the fake credentials at a fake website. Victims are automatically notified via e-mail when fake credentials have been used, indicating that their data has been stolen.

FIG. 6 shows the content of one fake e-mail generated. The general format of the file is son, matching the format of original e-mails as specified by BAE. Each template may be different. In the example shown in FIG. 6, the “From” field has been taken from a real e-mail of the same user; the “To” field contains a fake Gmail address based on the user's username; the body is mostly fixed, except for the username and password. The values of the “Cc” and “Bcc” fields may be predetermined as null; the value of the “HasAttachments” field may be predetermined as false; the value of the “Id” field is a randomly modified version of an id from a real e-mail; and the values of the “DateSent” and “TimeSent” fields may be computed as random offsets from the corresponding fields from a real e-mail of the same user (after the real e-mail has been shifted).

D. Running the DGS System

To run the system, the user may be required to specify the base directory within which all user directories reside. Additionally, the user may specify various optional parameters. If the user specifies a command with an incorrect format, a message may be displayed, such as the example screenshot depicted in FIG. 7. The “-c” option may enable the user to train and apply their own chunker (instead of a pre-trained chunker) as explained earlier. The other options could allow the user to specify deltas for shifting times and dates, to specify one or more .pshift files for shifting detected people, and to specify the name of the log file that is produced while the system is running.

The system has been tested on a corpus consisting of: (1) a subset of the Enron E-mail Dataset including 8,419 e-mails from 20 users, all converted to the proper .json format; (2) 215 .docx and .pdf files from the MITRE corpus; these MITRE files have been randomly scattered across user file folders and randomly added as attachments to e-mails; (3) 118 .txt files, representing the MITRE .pdf files converted to text (these are Unicode text files), plus one additional manually created ASCII .txt file; these .txt files were randomly scattered across user file folders (but these are not used as attachments); and (4) one additional complex .json file, including complex, formatted attachments and a .json field with an HTML-formatted body. Also included were five .pshift files. Assuming that the test corpus is placed in the directory “corpus/enron_plus_mitre” relative to the main system, a test run using all of the provided .pshift files, with specified deltas of −500 days and +630 minutes, can be run as follows: python batch_process son.py corpus/enron_plus_mitre-d-500-m 630-1 log l.txt-p KenLay.pshift-p DougGilbert-smith.pshift-p NatalieMcCarthy.pshift-p WandaCuny.pshift-p CarlReiber.pshift

FIG. 8 shows a sample screenshot part way through one test run of the system. The user may be updated after every 100 e-mails and non-attachment files have been processed. The log file (not shown here), which can be examined as the system is running or afterward, may contain much more detailed information. The system may terminate after all e-mails and files have been processed. In the alternative, the a daemon may be run in the background and automatically process new users, e-mails, or files whenever they appear.

In addition to the required and optional command line arguments, the user may also configure many different aspects of the system through a configuration file. These configurable properties may include: (1) the default name of the log file; (2) the names of the subdirectories for original and modified files and e-mails in the corpus; (3) the expected fields in the .json files; (4) the probabilities determining how often fake e-mails are randomly generated; (5) the content of the templates for generating fake e-mails; (6) the range of random offsets from the base e-mails for timestamps of fake e-mails; (7) whether or not to delete original e-mails and files after the modified versions have been created; and (8) the user information for the user running the system, so they may be notified when an unauthorized user has been lured to a fake website. In general, these properties tend to be more technical properties that are not likely to change frequently between runs of the system.

E. Examining System Output

FIG. 9 shows an example e-mail from the test corpus in its original .json format (left) and after being modified by the system using the example command shown earlier (right). Note that in this particular case, the body of the e-mail contained one date, which was detected and shifted, and one name that matched our example “KenLay.pshift” file (shown earlier), which was also detected and modified. Additionally, the “DateSent” and “TimeSent” fields of the e-mail were shifted.

The system may include a json_diff utility, written in Python and runnable from the command line, which displays the differences between two specified json files in a diff-like format. FIG. 10 shows a screenshot displaying the output of the json_diff utility used to compare the original and modified .json files displayed in FIG. 9.

To compare modified .docx files or .pdf files with the corresponding originals, the user may need to open both files and compare them by eye. Of course, for these file types, we are interested not only in the content that has changed, but also in ensuring that the formatting has stayed the same, or has changed in an acceptable manner.

FIG. 11 shows an excerpt from a .docx file from the test corpus in its original state (left) and after being processed by the sample command shown earlier (right). This particular .docx file was one of the attachments for our complex .json file; the body contains the text of an e-mail from the Enron dataset, formatted in variety of ways. Two dates were detected and modified where they appear in the document. In addition, the used .pshift file indicates that the name “Wanda Curry” should change to the name “Melanie Curtis”, and that only the first name is required for a match. The name was detected in two locations in this excerpt, but missed in a third location.

FIGS. 12A and 12B show an excerpt from a .pdf file in the test corpus in its original state (FIG. 12A) and after being processed by the sample command shown earlier (FIG. 12B). This particular document came from the MITRE corpus. Examining closely, one can see that in this excerpt, there was just a single date (specifying a year), and it was correctly detected and shifted. In addition, one of the .pshift files that we have been using for testing indicates that the name “Carl Reiber” should be changed to “Derek Hunt,” that only the last name is required, and the first name can be represented with just the initial “C.” In this excerpt, five instances of the name were detected and modified, and two instances were missed. The token near the top of the document, “Spotlight_Reiber_ver4 July28” may contain a name and date within a larger, single token; our system will not be able to identify concepts that occupy only a part of a larger token). The modified document looks similar to the original and completely reasonable. As explained earlier, formatting of .pdf files is only approximately maintained. Note also that metadata about the document, such as the title that appears in the title bar, is preserved.

Various other modifications will be obvious to a person of skill in the art without deviating from the inventions claimed herein.

Claims

1. (canceled)

2. (canceled)

3. A method for detecting an unauthorized access comprising: providing fake login credentials;providing a website that presents one or more fields in which login credentials may be entered;receiving the fake login credential in the one or more fields;generating an alert upon receiving the fake login credentials;transmitting the alert.

4. The method of claim 3 wherein the alert is transmitted by email.

5. The method of claim 4 wherein the alert indicates that the login credentials have been received in the one or more fields.

6. The method of claim 5 wherein the website is a fake website.

7. The method of claim 3 wherein the alert indicates that the login credentials have been received in the one or more fields.

8. The method of claim 3 wherein the website is a fake website.

9. A system for detecting an unauthorized access comprising: a server having a computer readable storage medium;machine readable code stored on said computer readable storage medium;fake login credentials stored on said computer readable storage medium;wherein said machine readable code includes instructions for rendering a website that presents one or more fields in which login credentials may be entered; andwherein said machine readable code includes instructions capable of generating an alert and transmitting the alert upon receipt of the fake login credentials in the one or more fields.

10. The system of claim 9 wherein the alert is transmitted by email.

11. The system of claim 10 wherein the alert indicates that the login credentials have been entered in the one or more fields.

12. The system of claim 11 wherein the website is a fake website.

13. The system of claim 9 wherein the alert indicates that the login credentials have been entered in the one or more fields.

14. The system of claim 9 wherein the website is a fake website.

15. The system of claim 9, wherein the alert is transmitted to a device that is remote from the system.