CN117917043A

CN117917043A - Credential input detection and threat analysis

Info

Publication number: CN117917043A
Application number: CN202280059733.5A
Authority: CN
Inventors: P·梅苏里亚; A·阿拉巴斯; A·萨加尔; M·B·福蒂尼; 张汝颇; C·斯托克韦尔; M·D·麦科马克; J·J·韦伯; C·J·斯特姆普勒; S·R·哈密尔顿; B·K·凯特林; R·J·穆里略; R·G·莱弗茨; E·P·道格拉斯; C·塞弗特
Original assignee: Microsoft Technology Licensing LLC
Current assignee: Microsoft Technology Licensing LLC
Priority date: 2021-09-17
Filing date: 2022-08-23
Publication date: 2024-04-19

Abstract

The techniques described herein identify and mitigate phishing attempts by analyzing received user inputs at the operating system level. Initially, credentials (such as a user name or password) are registered with the threat detection system. The techniques described herein intercept user input at the operating system level, generate an input hash value, and compare it to the hash value of the credential being monitored. When the hash value for the entered string matches the hash value for the credential being monitored, the credential entry is detected. When a secret entry is detected, the techniques described herein will perform threat assessment. Threat assessment may use application context and network context as inputs to the assessment. When a threat is detected, various mitigation actions may be employed.

Description

Credential input detection and threat analysis

Background

On the internet, programs for fraudulently obtaining credentials and cryptographic information of others have become commonplace. These programs are commonly referred to as "phishing". Phishing programs can be very complex and continue to grow in their level of complexity. In some plans, a user may transfer from a desired page to a fraudulent page that appears to be similar in appearance to the desired page. The user may be directed to this type of fraudulent page by clicking on a link, typing a website by mistake, or any other mechanism. Other programs may be based on the user being persuaded to browse fraudulent pages based on error information, such as e-mails purported to be from known businesses. In other plans, the user may enter information correctly to browse the desired site, but the user may be rerouted due to server damage. When login and password prompts are presented to the user, the user typically has little context to evaluate whether the request for login credentials is legitimate. This makes advanced phishing schemes difficult or even impossible to detect by the user.

Disclosure of Invention

This summary is intended to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

Initially, credentials (such as a user name or password) are registered in a threat detection system. The various aspects of the technology described herein are not limited to use with a username or password. The credential may be any type of secret or confidential information, such as a social security number, credit card information, driver's license number, passport ID, which may be monitored by the system described herein. In one aspect, a user name and password for an operating system are automatically registered. A user interface may be provided for a user or other individual (e.g., a system administrator) to register additional credentials for monitoring.

The registered credentials are associated with the user in a credential data store, which may be described herein as a credential manager. In one aspect, rather than the credentials being stored, a hash of the credentials is stored. In an aspect, a hash of the credential is generated using a first function and stored for comparison with a hash generated from text entered by the user.

The techniques described herein identify and mitigate phishing attempts by analyzing received user input at the operating system level. When input is received at the operating system level, detection of threats that may not be detected by application-level input analysis is allowed. The techniques described herein will perform threat assessment when a credential entry is detected. Threat assessment may use application context and network context as inputs to the assessment. Among other possible categorizations, threat assessment may categorize credential inputs as valid web pages, secure/unsecure applications, invalid credentials, password reuse, untrusted, known malicious and unknown.

When a threat is detected, various mitigation actions may be taken. The user and/or system administrator may specify mitigation actions to be taken when the threat is detected. Different mitigation actions may be specified for different threat classifications.

Drawings

The technology described herein is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings in which like reference numerals refer to similar elements and in which:

FIG. 1 is a block diagram of an example operating environment suitable for implementation with respect to the present disclosure;

2-4 are diagrams depicting capturing keyboard and analysis keyboard entries at an operating system level according to an aspect of the technology described herein;

FIG. 5 is a diagram illustrating analyzing keystrokes in an input buffer to detect credentials, according to an aspect of the technology described herein;

FIGS. 6-8 are diagrams showing a user interface during a phishing attempt;

FIG. 9 is a block diagram illustrating an activity of components for detecting a phishing website according to an aspect of the technology described herein;

FIG. 10 is a block diagram illustrating the activity of components for detecting man-in-the-middle attacks according to an aspect of the technology described herein;

FIG. 11 is a block diagram illustrating activity of components for detecting phishing attempts by a word processor application, according to an aspect of the technology described herein;

FIG. 12 is a block diagram illustrating activity of components for detecting phishing attacks through a video conferencing platform according to an aspect of the technology described herein;

FIG. 13 is a block diagram illustrating activity of a component for detecting phishing attacks through operating system notification according to an aspect of the technology described herein;

FIG. 14 is a block diagram illustrating an activity of components for detecting password reuse according to an aspect of the technology described herein;

FIG. 15 is a block diagram illustrating activities of components for validating proper password use according to an aspect of the technology described herein;

FIG. 16 is a flow chart illustrating a method of detecting an analysis credential input in accordance with an aspect of the technology described herein;

FIG. 17 is a block diagram illustrating a computing device suitable for use with aspects of the technology described herein;

FIG. 18 is a flow chart illustrating a method of detecting an analysis credential input in accordance with an aspect of the technology described herein; and

FIG. 19 is a flow chart illustrating a method of detecting an analysis credential input according to an aspect of the technology described herein.

Detailed Description

The various techniques described herein have been described with sufficient specificity to meet statutory requirements. However, the description itself is not intended to limit the scope of this patent. Rather, the inventors have contemplated that the claimed subject matter might also be embodied in other ways, to include different steps or combinations of steps similar to the ones described in this document, in conjunction with other present or future technologies. Furthermore, although the terms "step" and/or "block" may be used herein to connote different elements of methods employed, the terms should not be interpreted as implying any particular order among or between various steps herein disclosed unless and except when the order of individual steps is explicitly described.

The techniques described herein identify and mitigate phishing attempts by analyzing received user input at the operating system level. When input is received at the operating system level, detection of threats that may not be detected by application-level input analysis is allowed. The solicitation of credentials by a phishing application is one example of an attack that may avoid detection at the application level, but may be detected by analyzing received input at the operating system level according to the techniques described herein.

The registered credentials are associated with the user in a credential data store, which may be described herein as a credential manager. In one aspect, rather than the credentials being stored, a hash of the credentials is stored. In an aspect, a hash of the credential is generated using a first function and stored for comparison with a hash generated from text entered by a user. When a credential entry is detected, the techniques described herein will perform threat assessment without the credential or credential hash exiting the local operating system.

The techniques described herein intercept user input at the operating system level, generate a hash of the input, and compare it to the hash of the monitored credential. In an aspect, a hash of the last n characters received is generated, where n is the character length of the credential. For example, a hash of the last 8 characters entered may be generated and compared to a hash of an 8 character password. In another aspect, a hash of less than the complete credential is generated and used for detection of potential entries of the credential before the entry is completed. For example, hashes of 4 characters, 5 characters, 6 characters, and 7 characters may be generated to predict an entry for an 8-character password. In this case, the input string is hashed at a character length that matches the hash value of the partial credential stored in the credential manager.

A credential entry is detected when the hash for the entered string matches the hash for the monitored credential. Potential credential entries are detected when the hash of the entered string matches the hash for the partial credential.

When a credential entry is detected, the techniques described herein will perform threat assessment. Threat assessment may use application context and network context as inputs to the assessment. Other information may also be used in the threat assessment process. Various sensors are used to identify characteristics of the application context and the network context. Various aspects of the technology described herein may use a plurality of context sensors: universal sensor, custom sensor, and enlightenment sensor. The generic sensor provides basic network and process metadata for revealing context about identified threats. Custom sensors will be application specific sensors for first party applications, browsers, messaging, and other applications where credential entries are derived from telemetry.

Applications with enlightenment sensors can utilize APIs to provide context directly to an operating system. These applications may be specifically programmed to interact with the techniques described herein. In some aspects, code within the operating system shell may use a public API.

