Patent Description:
Modern false computing resources are unfortunately easy to detect by malicious entities. For example, a modern false email account or file-hosting account will contain only a static set of documents (e.g., emails, hosted files, etc.). Moreover, a modern false email account does not respond to messages or otherwise interact with malicious entities. Upon identifying a specific computing resource is being a false computing resource, malicious entities immediately log off and do not return. If a malicious entity quickly recognizes the false nature of a computing resource, an organization may expend significantly more resources setting up the false computing resources than is consumed from the malicious entity.

<CIT> discloses a system and method for providing security for a computer network. Content sets are generated for a computer associated with the network. It is determined whether a user should be routed to the generated content sets. If it is determined that the user should be routed to the generated content sets, a generated content set is selected and the user is so routed. Various actions and events may be recorded in a log file, and the log file analyzed using regular expressions.

<CIT> discloses concepts and technologies for multilayered deception for intrusion detection.

Technologies described herein facilitate generating and deploying dynamic false user accounts. Generally described, embodiments disclosed herein obtain a false tenant model that is usable to dynamically populate a false user account with messages and/or data files. Thus, rather than containing only a static set of documents, a "dynamic" false user account is continually populated with fresh documents (e.g., emails, hosted files, etc.). This results in dynamic false user accounts appearing practically indistinguishable from real user accounts that are continually populated with new real email messages and/or new real hosted files as they are used by account owners to perform legitimate business activities. The realistic nature of the dynamic false user accounts described herein significantly reduces the ability of malicious entities to identify a user account as being false in nature. Thus, as compared to conventional false user accounts that are static in nature, the dynamic false user accounts described herein are better suited for enticing malicious entities to remain logged in - thereby prolonging the period of time during which the malicious entities' behavior can be observed and the amount of the malicious entities' time that is wasted.

Implementations of the techniques described herein improve computing security with respect to sensitive organizational resources. For example, various implementations are designed to isolate malicious code (e.g., malicious user interface (UI) controls) from reaching real user accounts and real user devices for the specific technical purpose of preventing vulnerable computing resources (e.g., user accounts and user devices) from being compromised. With respect to this point, it can be appreciated that in many cases phishing emails and/or other malicious communications contain viruses (e.g., ransomware). Therefore, as compared to conventional "static" false user accounts, implementing dynamic false user accounts that are practically indistinguishable from real user accounts entice a significantly larger amount of interaction from malicious entities'. It can be appreciated that this larger amount of interaction facilities harvesting additional information about attack strategies and malware that are used by the malicious entities - thereby thwarting future use of such attack strategies and malware.

Furthermore, it will be appreciated that by quarantining communications from known malicious entities so that they don't reach real user accounts, the described techniques are specifically directed towards performing isolation and eradication of computer viruses, worms, and other malicious code from vulnerable computing resources (e.g., user accounts, user devices, etc.). This mitigates security risks that are posed by communications from known malicious entities (e.g., malicious phishing email scams) and, in turn, significantly reduces the computing resources and human resources that are required to regain security of compromised user devices and/or user accounts. To illustrate this point, consider that once a phisher gains access to a specific real user account it is common for the phisher to immediately change the user credentials associated with this specific real user account to essentially lock-out the real and rightful owner of the account. Then, significant computing resources are typically allotted to sophisticated security systems in order to regain control over the real user account. Since the dynamic nature of the novel false user accounts described herein deceives malicious entities into divulging significant details regarding their attack strategies and malicious code(s), the techniques described herein significantly improve an organization's ability to prevent real computing resources from being compromised.

In some implementations, a system receives a corpus of text that includes a set of data files which exhibit certain properties. As an example, the system may receive the corpus of text in the form of selections of one or more components of real user accounts such as, for example, real email accounts and/or real file-hosting accounts. Additionally, or alternatively, the system may receive the corpus of text in the form of business documents that generally relate to a particular industry (e.g., banking, software, etc.) and/or technological space (e.g., software, vehicle autonomation, etc.). The system may analyze the corpus of text to identify the properties exhibited by the set of data files so that false data files can be generated that exhibit the same and/or similar properties but that lack real sensitive information that a malicious entity might be seeking.

In some implementations, the corpus of text may be provided to a corpus analysis application which may utilize various artificial intelligence (AI) techniques to identify the properties that are exhibited by the set of data files. As a specific example, the corpus analysis application may utilize a recurrent neural network (RNN) that includes multiple layers of Long Short-Term Memory (LSTM) units to analyze the corpus of text and to determine the various properties. Regarding the properties of the corpus of text that may be determined, the corpus analysis application may determine the vocabulary and/or grammatical structure that is used within the corpus of text. The vocabulary may include a listing of the individual words found in the corpus and their corresponding frequency of use. The grammatical structure may be an underlying structure or theme with which the various individual words of the vocabulary are compiled together in the corpus of text in order to communicate concepts and/or information.

Based on the properties of the corpus of text, the system may generate a false tenant model that is usable to generate other data files that are false in nature and that exhibit the properties of the analyzed corpus of text. For example, if the corpus of text includes a plurality of emails obtained from one or more real inboxes and/or real outboxes, then the false tenant model may be usable to generate other individual emails that exhibit similar properties as was observed in association one or more real inboxes and/or real outboxes. However, despite appearing similar to the analyzed set of "real" data files, the data files that are generated by the false tenant model are fanciful data files and therefore have no real value to a malicious entity who gains access thereto. For example, the generated files may appear to be genuine email documents despite being generated by a computing system rather than by an actual person. The realistic nature of the generated file deceives a malicious entity that views the generated files into believing that the generated fake data files are actually are real data files containing potentially valuable information.

Upon being generated, the system may deploy the false tenant model to populate a false user account with a set of false data files that appear real and legitimate but that are of no real value. For example, the false user account may be an email account that appears to be a real email account and may even be usable to send and/or receive emails. However, the false user account is not actually assigned to a real user but rather is designed to attract malicious entities to observe their computing habits, waste their time, and/or extract additional detail regarding new and/or evolving phishing campaigns. It can be appreciated that in some cases such a false user account may be colloquially referred to in various industries and/or contexts as a "honeypot" type user account.

The system may receive a request for access to the false user account from a computing device that is being operated by a malicious entity. For purposes of the present discussion, such a computing device may be referred to herein as a phisher device. The phisher device may be a laptop computer or some other type of personal computing device. In some implementations, the request may include credentials associated with the false user account. As described herein, the credentials may be transmitted in a seed response to lure the malicious entity (e.g., a malicious phisher and/or industrial spy) into accessing the false user account that is being and/or has been populated with data files generated via the false tenant model.

Then, the system may respond to the request by provisioning the phisher device with access to false user account and the data file therein which have been generated by the false tenant model. In this way, the malicious entity is enabled to log into the false user account which in turn provides the malicious entity with the false impression that access has been obtained to a real user account that is being used to conduct actual business. In some embodiments, the false tenant model may be used to periodically generate and add new files into the false user account. In this way, the malicious entity can be logged into the false user account and, in real time, be witnesses emails being sent and/or received to give the impression that a real user is concurrently logged into and even using the false user account. The realistic nature of the dynamic false user accounts described herein significantly reduce the ability of malicious entities to identify a user account as being false in nature.

In some implementations, the credentials included within the request may include a combination of a real alias (e.g., an email alias that is assigned to a real user account) and a deception trap password that provisions access to the false user account in lieu of the real user account. Logging into the false user account with the deception trap password may provision access to the false user account in a matter that gives the impression of being logged into the real user account. For example, if a real user account corresponds a real user alias of steve@enterprisedomain. com, then providing a deception trap password along with the steve@enterprisedomain. com alias may provision access to the false user account in a manner that deceives the malicious entity into thinking they are logged into the real user account as steve@enterprisedomain.

It should be appreciated that the above-described subject matter may also be implemented as a computer-controlled apparatus, a computer process, a computing system, or as an article of manufacture such as a computer-readable medium. These and various other features will be apparent from a reading of the following Detailed Description and a review of the associated drawings.

This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended that this Summary be used to limit the scope of the claimed subject matter.

The same reference numbers in different figures indicates similar or identical items.

The following Detailed Description describes techniques for generating and deploying dynamic false user accounts. In various implementations, false user accounts are populated with sets of false data files that are generated to exhibit properties which are similar to a set of previously analyzed real data files. In this way, the false data files are modeled after (e.g., mimic) the real data files but are void of sensitive real information that could be exploited by a malicious entity (e.g., a phisher, an industrial sky, etc.) if obtained.

