Non-system user account identification method and device, electronic equipment and storage medium

Abstract

The invention provides a non-system user account identification method and device, electronic equipment and a storage medium, and relates to the technical field of mobile communication, in particular to the technical field of mobile security risk control. According to the specific implementation scheme, a target environment in an operating system is accessed based on target permission; key directories and files related to the user account in the target environment are monitored, and a suspicious user account is obtained; obtaining a target running log related to user account management; and identifying a non-system user account from the suspicious user accounts according to the target operation log.

Description

Technical Field

[0001] This disclosure relates to the field of mobile communication technology, specifically to the field of mobile security risk control technology, and particularly to a method, apparatus, electronic device, and storage medium for identifying non-system user accounts. Background Technology

[0002] Terminal devices may exploit root privileges in the operating system to create new user accounts via commands, allowing applications to run and data to be stored under those accounts, thus circumventing the main user's security monitoring. Currently, security monitoring of terminal devices focuses on the default user environment and lacks the ability to detect user accounts created with root privileges. Summary of the Invention

[0003] This disclosure provides a method, apparatus, electronic device, and storage medium for identifying non-system user accounts.

[0004] According to one aspect of this disclosure, a method for identifying non-system user accounts is provided, comprising: accessing a target environment in an operating system based on target permissions; monitoring key directories and files related to user accounts in the target environment to obtain suspicious user accounts; obtaining target runtime logs related to user account management; and identifying non-system user accounts from the suspicious user accounts based on the target runtime logs.

[0005] According to another aspect of this disclosure, a device for identifying non-system user accounts is provided, comprising: an access module for accessing a target environment in an operating system based on target permissions; a monitoring module for monitoring key directories and files related to user accounts in the target environment to obtain suspicious user accounts; an acquisition module for acquiring target operation logs related to user account management; and an identification module for identifying non-system user accounts from the suspicious user accounts based on the target operation logs.

[0006] According to another aspect of this disclosure, an electronic device is provided, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the non-system user account identification method described in one aspect of the above embodiment.

[0007] According to another aspect of this disclosure, a non-transitory computer-readable storage medium storing computer instructions is provided, wherein computer programs / instructions are stored thereon, the computer instructions being used to cause the computer to execute the non-system user account identification method described in the above-mentioned embodiment.

[0008] According to another aspect of this disclosure, a computer program product is provided, including a computer program / instructions that, when executed by a processor, implement the non-system user account identification method described in one aspect of the above-described embodiments.

[0009] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0010] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein:

[0011] Figure 1 A flowchart illustrating a method for identifying non-system user accounts provided in this embodiment of the disclosure;

[0012] Figure 2 A flowchart illustrating another method for identifying non-system user accounts provided in this embodiment of the disclosure;

[0013] Figure 3 A flowchart illustrating another method for identifying non-system user accounts provided in this embodiment of the disclosure;

[0014] Figure 4 A schematic diagram of the structure of a non-system user account identification device provided in an embodiment of this disclosure;

[0015] Figure 5 This is a block diagram of an electronic device used to implement the non-system user account identification method of the embodiments of this disclosure. Detailed Implementation

[0016] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0017] It should be noted that the acquisition, storage, use, and processing of data in this disclosed technical solution all comply with the provisions of relevant laws and regulations.

[0018] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, data stored, data displayed, etc.) and signals involved in this disclosure are all authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with relevant laws, regulations and standards.

[0019] The following description, with reference to the accompanying drawings, outlines a method, apparatus, electronic device, and storage medium for identifying non-system user accounts according to embodiments of this disclosure.

[0020] Mobile security risk control technology refers to the use of technical means to identify, assess and prevent security threats in mobile communications, and to ensure the security of user data, devices and networks. Its core objective is to prevent information leakage, attacks and system intrusions.

[0021] Non-system user accounts refer to accounts created by using the root privileges of the operating system and through commands, thereby running applications and storing data under the account to evade the security monitoring of the main user.

[0022] Figure 1 This is a flowchart illustrating a method for identifying non-system user accounts provided in an embodiment of the present disclosure.

[0023] like Figure 1 As shown, the method for identifying non-system user accounts may include:

[0024] S101, access the target environment in the operating system based on target permissions.