Among other possible categorizations, threat assessment may categorize credential inputs as valid/invalid locations, secure/unsafe applications, invalid credentials, password reuse, untrusted, known malicious and unknown.

As used herein, a valid location categorization is assigned when a credential matches an appropriate identity provider and authentication server used by an organization associated with the credential. For example, logic. When entering credentials associated with a MICROSOFT account of a user, the credential input event may be classified as a valid location when the network context shows that the credentials are being communicated to logic. If the network context displays a URL or other feature that is not associated with the credential organization, the location may be classified as invalid. The classification of invalidation may trigger a mitigation action, such as blocking the communication of the credential with the URL or suspension of the credential.

As used herein, a secure/unsecure application is a categorization that has been previously assigned to an application that receives a password/credential entry. The categorization indicates whether the application is secure or not secure for receiving the plain text password. The relevant application may be an active application for which the credential is directed. Some applications may be classified as unsafe for all passwords because it is known for phishing attacks or otherwise classified as unreliable or unsafe. For example, entering a password in an application is an unsafe practice even if the application is secure, such as may occur if a user types the password in an email or document.

As used herein, when a location that is not known to be bad has an invalid certificate, invalid certificate categorization may occur, which may indicate that a potential man-in-the-middle attack exists. The certificate may be part of the network context.

As used herein, password reuse occurs when a password registered with a first organization is entered to log into a trusted site of a different organization. For example, logging in facebook.com using MICROSOFT credentials may be password reuse. In this case, the user may have selected the same password for two different accounts, which is an unsafe practice. Some organizations have policies that prohibit employees from using the organization password for other accounts. Detection of password reuse may result in notifications being communicated to users and/or organizations. Pausing the password is another possible mitigation in response to detecting password reuse. As used herein, password reuse is different from password history enforcement, which may prevent a user from using the same password twice on a single system at different times. For example, a system requiring a new password per month may prevent a user from reusing a password previously used on the system. Password reuse, as used herein, detects the use of a single password on two different systems (e.g., a work account and a social media account).

As used herein, when a password is entered on an untrusted site (as indicated by the source tracking known phishing sites and/or sites constituting security risks), an untrusted categorization may be assigned.

As used herein, a known malicious categorization may be assigned when a password is entered on a known malicious site (as indicated by the source tracking the known phishing site and/or the site constituting the security risk).

As used herein, an unknown classification may be assigned when a password entry does not conform to any available classification. Unknown classifications may also be used when two or more classifications are applied. For example, if there are two network connections, one of the network connections is evaluated as untrusted and the other network connection results in password reuse. Unknown classifications may also be assigned when the site appears to be a new phishing site, but has not been tracked by any known phishing site list (or conversely, safe/reliable sites).

When a threat is detected, various mitigation actions may be taken. The user and/or system administrator may specify mitigation actions to be taken when the threat is detected. Different mitigation actions may be specified for different threat classifications. One type of mitigation is threat reporting. Useful sensor data and telemetry data may be sent to a cloud protection service associated with an operating system provider, as well as a system manager associated with an organization (e.g., employer) that manages the computing device. The same information may also be accessed by the user of the monitored device. The determination of phishing may also be shared with a centralized threat protection service (taking into account all compliance and privacy criteria) that would benefit from utilizing phishing data to better protect customers from phishing.

The mitigation action may also include a user-perceived effort. From the user's perspective, phishing protection may have a generic (non-application specific) user interface, allowing for discouraging phishing attempts, changing passwords, alerting of detected risks, phishing education, and social engineering training. The last two options may be attractive to businesses that wish to distribute targeted additional security training to end users. An application specific user interface may also be used. The communication of threat detection information may be enabled via a public API.

Having briefly described an overview of aspects of the technology described herein, an exemplary operating environment in which aspects of the technology described herein may be implemented is described below in order to provide a general context for the aspects.

Turning now to FIG. 1, a block diagram is provided that illustrates an example operating environment 100 in which aspects of the present disclosure may be employed. It should be understood that this and other arrangements described herein are described by way of example only. Other arrangements and elements (e.g., machines, interfaces, functions, orders, and groupings of functions, etc.) can be used in addition to or instead of those shown, and some elements may be omitted entirely for clarity. Furthermore, many of the elements described herein are functional entities, may be implemented as discrete components or distributed components or in combination with other components, and in any suitable combination and location. The various functions described herein as being performed by one or more entities may be carried out by hardware, firmware, and/or software. For example, some functions may be performed by a processor executing instructions stored in a memory.

Among other components not shown, the example operating environment 100 includes a plurality of user devices, such as user devices 102a and 102 b-102 n; a plurality of data sources, such as data sources 104a and 104b through 104n; a server 106; and a network 110. Each of the components shown in fig. 1 may be implemented via any type of computing device, such as computing device 1700 described in connection with fig. 17. These components may communicate with each other via a network 110, which network 110 may include, but is not limited to, one or more Local Area Networks (LANs) and/or Wide Area Networks (WANs). In an exemplary implementation, network 110 includes the Internet and/or a cellular network, as well as any of a variety of possible public and/or private networks.

The user devices 102a and 102 b-102 n may be client devices on the client side of the operating environment 100, while the server 106 may be on the server side of the operating environment 100. In some aspects, the techniques described herein may take the form of security functions running on a single user device. The security function may be part of the user equipment operating system. The user device may be protected by threat detection techniques described herein. In particular, threat detection may intercept user input, detect credential input, and conduct threat assessment at the operating system level. The threat may be a server-side phishing attempt originating from the operating environment 100.

The server 106 may include server-side software designed to work with client-side software on the user devices 102a and 102 b-102 n to implement any combination of features and functions discussed in this disclosure. For example, the server 106 may operate a threat detection system that receives information regarding analyzed or detected threats. A system administrator for an organization may use server 106 to set monitoring and mitigation parameters for threat detection systems running on user devices associated with the organization. The partitioning of the operating environment 100 is provided to illustrate one example of a suitable environment, and does not require that any combination of the server 106 and the user devices 102a and 102 b-102 n remain as separate entities for each implementation.

The user devices 102a and 102 b-102 n may comprise any type of computing device capable of being used by a user. For example, in an aspect, the user devices 102 a-102 n may be of the type of computing device described in connection with fig. 10 herein. By way of example and not limitation, a user device may be embodied as a Personal Computer (PC), laptop computer, mobile device, smart phone, tablet computer, smart watch, wearable computer, fitness tracker, virtual reality headset, augmented reality glasses, personal Digital Assistant (PDA), MP3 display, global Positioning System (GPS) or device, video display, handheld communication device, gaming device or system, entertainment system, vehicle computer system, embedded system controller, remote control, appliance, consumer electronics device, workstation, or any combination of these depicted devices, or any other suitable device.

The data sources 104a and 104b through 104n may include data sources and/or data systems configured to make data available to any of the various components of the operating environment 100. For example, the data sources may include email servers, social media servers, or other sources that may be used to install objects for phishing attacks identified by the techniques described herein. The data sources 104a and 104 b-104 n may be discrete from the user devices 102a and 102 b-102 n and the server 106, or may be incorporated and/or integrated into at least one of these components.

The operating environment 100 may be used to implement one or more components of the computing environment 200 depicted in fig. 2, including components for password entry detection, context acquisition, threat assessment, mitigation, and user awareness.

Turning now to FIG. 2, a computing environment 200 suitable for use with aspects of the technology described herein is provided. Figures 2-4 are used herein to illustrate how a keystroke is entered and analyzed by the techniques described herein. Before describing the actions to be taken to analyze a keystroke, a brief description of the components is displayed. Some of the components depicted in FIG. 2 are terms that are often used to describe components of the WINDOWS operating system provided by MICROSOFT. However, aspects of the technology described herein are not limited to use with WINDOWS. Features of the technology described herein may be added to other operating systems that contain many of the same components and perform similar functions.