Generally described, various embodiments obtain a false tenant model that is usable to dynamically populate a false user account with messages and/or data files. Thus, rather than containing only a static set of documents, a "dynamic" false user account is continually populated with fresh documents (e.g., emails, hosted files, etc.). This results in dynamic false user accounts appearing practically indistinguishable from real user accounts that are continually populated with new real email messages and/or new real hosted files as they are used by account owners to perform legitimate business activities.

The realistic nature of the dynamic false user accounts described herein significantly reduces the ability of malicious entities to identify a user account as being false in nature. Thus, as compared to conventional false user accounts that are static in nature, the dynamic false user accounts described herein are better suited for enticing malicious entities to remain logged in - thereby prolonging the period of time during which the malicious entities' behavior can be observed and the amount of the malicious entities' time that is wasted.

Implementations of the techniques described herein improve computing security with respect to sensitive organizational resources. For example, various implementations are designed to isolate malicious code (e.g., malicious user interface (UI) controls) from reaching real user accounts and real user devices for the specific technical purpose of preventing vulnerable computing resources (e.g., user accounts and user devices) from being compromised. With respect to this point, it can be appreciated that in many cases phishing emails and/or other malicious communications contain viruses (e.g., ransomware). Therefore, as compared to conventional "static" false user accounts, implementing dynamic false user accounts that are practically indistinguishable from real user accounts entice a significantly larger amount of interaction from malicious entities'. It can be appreciated that this larger amount of interaction facilities harvesting additional information about attack strategies and malware that are used by the malicious entities - thereby thwarting future user of such attack strategies and malware.

Turning now to <FIG>, illustrated is a system <NUM> for deploying a machine learning engine <NUM> to analyze a corpus of text <NUM> to generate a false tenant model <NUM> that is usable for populating a false tenant <NUM> with false data files <NUM> such as, for example, false emails, false word processing documents, and so on. In the illustrated implementations, the false tenant model <NUM> is used to periodically generate new email messages and add these newly generated email messages to a false "email" inbox <NUM> of the false user account <NUM>. In this way, when a malicious entity logs into the false user account <NUM> (e.g., using credential obtained in a seed response as described elsewhere herein) it will appear as if the false user account <NUM> is actually being used at that time. For example, from the perspective of the malicious entity, new email message type false data files <NUM> will be periodically received in the false inbox <NUM> and/or false outbox <NUM> - thereby making it appear as if a real user is actually signed into and conducting business from the false user account <NUM>.

As illustrated, the system <NUM> may include one or more tenant servers <NUM> that are designed to implement one or more real tenants <NUM>. Individual ones of these real tenants <NUM> may correspond to individual enterprises (e.g., businesses, government organizations, education organizations, etc.) and may include one or more real user accounts <NUM>. For example, a particular business may purchase a subscription to a real tenant <NUM> (e.g., an OFFICE <NUM> tenant offered by MICROSOFT, a G SUITE tenant offered by GOOGLE, etc.) and a tenant administrator within the particular business may initiate (set-up) and manage the real user accounts <NUM> for individual employees of the particular business.

Individual users (e.g., employees) may be assigned real user credentials that enable the individual users to access their real user accounts <NUM> via one or more user devices. As a specific but nonlimiting example, the real user credentials may include an email alias (e.g., steve@enterprisedomain. com) and a real user password. The individual users may log into their real user account <NUM> by entering these credentials via a specific webpage that is associated with the tenant servers <NUM>. Upon successfully logging into their corresponding real user account <NUM>, the users may be provided with access to a variety of resources such as, for example, an email account (e.g., a GMAIL and/or OUTLOOK account) and/or a file hosting account (e.g., GOOGLE DRIVE and/or OUTLOOK).

As further illustrated, the tenant servers <NUM> may include a security filter <NUM> to analyze messages and to filter out phishing messages that are designed to fraudulently deceive users into providing various types of sensitive information. For example, as illustrated, a message <NUM> is transmitted from a phisher computer system <NUM> to the tenant servers <NUM> where it is received by the security filter <NUM>. In order to safely handle fishing messages, the tenant servers <NUM> may implement a detonation chamber <NUM> that is designed to facilitate manipulation of various aspects of individual messages in a protected environment. For example, the detonation chamber <NUM> may be an isolated computing environment such as, for example, a container and/or light weight virtual machine that isolates the real tenants <NUM> and real user accounts <NUM> thereof from any computing activity that occurs within the detonation chamber <NUM>. These aspects will be described in more detail below with respect to <FIG> and <FIG>.

In the illustrated example, a false tenant model <NUM> is created by a machine learning engine <NUM> and is then provided to the tenant servers <NUM> for continual deployment. The false tenant model <NUM> may be created by receiving a corpus of text <NUM> from one or more real tenants <NUM>. The corpus of text <NUM> may be a selected portion of data that is saved in association with one or more real user accounts <NUM>. As illustrated, the real user accounts <NUM> may include one or more of real inboxes <NUM>, real outboxes <NUM>, and/or real hosted files <NUM>. The real inboxes <NUM> may correspond to storage locations in which incoming emails that are addressed to particular email aliases are stored. The real outboxes <NUM> may correspond to storage locations in which copies of outgoing mail that is sent from the particular email aliases are stored. The real hosted files <NUM> may correspond to storage locations in which account owners corresponding to the real user accounts <NUM> are enabled to store data files such as, for example, text documents, spreadsheets, slide presentations, and so on. It can be appreciated that individual real user accounts <NUM> may each have an individual corresponding real inbox <NUM>, real outbox <NUM>, and set of real hosted files <NUM>.

As used herein, when used in the context of an adjective modifying a noun, the term "false" generally refers to the denoted item (e.g., user account, response, credit card number, user credential, etc.) appearing to be a genuine instance of the denoted item that is deliberately made to deceive an entity. For example, a user account that is created and populated with items (e.g., emails, data files, etc.) that are generated by a machine learning model (e.g., a false tenant model) rather than by a human user for the purpose of deceiving a phishing entity, may aptly be referred to herein as a false user account. As another example, a response that is generated by a response engine as described herein and then transmitted to a phishing entity to dilute and/or pollute response data may aptly be described as a false response. As used herein, when used in the context of an adjective modifying a noun, the term "real" generally refers to the denoted item being a genuine instance of the denoted item. For example, a user account that is actually assigned to and utilized by a human employee of an organization may aptly be described as a real user account.

In some embodiments, the corpus of text <NUM> may include one or more real inboxes <NUM>, real outboxes <NUM>, and/or sets of real hosted files <NUM>. For example, an administrator of a real tenant <NUM> may select a set of individual real user accounts <NUM> that are to be used as the corpus of text <NUM>. Stated alternatively, the set of data files that make up the corpus of text <NUM> may be real data files that are harvested from one or more selected real user accounts <NUM>.

In some implementations, one or more false tenants <NUM> may individually correspond to one or more real tenants <NUM> and the false tenant model(s) <NUM> that are used to populate the false tenant(s) <NUM> may generated based on "real" data files that are provided by the one or more real tenants <NUM>. In this way, the messages and/or data files that are ultimately generated to populate the false user accounts <NUM> of a particular false tenant <NUM> may actually stem from a corpus of text <NUM> that is obtained from real user accounts <NUM> of the particular real tenant <NUM> to which the false tenant <NUM> corresponds. For example, a particular enterprise that subscribes to a real tenant <NUM> may provide access to one or more of its real user accounts <NUM> to be used as the corpus of text <NUM>. It can be appreciated that in such embodiments the actual messages and/or data files that are generated by the false tenant model <NUM> that is generated based on the corpus of text <NUM> provided by a particular real tenant <NUM> may appear to the phisher <NUM> as genuine business data.

As illustrated, the corpus of text <NUM> may be provided to the machine learning engine <NUM> and, more particularly, to a corpus analysis application <NUM> that is implemented by the machine learning engine <NUM>. When deployed by the machine learning engine <NUM> to analyze the corpus of text <NUM>, the corpus analysis application <NUM> may utilize one or more machine learning techniques to determine various properties of the corpus of text <NUM>. As a specific but non-limiting example, the corpus analysis application <NUM> may utilize a recurrent neural network (RNN) to determine various properties of the corpus of text <NUM>. An exemplary RNN may include a plurality of layers of Long Short-Term Memory (LSTM) units <NUM> to analyze the corpus of text <NUM> and determine the various properties.