[0025] It should be noted that the execution entity of the non-system user account identification method in this disclosure embodiment can be a hardware device with data processing capabilities and / or the necessary software to drive the hardware device. Optionally, the execution entity may include a server, a user terminal, and other smart devices. Optionally, the user terminal includes, but is not limited to, mobile phones, computers, smart voice interaction devices, etc. Optionally, the server includes, but is not limited to, a network server, an application server, or a server of a distributed system, or a server combined with blockchain, etc. This disclosure embodiment does not impose specific limitations.

[0026] Understandably, operating systems can restrict user account permissions to limit their access to resources. For example, they can restrict read, write, execute, and network access. Target permissions refer to access rules set for a specific environment. The target environment refers to the operating system environment directly controlled and manipulated by the target permissions.

[0027] In some embodiments, a target environment in the operating system can be accessed based on an access control model using target permissions. For example, the target environment can be accessed with target permissions based on a discretionary access control model; or, for example, the target environment can be accessed with target permissions based on a mandatory access control model. This disclosure does not specifically limit the scope of the access control model.

[0028] For example, the target privileges are root privileges, and the target environment is a root environment. In other words, it is possible to access the root environment in the operating system based on root privileges.

[0029] S102, monitor key directories and files related to user accounts in the target environment to obtain suspicious user accounts.

[0030] In some embodiments, after accessing the target environment in the operating system, key directories and files related to user accounts in the target environment can be monitored at set intervals, and key directories and files related to user accounts in the target environment can be continuously monitored.

[0031] In some embodiments, key directories and files related to user accounts may be user account data directories, user account file lists, etc.

[0032] In some embodiments, suspicious user accounts are identified by monitoring changes to key directories and files. Optionally, it is possible to detect whether new user accounts have been added to key directories, and if so, to retrieve the user accounts stored in the files. If the new user accounts do not exist in the files, they can be identified as suspicious user accounts.

[0033] Optionally, the existence of a newly added user account in the file can be determined based on its timestamp. If the timestamp of the newly added user account differs from the timestamp of the user account stored in the file, the newly added user account can be identified as a suspicious user account. For example, if the timestamp A of the newly added user account is later than the timestamp B of the user account stored in the file, the newly added user account is considered a suspicious user account; conversely, if the timestamp A of the newly added user account does not exist in the file, the newly added user account is also considered a suspicious user account.

[0034] It should be noted that the monitoring of key directories and files related to user accounts in the target environment in this embodiment is carried out with the authorization of the user account and strictly complies with relevant laws and regulations such as privacy and security, and meets the restriction requirements for data collection.

[0035] S103, Obtain target runtime logs related to user account management.

[0036] In some embodiments, the system operation logs of the operating system can be obtained, and system operation logs related to user account management can be filtered out from the system operation logs as target operation logs. Optionally, based on the operation events recorded in the system operation logs, and by determining whether the operation events are related to user account management, if they are related to user account management, the system operation log corresponding to the operation event can be determined as the target operation log.

[0037] For example, if there are system operation log 1, system operation log 2, and system operation log 3, and their corresponding operation events are event 1, event 3, and event 3 respectively, if event 1 is related to user account management, system operation log 1 can be identified as the target operation log.

[0038] For example, if the running event is a broadcast or notification created by a user account, a user account switching event, or a user account loading application data, it can be determined that the running event is related to user account management.

[0039] In some embodiments, the type of system operation log can also be determined. If the type of system operation log is user account management, then the system operation log can be determined as the target operation log. Optionally, the type of system operation log can be determined from the operating system's configuration information.

[0040] S104. Identify non-system user accounts from suspicious user accounts based on the target's runtime logs.

[0041] In some embodiments, the behavioral event sequence of a suspicious user account can be determined based on the target runtime log, and the event trajectory of the suspicious user account can be determined based on the behavioral event sequence. Thus, based on the event trajectory, it can be determined whether the suspicious user account is a non-system user account, thereby enabling the identification of non-system user accounts from suspicious user accounts.

[0042] Understandably, non-system user accounts lack full operating system privileges, which restricts their access and affects their behavior patterns and operational scope. In other words, the event completeness of event logs for non-system user accounts is less than that for system user accounts.

[0043] In some embodiments, a threshold for the completeness of the event trace of a suspicious user account can be set. If the event completeness of the event trace of a suspicious user account is less than the threshold, the suspicious user account can be determined to be a non-system user account.