Computing environment 200 includes hardware layer 250, operating system components 220, kernel components 240, and example applications. Together with components not shown, operating system component 220 can be described as an operating system. Some operating systems may combine user mode and kernel mode, or mobile operation. In WINDOWS, the processor switches between two modes depending on the type of code running on the processor. The application runs in user mode and the core operating system components run in kernel mode. While many drivers operate in kernel mode, some drivers may operate in user mode.

When a user mode application begins, the operating system creates a process for the application. The process provides a private virtual address space and a private handle table for the application. Because the virtual address space of an application is private, one application cannot change data belonging to another application. In addition to being private, the virtual address space of user mode applications is limited. A processor operating in user mode cannot access a virtual address reserved for the operating system. Limiting the virtual address space of user mode applications may prevent applications from viewing, changing, and potentially damaging, critical operating system data.

All kernel components 240 share the same system address space (only accessible from kernel mode). This means that the kernel mode driver is not isolated from other drivers and the operating system itself.

As used herein, operating system component 220 may include kernel component 240. Many components of the operating system, such as the hardware abstraction layer between the hardware and kernel components 240, are not shown in FIG. 2, including exemplary components as well as components for threat detection. The kernel (of which kernel component 240 is a part) is a computer program located at the operating system core of a computer and has control over the system. The kernel facilitates interactions between hardware and software components. The kernel controls hardware resources (e.g., I/O, memory) via device drivers, arbitrates conflicts between processes related to these resources, and optimizes use of common resources (e.g., CPU, memory, and storage 252). On some systems, the kernel is one of the first programs that is loaded at the start (after the boot loader). After loading, the kernel may handle the rest of the initialization and memory, peripheral devices, and input/output (I/O) requests from the software, converting them into data processing instructions for the CPU.

The code of the kernel may be loaded into a separate area of memory that is protected from access by application software or other less critical parts of the operating system. The kernel performs its tasks in this protected kernel space, such as running processes, managing hardware devices such as hard disks, and handling interrupts. In contrast, applications like spreadsheet 210, browser 212, word processor 214, or video conferencing platform 216 may use separate areas of memory, sometimes described as user modes. This separation helps to prevent user data and kernel data from interfering with each other and causing instability and slowness, as well as prevent malfunctioning applications from affecting other applications or crashing the entire operating system.

Kernel component 240 includes thread manager and scheduler 242, threat defenses 244, input manager 246 and network connection manager 248. The operating system kernel may include additional components. Thread manager 240 handles execution of threads during processing. An instance of a program runs in a process. Each process has an ID, a number that identifies it. Threads are schedulable entities within a process, execution flow within a process.

Threat defenses 244 provide access control and reporting functions. One function in the technical context described herein is to provide a reporting pipeline to an enterprise regarding the security status of enterprise devices, such as employees' notebook computers. Thus, the judgment of each credential entry may be communicated to the enterprise through threat defenses 244 to alert the IT manager to a potential phishing attack or unsafe credential entry. This report may be part of various mitigation actions, such as disabling passwords. The operating system must ensure that the operation does not violate system policies. For example, a device may or may not be accessible to all requests. For example, the drive may allow certain requests to succeed or fail, depending on the rights of the requesting entity. Threat defenses 244 may use an Access Control List (ACL) to determine what objects have what security. Threat defenses 244 may perform access checks before an object (file, event, mutex lock, procedure, thread, etc.) opens a handle and what operations (read, write, delete, etc.) may be performed on the object.

The input manager 246 facilitates hardware input. Computers are composed of a variety of devices that provide input and output (I/O) to the outside world. Typical devices are keyboards, mice, audio controllers, video controllers, disk drives, network ports, etc. The device driver provides a software connection between the device and the operating system. The input manager 246 manages communications between applications and interfaces provided by device drivers.

Network connection manager 248 manages communications among NIC 258, operating system components, and applications. The network connection manager 248 may provide network context information. The network manager may interact with one or more drivers to implement networking in an operating system.

Operating system components 220 may be located outside of the kernel and include a credential manager 232, a Local Secure Authorization Subsystem Service (LSASS) 234, an input manager 236, and SMARTSCREEN applications 239. Operating system components are omitted from fig. 2 for simplicity.

The credential manager 232 manages credentials. The credential manager 232 may use a credential management API and credential management User Interface (UI) functions to obtain and manage credential information such as usernames and passwords. These functions request that account information (e.g., MICROSOFT account, GOOGLE account) be used in place of credentials, such as pins, established at login. Such a request typically occurs when the login credentials do not have the rights required by the application. The credential management UI functionality may provide an interface that has the appearance of an operating system user interface. These functions include customizable options to add user information to the user credential store. The credential management 232 may receive credentials to be monitored for threat detection. In an aspect, the credential management interface allows for providing monitoring and mitigation of preferences to be provided.

(LSASS) 234 is responsible for enforcing security policies on the system. (LSASS) 234 verifies the user logged into the computer or server, handles the password change and creates an access token. The LSASS may provide the stored credentials or secrets to other components described herein. For example, LSASS may provide credentials for entry detection. Once an entry is detected, a determination may be made as to whether the environment or context for the credential entry is secure.

SMARTSCREEN 239 a 239 can determine if a site is potentially malicious by analyzing the browsed web page for indications of suspicious behavior and examining the browsed site against a dynamic list of reported and machine-identified phishing sites and malware sites. SMARTSCREEN 239 may communicate with cloud components that attempt to identify phishing sites and malware sites. If a match is found, SMARTSCREEN 239 displays a warning to let the user know that the site may be malicious.

SMARTSCREEN 239 can determine whether the downloaded application or application installation is potentially malicious by examining the downloaded file against a list of reported malware sites and known unsafe programs. SMARTSCREEN 239 may communicate with cloud components that attempt to identify whether the downloaded application or application installation is potentially malicious. If a malicious decision is given SMARTSCREEN displays a warning to let the user know that the site or application may be malicious. SMARTSCREEN 239 may check the downloaded files against a list of known files downloaded by many Windows users. If the file is not in the list SMARTSCREEN displays a warning, caution is recommended.

The shell is the portion of the operating system that allows a user to communicate with the operating system, including the kernel. Operating system components 220 also include components that may be considered part of the OS shell, such as user interface components 222, clipboard 224, notification components 226, and authorization dialog 228. The user interface component 222 provides a primary user interface for the operating system, such as a desktop in WINDOWS. Interface features in clipboard 224 may capture objects (files, text, images) and perform operations (copy, cut, move) on the captured objects in an operating system user interface and/or an application interface. For example, clipboard 224 may allow a user to copy text from a first application interface to a different interface or to a different location in the first application interface. The notification component 226 manages notifications provided by the operating system. The notification may originate from an application or service, such as an email application or a social media service. The notification may allow the user to provide information and may be a potential source of phishing, such as through an infected application. The authorization dialog 228 allows the user to provide and/or confirm information for authenticating the user to various entities and components.

Among other components, the hardware layers include a CPU, memory and storage 252, pointers 254, a keyboard 256, and a Network Interface Controller (NIC) 258, which may be similar to those described in fig. 17. Pointer 254 may be a mouse, a trackball, a touch screen, a touchpad, a natural user input (e.g., gesture) interface, or some other input device that controls the position of the interface pointer. The keypad 256 may be a physical keypad or a touch screen keypad.

NIC 258 (also known as a network card, network adapter, local area network adapter, or physical network interface, and similar terms) is a computer hardware component that connects a computer to a computer network. NIC allows computers to communicate over a computer network, whether using cable or wireless. The NIC may be a physical layer and data link layer device in that it provides physical access to the network medium and, for IEEE802 and similar networks, a low-level addressing system by using a MAC address uniquely assigned to the network interface.

Example applications include a spreadsheet application 210, a web browser 212, a word processor application 214, and a video conferencing platform 216. These applications may be the source of phishing attacks detected by the techniques described herein.

Fig. 2 shows how input signals from keyboard 256 are communicated to applications through the operating system. In the example shown, a keystroke is entered on the keyboard 256, which causes a signal to be sent to the input assembly 246. The input component 246 receives a signal (e.g., a scan code) from a keyboard driver (not shown) and can convert it to a new signal identifying the character indicated by the keystroke, e.g., as Unicode text. The character is then passed to the active application (the application to which the input is addressed), in this case the word processor 214. Word processor 214 then takes an action based on the keystroke (e.g., enter the keystroke in the active document). The flow shown in fig. 2 may occur through typical communications that occur separately from the techniques described herein.