Regarding the properties of the corpus of text <NUM> that may be determined, the corpus analysis application <NUM> may determine the vocabulary and/or grammatical structure that is used within the corpus of text <NUM>. The vocabulary may include a listing of the individual words found in the corpus of text <NUM> and their corresponding frequency of use within the corpus of text <NUM>. The grammatical structure may be an underlying structure or theme with which the various individual words of the vocabulary are compiled together in the corpus of text <NUM> in order to communicate concepts and/or information.

Based on the properties that are determined for the corpus of text <NUM>, the corpus analysis application <NUM> may generate a false tenant model <NUM> that is usable to generate new false data files <NUM> that are structurally similar to those included within the corpus of text <NUM> - but which are fanciful and of no actual value to any malicious entity obtaining access thereto. In some embodiments, these generated false data files <NUM> are generated and/or added to the false user accounts <NUM> periodically over time. For example, as illustrated, a first false data file <NUM>(<NUM>) is transmitted to the false user accounts <NUM> at a first time Ti whereas a Nth false data file <NUM>(N) is transmitted to the false user account <NUM> at an Nth time TN - that is subsequent to the first time Ti. In this way, the false user accounts <NUM> are continually changing over time - just as a real user account <NUM> that is actually being used does.

In some embodiments, the false tenant model <NUM> is designed to populate the false tenant accounts <NUM> with new false data files <NUM> in accordance with patterns of activity that are identified within the corpus of text <NUM>. For example, the false tenant model <NUM> may cause "generated" false email messages to be sent to the false inboxes <NUM> at a rate that is similar to that which "real" email messages are sent to the real inboxes <NUM> over the course of a typical business day. Furthermore, such activity may be slowed or halted during off-peak, non-business, and/or holiday hours. Similar, patterns of activity may be identified with respect to the real outboxes <NUM> and/or real hosted files <NUM> and may be incorporated into the false tenant model <NUM>. In this way, the frequency at which "sent" email messages are populated into the false outbox <NUM> may resemble that which the real user(s) actually send messages over the course of a typical business day. Additionally, or alternatively, the frequency at which data files are added to the set of real hosted files <NUM> may also be similarly modulated.

In some embodiments, the system <NUM> may implement a phishing activity reporter <NUM> that is configured to report certain types of phishing activity to the real tenants <NUM>. For example, the phishing activity reporter <NUM> may monitor interaction data that indicates computing activities that take place between a phisher device and the false user accounts. Then, based on the interaction data, the phishing activity reporter <NUM> may determine whether a malicious entity appears to be a common "commodity" type phisher that is pursuing sensitive information but has no particular or heightened interest in obtaining sensitive data specifically from a particular tenant. For example, the interaction data may correspond to the malicious entity logging onto a false user account <NUM> that appears to the malicious entity to be owned by steve@enterprisedomain. Once logged on, the malicious entity may download false contact information that is associated with the false user account <NUM> without browsing through and/or reading various specific documents that are stored in this account. Under these circumstances, the phishing activity reporter <NUM> may classify the malicious entity as a common "commodity" type phisher and report the phishing activity to one or more real tenants <NUM>.

Alternatively, once logged on, the malicious entity may begin speedily browsing through and/or downloading the various false documents (e.g., fake email messages, fake data files, fake engineering drawings, etc.). It can be appreciated that this type of activity may indicate that the malicious entity has a specific interest in obtaining sensitive details about the particularly targeted business. Under these alternative circumstances, the phishing activity reporter <NUM> may classify the phisher as an "industrial espionage" type phisher and report the phishing activity to a specifically targeted real tenant <NUM>. In this way, a real business can deploy false user accounts <NUM> that appear to include information that is valuable to their competitors and, therefore, serve to attract malicious competitors into accessing these accounts. Then, when the real business is actually targeted by such a competitor they can quickly learn of the ongoing threat and take appropriate security measures. It can be appreciated that such accounts may colloquially be referred to as "honeypot" accounts or simply "honeypots.

In some instances, the system <NUM> enables personnel associated with the individual real tenants <NUM> to provide tenant defined parameters <NUM> that prescribe various aspects of how the false data files <NUM> and/or other content is to be generated for the false user accounts <NUM>. In some implementations, the tenant defined parameters <NUM> may prescribe that specific words and/or phrases be included and/or omitted from any documents that are generated by the false tenant model <NUM>. As a specific but nonlimiting example, a tenant administrator associated with the real tenant <NUM> may recognize that due to a major product release being internally code names as "RENO," this word will appear with frequency in the corpus of text <NUM>. Normally, this may trigger the false tenant model <NUM> to generate documents that also include this word. However, in order to further shield their internal operations and protect this code name from being externally identified by a malicious entity, the tenant defined parameters <NUM> may restrict this word from being used in any documents that are added to the false user account(s) <NUM> that are based on that particular real tenant <NUM>.

Additionally, or alternatively, the tenant defined parameters <NUM> may include file names for specific false data files <NUM> and/or data files that are generated by the false tenant model <NUM>. For example, suppose that a business is in the process of developing a new version of a product. A tenant administrator may rename fake email messages and/or hosted documents to include a name of this product. In this way, if a malicious entity gains access to the false user account <NUM> and begins reading and/or downloading files that are intentionally named to indicate their relation to the product, the phishing activity reporter <NUM> may report this activity to inform the tenant administrator that potential industrial espionage is taking place.

Turning now to <FIG>, illustrated is a schematic diagram of an illustrative computing environment <NUM> that is configured to deploy the machine learning engine <NUM> to analyze the corpus of text <NUM> to generate a false tenant model <NUM>. Ultimately, the false tenant model <NUM> may be utilized by the tenant server(s) <NUM> to populate false user accounts <NUM> with false data files <NUM> as described herein.

In some embodiments, the machine learning engine <NUM> may generate the false tenant model <NUM> based on sets of real data files <NUM> that are stored in association with and/or transmitted between one or more real user accounts <NUM>. For example, as illustrated, a first account owner <NUM>(<NUM>) through an Nth account owner <NUM>(N) may transmit one or more email messages during the performance of their legitimate business functions. These messages may be transmitted within an organization (e.g., between employees of the organization that subscribes to the real tenant <NUM>) or may be transmitted external to the organization (e.g., from an employee of the organization to a third-party vendor, or vice versa). Thus, it can be appreciated that in some implementations, the corpus of text <NUM> may be made up of a set of real data files <NUM> that are stored and/or generated in association with a real tenant <NUM>. Additionally, or alternatively, the corpus of text <NUM> may be made up of a set of data files (e.g., letters, emails, engineering prints, spreadsheets, tax documents, etc.) that are not specific to a particular real tenant <NUM>. For example, the corpus of text <NUM> may include a portion of data files that are stock data files <NUM> that may be used repeatedly to generate false tenant models <NUM> for a plurality of different real tenants <NUM>.

In some embodiments, the machine learning engine <NUM> may generate the false tenant model <NUM> using a "deep learning" type machine learning algorithm that leverages a sequenced arrangement of layers of processing units. In an exemplary implementation, the sequenced arrangement comprises a sequence of multiple layers of nonlinear processing units wherein each successive layer may use an output from a previous layer as an input.

In a specific but nonlimiting example, the corpus analysis application may utilize a recurrent neural network (RNN) that includes multiple layers of Long Short-Term Memory (LSTM) units to analyze the corpus of text and to determine various properties that are exhibited by the set of data files. For example, the corpus analysis application may determine the vocabulary and grammatical structure that is used within the corpus of text. The vocabulary may include a listing of the individual words found in the corpus and their corresponding frequency of use. The grammatical structure may be an underlying structure or theme with which the various individual words of the vocabulary are compiled together in the corpus of text to communicate concepts and/or information. Stated in generalized and simplistic terms, the machine learning engine <NUM> may utilize an RNN having layers of LSTM units to learn the language that is spoken/written within the corpus of text <NUM>. Additionally, or alternatively, other machine learning techniques may also be utilized, such as unsupervised learning, semi-supervised learning, classification analysis, regression analysis, clustering, etc. One or more predictive models may also be utilized, such as a group method of data handling, Naive Bayes, k-nearest neighbor algorithm, majority classifier, support vector machines, random forests, boosted trees, Classification and Regression Trees (CART), neural networks, ordinary least square, and so on.