[0044] In some embodiments, the behavioral trajectory of a suspicious user account can be obtained from the target runtime log based on the user account identifier of the suspicious user account, and the behavioral event sequence of the suspicious user account can be determined based on the behavioral trajectory. For example, the behavioral event sequence includes, but is not limited to: the creation time of the suspicious user account, whether it interacted with the application, runtime, state transitions, etc.

[0045] It should be noted that the method proposed in the embodiments of this disclosure can be used to identify any terminal device as abnormal. If a non-system user account is identified in any terminal device, the terminal device can be determined to be an abnormal terminal device.

[0046] According to the non-system user account identification method provided in this disclosure, the target environment of the operating system is accessed with target permissions, and key directories and files related to user accounts in the target environment are monitored to obtain suspicious user accounts. Furthermore, target runtime logs are obtained, and non-system user accounts can be identified from the suspicious user accounts based on these logs. Therefore, this solution, by accessing the target environment of the operating system with target permissions, can achieve comprehensive awareness of newly added user accounts based on different permissions, improving the coverage of non-system user account identification. Based on static directories and files, and dynamic runtime logs, non-system user accounts are identified to improve the accuracy and reliability of the identification.

[0047] Figure 2 This is a flowchart illustrating a method for identifying non-system user accounts provided in an embodiment of the present disclosure.

[0048] like Figure 2 As shown, the method for identifying non-system user accounts may include:

[0049] S201, Access to the target environment in the operating system based on target permissions.

[0050] The details of step S201 can be found in the above embodiments and will not be repeated here.

[0051] S202, traverse the key directories and obtain directory snapshots of the key directories.

[0052] S203, based on the directory snapshot and user account list file, identify newly added user accounts in the target environment as suspicious user accounts.

[0053] Understandably, when adding a user with target privileges, the operating system creates a new user account named after the new user's identifier in the critical directory and adds the new user account to the user account list file. In other words, new user accounts in the target environment can be identified as suspicious user accounts based on the critical directory and the user account list file.

[0054] In some embodiments, a key directory refers to a directory where files related to user account management are stored. For example, a user account data directory that stores basic user account information can be used as a key directory.

[0055] In some embodiments, the critical directory can be traversed based on target permissions, and a directory snapshot of the critical directory can be obtained during the traversal. Optionally, a directory snapshot refers to a record of the state of the directory at a certain moment, including user account identifier, file attributes (such as size, permissions, timestamps), etc.

[0056] In some embodiments, when traversing a key directory, a directory snapshot of the key directory can be obtained by accessing the space where the directory snapshot of the key directory is stored.

[0057] In some embodiments, the newly added user accounts can be identified by obtaining snapshot differences from directory snapshots, thereby enabling rapid identification of new user accounts in the operating system and reducing security risks. Optionally, to improve the accuracy of identifying new user accounts, new user accounts in the target environment can also be identified based on user accounts and corresponding timestamps in a user account list file.

[0058] In some embodiments, snapshot differences are obtained by comparing directory snapshots, and candidate new user accounts are determined based on these snapshot differences. Optionally, the identifier of the new user account is determined as a snapshot difference by comparing the target snapshot, thereby identifying the user account corresponding to the new user account identifier as a candidate new user account from the snapshot differences.

[0059] For example, the directory snapshots are in chronological order as: Directory Snapshot 1 and Directory Snapshot 2. Directory Snapshot 1 contains user account identifiers A and B, while Directory Snapshot 2 contains user account identifiers A, B, and C. By comparing Directory Snapshot 1 and Directory Snapshot 2, user account C can be identified as the snapshot difference, and user account C can be selected as a candidate for new user account.

[0060] Furthermore, the user accounts and their corresponding timestamps can be obtained from the user account list file. Based on the user accounts and their corresponding timestamps in the user account list file, the candidate new user accounts can be updated to obtain new user accounts, which will then be identified as suspicious user accounts.

[0061] Optionally, it can be determined whether the candidate new user account exists in the user account list file. If it does not exist, the candidate new user account can be confirmed as a new user account. For example, it can be determined whether the candidate new user account exists in the user account list file by comparing whether the candidate new user account is the same as a user account in the user account list file.