FIG. 3 shows aspects of the technology described herein that use input component 246 to copy keystrokes to LSASS234. As previously described, the keystrokes are also sent to word processor 214.LSASS234 may maintain a keystroke buffer that stores the last x keystrokes received.

An exemplary keystroke buffering is shown with reference to fig. 5. It can be seen that the keystroke buffer stores the last 11 characters received. Aspects of the technology may work with different sizes of buffers. In aspects, the buffer holds the same or more keystrokes as the longest credential being monitored. With each new keystroke, the buffered content is updated to contain the most recent keystroke and the oldest keystroke is removed. At a first point in time, the first content 510 begins with a period and ends with the letter "o". At a second point in time, the second content 512 begins with "o" and ends with a space. The content reflects the user entering key "r" and space, resulting in periods and "c" being removed. At a third point in time, the third content 514 reflects an entry for the backspace key to delete the space and insert "d". This shows a special case of keystroke buffer management involving a backspace key. When the backspace key is pressed, the last letter entered is deleted, but the backspace key itself is not entered as a keystroke into the keystroke buffer. Other controls, such as shift, cap lock, etc., may be omitted from the buffer.

In fig. 4, a keystroke hash is generated from the keystroke buffer and compared to hashes of one or more credentials. Alternatively or additionally, the hash of the partial key may be compared to the hash for the keystroke buffer. In both cases, the hash is generated from the same number of characters. For example, if the password covers eight characters, then the hash of the eight characters from the keystroke buffer should be compared to the hash of the password. The two hashes may be generated using the same function. The partial hash of the six characters from the password should be compared to the hashes of the six strokes from the buffer. These options are again shown with reference to fig. 5, where a first hash 520 of the last six keystrokes is generated. A second hash 522 of the last seven strokes is also generated along with a third hash 524 of the last eight strokes. These three hashes may be compared with hashes of different credentials and/or partial credentials. When the hash from the keystroke buffer matches the hash of the credential, then the credential entry event is identified and threat assessment is penalized. Various threat assessments are then illustrated with reference to fig. 10-16.

Threat assessment functionality may cooperate with LSASS234 and SMARTSCREEN 239. Initially, the keystroke is communicated to a secret filter, which may be part of LSASS 234. The secret filter compares the keystroke hash to the credential hash and determines whether the credential has been typed. When the credential is identified, the threat assessment engine performs threat assessment.

The threat assessment engine uses the application context and the network context, as well as other data, to identify threats or lack thereof. The network sensor may receive network state information from the kernel network sensor and possibly other operating system components. The network state information may include URLs, IP addresses, process IDs, SNIs, domain information (e.g., domain names), and other characteristics of ongoing communication sessions between external resources.

The application context sensor retrieves state information for the application that is entering the credential. The application context sensor may perform process mapping to determine what processes are relevant to the threat. For example, the application context sensor may map the detected input (e.g., a keystroke) to a network connection. The input entries may occur in one process and flow through the network via the same process or a completely different process (e.g., a network proxy process). The application context sensor provides insight into this flow to identify a set of related network connections. Once the relevant network connections are identified, the connections can be used to build a network context. The insights identified by the application context sensor include, but are not limited to, process trees, application process models, inter-process communications, API surfaces, process start command line parameters, process call sources (i.e., initiated by other applications such as file managers, outlook, etc.), associated I/O handles, and function call stacks.

In another mapping example, an application context sensor may map inputs to a known security pattern to discover potential unsafe conditions. Legal credential entries for a given application typically occur according to well-known patterns, where deviations from the pattern may indicate unsafe behavior. For example, credential entries in word processing applications should occur in a credential dialog process or a landing page hosted in the WebView process. All other credential entries may be unsafe. For example, the process of a credential entry into the body of a hosted document implies a password cache. Similar security/non-security modes exist for messaging applications (i.e., through the security credential entry of a dialog box hosted within the WebView process and the security credential entry of a dialog box hosted within the chat window process). The function call stack may also be used to determine a secure/unsecure context. The observed function call stack associated with how an application typically requests credentials (i.e., the function foo calls the function foobar) may be categorized as safe. Any other call stack may be unsafe.

The application context data store stores information about threatening and non-threatening application contexts. For example, the application context data store may store an application context for a desired password entry. If a password is being entered and the application context does not match the context of the desired password entry, threat detection may result, depending on other factors considered. The data collection manager gathers application and network context data and may pre-process it into a format suitable for the analysis engine. The session manager oversees threat detection and passes the detected application context, network context, and credentials to the analytics engine. The analysis engine determines whether a threat exists. In one aspect, the threat is detected by analyzing a series of rules defining the threat. These rules may result in an assignment categorization of the detected credential entries. Among other possible categorizations, threat assessment may categorize credential inputs as valid/invalid locations, secure/unsafe applications, invalid credentials, password reuse, untrusted, known malicious and unknown.

As used herein, an allocation valid location is categorized when a credential matches an appropriate identity provider and authentication server used by an organization associated with the credential. For example, logic. When entering credentials associated with a MICROSOFT account of a user, a credential entry event may be classified as a valid location when the network context shows that the credentials are being communicated to logic. If the network context displays a URL or other feature that is not associated with the credential organization, the location may be classified as invalid. The classification of invalidation may trigger a mitigation action, such as blocking the communication of the credential with the URL or suspension of the credential.

As used herein, a secure/unsecure application is an application that detects that a password/credential entry is secure or unsecure for entering a plain text password. The application involved may be an active application addressed by the credential. The operating system can determine which application is receiving input. Some applications may be classified as unsafe for all passwords because it is known to be used for phishing attacks or otherwise classified as unsafe.

As used herein, invalid certificate categorization occurs when a location that is not known to be bad has an invalid certificate, which may indicate that a potential man-in-the-middle attack exists. For example, the location may be a trusted website. The certificate may be part of the network context.

As used herein, when a password is entered on an untrusted site (as indicated by the source tracking known phishing sites and/or sites constituting security risks), an untrusted categorization may be assigned. SMARTSCREEN is one example of a component that an operating system may use to store information about trusted and untrusted sites.

As used herein, an unknown classification may be assigned when a password entry does not conform to any available classification. Unknown classifications may also be used when two or more classifications are applied. For example, if there are two network connections, one of the network connections is evaluated as untrusted and the other network connection results in password reuse.

When a threat is detected, the presence of the threat may be communicated to one or more components or entities. These components or entities may include mitigation components, UI components, users, cloud-based enterprise security, system administrators, and the like.

Fig. 6, 7, and 8 illustrate phishing attacks that may be detected by the techniques described herein. In fig. 6, the user clicks on an immediate registration link in an email 600 from a legitimate business. Initially, the phishing page 700 is opened in fig. 7, requiring MICROSOFT credentials. In the second load shown in FIG. 8, legal page 800 is open. This situation may be caused by a trusted company being hacked. Hackers may employ the a/B test feature by analysis of web pages by different versions of the test web page to expose phishing pages. The techniques described herein may identify such attacks because the MICROSOFT account password should not be associated with a trusted web page. The web context of the browser will display a trusted URL, but the URL will not match the web context associated with the monitored credential. It should be noted that the browser state may also not match the expected state of the monitored credential entry. A typical security application may miss the attack because the site credentials may appear to be ordered. Furthermore, the secure application may not know which password to use with which service or application. Many security services cannot even recognize that a password (or other credential) has been entered.

Turning now to fig. 9, the detection of phishing websites is shown. Initially, a series of keystrokes is communicated to LSASS234, where the password entry is identified along with other components, such as SMARTSCREEN components. As can be seen, the active application is a web browser 212. When a cryptographic entry is detected, threat assessment is performed. There are two processes in the web browser running. The first process may be a legal process that is not a security threat. The second process is injected with a fishing code in the input, possibly communicated to both processes.