In the illustrated example, the machine learning engine <NUM> may also utilize tenant defined parameters <NUM> to generate the false tenant model <NUM>. For example, personnel associated with the individual real tenants <NUM> may provide tenant defined parameters <NUM> that prescribe various aspects of how the false data files <NUM> and/or other content is to be generated for the false user accounts <NUM>. The tenant defined parameters <NUM> may prescribe that specific words and/or phrases be included and/or omitted from any documents that are generated by the false tenant model <NUM>. As a specific but nonlimiting example, a tenant administrator <NUM> associated with the real tenant <NUM> may recognize that due to a major product release being internally code names as "RENO," this word will appear with frequency in the corpus of text <NUM>. Normally, this may trigger the false tenant model <NUM> to generate documents that also include this word. However, to further shield their internal operations and protect this code name from being externally identified by a malicious entity, the tenant defined parameters <NUM> may restrict this word from being used in any documents that are added to the false user account(s) <NUM> that are based on that particular real tenant <NUM>.

Based on the corpus of text <NUM> and the tenant defined parameters <NUM> (if any are provided), the machine learning engine <NUM> generates the false tenant model <NUM> for dynamically populating a false user account with messages and/or data files. In some implementations, a "dynamic" false user account may be continually populated with fresh documents (e.g., emails, hosted files, etc.) so as to appear practically indistinguishable from real user accounts that are continually populated with new real email messages and/or new real hosted files as they are used by account owners to perform legitimate business activities. The realistic nature of the dynamic false user accounts described herein significantly reduces the ability of malicious entities to identify a user account as being false in nature. Thus, as compared to conventional false user accounts that are static in nature, the dynamic false user accounts described herein are better suited for enticing malicious entities to remain logged in - thereby prolonging the period of time during which the malicious entities' behavior can be observed and the amount of the malicious entities' time that is wasted.

In some implementations, the machine learning engine <NUM> may continually and/or periodically analyze additional real data files <NUM> for a particular real tenant <NUM> to continually and/or periodically update a particular false tenant <NUM> that specifically corresponds to the particular real tenant <NUM>. In this way, the false data files that are generated to populate the false tenant's <NUM> false user accounts <NUM> will closely resemble the real data files <NUM> that are currently and/or recently being generated in association with the real tenant <NUM>.

Turning now to <FIG>, illustrated is a system <NUM> for routing access requests <NUM> through a gate keeper <NUM> to selectively provision access to false user accounts <NUM> or real user accounts <NUM> based upon credentials included within the access requests <NUM>. For purposes of the present discussion, presume that the tenant server(s) <NUM> are facilitating a real user account <NUM> that corresponds to a real user alias <NUM> and an account owner password <NUM>. The real user alias <NUM> may be an email address that corresponds to the real user account <NUM>. The account owner password <NUM> may be an alphanumerical sequence of letters and/or numbers that are provided by the account owner <NUM> to receive full access <NUM> to the real user account <NUM>. As a specific example, the real user alias <NUM> may be the email address of "steve@enterprisedomain. com" and the account owner password <NUM> may be "<NUM>. " Thus, as illustrated, the account owner <NUM> may generate a first access request <NUM>(<NUM>) that includes the real user alias <NUM> of "steve@enterprisedomain. com" and the account owner password <NUM> of "<NUM>. " Then, by virtue of the first access request <NUM>(<NUM>) correctly including the real alias <NUM> in conjunction with the account owner password <NUM>, the gatekeeper <NUM> may grant the account owner <NUM> with the full access <NUM> to the real user account <NUM> and/or other computing resources facilitated by the real tenant <NUM>.

In contrast, a second access request <NUM>(<NUM>) may include credentials that are associated with the false tenant <NUM>. For example, as illustrated, the second access request <NUM>(<NUM>) includes the real user alias <NUM> in conjunction with a deception trap password <NUM>. The deception trap password <NUM> may be a specific alphanumerical sequence of letters and/or numbers that cue the gatekeeper <NUM> to provide false access <NUM> to deceive a malicious entity <NUM> into believing that the full access <NUM> to the real tenant <NUM> has been granted. For example, the false access <NUM> may cause a computing device from which the second access request <NUM>(<NUM>) was transmitted to render a false inbox <NUM> and/or false outbox <NUM> that is populated with false data files <NUM>.