[0062] Optionally, the timestamps of the candidate newly added user accounts can be compared with the timestamps of the corresponding user accounts in the user account list file to determine whether the candidate newly added user accounts exist in the user account list file.

[0063] S204, Obtain target runtime logs related to user account management.

[0064] S205, Identify non-system user accounts from suspicious user accounts based on the target's runtime logs.

[0065] The details of steps S204-S205 can be found in the above embodiments and will not be repeated here.

[0066] According to the non-system user account identification method provided in this disclosure, by traversing key directories, candidate new user accounts are identified, and based on the user account list file, new user accounts can be identified as suspicious user accounts from the candidate new user accounts. Therefore, this solution, by identifying suspicious user accounts from key directories and the user account list file, can improve the response speed for identifying suspicious user accounts and provide data support for subsequent identification of non-system user accounts.

[0067] Figure 3 This is a flowchart illustrating a method for identifying non-system user accounts provided in an embodiment of the present disclosure.

[0068] like Figure 3 As shown, the method for identifying non-system user accounts may include:

[0069] S301, accessing the target environment in the operating system based on target permissions.

[0070] S302 monitors key directories and files related to user accounts in the target environment to obtain suspicious user accounts.

[0071] The details of steps S301-S302 can be found in the above embodiments and will not be repeated here.

[0072] S303, Obtain target runtime logs related to user account management.

[0073] In some embodiments, target operation logs related to user account management can be obtained from the system's operation logs, thereby enabling precise location of user account operation behaviors and improving the efficiency of identifying non-system user accounts.

[0074] In some embodiments, the system's runtime logs can be read based on log read instructions, and the contents of the runtime logs can be obtained to determine the type of the system's runtime logs based on the contents. For example, runtime log A is used to record information such as the running status and operations of applications, so runtime log A can be identified as an application log. As another example, runtime log B is used to record security-related events, so runtime log B can be identified as a security log.

[0075] Furthermore, the system's operational logs can be filtered based on log type to obtain the target operational logs. In other words, based on log type, operational logs related to user account management can be identified from the system's operational logs and used as the target operational logs.

[0076] S304. Based on the target's runtime logs, obtain behavioral data of suspicious user accounts, including behavioral events and corresponding timestamps.

[0077] In some embodiments, behavioral events corresponding to the user account identifier and the timestamps of the behavioral events can be obtained from the target runtime logs based on the user account identifier of the suspicious user account as behavioral data for the suspicious user account. Optionally, runtime logs related to the suspicious user account can be determined from the target runtime logs based on the user account identifier of the suspicious user account, and behavioral events can be determined from the runtime logs based on set fields.

[0078] For example, Run Log 1 is the run log of suspicious user account 1, and the set field is field A. The data corresponding to field A is obtained from Run Log 1 as the behavior event of suspicious user account 1.

[0079] S305. Based on the behavioral data, reconstruct the behavioral trajectory of the suspicious user account to obtain the behavioral event sequence of the suspicious user account.

[0080] In some embodiments, the behavioral events of a suspicious user account are sorted in chronological order according to the timestamps in the behavioral data, and the behavioral path of the suspicious user account is determined based on the behavioral events, thereby restoring the behavioral trajectory of the suspicious user account and determining the sequence of behavioral events of the suspicious user account based on the behavioral trajectory.

[0081] In some embodiments, different stages of a behavioral event sequence can be determined based on behavioral trajectories, thereby generating a behavioral event sequence for a suspicious user account based on these different stages. For example, the different stages of a behavioral event sequence include: creation, activation, switching, and deletion. Creation refers to creating a new user account in the system; activation refers to the suspicious user account interacting with the system; switching refers to switching operations in the system from one user account to another; and deletion refers to deleting the suspicious user account from the system.

[0082] For example, taking the scenario of suspicious user account 1 using application A to make purchases as an example, the behavioral event sequence of suspicious user account 1 will be explained. The behavioral data of suspicious user account 1 includes: timestamp A (creating suspicious user account 1), timestamp B (logging into application A), timestamp C (accessing product 1), timestamp D (adding product 1 to the shopping cart), timestamp E (submitting the order), timestamp F (exiting application A), and timestamp G (deleting suspicious user account 1). Based on the behavioral data, the behavioral trajectory of suspicious user account 1 can be reconstructed as: creating suspicious user account 1 - logging into application A - browsing product 1 - adding to the shopping cart - submitting the order - exiting application A - deleting suspicious user account 1. Therefore, the behavioral event sequence of suspicious user account 1 can be determined as: timestamp A (creating suspicious user account 1) and timestamp G (deleting suspicious user account 1).