The network context may be determined for both processes, but shows network communications from the phishing code. These communications directed to phishing server 400 define at least part of the network context. The threat assessment engine may determine that the network address has been associated with a known phishing entity. Because part of the network context relates to the address of a known network fishing entity, the cryptographic entry may be identified as a threat. It should be noted that the processing phishing code may have spoofed a security function running in the web browser. The web browser may not be able to determine the entire network context for the computing device. With the techniques described herein, because the operating system level network sensors are able to determine the overall network context for the device and identify some network traffic directed to the phishing component 400. Even if phishing server 400 is not in the list of known phishing servers, a threat may still be detected if the network context does not match the expected context of the entry of the detected credential. The full context for the entry of the detected credential may also include the application context of the web browser, including the page being presented or the running application.

Turning now to fig. 10, detection of a man-in-the-middle attack is shown. Man-in-the-middle attacks require the victim, i.e., the entity with which the victim is attempting to communicate, and the "man-in-the-middle" that intercepts the victim's communication. The victim is unaware of the presence of the man-in-the-middle. With man-in-the-browser attacks (MITB), an attacker needs a way to inject malware or malware into a victim's computer or mobile device. By clicking on a link in a phishing message or opening an attachment, users may inadvertently load malware onto their devices. Malware may then be installed on the browser without the knowledge of the user. Malware records data sent between a victim and a particular target website, such as a financial institution, and communicates it to an attacker. The malware in this case is phishing code that is loaded into the browser.

Initially, a series of keystrokes is communicated to LSASS234, where the password entry is identified along with other components, SMARTSCREEN components. As can be seen, the active application is a web browser 212. The arrangement and communication in fig. 10 is similar to that in fig. 9, except that the attack in fig. 9 is based on a phishing website. In fig. 10, the website is secure, but the malware code in the browser replicates the keystroke and sends it to the destination, phishing server 400, which is not appropriate for the application context, and possibly in the identified phishing list.

Turning now to FIG. 11, the detection of a phishing attack in a document is shown. Initially, a series of keystrokes are communicated to LSASS234, where the password entry is identified along with other components (e.g., SMARTSCREEN components). As can be seen, the active application is a word processor 214. In this case, the network context may not be involved. Merely detecting that the user entered a password in the document, even plain text may be sufficient to identify the threat. In other words, where the entry for the password is appropriate, there may be no context for the application. In other cases, such as when an application is provided as a service, an entry for a password may be appropriate in some contexts. In these cases, the stored application state consistent with the password entry may be compared to the actual state at the time the password was entered to determine if a threat exists. In some cases, this may be simply a bad security practice for the user, rather than a phishing attack. But phishing attacks can occur through documents and other files that have macros that generate the phishing interface. The interface may require credentials to be provided to open a document or perform other actions. The macro may collect the credentials and communicate via email or other methods.

Turning now to fig. 12, the detection of a phishing attack in a video platform is shown. Initially, a series of keystrokes are communicated to LSASS234, where the password entry is identified along with other components (e.g., SMARTSCREEN components). As can be seen, the active application is a videoconferencing platform 216. In this case, the network context may not be involved. Simply detecting that the user entered a password in a chat may be sufficient to identify a threat. In other words, where the entry for the password is appropriate, there may be no context for the application. In other cases, such as when an application is provided as a service, an entry for a password may be appropriate in some contexts. In these cases, the stored application state consistent with the password entry may be compared to the actual state at the time the password was entered to determine if a threat exists. In some cases, this may be simply a bad security practice for the user, rather than a phishing attack. However, phishing attacks can occur through video chat, such as when an entity impersonates to provide technical support. The macro on the platform may also generate an interface that requests the password. The interface may require credentials to join the meeting, record, or take other actions. The macro may collect the credentials and communicate via email or other methods.

Turning now to FIG. 13, the detection of a phishing attack in an operating system notification is shown. Initially, a series of keystrokes is communicated to LSASS234, where the password entry is identified along with other components, such as SMARTSCREEN components. As can be seen, the active function is an operating system notification function 226. Some legitimate notifications may require the user to enter credentials, e.g., after expiration of a token generated by a previous password entry. A network context may be determined. It should be noted that the communication directed to phishing server 400 defines at least part of the network context. The threat assessment engine may determine that the network address has been associated with a known phishing entity. Because part of the network context relates to the address of a known network fishing entity, the cryptographic entry may be identified as a threat. With the techniques described herein, because the operating system level network sensors are able to determine the overall network context for the device and identify some network traffic directed to the phishing component 400. This allows phishing attempts to be correctly identified and mitigated. Even if phishing server 400 is not in the list of known phishing servers, a threat may still be detected if the network context does not match the expected context of the entry of the detected credential. The full context for the entry of the detected credential may also include the application context of the web browser, including the page being presented or the running application.

Turning now to fig. 14, the detection of password reuse is shown. Initially, a series of keystrokes is communicated to LSASS234, where the password entry is identified along with other components, such as SMARTSCREEN components. As can be seen, the active application is a web browser 212. When a cryptographic entry is detected, threat assessment is performed. The web browser has two processes running, but in this case both are legal.

The network context may be determined for two processes. The threat assessment engine may identify a network address from a trusted source, but not a trusted source associated with the password. This may indicate password reuse, i.e., one person may occur when using the same password in multiple accounts. In this case, the mitigating step may involve notifying the user and the system administrator.

Turning now to fig. 15, the detection of non-threatening password use is shown. Initially, a series of keystrokes is communicated to LSASS234, where the password entry is identified along with other components, such as SMARTSCREEN components. As can be seen, the active application is a web browser 212. When a cryptographic entry is detected, threat assessment is performed. The web browser has two processes running, but in this case both are connected to a legal authentication site.

The network context may be determined for two processes. The threat assessment engine may identify a network address from a trusted source, i.e., a source that is expected to be used with the password. In this case, no mitigation needs to be taken, but the application and network context may be collected to help refine the correct network and application context for the use of passwords.

Example method

Referring now to fig. 16, 18, and 19, each block of the methods 1600, 1800, and 1900 described herein includes a computing process that may be performed using any combination of hardware, firmware, and/or software. For example, various functions may be performed by a processor executing instructions stored in a memory. The methods may also be embodied as computer-usable instructions stored on a computer storage medium. The method may be provided by an operating system. Further, methods 1600, 1800, and 1900 describe fig. 1-15 by way of example. However, the methods may additionally or alternatively be performed by any one system or any combination of systems, including but not limited to those described herein.

Fig. 16 is a flow chart illustrating a method 1600 for detecting an analysis credential input, according to some embodiments of the present disclosure. Method 1600 may be performed on or with a system similar to that described with reference to fig. 1-15. In particular, method 1600 may be performed by one or more operating system components.

Method 1600 includes, at block 1610, receiving input for a computing device. The input may be text input including characters, numbers, and symbols. In one aspect, text input is received from a hard keyboard or a soft keyboard. The techniques described herein identify and mitigate phishing attempts by analyzing received user input at the operating system level. When input is received at the operating system level, detection of threats that may not be detected by application-level input analysis is allowed. Text input may be entered through a real or virtual keyboard or through other means (e.g., gesture interface, voice-to-text). Text input may be received from a hardware driver of an input device for initiating characters of the text input. Text input is addressed to an application running on a computing system. Text input may be communicated from the operating system to the application. Text input is directed to an application rather than being communicated directly to the operating system. The operating system communicates the text input to the application.

The method 1600 includes determining, at block 1620, that the text input corresponds to a credential. As previously described, this step may be performed by an operating system component. Initially, credentials (such as a user name or password) are registered in a threat detection system. The various aspects of the technology described herein are not limited to use with a username or password. The credential may be any type of secret or confidential information, such as a social security number, credit card information, driver's license number, passport ID, which may be monitored by the system described herein. In one aspect, a user name and password for an operating system are automatically registered. A user interface may be provided for a user or other individual (e.g., a system administrator) to register additional credentials for monitoring.