In some implementations, one or more components of the system <NUM> may monitor interactions that occur between a phisher device and the false user account <NUM> to harvest additional information about attack strategies and malware that are used by the malicious entities - thereby thwarting future user of such attack strategies and malware. As illustrated, for example, interaction data <NUM> is being transmitted from the phishing device <NUM> to the false user account <NUM>. Exemplary interaction data <NUM> may include information associated with phishing campaigns, malware that is used by the malicious entity <NUM>, and/or specific types of information being targeted by the malicious entity <NUM>. It can be appreciated that while generating the interaction data <NUM>, the malicious entity <NUM> may be under the belief that the false user account <NUM> is actually the real user account <NUM> that corresponds to the real user alias <NUM> (e.g., the email account of steve@enterprisedomain.

As described herein, the false tenant model <NUM> may be used to generate fake documents, fake emails, and/or fake contacts (e.g., fake email aliases). This generated content can be used to populate the false user account <NUM> thereby making it appear to be a real user account (i.e. a user account that is actively utilized by a real user for business purposes). In some embodiments, the false access <NUM> may be designed to give the appearance that emails are being transmitted to and/or from these fake contacts - all while the malicious entity <NUM> (e.g., phisher) is logged into the false user account <NUM>. For example, the false tenant model <NUM> may be used to continually populate the inbox and/or outbox with received and/or sent mail over the course of time. In this way, as the malicious entity <NUM> is logged into the false user account <NUM>, the impression is given that some real user is also simultaneously logged in and is currently using the account to send and/or receive emails - although it can be appreciated that no such real user actually exists. Email messages that are "sent" by the malicious entity <NUM> from the false user account <NUM> may in some embodiments show up in the outbox. Furthermore, in some implementations, emails that are "sent" by the malicious entity <NUM> may be transmitted to a response engine to trigger false responses and/or seed responses as described below.

In some embodiments, the system <NUM> may implement a phishing activity reporter <NUM> that is configured to report certain types of phishing activity to the real tenants <NUM>. For example, the phishing activity reporter <NUM> may monitor interaction data that takes place between a phisher device and the false user accounts. Then, based on the interaction data, the phishing activity reporter <NUM> may determine whether a malicious entity appears to be a common "commodity" type phisher that is pursuing sensitive information but has no particular or heightened interest in obtaining sensitive data specifically from a particular tenant. For example, once logged on, the malicious entity may download false contact information that is associated with the false user account <NUM> without browsing through and/or reading various specific documents that are stored in this account. Under these circumstances, the phishing activity reporter <NUM> may classify the malicious entity as a common "commodity" type phisher and report the phishing activity to one or more real tenants <NUM>. Alternatively, once logged on, the malicious entity may begin speedily browsing through and/or downloading the various false documents (e.g., fake email messages, fake data files, fake engineering drawings, etc.). It can be appreciated that this type of activity may indicate that the malicious entity has a specific interest in obtaining sensitive details about the particularly targeted business. Under these alternative circumstances, the phishing activity reporter <NUM> may classify the phisher as an "industrial espionage" type phisher and report the phishing activity to a specifically targeted real tenant <NUM>.

In this way, a real business can deploy false user accounts <NUM> that appear to include information that is valuable to their competitors and, therefore, serve to attract malicious competitors into accessing these accounts. Then, when the real business is actually targeted by such a competitor they can quickly learn of the ongoing threat and take appropriate security measures. It can be appreciated that such accounts may colloquially be referred to as "honeypot" accounts or simply "honeypots. " Based on the analysis of the interaction data <NUM>, the phishing activity reporter <NUM> may generate a phishing activity report <NUM> and send it to the account owner <NUM> and/or a tenant administrator <NUM> associated with the real tenant <NUM>.

In some embodiments, the tenant server(s) <NUM> may respond to the second access request <NUM>(<NUM>) and/or specific activities that are performed by the malicious entity <NUM> while logged into the false user account <NUM> by transmitting a security software <NUM> to the phisher computing device <NUM>. The security software <NUM> may be configured to monitor computing activities that the malicious entity <NUM> performs on the phisher device <NUM>. Additionally, or alternatively, the security software <NUM> may be configured to monitor one or more identifying features (e.g., screen size, driver configurations, etc.) of the phisher device <NUM>. Implementations of such techniques may be implemented by and/or in cooperation with law enforcement agencies.

As a specific example, the false user account <NUM> may be populated with one or more false data files <NUM> that are specifically named by the account owner <NUM> and/or the tenant administrator <NUM> to give the impression of being highly proprietary information. For example, if an organization is in the process of developing a highly proprietary new version of a popular smartphone, one or more false data files <NUM> may be populated into the false user account <NUM> and named in a fashion to appear to contain secret details associated with the highly proprietary new version of a popular smartphone. Then, if the malicious entity <NUM> logs into the false user account <NUM> using the deception trap password <NUM>, and then attempts to download a false data file that appears to contain proprietary information, the security software <NUM> may be transmitted to the phisher device <NUM> to monitor certain identifying features (e.g., screen size, driver configurations, etc.). It can be appreciated that because there is no legitimate purpose for an entity to attempt to access and download the false user accounts <NUM>, it can be presumed with a high degree of confidence that any entity which logs into the false user account by providing the real user alias <NUM> in conjunction with the deception trap password <NUM> is a malicious entity <NUM>. Thus, in many jurisdictions it may be feasible for law enforcement agencies and/or judicial agencies to condone (e.g., issue a warrant for) transmitting the security software <NUM> to fingerprint and/or monitor the phisher device <NUM>.

Turning now to <FIG>, illustrated is a system <NUM> for identifying messages <NUM> that are designed to fraudulently obtain sensitive information (e.g., phishing messages) and then generating fake sensitive information to pollute response data <NUM> that is associated with a phishing campaign <NUM>. Exemplary fake sensitive information may include, but is not limited to, dummy banking information (i.e., information that appears to be but is not actually associated with a valid bank account) and/or dummy email account credentials (i.e., information that appears to be but is not actually associated with a valid email account). In this way, even if a phisher (e.g., a person or entity that is implementing a phishing campaign <NUM>) does obtain some real sensitive information (e.g., real bank account information and/or real email account information) from users that are unsuspectingly deceived by the messages <NUM>, the phisher will have difficulty in confidently identifying and exploiting this real sensitive information since it will be essentially buried within the fake sensitive information. Thus, among other benefits, the technologies described herein provide a significant barrier to successfully exploiting any fraudulently obtained real sensitive information.

As illustrated, a security filter <NUM> may analyze messages <NUM> to filter out phishing messages that are designed to fraudulently persuade ("deceive") account owners <NUM> into providing various types of sensitive information. For example, as illustrated, a message <NUM> is transmitted from a phisher computer system <NUM> to the tenant servers <NUM> where it is received by the security filter <NUM>. The message <NUM> may correspond to a first phishing campaign <NUM>(<NUM>) that a phishing entity generates on a phisher device <NUM> and uploads to the phisher computing system <NUM> for implementation. The phisher computing system <NUM> may include one or more server computers that are leveraged to implement one or more phishing campaigns <NUM>.

Upon receipt of the message <NUM>, the tenant servers <NUM> may deploy the security filter <NUM> to analyze the message <NUM> with respect to the filter criteria <NUM>. The filter criteria <NUM> may include, for example, a blacklist of known malicious phishing websites so that any message that contains a link to a blacklisted website will be designated as a phishing message, a white list of known trusted websites so that any message that contains a link to a non-whitelisted website will be designated as a phishing message, or other criteria that is indicative of a particular message being designed for phishing purposes. Based on the analysis of individual messages <NUM> with respect to the filter criteria <NUM>, the security filter <NUM> may determine which messages are allowed to pass through to the real user account(s) <NUM> for access by the users via the user device(s) <NUM>. In the illustrated example, the message <NUM> that is transmitted from the phisher computing system <NUM> is analyzed by the security filter <NUM> with respect to the filter criteria <NUM> and, ultimately, is designated by the security filter <NUM> as a phishing message.

In order to safely handle fishing messages, the tenant servers <NUM> may implement a detonation chamber <NUM> that is designed to facilitate manipulation of various aspects of individual messages <NUM> in a protected environment. For example, the detonation chamber <NUM> may be an isolated computing environment such as, for example, a container and/or light weight virtual machine that isolates the real tenants <NUM> and real user accounts <NUM> thereof from any computing activity that occurs within the detonation chamber <NUM>. In the illustrated example, the message <NUM> is designated by the security filter <NUM> as a phishing message and, as a result, is transmitted into the detonation chamber <NUM>. The detonation chamber <NUM> isolates the message <NUM> and any malicious contents thereof from other components of the tenant servers <NUM>.

In some implementations, links that are contained within the message <NUM> that the security filter <NUM> transmits into the detonation chamber <NUM> may be detonated (e.g., activated and/or selected) within the detonation chamber <NUM> to safely observe and/or analyze the resulting effects. As a specific but nonlimiting example, the message <NUM> may contain a link that directs a web browsing application to a phishing website that is designed to fraudulently obtain sensitive information from unsuspecting users. In many instances such phishing websites are specifically designed to aesthetically mimic a website of a legitimate organization and may even be hosted at a website address that closely resembles that of the legitimate organization's website. For example, the message <NUM> may indicate that the user's bank account has experienced a security breach and that the specific user action of visiting a linked website for the purpose of resetting a password is required to prevent the bank account from being frozen.

Upon activating the link(s) that is contained within the message <NUM>, a web browser may open the linked website which may include various form fields that the users instructed to enter specific types of sensitive information into. For example, users may be prompted to enter a username and password associated with an online banking account.

The tenant servers <NUM> may further utilize a response engine <NUM> to generate a response <NUM> to the message <NUM> in order to pollute response data <NUM> on the phisher computing system <NUM>. The response engine <NUM> may analyze the message <NUM> to identify one or more types of sensitive information that the message <NUM> is designed to fraudulently obtain from unsuspecting users. For example, continuing with the example in which the message <NUM> indicates that the user's bank account has been compromised and contains a link to a website that prompts users to enter their associated username and/or password, the response engine <NUM> may analyze the linked website to identify that users are being prompted to enter a username into a first form field and a password into a second form field.

Upon identifying the type(s) of information being sought, the response engine <NUM> may generate content that includes fake sensitive information of those type(s). For example, the response engine <NUM> may generate fake usernames and/or fake passwords. Ultimately, response engine <NUM> may cause a response <NUM> that contains generated content to be transmitted to the phisher computing system <NUM>.

In some implementations, the response engine <NUM> may generate false responses <NUM>(F) which include false sensitive information that is completely unusable. For example, a false response <NUM>(F) may include one or both of a false username and/or false password that are generated by the response engine <NUM> and are unusable in the sense that the false username and/or false password do not provide access to any real user account <NUM> or any false user account <NUM> as described below. As another example, a false response <NUM>(F) may include false credit card number that is unusable in the sense that it does not actually correspond to any credit card account.

In some implementations, the response engine <NUM> may be configured to generate false sensitive information that on its face passes one or more authenticity criteria. As a specific but nonlimiting example, under circumstances in which the response engine <NUM> determines that the message <NUM> is fraudulently seeking credit card numbers, the response engine may generate and transmit false credit card numbers which satisfy the Luhn algorithm that is commonly used to verify the authenticity of credit card numbers. In this way, it will be impractical for the phisher to sift through the responses and separate the fake sensitive information from any real sensitive information that is also obtained.

By generating and transmitting false responses <NUM>(F) that are responsive to the message <NUM> but that merely include false sensitive information of the type being sought within the message <NUM>, the system <NUM> may create substantial barriers to phishers being able to exploit even real responses <NUM>(R) (i.e., responses that are generated by real users and that contain real sensitive information) - if any exist within the response data <NUM>. For example, consider a scenario in which implementation of the phishing campaign <NUM>(<NUM>) results in one million emails being sent out to different user aliases. Suppose that of the one million emails that are sent, some fraction of these emails successfully reaches users' inboxes (e.g., passes through the security filter <NUM>) and dupes these users into providing real sensitive information. Typically, a phisher that receives these responses would have a very high degree of confidence that the information provided is actual real sensitive information that is readily exploitable (e.g., for financial gain and/or other purposes).

By transmitting some amount of false responses <NUM>(F), the techniques described herein serve to pollute the response data <NUM> by diluting any real responses <NUM>(F) with some amount of false responses <NUM>(F). For example, suppose that the response data <NUM> includes a mere fifteen real responses <NUM>(R). Typically, even though the phishing campaign <NUM>(<NUM>) may have a relatively low success rate (e.g., <NUM> parts per million) the resulting successes are readily identifiable and exploitable to any malicious entity having access to the response data <NUM>. However, if the response data <NUM> further includes some amount of false responses <NUM>(F), then the resulting successes will be hidden or buried within the noise generated by the false responses <NUM>(F). This makes identification and exploitation of the real sensitive data difficult and in some cases impractical. Building off the specific but nonlimiting example from above, if in addition to the fifteen real responses <NUM>(R) the response data <NUM> also includes fifteen-hundred false responses <NUM>(F), then a phisher will be forced to spend a substantial amount of time and resources sifting through the false responses <NUM>(F). Furthermore, the phisher will have no effective means to readily identify whether any particular piece of sensitive information is real or fake.

In some implementations, the response engine <NUM> may generate seed responses <NUM>(S) which include information that appears to be of the type being sought within the message <NUM> but which actually leads to one or more false user accounts <NUM>. As a specific but nonlimiting example, under circumstances in which the message <NUM> seeks to obtain credentials that are usable to access a real user account <NUM>, the response engine <NUM> may generate a seed response <NUM>(S) that includes one or more credentials that are usable to access a false user account <NUM> that is being hosted by a false tenant <NUM>. An exemplary seed response <NUM>(S) may include the deception trap password <NUM>. As illustrated, the phisher device <NUM> may be used to obtain the seed response <NUM>(S) from the response data <NUM>. Then, the phisher device <NUM> may be used to access the false user account <NUM> by providing the user credentials obtained from the seed response <NUM>(S) to the tenant servers <NUM>.

As described above, the false user account <NUM> may even be populated with false data files to give the appearance of being a real user account <NUM>. For example, the tenant server <NUM> may implement one or more false tenant models <NUM> to generate false data files (e.g., data files that contain made-up or fanciful data but that resemble legitimate business files such as user emails and hosted documents). Thus, a malicious actor that logs onto the false user account <NUM> may be enticed to spend time browsing through the false data files.

In some implementations, the response engine <NUM> may be designed to cause transmission of false responses <NUM>(F) and/or seed responses <NUM>(S) at a rate that is sufficiently high to disrupt operation of the phisher computing system <NUM>. For example, the response engine <NUM> may conduct a Denial of Service (DoS) attack and/or a Distributed Denial of Service (DDoS) attack by repeatedly activating the link within the message <NUM> and/or repeatedly transmitting responses <NUM> to the phisher computing system <NUM>. In this way, the techniques described herein may be usable to both pollute the response data <NUM> with false responses <NUM>(F) and/or seed responses <NUM>(S) and also to prevent unsuspecting users from even being able to provide real sensitive information. For example, even if a phishing message associated with the phishing campaign <NUM>(<NUM>) actually makes it through to a particular user's inbox and this particular user actually clicks the link with the intention of providing the requested information (e.g., the real sensitive information), the web server(s) that is hosting phishing website will be experiencing so many requests and/or responses from the response engine <NUM> that it will be unable to serve the particular user's request.

The tenant server(s) <NUM> may include a device identification engine <NUM> to determine configuration data <NUM> that corresponds to the phisher device <NUM> when that phisher device <NUM> is used to log into the false user account <NUM>. Exemplary configuration data <NUM> may include, but is not limited to, a screen size of the phisher device <NUM>, a resolution of the phisher device <NUM>, browser configurations on the phisher device <NUM>, one or more plug-ins that are being operated by the phisher device <NUM>, what browser is being used on the phisher device <NUM>, an Internet protocol (IP) address associated with the phisher device <NUM>, and/or any other information that is discernible about the phisher device <NUM>. This configuration data <NUM> may provide the device identification engine <NUM> with the ability to identify one or more other login attempts that originate from the phisher device <NUM>.

Stated plainly, the configuration data <NUM> serves as a "fingerprint" for the phisher device <NUM>. For example, due to the extremely high number of possible combinations of browser settings and plug-ins that can exist on any particular personal computing device (e.g., a laptop computer, etc.), it may be exceedingly improbable that more than one computing device at any particular IP address will have a specific combination of browser settings and plug-ins. This may hold true even if the particular IP address supports a substantially large number of computing devices such as, for example, in the case of IP addresses that are assigned to universities and other large organizations.

Since the false user account <NUM> is not actually assigned to any human user for legitimate purposes, it can be assumed with a high degree of confidence that the phisher device <NUM> that has logged into the false user account 132is being used by a malicious entity for illegitimate and malicious purposes. Accordingly, the system <NUM> may utilize the configuration data <NUM> to "fingerprint" the phisher device <NUM> and identify when it is subsequently used to attempt to log into one or more real user accounts <NUM>. In some implementations, the tenant servers <NUM> may deny such attempts to log into real user accounts <NUM> from devices that are identified as having previously been used to log into one or more false user accounts <NUM>- even if the user credentials provided from the phisher device <NUM> are completely accurate. In this way, even if a particular user is duped by a phishing email and provides the phisher with their real user credentials, the phisher will still be denied access to the particular user's real user account <NUM> - so long as the phisher attempts to access the account from a "fingerprinted" computing device.

Additionally, or alternatively, the tenant servers <NUM> may initiate enhanced security protocols in association with a real user account <NUM> in response to determining that the "fingerprinted" phisher device <NUM> is currently being used in an attempt to log into the real user account <NUM>. For example, suppose that information has been provided in association with the real user account <NUM> that is sufficient to require multi-factor authentication for logging in. For example, the user for the account has provided both a password and also a cell phone number via which receive text message codes that are to be provided as an additional factor (i.e., in addition to the password) in order to log into the particular real user account <NUM>. Under these specific but nonlimiting circumstances, an attempt to log into the real user account <NUM> from a device that resembles the phisher device <NUM> (e.g., has configuration data <NUM> that matches that of the phisher device <NUM> to a certain degree) may trigger heightened security requirements of multifactor authentication.

Additionally, or alternatively, the tenant servers <NUM> may initiate enhanced security protocols for one or more real user accounts <NUM> in response to determining that the "fingerprinted" phisher device <NUM> has at some previous time been used to log into the real user accounts <NUM>. For example, suppose that the phisher device <NUM> has already been used to log into a real user account <NUM> and then is subsequently used to log into the false user account <NUM>- for which the credentials are provided in the seed response <NUM>(S). Under these circumstances, one or more tenant administrators for the real tenants <NUM> may be notified that the real user account <NUM> has ostensibly been compromised and/or a password reset procedure may be required in association with the particular real user account <NUM>.

Turning now to <FIG>, illustrated is a system <NUM> for enabling a real user to designate a message <NUM> as a phishing attempt in order to deploy artificial intelligence (AI) techniques to generate an impersonation response <NUM> which lures a phisher associated with the message <NUM> into a conversation cycle <NUM>. As illustrated, the message <NUM> originates at the phisher computing system <NUM> in association with a phishing campaign - as described above in relation to <FIG>. However, for purposes of the <FIG>, the filter criteria <NUM> do not cause the security filter <NUM> to identify the message <NUM> as being a phishing message. For example, the message <NUM> may originate in association with a "novel" phishing campaign <NUM> that has not previously been identified and used to update the filter criteria <NUM>. As illustrated in <FIG>, the security filter <NUM> allows the message <NUM> to pass through to the real tenant <NUM> and into one or more real user accounts <NUM>. For example, the message <NUM> may pass to an email inbox of a real user account <NUM> and, therefore, may be accessible by a real user via the user device <NUM>.

Upon review of the message <NUM>, the real user may recognize the nature of the message <NUM> and designate the message as a phishing attempt. That is, the real user may mark the message <NUM> as a flagged message <NUM> that is flagged ("designated") as a phishing email. The flagged message <NUM> may be transmitted to the security filter <NUM> which may analyze the flagged message <NUM> to update the filter criteria <NUM>. As a specific but nonlimiting example, the security filter <NUM> may identify one or more user interface (UI) input controls of the flagged message <NUM> and update the filter criteria <NUM> for identifying similar or identical UI input controls in future messages <NUM> that are received via the tenant server(s) <NUM>. Exemplary such UI input controls include, but are not limited to, links to websites, form fields, particular phrases and/or patterns of phrases, and so on. As illustrated, the flagged message <NUM> may also be passed into the detonation chamber <NUM> to facilitate securely interacting with and/or responding to the flagged message <NUM> using the response engine <NUM>. For example, one or more links that are included within the flagged message <NUM> may be activated within the detonation chamber 116to safely observe the resulting effects.

The flagged message <NUM> may be analyzed by the response engine <NUM> to generate a response to the flagged message <NUM>. In the illustrated embodiment, the response that is generated by the response engine <NUM> is an impersonation response <NUM> that is transmitted to the phisher computing system <NUM> with data indicating that the impersonation response originated (e.g., was drafted in and/or transmitted from) from the particular real user account <NUM> to which the message <NUM> was addressed. For example, if the message <NUM> is specifically addressed to steve@enterprisedomain. com, then the impersonation response <NUM> may include data that is designed to forge a portion of header data included within the impersonation response <NUM> so that the appears to have originated from the real user account <NUM> of steve@enterprisedomain. com - despite having actually originated from within the detonation chamber <NUM>. Stated plainly, an impersonation response <NUM> is a response that is designed to "spoof' the particular user account to which the message <NUM> was addressed.

In various implementations, the response engine <NUM> may analyze the flagged message <NUM> to identify one or more types of sensitive information that are being pursued. As a specific but nonlimiting example, the flagged message <NUM> may be an email message that appears to originate from the user's cellular phone service provider. The flagged message <NUM> may indicate that the user's account is past due, and that service will be terminated unless a payment is submitted immediately. The flagged message <NUM> may further indicate that payment can be submitted via a cashier's check or a credit card by replying the email with that information. Under these specific circumstances, the response engine <NUM> may analyze the flagged message <NUM> to determine that the phishing campaign is pursuing credit card information. Then, the response engine <NUM> may generate (or otherwise obtain) false credit card information to include within the impersonation response <NUM>.

In various implementations, the response engine <NUM> may leverage one or more artificial intelligence (AI) techniques to generate a response to the flagged message <NUM> that closely resembles how a human might actually respond to such a message. In the illustrated embodiment, the response engine <NUM> includes a natural language processing (NLP) model <NUM> that is usable to generate responses to messages in a manner that is consistent with how two humans might typically interact and/or converse with one another. For example, the response engine <NUM> may generate a response to the flagged message <NUM> that is apologetic for becoming past due on the cellular phone account and asking whether the company will accept a particular type of credit card. Then, the response that is generated may be transmitted to the phisher computer system <NUM> response as the impersonation response <NUM>. In this example, the response engine <NUM> has generated an impersonation response <NUM> that indicates a willingness to comply with the phishing message scam, but which does not actually include the sensitive information that is being pursued.

In various implementations, the response engine <NUM> may be specifically designed to generate such responses when feasible in order to lure the phisher into replying to the impersonation response <NUM> with a responsive message <NUM>. In this way, the response engine <NUM> may be initiate a conversation cycle <NUM> with the phisher in which a series of additional impersonation responses <NUM> and responsive messages <NUM> are transmitted between the phisher and the response engine <NUM> - thereby consuming the phisher's time and resources.

In some implementations, the impersonation responses <NUM> may be tagged with data that instructs or otherwise causes the tenant servers <NUM> to prevent the responsive messages <NUM> from being sent to the real user account <NUM>. In this way, once the impersonation response <NUM> is sent by the response engine <NUM>, any resulting messages from the phisher that are addressed to the user will not end up in the user's real email inbox. Thus, once a user flags the message <NUM> as being a phishing attempt, the system <NUM> will initiate the conversation cycle <NUM> to waste the phisher's time without consuming any additional amount of the real user's time.

In some implementations, the response engine <NUM> may be designed to induce a conversation cycle <NUM> in which the phisher is lured into divulging additional details of one or more other phishing campaigns <NUM>. As a specific but nonlimiting example, the response engine <NUM> may generate an impersonation response <NUM> that provides information for a false credit card that has a recently lapsed expiration date. The false credit card information may be designed to cause actual credit card charging systems to indicate that the card has expired. Thus, if the phisher attempts to use the false credit card information to make an online purchase (as phishers often do anonymously online with real credit card information), they will receive a message that payment cannot be processed because the credit card provided has expired. This may induce the phisher into sending a responsive message <NUM> that indicates that payment has failed and that requests alternate credit card information. Then, the response engine <NUM> may generate another impersonation response <NUM> that indicates that the credit card provided was the only credit card owned and that the user was unaware that it had expired.

The message generated by the response engine <NUM> may further inquire as to whether any alternate forms of online payment can be accepted. This impersonation response <NUM> may then induce the phisher into providing instructions on how to remit payment to a particular online payment account that the phisher also uses to conduct another phishing campaign <NUM>.

In some embodiments, the additional details of the phishing campaigns <NUM> that are identified by inducing the conversation cycle <NUM> may be used to update the filter criteria <NUM>. For example, when the phisher is induced into providing details associated with the particular online payment account, the filter criteria <NUM> may be updated to reflect this information. Once the filter criteria <NUM> are updated, then any emails received at the tenant server <NUM> in the future which contain details regarding this particular online payment account may be recognized by the security filter <NUM> as being associated with a phishing campaign <NUM>.

Although these techniques are predominantly discussed in the context of the impersonation response <NUM> spoofing a real user account <NUM>, it is contemplated that such techniques may also be deployed to spoof false user accounts <NUM> (not shown in <FIG>) to which a message <NUM> is addressed. For example, as described above, a phishing entity may send out emails in association with a phishing campaign and may receive back a seed response <NUM>(S) that includes false sensitive information. This false sensitive information may include false email aliases (e.g., email addresses). Then, the phishing entity may send out phishing emails to this false email address. Upon receipt of phishing emails that are addressed to the false email address, the response engine <NUM> may generate an impersonation response <NUM> that spoofs the false email address.

Although these techniques are predominantly discussed in the context of the impersonation response(s) <NUM> and/or conversation cycle <NUM> occurring as a result of the message <NUM> being manually flagged by the user of the real user account <NUM> as phishing, it is contemplated that such techniques may also occur as a result of the message <NUM> being flagged as phishing by the security filter <NUM> based on the filter criteria. For example, the impersonation response(s) <NUM> and/or conversation cycle <NUM> described in relation to <FIG> may occur even with respect to messages that do not pass through the security filter <NUM> to the real user account <NUM>.

<FIG> is a flow diagram of an illustrative process <NUM> which is illustrated as a collection of blocks in a logical flow graph, which represent a sequence of operations that can be implemented in hardware, software, or a combination thereof. In the context of software, the blocks represent computer-executable instructions that, when executed by one or more processors, perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, and the like that perform or implement particular functions. The order in which operations are described is not intended to be construed as a limitation, and any number of the described blocks can be combined in any order and/or in parallel to implement the process. Other processes described throughout this disclosure shall be interpreted accordingly.

Turning now to <FIG>, illustrated is a flow diagram of an exemplary process <NUM> to provision access to a false user account that is populated with fake data files that are generated based on a false tenant model.

At block <NUM>, a system may analyze a corpus of text <NUM> to identify properties of a first set of data files. For example, the system may receive the corpus of text <NUM> in the form of selections of one or more components of real users accounts <NUM> such as, for example, real inboxes <NUM>, real outboxes <NUM>, and/or real hosted file locations. The corpus of text <NUM> may be provided to a corpus analysis application <NUM> which may utilize various artificial intelligence (AI) techniques to discern the properties of the first set of data files. As a specific example, the corpus analysis application <NUM> may utilize an RNN that includes a plurality of layers of Long Short-Term Memory (LSTM) units <NUM> to analyze the corpus of text and determine the various properties. With regard to the properties of the corpus of text <NUM>, the corpus analysis application <NUM> may determine the vocabulary that is used within the corpus of text <NUM>. The corpus analysis application <NUM> may further determine the frequency with which various words within the vocabulary are used and/or the context within which the various words within the vocabulary are used.

At block <NUM>, the system may generate a false tenant model <NUM> that is usable to generate other data files that also exhibit the properties of the first set of data files. For example, if the corpus of text <NUM> includes a plurality of emails included in one or more real inboxes <NUM> and/or real outboxes <NUM>, then the false tenant model <NUM> may be usable to generate other individual emails that exhibit similar properties as was observed in association with the corpus of text <NUM>. However, despite appearing similar to the first set of data files, the files that are generated by the false tenant model <NUM> are fanciful data files with no real value to a phisher who gains access thereto. For example, the generated files may appear to be genuine email documents despite being generated by a computing system rather than by an actual person.

At block <NUM>, the system may deploy the false tenant model <NUM> to populate a false user account 132with a second set of data files. For example, the false user account <NUM> may be an email account that appears to be a real email account and may even be usable to send and/or receive emails. However, the false user account 132is not actually assigned to a real user but rather is a "honeypot" type user account that is designed to attract phishers to observe their computing habits, waste their time, and/or extract additional detail regarding new and/or evolving phishing campaigns.

At block <NUM>, the system may receive a request for access to the false user account 132from a computing device such as, for example, the phisher device <NUM>. The phisher device <NUM> may be a laptop computer or some other type of personal computing device. The request may include credentials associated with the false user account <NUM>. For example, the credentials may be transmitted in a seed response <NUM>(S) to lure the phisher(s) into accessing the honeypot type false user account <NUM>.

Then, at block <NUM>, the system may respond to the request by provisioning the computing device with access to the second set of data files. In this way, the phisher is enabled to log into the false user account 132which in turn provides the phisher with the false impression that access has been obtained to a real user account <NUM> that is being used to conduct actual business. Furthermore, in some embodiments, the false tenant model <NUM> may be used to periodically generate and add new files into the false user account <NUM>. In this way, the phisher can be logged into the false user account 132and, in real time, be witnesses emails being sent and/or received to give the impression that a real user is concurrently logged into and even using the false user account <NUM>.

<FIG> shows additional details of an example computer architecture <NUM> for a computer capable of executing the techniques described herein. The computer architecture <NUM> illustrated in <FIG> illustrates an architecture for a server computer, or network of server computers, or any other types of computing devices suitable for implementing the functionality described herein. The computer architecture <NUM> may be utilized to execute any aspects of the software components presented herein.

The computer architecture <NUM> illustrated in <FIG> includes a central processing unit <NUM> ("CPU"), a system memory <NUM>, including a random-access memory <NUM> ("RAM") and a read-only memory ("ROM") <NUM>, and a system bus <NUM> that couples the memory <NUM> to the CPU <NUM>. A basic input/output system containing the basic routines that help to transfer information between input controls within the computer architecture <NUM>, such as during startup, is stored in the ROM <NUM>. The computer architecture <NUM> further includes a mass storage device <NUM> for storing an operating system <NUM>, other data, and one or more application programs. The mass storage device <NUM> may further include one or more of the security filter <NUM>, the detonation chamber <NUM>, the false tenant model <NUM>, the real tenants <NUM>), and/or the false tenants <NUM>.