[0083] S306, Based on the sequence of behavioral events of suspicious user accounts, identify non-system user accounts from among the suspicious user accounts.

[0084] In some embodiments, suspicious user accounts can be associated with main system user accounts to obtain a complete system event track, thereby identifying whether the suspicious user account is a non-system user account based on the event track, thus improving the accuracy of identifying non-system user accounts.

[0085] In some embodiments, suspicious user accounts and main system user accounts can be correlated on a timeline based on a sequence of behavioral events to generate an event trajectory. Optionally, a second timestamp corresponding to the main system user account on the timeline can be determined based on a first timestamp in the sequence of behavioral events, thereby determining a first event corresponding to the first timestamp and a second event corresponding to the second timestamp. Further, the first event and the second event are correlated to obtain the event trajectory.

[0086] Understandably, non-system user accounts lack full operating system privileges, which restricts their access and affects their behavior patterns and operational scope. In other words, the event logs of non-system user accounts have less completeness than a set limit, allowing for the identification of non-system user accounts from among suspicious user accounts based on these logs.

[0087] In some embodiments, event completeness is a key indicator for assessing whether the behavioral trajectory of a suspicious user account is comprehensive and without omissions. The event completeness of a suspicious user account can be determined based on the event trajectory. For example, the event completeness of a suspicious user account can be determined by assessing whether the event trajectory covers all operational steps, whether it has temporal continuity, and whether it has contextual completeness.

[0088] Optionally, the event trajectory can be scored in multiple dimensions based on the integrity assessment model, and the scores of each dimension can be weighted to determine the integrity score. The integrity of the event for a suspicious user account can be determined by establishing a pre-established correlation between the integrity score and the event integrity.

[0089] In some embodiments, non-system user accounts are identified from suspicious user accounts by comparing the event completeness of a suspicious user account with a set completeness. Optionally, a suspicious user account is identified as a non-system user account in response to an event completeness less than a set completeness.

[0090] In some embodiments, if the event completeness is greater than or equal to a set completeness, the suspicious user account can be further identified based on the environmental characteristics information of the suspicious user account, thereby enabling accurate identification of non-system user accounts and ensuring system security.

[0091] In other words, in response to an event completeness greater than or equal to a set completeness, environmental characteristic information of suspicious user accounts is obtained, and non-system user accounts are identified from the suspicious user accounts based on the environmental characteristic information.

[0092] It is understandable that non-system user accounts are user accounts created in the target environment of the operating system using the target permissions, and therefore non-system user accounts contain characteristics of the target environment.

[0093] In other words, if the environmental feature information includes the characteristics of the target environment, the suspicious user account is determined to be a non-system user account; if the environmental feature information does not include the characteristics of the target environment, the suspicious user account is determined to be a work configuration user account.

[0094] In some embodiments, before determining non-system user accounts from suspicious user accounts based on the behavioral event sequence of suspicious user accounts, auxiliary identification information of suspicious user accounts may be obtained, and the behavioral event sequence may be optimized based on the auxiliary identification information to improve the accuracy of the behavioral event sequence and further improve the accuracy of identifying non-system user accounts.

[0095] In some embodiments, currently active user accounts can be used as auxiliary identification information. Alternatively, target processes associated with suspicious user accounts can be obtained from a process list and used as auxiliary identification information. In other words, currently active user accounts and target processes associated with suspicious user accounts are obtained as auxiliary identification information for suspicious user accounts, and the behavioral event sequence is optimized based on this auxiliary identification information to obtain an optimized behavioral event sequence for the suspicious user account.

[0096] In some embodiments, the completeness of a behavioral event sequence can be verified based on auxiliary identification information. If the auxiliary identification information is consistent with the behavioral event sequence, the behavioral event sequence is considered complete. If the auxiliary identification information is inconsistent with the behavioral event sequence, the behavioral event sequence is considered incomplete. Information in the auxiliary identification information that is inconsistent with the behavioral event sequence can be added to the behavioral event sequence to optimize the behavioral event sequence and obtain an optimized behavioral event sequence for the suspicious user account.