Method 1600 includes determining a current network context for the application from an operating system network sensor at block 1630. As previously described, this step may be performed by an operating system component. The network sensor may receive network state information from the kernel network sensor and possibly other operating system components. The network state information may include URLs, IP addresses, process IDs, SNIs, domain information (e.g., domain names), and other characteristics of ongoing communication sessions between external resources.

Method 1600 includes, at block 1640, detecting a mismatch between a current network context and an expected network context for an application. As previously described, this step may be performed by an operating system component, and one or more attributes of the current network context and the expected network context may be compared to detect a mismatch.

Method 1600 includes, at block 1650, identifying, at an operating system, a threat in response to a mismatch between a current network context and an expected network context for the application. In this case, a mismatch may mean that the credential entry is not completed in the normal context. The abnormal context indicates a threat to security or confidentiality of the credential. As previously described, this step may be performed by an operating system component. In one aspect, the threat is detected by analyzing a series of rules defining the threat. These rules may result in an assignment categorization of the detected credential entries. Among other possible categorizations, threat assessment may categorize credential inputs as valid/invalid locations, secure/unsafe applications, invalid credentials, password reuse, untrusted, known malicious and unknown.

Method 1600 includes initiating a security mitigation in response to the identification, at block 1660. As previously described, this step may be performed by an operating system component. When a threat is detected, various mitigation actions may be taken. Threat categorization may trigger mitigation actions such as blocking the communication of credentials with URLs or suspension of credentials. The user and/or system administrator may specify mitigation actions to be taken when the threat is detected. Different mitigation actions may be specified for different threat classifications. One type of mitigation is threat reporting. Useful sensor data and telemetry data may be sent to a cloud protection service associated with an operating system provider, as well as a system manager associated with an organization (e.g., employer) that manages the computing device. The same information may also be accessed by the user of the monitored device. The determination of phishing may also be shared with a centralized threat protection service (taking into account all compliance and privacy criteria) that would benefit from utilizing phishing data to better protect customers from phishing.

Monitoring of password reuse may result in notifications being communicated to users and/or organizations. Pause passwords are another possible mitigation in response to detecting password reuse or other threats.

Fig. 18 is a flow chart illustrating a method 1800 for detecting an analysis credential entry according to some embodiments of the present disclosure. The method 1800 may be performed on or with a system similar to that described with reference to fig. 1-15. In particular, method 1800 may be performed by one or more operating system components.

The method 1800 includes, at block 1810, receiving an input at a computing device. The input may be a text input including characters, numbers, and symbols. In one aspect, text input is received from a hard keyboard or a soft keyboard. The input is addressed to the application. As previously described, this step may be performed by an operating system component. The techniques described herein identify and mitigate phishing attempts by analyzing received user input at the operating system level. When input is received at the operating system level, detection of threats that may not be detected by application-level input analysis is allowed. Text input may be entered through a real or virtual keyboard or through other means (e.g., gesture interface, voice-to-text). Text input may be received from a hardware driver of an input device for initiating characters of the text input. Text input is addressed to an application running on a computing system. Text input may be communicated from the operating system to the application. Text input is directed to an application rather than being communicated directly to the operating system. The operating system communicates the text input to the application.

The method 1800 includes, at block 1820, determining that the text input corresponds to a credential. As previously described, this step may be performed by an operating system component. Initially, credentials (such as a user name or password) are registered in a threat detection system. The various aspects of the technology described herein are not limited to use with a username or password. The credential may be any type of secret or confidential information, such as a social security number, credit card information, driver's license number, passport ID, which may be monitored by the system described herein. In one aspect, a user name and password for an operating system are automatically registered. A user interface may be provided for a user or other individual (e.g., a system administrator) to register additional credentials for monitoring.

The registered credentials are associated with a user in a credential data store. In some aspects, a hash of the credential is generated using a first function and stored for comparison with a hash generated from the user input. The techniques described herein intercept user input at the operating system level, generate a hash of the input, and compare it to the hash of the monitored credential. In an aspect, a hash of the last n characters received is generated, where n is the character length of the credential. For example, a hash of the last 8 characters entered may be generated and compared to a hash of an 8 character password. In another aspect, a hash of less than the complete credential is generated and used for detection of potential entries of the credential before the entry is completed. For example, hashes of 4 characters, 5 characters, 6 characters, and 7 characters may be generated to predict an entry for an 8-character password. In this case, the input string is hashed at a character length that matches the hash value of the partial credential stored in the credential manager.

Method 1800 includes, at block 1830, determining a current application context for the application, which may be performed by an operating system component, as previously described. Features of the application context include, but are not limited to, process trees, application process models, inter-process communications, API surfaces, process start command line parameters, process call sources (i.e., launched by other applications such as file managers, outlook, etc.), associated I/O handles, and function call stacks.

The method 1800 includes, at block 1840, detecting a mismatch between a current application context and an expected application context for an application. As previously described, this step may be performed by an operating system component. The mismatch may be detected by comparing one or more attributes of the intended application context with the current application context.

The method 1800 includes identifying a threat in response to the mismatch at block 1850. In this case, a mismatch may mean that the credential entry is not completed in the normal context. The abnormal context indicates a threat to security or confidentiality of the credential. As previously described, this step may be performed by an operating system component. In another mapping example, an application context sensor may map inputs to a known security pattern to discover potential unsafe conditions. Legal credential entries for a given application typically occur according to well-known patterns, where deviations from the pattern may indicate unsafe behavior. For example, credential entries in word processing applications should occur in a credential dialog process or a landing page hosted in the WebView process. All other credential entries are potentially unsafe. For example, the process of a credential entry into the body of a hosted document implies a password cache. Similar security/non-security modes exist for messaging applications (i.e., through the security credential entry of a dialog box hosted within the WebView process and the security credential entry of a dialog box hosted within the chat window process). The function call stack may also be used to determine a secure/unsecure context. The observed function call stack associated with how an application typically requests credentials (i.e., the function foo calls the function foobar) may be categorized as safe. Any other call stack may be unsafe.

The application context data store may store information about threat and non-threat application contexts. For example, the application context data store may store application contexts for which passwords are desired to be entered. If a password is being entered and the application context does not match the context in which the password is expected to be entered, threat detection may result, depending on other factors considered. The data collection manager gathers application and network context data and may pre-process it into a format suitable for the analysis engine. In one aspect, the threat is detected by analyzing a series of rules defining the threat. These rules may result in assigning classifications to detected credential entries. Among other possible categorizations, threat assessment may categorize credential inputs as valid/invalid locations, secure/unsafe applications, invalid credentials, password reuse, untrusted, known malicious and unknown.

Method 1800 includes initiating security mitigation in response to the identification at block 1860. As previously described, this step may be performed by an operating system component. When a threat is detected, various mitigation actions may be taken. Threat categorization may trigger mitigation actions such as blocking the communication of credentials with URLs or suspension of credentials. The user and/or system administrator may specify mitigation actions to be taken when the threat is detected. Different mitigation actions may be specified for different threat classifications. One type of mitigation is threat reporting. Useful sensor data and telemetry data may be sent to a cloud protection service associated with an operating system provider, as well as a system manager associated with an organization (e.g., employer) that manages the computing device. The same information may also be accessed by the user of the monitored device. The determination of phishing may also be shared with a centralized threat protection service (taking into account all compliance and privacy criteria) that would benefit from utilizing phishing data to better protect customers from phishing.

Fig. 19 is a flow chart illustrating a method 1900 for detecting an analysis credential entry, according to some embodiments of the present disclosure. Method 1900 may be performed on or with a system similar to that described with reference to fig. 1-15. In particular, method 1900 may be performed by one or more operating system components.