The mass storage device <NUM> is connected to the CPU <NUM> through a mass storage controller (not shown) connected to the bus <NUM>. The mass storage device <NUM> and its associated computer-readable media provide non-volatile storage for the computer architecture <NUM>. Although the description of computer-readable media contained herein refers to a mass storage device, such as a solid-state drive, a hard disk or CD-ROM drive, it should be appreciated by those skilled in the art that computer-readable media can be any available computer storage media or communication media that can be accessed by the computer architecture <NUM>.

Communication media includes computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any delivery media. The term "modulated data signal" means a signal that has one or more of its characteristics changed or set in a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of the any of the above should also be included within the scope of computer-readable media.

By way of example, and not limitation, computer storage media may include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. For example, computer media includes, but is not limited to, RAM, ROM, EPROM, EEPROM, flash memory or other solid state memory technology, CD-ROM, digital versatile disks ("DVD"), HD-DVD, BLU-RAY, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the computer architecture <NUM>. For purposes of the claims, the phrase "computer storage medium," "computer-readable storage medium" and variations thereof, does not include waves, signals, and/or other transitory and/or intangible communication media, per se.

According to various techniques, the computer architecture <NUM> may operate in a networked environment using logical connections to remote computers through a network <NUM> and/or another network (not shown). The computer architecture <NUM> may connect to the network <NUM> through a network interface unit <NUM> connected to the bus <NUM>. It should be appreciated that the network interface unit <NUM> also may be utilized to connect to other types of networks and remote computer systems. The computer architecture <NUM> also may include an input/output controller <NUM> for receiving and processing input from a number of other devices, including a keyboard, mouse, or electronic stylus (not shown in <FIG>). Similarly, the input/output controller <NUM> may provide output to a display screen, a printer, or other type of output device (also not shown in <FIG>). It should also be appreciated that via a connection to the network <NUM> through a network interface unit <NUM>, the computing architecture may enable the tenant servers <NUM> to communicate with one or more of the machine learning engine <NUM>, the phisher computing system <NUM>, the user device <NUM>, and/or the phisher device <NUM>.