[0097] Optionally, an access command can be received, and the currently active user account can be obtained based on the access command. Optionally, a process access command can be used to select the target process associated with the suspicious user account from the process list.

[0098] Optionally, a process list can be obtained from the operating system using a process access command. From the process list, processes that are associated with the identifier of a suspicious user account can be identified as the target processes of the suspicious user account.

[0099] In some embodiments, after identifying non-system user accounts from suspicious user accounts, an anomaly identification report of the non-system user accounts can be generated, thereby visually displaying the behavioral trajectory of the non-system user accounts.

[0100] In some embodiments, by identifying the applications and data associated with the non-system user account and obtaining the behavioral trajectory of the non-system user account, behavioral summary information of the non-system user account is generated based on the behavioral trajectory of the non-system user account, thereby generating an anomaly identification report of the non-system user account based on the applications and data and the behavioral summary information.

[0101] Optionally, a report template can be set, and application, data, and behavioral summary information can be added to the report template to obtain an anomaly identification report for non-system user accounts.

[0102] According to the non-system user account identification method provided in this disclosure, behavioral data of suspicious user accounts is obtained from the target operation log, and the behavioral trajectory of the suspicious user accounts is reconstructed based on the behavioral data, thereby determining the behavioral event sequence of the suspicious user accounts. Furthermore, non-system user accounts are identified from the suspicious user accounts based on the behavioral event sequence. Therefore, by determining the behavioral event sequence of suspicious user accounts, comprehensive coverage of suspicious user accounts can be achieved, and the activities of removed non-system user accounts can be traced, improving the comprehensiveness of non-system user account identification.

[0103] Corresponding to the non-system user account identification methods provided in the above embodiments, one embodiment of this disclosure also provides a non-system user account identification device. Since the non-system user account identification device provided in this disclosure corresponds to the non-system user account identification methods provided in the above embodiments, the implementation methods of the above non-system user account identification methods are also applicable to the non-system user account identification device provided in this disclosure, and will not be described in detail in the following embodiments.

[0104] Figure 4 This is a schematic diagram of the structure of a non-system user account identification device provided in an embodiment of this disclosure.

[0105] like Figure 4 As shown, the non-system user account identification device 400 of this embodiment includes an access module 401, a monitoring module 402, an acquisition module 403, and an identification module 404.

[0106] Access module 401 is used to access the target environment in the operating system based on the target permissions;

[0107] Monitoring module 402 is used to monitor key directories and files related to user accounts in the target environment and obtain suspicious user accounts;

[0108] Module 403 is used to obtain target runtime logs related to user account management;

[0109] The identification module 404 is used to identify non-system user accounts from suspicious user accounts based on the target's runtime logs.

[0110] In one embodiment of this disclosure, the monitoring module 402 is further configured to: traverse the key directory and obtain a directory snapshot of the key directory; and identify newly added user accounts in the target environment as suspicious user accounts based on the directory snapshot and the user account list file.

[0111] In one embodiment of this disclosure, the monitoring module 402 is further configured to: compare the directory snapshots, obtain snapshot differences, and determine candidate new user accounts based on the snapshot differences; obtain user accounts and corresponding timestamps from the user account list file; and update the candidate new user accounts based on the user accounts and corresponding timestamps from the user account list file to obtain new user accounts.

[0112] In one embodiment of this disclosure, the acquisition module 403 is further configured to: read the system's operation log; determine the type of the system's operation log; and filter the system's operation log according to the log type to obtain the target operation log.

[0113] In one embodiment of this disclosure, the identification module 404 is further configured to: obtain behavioral data of a suspicious user account based on the target running log, wherein the behavioral data includes behavioral events and corresponding timestamps; reconstruct the behavioral trajectory of the suspicious user account based on the behavioral data to obtain a behavioral event sequence of the suspicious user account; and determine non-system user accounts from the suspicious user accounts based on the behavioral event sequence of the suspicious user account.

[0114] In one embodiment of this disclosure, the identification module 404 is further configured to: obtain target processes associated with currently active user accounts and suspicious user accounts as auxiliary identification information for suspicious user accounts; and optimize the behavioral event sequence based on the auxiliary identification information to obtain an optimized behavioral event sequence for suspicious user accounts.