At block 1910, method 1900 includes receiving, at a computing device, an input. The input may be a text input including characters, numbers, and symbols. In one aspect, text input is received from a hard keyboard or a soft keyboard. Text input is addressed to the application. As previously described, this step may be performed by an operating system component. The techniques described herein identify and mitigate phishing attempts by analyzing received user input at the operating system level. When input is received at the operating system level, detection of threats that may not be detected by application-level input analysis is allowed. Text input may be entered through a real or virtual keyboard or through other means (e.g., gesture interface, voice-to-text). Text input may be received from a hardware driver of an input device for initiating characters of the text input. Text input is addressed to an application running on a computing system. Text input may be communicated from the operating system to the application. Text input is directed to an application rather than being communicated directly to the operating system. The operating system communicates the text input to the application.

Method 1900 includes determining that the text input corresponds to a credential at block 1920. As previously described, this step may be performed by an operating system component. The various aspects of the technology described herein are not limited to use with a username or password. The credential may be any type of secret or confidential information, such as a social security number, credit card information, driver's license number, passport ID, which may be monitored by the system described herein. In one aspect, a user name and password for an operating system are automatically registered. A user interface may be provided for a user or other individual (e.g., a system administrator) to register additional credentials for monitoring

Method 1900 includes, at block 1930, determining a current application context for the application, which may be performed by an operating system component, as previously described. Features of the application context include, but are not limited to, process trees, application process models, inter-process communications, API surfaces, process start command line parameters, process call sources (i.e., launched by other applications such as file managers, outlook, etc.), associated I/O handles, and function call stacks.

Method 1900 includes determining a current network context for the application from an operating system network sensor at block 1940. As previously described, this step may be performed by an operating system component. The network sensor may receive network state information from the kernel network sensor and possibly other operating system components. The network state information may include URLs, IP addresses, process IDs, SNIs, domain information (e.g., domain names), and other characteristics of ongoing communication sessions between external resources. .

Method 1900 includes detecting a threat in response to a mismatch between the current network context and an expected network context for the application, at block 1950. As previously described, this step may be performed by an operating system component. The mismatch may be detected by comparing one or more attributes of the intended application context with the current application context.

Method 1900 includes, at block 1960, identifying a threat at an operating system in response to the mismatch. In this case, a mismatch may mean that the credential entry is not completed in the normal context. The abnormal context indicates a threat to security or confidentiality of the credential. As previously described, this step may be performed by an operating system component. In one aspect, the threat is detected by analyzing a series of rules defining the threat. These rules may result in an assignment categorization of the detected credential entries. Among other possible categorizations, threat assessment may categorize credential inputs as valid/invalid locations, secure/unsafe applications, invalid credentials, password reuse, untrusted, known malicious and unknown.

Method 1900 includes, at block 1970, responding to security mitigation identified by the operating system. As previously described, this step may be performed by an operating system component. When a threat is detected, various mitigation actions may be taken. Threat categorization may trigger mitigation actions such as blocking the communication of credentials with URLs or suspension of credentials. The user and/or system administrator may specify mitigation actions to be taken when the threat is detected. Different mitigation actions may be specified for different threat classifications. One type of mitigation is threat reporting. Useful sensor data and telemetry data may be sent to a cloud protection service associated with an operating system provider, as well as a system manager associated with an organization (e.g., employer) that manages the computing device. The same information may also be accessed by the user of the monitored device. The determination of phishing may also be shared with a centralized threat protection service (taking into account all compliance and privacy criteria) that would benefit from utilizing phishing data to better protect customers from phishing.

Exemplary operating Environment

Referring to the drawings in general, and initially to FIG. 17 in particular, an exemplary operating environment for implementing aspects of the technology described herein is shown and designated generally as computing device 1700. Computing device 1700 is but one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use of the technology described herein. Neither should the computing device 1700 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated.

The techniques described herein may be described in the general context of computer code or machine-useable instructions, including computer-executable instructions such as program components, being executed by a computer or other machine, such as a personal data assistant or other handheld device. Generally, program components, including routines, programs, objects, components, data structures, etc., refer to code that perform particular tasks or implement particular abstract data types. The techniques described herein may be practiced in a variety of system configurations, including hand-held devices, consumer electronics, general-purpose computers, special-purpose computing devices, etc. Aspects of the technology described herein may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network.

With continued reference to fig. 17, the computing device 1700 includes a bus 1710, the bus 1710 being coupled directly or indirectly to: memory 1712, one or more processors 1714, one or more presentation components 1716, input/output (I/O) ports 1718, I/O components 1720, and an illustrative power supply 1722. Bus 1710 represents what may be one or more busses (such as an address bus, data bus, or combination thereof). Although the various blocks of FIG. 17 are shown with lines for the sake of clarity, in reality, delineating various components is not so clear, and metaphorically, the lines would more accurately be grey and fuzzy. For example, presentation components such as display devices may be considered I/O components. In addition, the processor has a memory. The inventors hereof recognize that such is the nature of the art, and that the diagram of FIG. Shen Tu illustrates merely an exemplary computing device that can be used in connection with one or more aspects of the techniques described herein. There is no distinction between categories such as "workstation," server, "" laptop, "" handheld device, "etc., as all of these categories are within the scope of fig. 17 and refer to" computer "or" computing device.

Computing device 1700 typically includes a variety of computer-readable media. Computer readable media can be any available media that can be accessed by computing device 1700 and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes volatile and nonvolatile, 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.

Computer storage media includes RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital Versatile Disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices. The computer storage medium does not include a propagated data signal.

Communication media typically embodies 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 information delivery media. The term "modulated data signal" means a signal that has one or more of its characteristics set or changed in such 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 any of the above should also be included within the scope of computer readable media.

The memory 1712 includes computer storage media in the form of volatile and/or nonvolatile memory. The memory 1712 may be removable, non-removable or a combination thereof. Exemplary memory includes solid state memory, hard drives, optical drives, and the like. The computing device 1700 includes one or more processors 1714 that read data from various entities such as a bus 1710, memory 1712, or I/O component 1720. The presentation component 1716 presents data indications to a user or other device. Exemplary presentation components 1716 include a display device, speakers, printing components, vibration components, and the like. I/O ports 1718 allow computing device 1700 to be logically coupled to other devices, including I/O component 1720, some of which may be built-in.

Exemplary I/O components include microphones, joysticks, game pads, satellite antennas, scanners, printers, display devices, wireless devices, controllers (e.g., stylus, keyboard and mouse), natural User Interfaces (NUI), and the like. In aspects, a pen digitizer (not shown) and accompanying input instrument (also not shown, but which may include, by way of example only, a pen or stylus) are provided in order to digitally capture hand drawn user input. The connection between the pen digitizer and the processor 1714 can be direct or via coupling using a serial port, parallel port, and/or other interface and/or system bus as known in the art. Further, the digitizer input component may be a separate component from an output component, such as a display device, or in some aspects, the available input area of the digitizer may coexist with, be integrated with, or exist as a separate device overlaying or otherwise appended to the display device. Any and all such variations, and any combination thereof, are considered to be within the scope of the technical aspects described herein.

NUI processes user-generated air gestures, speech, or other physiological inputs. Appropriate NUI input may be interpreted as ink strokes for presentation in association with computing device 1700. These requests may be transmitted to the appropriate network element for further processing. NUI enables any combination of speech recognition, touch and stylus recognition, facial recognition, biometric recognition, on-screen and near-screen gesture recognition, air gestures, head and eye tracking, and touch recognition associated with a display on computing device 1700. Computing device 1700 may be equipped with depth cameras, such as stereoscopic camera systems, infrared camera systems, RGB camera systems, and combinations of these cameras, for gesture detection and recognition. Additionally, computing device 1700 may be equipped with an accelerometer or gyroscope capable of detecting motion. The output of the accelerometer or gyroscope may be provided to a display of the computing device 1700 to present an immersive augmented reality or virtual reality.