It should be appreciated that the software components described herein may, when loaded into the CPU <NUM> and executed, transform the CPU <NUM> and the overall computer architecture <NUM> from a general-purpose computing system into a special-purpose computing system customized to facilitate the functionality presented herein. The CPU <NUM> may be constructed from any number of transistors or other discrete circuit input controls, which may individually or collectively assume any number of states. More specifically, the CPU <NUM> may operate as a finite-state machine, in response to executable instructions contained within the software modules disclosed herein. These computer-executable instructions may transform the CPU <NUM> by specifying how the CPU <NUM> transitions between states, thereby transforming the transistors or other discrete hardware input controls constituting the CPU <NUM>.

For example, the software may transform the state of transistors, capacitors, or other discrete circuit input controls constituting the semiconductor memory.

As another example, the computer-readable media disclosed herein may be implemented using magnetic or optical technology. In such implementations, the software presented herein may transform the physical state of magnetic or optical media, when the software is encoded therein. These transformations may include altering the magnetic characteristics of particular locations within given magnetic media. These transformations also may include altering the physical features or characteristics of particular locations within given optical media, to change the optical characteristics of those locations. Other transformations of physical media are possible without departing from the scope and spirit of the present description, with the foregoing examples provided only to facilitate this discussion.

In light of the above, it should be appreciated that many types of physical transformations take place in the computer architecture <NUM> in order to store and execute the software components presented herein. It also should be appreciated that the computer architecture <NUM> may include other types of computing devices, including hand-held computers, embedded computer systems, personal digital assistants, and other types of computing devices known to those skilled in the art. It is also contemplated that the computer architecture <NUM> may not include all of the components shown in <FIG>, may include other components that are not explicitly shown in <FIG>, or may utilize an architecture completely different than that shown in <FIG>.