[0115] In one embodiment of this disclosure, the identification module 404 is further configured to: obtain a process list; and determine, from the process list, processes that are associated with the identifier of a suspicious user account, as target processes of the suspicious user account.

[0116] In one embodiment of this disclosure, the identification module 404 is further configured to: associate suspicious user accounts with main system user accounts on a timeline according to the sequence of behavioral events to generate an event trajectory; and identify non-system user accounts from the suspicious user accounts according to the event trajectory.

[0117] In one embodiment of this disclosure, the identification module 404 is further configured to: determine the event completeness of a suspicious user account based on the event trajectory; and determine that the suspicious user account is a non-system user account in response to the event completeness being less than a set completeness.

[0118] In one embodiment of this disclosure, the identification module 404 is further configured to: obtain environmental feature information of a suspicious user account in response to an event completeness greater than or equal to a set completeness; determine that the suspicious user account is a non-system user account in response to the environmental feature information including features of the target environment; and determine that the suspicious user account is a work configuration user account in response to the environmental feature information not including features of the target environment.

[0119] In one embodiment of this disclosure, the identification module 404 is further configured to: determine the applications and data associated with the non-system user account; generate behavioral summary information of the non-system user account based on the behavioral trajectory of the non-system user account; and generate an anomaly identification report of the non-system user account based on the applications and data, as well as the behavioral summary information.

[0120] The non-system user account identification device provided in this disclosure accesses the target environment of the operating system with target permissions and monitors key directories and files related to user accounts in the target environment to obtain suspicious user accounts. Further, it acquires target runtime logs and, based on these logs, identifies non-system user accounts from among the suspicious user accounts. Therefore, this solution, by accessing the target environment of the operating system with target permissions, can achieve comprehensive awareness of newly added user accounts based on different permissions, improving the coverage of non-system user account identification. Based on static directories and files, and dynamic runtime logs, it identifies non-system user accounts to improve the accuracy and reliability of the identification.

[0121] The acquisition, storage, and application of user account personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0122] According to an embodiment of the present disclosure, the present disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0123] Figure 5 A schematic block diagram of an example electronic device 500 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0124] like Figure 5As shown, device 500 includes a computing unit 501, which can perform various appropriate actions and processes based on computer programs / instructions stored in read-only memory (ROM) 502 or loaded from storage unit 506 into random access memory (RAM) 503. RAM 503 may also store various programs and data required for the operation of device 500. The computing unit 501, ROM 502, and RAM 503 are interconnected via bus 504. Input / output (I / O) interface 505 is also connected to bus 504.

[0125] Multiple components in device 500 are connected to I / O interface 505, including: input unit 506 such as keyboard, mouse, etc.; output unit 507 such as various types of monitors, speakers, etc.; storage unit 508 such as disk, optical disk, etc.; and communication unit 509 such as network card, modem, wireless transceiver, etc. Communication unit 509 allows device 500 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0126] The computing unit 501 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 501 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 501 performs the various methods and processes described above, such as the method for identifying non-system user accounts. For example, in some embodiments, the method for identifying non-system user accounts can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 506. In some embodiments, part or all of the computer program / instructions can be loaded and / or installed on device 500 via ROM 502 and / or communication unit 509. When the computer program / instructions are loaded into RAM 503 and executed by the computing unit 501, one or more steps of the method for identifying non-system user accounts described above can be performed. Alternatively, in other embodiments, the computing unit 501 may be configured by any other suitable means (e.g., by means of firmware) to perform a method for identifying non-system user accounts.

[0127] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include: implementations in one or more computer programs / instructions that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transferring data and instructions to the storage system, the at least one input device, and the at least one output device.

[0128] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0129] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0130] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the computer. Other types of devices can also be used to provide interaction with the user; for example, the feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including acoustic input, voice input, or tactile input).

[0131] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), the Internet, and blockchain networks.

[0132] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. The client-server relationship is created by computer programs / instructions running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0133] It should be understood that the various forms of processes shown above can be used to reorder, add, or delete steps. For example, the steps described in the disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this document does not impose any restrictions.