The computing device may contain a radio 1724. Radio 1724 transmits and receives radio communications. The computing device may be a wireless terminal adapted to receive communications and media over various wireless networks. Computing device 1700 may communicate with other devices via wireless policies, such as code division multiple access ("CDMA"), global system for mobile communications ("GSM"), or time division multiple access ("TDMA"), among other policies. The radio communication may be a short range connection, a long range connection, or a combination of short range and long range wireless telecommunication connections. When referring to "short" and "long" types of connections, it is not meant to refer to the spatial relationship between two devices. In contrast, short and long distances are often referred to as different categories or types of connections (i.e., primary and secondary connections). The short-range connection may comprise a device providing wireless communication network access (e.g., a mobile hotspot)A connection such as a WLAN connection using the 802.11 protocol. A bluetooth connection with another computing device is a second example of a short-range connection. The remote connection may include a connection using one or more of CDMA, GPRS, GSM, TDMA and 802.16 policies.

Examples

Embodiment 1. One or more computer storage media include computer-executable instructions that, when executed by a computing device, cause an operating system component of the computing device to perform a method of detecting and analyzing credential input. The method includes receiving, at a computing device, an input, the input being addressed to an application. The method also includes determining that the input corresponds to a credential. The method also includes determining a current network context for the application from data provided by the operating system network sensor. The method also includes detecting a mismatch between the current network context and an expected network context for the application. The method further includes identifying a threat in response to the mismatch. The method further includes initiating a security mitigation in response to the identification.

Embodiment 2. The medium of embodiment 1 wherein the characteristics of the network context are selected from the group consisting of: URL, IP address, procedure ID, server Name Indication (SNI), and domain information.

Embodiment 3. The medium of any of the embodiments above wherein the credential is associated with a credential organization and the expected network context is a URL associated with the credential organization.

Embodiment 4. The medium of any of the embodiments above wherein the input is for a first set of characters of the password and the security mitigation is to prevent entry of remaining characters in the password.

Embodiment 5. The medium of any of the embodiments above wherein the input is a first set of characters for a password and the security mitigation is a warning message generated by an operating system.

Embodiment 6. The medium of any of the embodiments above wherein the method further comprises determining a current application context for the application. Wherein the identification of the threat is further responsive to an additional mismatch between the current application context and the intended application context for the application. Wherein the characteristics of the application context are selected from the group consisting of: process trees, application process models, inter-process communications, API surfaces, process start command line parameters, process call sources, associated I/O handles, and function call stacks.

Embodiment 7. The medium of embodiment 1 wherein the method further comprises registering the non-operating system credentials with the operating system.

Embodiment 8. A method of detecting and analyzing an input credential by an operating system component. The method includes receiving, at a computing device, an input, the input addressed to an application. The method also includes determining that the input corresponds to a credential. The method also includes determining a current application context for the application. The method also includes detecting a mismatch between the current application context and an expected application context for the application. The method further includes identifying a threat in response to the mismatch. The method further includes initiating a security mitigation in response to the identification.

Embodiment 9. The medium of any of the embodiments above, wherein the characteristics of the application context are selected from the group consisting of: process trees, application process models, inter-process communications, API surfaces, process start command line parameters, process call sources, associated I/O handles, and function call stacks.

Embodiment 10. The medium of any of the embodiments above wherein the intended application context is a function call stack having a first characteristic and the current application context does not include the first characteristic.

Embodiment 11. The medium of any of the above embodiments, wherein the intended application context is that the input is entered into a first process and the current application context is that the input is entered into a second process different from the first process.

Embodiment 12. The method of embodiment 11 wherein the first process is a credential dialog entry process.

Embodiment 13. The method of any of the embodiments above wherein the credential is a password and the threat is password reuse.

Embodiment 14. The medium of any of the embodiments above, further comprising determining a current network context for the application from data provided by the operating system network sensor, wherein the identification of the threat is further responsive to an additional mismatch between the current network context and an expected network context for the application, wherein a characteristic of the network context is selected from the group consisting of: URL, IP address, procedure ID, server Name Indication (SNI), and domain information.

Embodiment 15. A system comprising: one or more hardware processors; and

One or more computer-readable media having executable instructions for operating system components embodied thereon that, when executed by one or more processors, cause the one or more hardware processors to perform actions comprising receiving input at a system, the input being addressed to an application. The actions also include determining that the input corresponds to a credential. The actions also include determining a current application context for the application. The actions also include determining a current network context for the application from data provided by the operating system network sensor. The actions also include detecting a mismatch between the current network context and an expected network context for the current application context. The actions also include identifying a threat in response to the mismatch. The actions also include initiating a security mitigation in response to the identification.

Embodiment 16. The system of any of the above embodiments, wherein the characteristics of the application context are selected from the group consisting of: process trees, application process models, inter-process communications, API surfaces, process start command line parameters, process call sources, associated I/O handles, and function call stacks.

Embodiment 17. The system of any of the above embodiments, wherein the characteristics of the network context are selected from the group consisting of: URL, IP address, procedure ID, server Name Indication (SNI), and domain information.

Embodiment 18. The system of any of the above embodiments, wherein the intended application context for the credential is to inject the password into the first application and the current application context is to inject the credential into the second application.

Embodiment 19. The system of any of the above embodiments, wherein the credential is a password and the threat is an unsecure application to the password, wherein the unsecure application is not authorized to receive the password.

Embodiment 20. The system of any of the embodiments above, wherein the method further comprises registering the non-operating system credentials with the operating system.

The technology described herein has been described with respect to particular aspects, which are intended in all respects to be illustrative rather than restrictive. While the technology described herein is susceptible to various modifications and alternative constructions, certain illustrated aspects thereof are shown in the drawings and have been described above in detail. It should be understood, however, that there is no intention to limit the described technology to the specific forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of the technology described herein.

Claims

1. One or more computer storage media comprising computer-executable instructions that, when executed by a computing device, cause an operating system component of the computing device to perform a method of detecting and analyzing credential input, the method comprising:

receiving input at the computing device, the input addressed to an application;

Determining that the input corresponds to a credential;

determining a current network context for the application from data provided by an operating system network sensor;

Detecting a mismatch between the current network context and an expected network context for the application;

identifying a threat in response to the mismatch; and

Responsive to the identification, security mitigation is initiated.

2. The medium of claim 1, wherein a characteristic of the network context is selected from the group consisting of: URL, IP address, procedure ID, server Name Indication (SNI), and domain information.

3. The medium of claim 1, wherein the credential is associated with a credential organization, and the intended network context is a URL associated with the credential organization.

4. The medium of claim 1, wherein the input is for a first set of characters of a password and the security mitigation is to prevent entry of remaining characters in the password.

5. The medium of claim 1, wherein the input is a first set of characters for a password and the security mitigation is a warning message generated by the operating system.

6. The medium of claim 1, wherein the method further comprises:

Determining a current application context for the application;

Wherein the identification of the threat is further responsive to an additional mismatch between the current application context and an intended application context for the application; and

Wherein the characteristics of the application context are selected from the group consisting of: process trees, application process models, inter-process communications, API surfaces, process start command line parameters, process call sources, associated I/O handles, and function call stacks.

7. The medium of claim 1, wherein the method further comprises registering non-operating system credentials with the operating system.

8. A method of detecting and analyzing an input credential by an operating system component, the method comprising:

receiving input at a computing device, the input addressed to an application;

Determining that the input corresponds to a credential;

Determining a current application context for the application;

detecting a mismatch between the current application context and an expected application context for the application;

identifying a threat in response to the mismatch; and

Responsive to the identification, security mitigation is initiated.

9. The method of claim 8, wherein the characteristics of the application context are selected from the group consisting of: process trees, application process models, inter-process communications, API surfaces, process start command line parameters, process call sources, associated I/O handles, and function call stacks.

10. The method of claim 8, wherein the intended application context is a function call stack having a first characteristic and the current application context does not include the first characteristic.

11. The method of claim 8, wherein the intended application context is that the input is entered into a first process and the current application context is that the input is entered into a second process different from the first process.

12. The method of claim 11, wherein the first process is a credential dialog input process.

13. The method of claim 8, wherein the credential is a password and the threat is password reuse.

14. The method of claim 8, further comprising:

wherein the identification of the threat is further responsive to an additional mismatch between the current network context and an expected network context for the application; and

Wherein the characteristics of the network context are selected from the group consisting of: URL, IP address, procedure ID, server Name Indication (SNI), and domain information.