In embodiments, interaction data that indicates computing activities that occur between the computing device and the false user account may be analyzed. A phishing activity report may be generated that indicates aspects of the computing activities.

The access request may be analyzed to determine whether the one or more credentials include a real user alias, that corresponds to a real user account, in conjunction with an account owner password that corresponds to the real user account. Access to the real user account may be provided in response to the one or more credentials including the real user alias in conjunction with the account owner password. Access to the false user account may be provided in response to the one or more credentials including the real user alias and omitting the account owner password.

Interaction data that indicates computing activities that occur between the computing device and the false user account may be analysed. Filter criteria may be updated based on aspects of the computing activities.

Properties may include a grammatical structure of the plurality of real data files that correspond to one or more real user accounts.

Claim 1:
A system (<NUM>), comprising:
at least one processor (<NUM>); and
at least one memory (<NUM>) in communication with the at least one processor (<NUM>), the at least one memory (<NUM>) having computer-readable instructions stored thereupon that, when executed by the at least one processor (<NUM>), cause the at least one processor to:
cause a false tenant (<NUM>) to generate a false user account (<NUM>) in association with one or more credentials;
cause a machine learning engine (<NUM>) to analyze a corpus of text (<NUM>) to build a false tenant model (<NUM>) that is usable to generate false data files (<NUM>) that exhibit properties that have been identified by analyzing a corpus of text (<NUM>);
deploy the false tenant model (<NUM>) to populate the false user account (<NUM>) with the false data files (<NUM>);
receive, from a computing device (<NUM>), an access request (<NUM>) that includes the one or more credentials; and
based on the access request (<NUM>), provision the computing device (<NUM>) with access to the false data files that are included within the false user account.