[0134] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A method for identifying non-system user accounts, wherein, The method includes: Access to the target environment within the operating system based on target permissions; Monitor key directories and files related to user accounts in the target environment to obtain suspicious user accounts; Obtain target runtime logs related to user account management; Based on the target's runtime logs, identify non-system user accounts from the suspicious user accounts.

2. The method according to claim 1, wherein, The monitoring of key directories and files related to user accounts in the target environment to obtain suspicious user accounts includes: The key directories are traversed, and a directory snapshot of the key directories is obtained; Based on the directory snapshot and user account list file, newly added user accounts in the target environment are identified as suspicious user accounts.

3. The method according to claim 2, wherein, The step of identifying new user accounts in the target environment based on the directory snapshot and user account list file includes: The directory snapshots are compared to obtain snapshot differences, and candidate new user accounts are determined based on the snapshot differences. Retrieve the user accounts and their corresponding timestamps from the user account list file; The candidate new user accounts are updated based on the user accounts and corresponding timestamps in the user account list file to obtain the new user accounts.

4. The method according to claim 1, wherein, The acquisition of target runtime logs related to user account management includes: Read the system's runtime log; Determine the type of the system's runtime log; The system's runtime logs are filtered according to the log type to obtain the target runtime logs.

5. The method according to claim 1, wherein, The step of identifying non-system user accounts from the suspicious user accounts based on the target operation log includes: Based on the target operation log, obtain the behavioral data of the suspicious user account, wherein the behavioral data includes behavioral events and corresponding timestamps; Based on the behavioral data, the behavioral trajectory of the suspicious user account is reconstructed to obtain the behavioral event sequence of the suspicious user account; Based on the sequence of behavioral events of the suspicious user accounts, the non-system user accounts are identified from the suspicious user accounts.

6. The method according to claim 5, wherein, Before determining the non-system user account from the suspicious user accounts based on the behavioral event sequence of the suspicious user accounts, the method further includes: Obtain the target processes associated with currently active user accounts and the suspicious user accounts, as auxiliary identification information for the suspicious user accounts; The behavioral event sequence is optimized based on the auxiliary identification information to obtain the optimized behavioral event sequence of the suspicious user account.

7. The method according to claim 6, wherein, Obtaining the target process associated with the suspicious user account includes: Get the process list; From the process list, identify the processes that are associated with the identifier of the suspicious user account, and use them as the target processes for the suspicious user account.

8. The method according to any one of claims 5-7, wherein, The step of determining the non-system user account from the suspicious user accounts based on the behavioral event sequence of the suspicious user accounts includes: Based on the sequence of behavioral events, the suspicious user accounts and the main system user accounts are correlated on the timeline to generate event trajectories; Based on the event trajectory, the non-system user accounts are identified from the suspicious user accounts.

9. The method according to claim 8, wherein, The step of identifying the non-system user account from the suspicious user accounts based on the event trajectory includes: Based on the event trajectory, determine the event completeness of the suspicious user account; In response to the event completeness being less than a set completeness, the suspicious user account is determined to be a non-system user account.

10. The method according to claim 9, wherein, The method further includes: In response to an event completeness greater than or equal to the set completeness, environmental characteristic information of the suspicious user account is obtained; In response to the environmental feature information including the features of the target environment, the suspicious user account is determined to be a non-system user account; In response to the fact that the environmental feature information does not include the features of the target environment, the suspicious user account is determined to be a work configuration user account.

11. The method according to any one of claims 1-8, wherein, After identifying non-system user accounts from the suspicious user accounts, the process further includes: Identify the applications and data associated with the non-system user accounts; Generate behavioral summary information of the non-system user account based on the behavioral trajectory of the non-system user account; Based on the application and data, as well as the behavioral summary information, an anomaly identification report for the non-system user account is generated.

12. A device for identifying non-system user accounts, wherein, The device includes: The access module is used to access the target environment in the operating system based on the target permissions. The monitoring module is used to monitor key directories and files related to user accounts in the target environment and obtain suspicious user accounts; The acquisition module is used to acquire target runtime logs related to user account management; The identification module is used to identify non-system user accounts from the suspicious user accounts based on the target's running logs.

13. An electronic device, comprising: at least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method as described in any one of claims 1-11.

14. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-11.

15. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the method of any one of claims 1-11.

Images