An account security checking system based on RDP protocol

Abstract

This application relates to the technical field of network and information security, and discloses an account security inspection system based on the RDP protocol. It uses the WinRM protocol as the core remote execution protocol, while also supporting the RDP protocol as an alternative connection method, enabling agentless remote management of Windows hosts. The system employs a multi-dimensional security inspection module covering more than 20 security checks, including password policies, account locking, user permissions, and login auditing. It supports all versions of Windows Server 2008 to 2022 through a cross-distribution compatibility mechanism. It utilizes a dynamic load-aware concurrent inspection engine to process log analysis and embedded account scanning tasks in parallel, and automatically identifies abnormal changes to account information through baseline comparison with integrity protection and a permission change awareness module. This invention requires no software deployment on the target host, is non-intrusive to the production environment, and can efficiently complete account security checks on large-scale Windows assets, significantly improving the account security protection capabilities of enterprise information systems.

Description

Technical Field

[0001] This application relates to the technical field of network and information security, and in particular to an account security inspection system based on the RDP protocol. Background Technology

[0002] As enterprises increasingly adopt information technology, the Windows Server operating system, with its stability and ease of use, has been widely deployed in critical infrastructure sectors such as government, finance, power, and energy. Account security, as the first line of defense for Windows system security, is directly related to the secure and stable operation of the entire information system, encompassing multiple dimensions including password policies, account locking, user permissions, login auditing, and UAC (User Account Control).

[0003] Currently, enterprises primarily rely on two methods to check the security of Windows server accounts: one is the traditional manual inspection method, where security operations personnel log into the server via remote desktop and use commands such as secpol.msc and netuser to check security configurations item by item. This method is extremely inefficient. For enterprises with hundreds or thousands of servers, completing a comprehensive inspection requires a significant amount of manpower and time, is prone to human error, and demands a high level of professional skill from the operators. Another approach is to use existing automated security inspection tools, but these tools generally suffer from the following shortcomings: First, most tools are developed only for specific versions of Windows systems, lacking cross-version compatibility with multiple versions such as Windows Server 2008 to 2022, and thus failing to adapt to heterogeneous IT environments within enterprises. Second, most existing tools only focus on checking static security configurations, lacking the ability to compare and analyze historical baseline data, failing to detect dynamic changes in user permissions and group memberships, and making it difficult to identify potential risks of permission abuse. Third, almost all tools lack the ability to scan for embedded accounts in the file system (i.e., credentials hard-coded in configuration files and scripts), and the leakage of these hard-coded credentials will pose a serious security threat to enterprises. Finally, most existing tools adopt a single-threaded serial execution method, which is extremely inefficient for time-consuming tasks such as log analysis and file system scanning, and cannot meet the needs of rapid inspection of large-scale assets.

[0004] In addition, existing tools have problems such as insufficient security of remote connections, significant impact of concurrent execution on business, high false alarm rate, and lack of protection for baseline data, which further limit their large-scale application in enterprise production environments. Summary of the Invention

[0005] To address the aforementioned technical problems, this application provides an account security inspection system based on the RDP protocol, employing the following technical solution: An account security inspection system based on the RDP protocol includes: The WinRM remote execution engine is used to establish a remote connection with the target Windows host by encapsulating the WinRM protocol, execute PowerShell scripts or CMD commands and receive the return results. It supports the RDP protocol as an alternative remote connection method. When the WinRM service on the target host is not enabled, a remote desktop session is established through the RDP protocol to perform inspection tasks. The multi-dimensional security check module is used to perform multi-dimensional security checks on the target host, including password policy, account lockout policy, account status, permissions and configuration, logs and auditing. A cross-distribution compatibility mechanism is used to handle differences in security configuration paths and command outputs between different versions of Windows. The concurrent inspection engine is used to perform log analysis and embedded account scanning tasks in parallel using a multi-threaded concurrent architecture, and supports dynamically adjusting the number of concurrent threads based on the real-time load of the target host. An embedded account scanning module is used to scan hard-coded credentials in the target host file system, and it has a three-level false alarm filtering mechanism; The baseline comparison and permission change awareness module is used to compare the current inspection results with historical baseline data with integrity protection to identify abnormal changes in account information; The inspection results data model is used to serialize the inspection results into a structured JSON format for output.

[0006] Optionally, the WinRM remote execution engine manages connections and command execution uniformly through the WinRMWrapper class, supports both HTTP and HTTPS transmission protocols, enables server certificate verification by default, supports importing custom CA certificates, and does not require the installation of any proxy software on the target host.

[0007] Optionally, the inspection items of the multi-dimensional security inspection module include: Password policy checks: password complexity requirements, minimum password length, minimum password expiration time, maximum password expiration time, and mandatory password history. Account lockout policy check: account lockout threshold, account lockout duration; Account status check: Guest account status, administrator account name, accounts that have not been used for a long time, and accounts with blank passwords; Permissions and configuration checks: User Account Control level, Remote Desktop enabled status, Network Level Authentication enabled status, Anonymous enumeration restrictions, User home directory permissions; Log and audit checks: Login audit event recording, abnormal login behavior analysis, and user login IP stability. Abnormal login behaviors include exceeding the limit for the number of failed login attempts, logging in outside of working hours, IP address changes, abnormal geographical location, abnormal device fingerprints, abnormal login frequency, and abnormal privileged accounts.

[0008] Optionally, the cross-distribution compatibility mechanism is implemented in the following ways: Use the common PowerShell commands Get-WmiObject and Get-ItemProperty to obtain system configuration; Differences in configuration file formats exported from different versions of secedit are handled through string parsing and regular expression matching; Perform a general keyword matching between Chinese and English on the output of the netuser command.

[0009] Optionally, the concurrent inspection engine uses threading.Thread to implement an independent thread for log analysis, and uses concurrent.futures.ThreadPoolExecutor to execute log time-segmented query tasks and embedded account scanning multi-directory tasks in parallel. The maximum number of concurrent threads is dynamically calculated based on the number of CPU cores of the target host and the real-time load.

[0010] Optionally, the formula for calculating the maximum number of concurrent threads is: W=min([C / 3]×k,5); Where W is the maximum number of concurrent threads, C is the number of CPU cores of the target host, [] indicates rounding down, and k is the load factor; the rules for determining the load factor k are as follows: When the target host's CPU utilization is less than 30% and memory utilization is less than 50%, k=1; When 30% ≤ CPU utilization < 60% and 50% ≤ memory utilization < 70%, k = 0.5; When CPU utilization is ≥60% or memory utilization is ≥70%, k=0.2.

[0011] Optionally, the embedded account scanning module performs the scan through the following steps: Traverse all disks on the target host to locate the code directory containing the keywords src, service, controller, and api, as well as the C:\Program Files program installation directory; Perform regular expression matching on the .py, .java, .c, .js code files and .txt, .conf, .json, .yaml, .properties, .sql configuration files in each directory; Match username pattern and password field pattern; Perform a three-level false alarm filtering: the first level filters single-line and multi-line comments, the second level filters example values ​​containing test keywords, and the third level filters content in comment blocks and documentation. The file paths and matching content that contain both usernames and passwords and pass the filtering are summarized and output to form an embedded account risk list.

[0012] Optionally, the baseline comparison and permission change perception module includes a baseline data management submodule, which realizes automatic baseline generation, version control, encrypted storage and integrity verification functions; the module compares the user list, home directory, local group, global group and home directory permissions in the current inspection results with the verified historical baseline data item by item, detects changes in user home directory, changes in home directory permissions, changes in user group additions or deletions, and records the change details and marks permission change risk items when changes are found.

[0013] Optionally, the inspection result data model defines a HuntWindows security inspection result object and a User information object, which includes Boolean results for each inspection item, details of permission changes, basic user information, and embedded account risk list fields.

[0014] In summary, this application includes at least one of the following beneficial technical effects: This application utilizes the WinRM / RDP protocol for remote inspection, requiring no software installation on the target host and offering no intrusion into the production environment. It effectively avoids compatibility issues and security risks associated with deploying proxy software. The system uniformly supports mainstream versions of Windows Server 2008 to 2022, allowing a single system to cover heterogeneous enterprise IT environments and reducing security operation and maintenance costs. The system covers over 20 security checks, including password policies, account locking, user permissions, UAC, RDP configuration, login auditing, and embedded credentials, providing comprehensive inspection dimensions to fully uncover various security issues on Windows host accounts. Through a dynamic load-aware multi-threaded parallel processing mechanism, it minimizes the impact on target host operations while ensuring inspection efficiency, adapting to the needs of large-scale asset inspections. The system supports comparison with historical data with integrity protection, automatically identifying abnormal changes in account permissions and group membership relationships, enhancing the enterprise's continuous security monitoring capabilities. A three-level false alarm filtering mechanism significantly reduces the false alarm rate of embedded account scanning, decreasing the workload for security personnel. The structured inspection results in JSON format facilitate integration with upstream systems such as asset management platforms and SIEM, enabling the automation and standardization of the security inspection process. Attached Figure Description

[0015] Figure 1This is a schematic diagram of the module operation architecture of an account security inspection system based on the RDP protocol. Detailed Implementation

[0016] The embodiments of this application are described in detail below, and examples of the embodiments are shown in the accompanying drawings.

[0017] In the description of this specification, the references to "certain embodiments," "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples" refer to specific features, structures, materials, or characteristics described in connection with the described embodiment or example, which are included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0018] This application discloses an account security inspection system based on the RDP protocol, referring to... Figure 1 It includes a control center, a concurrent scheduling engine, a WinRM remote execution engine, a multi-dimensional security check module, an embedded account scanning module, a baseline comparison module, and a result data model.

[0019] The control center, located at the top layer of the system, serves as the system's input / output hub. On the left, it receives external input parameters, including the target host's username, password, IP address, WinRM / RDP port number, and historical baseline data; on the right, it outputs the final JSON-formatted check results. The control center passes the input parameters to the concurrent scheduling engine and receives structured data returned by the result data model.

[0020] The concurrent scheduling engine is directly connected to the control center and includes two sub-components: a concurrent scheduler and a multi-thread / thread pool management system. The concurrent scheduler is responsible for receiving task instructions from the control center and generating the optimal concurrent configuration based on the number of CPU cores and real-time load of the target host using a dynamic thread count calculation unit. The multi-thread / thread pool management component is responsible for creating, scheduling, and destroying all inspection task threads, coordinating the execution order of the main thread and independent threads, and avoiding resource contention and deadlock.

[0021] The WinRM remote execution engine, connected to the concurrent scheduling engine, is the core channel for communication between the system and the target Windows host. It comprises three sub-components: the WinR connector, the command executor, and the execution monitor. The WinR connector is responsible for establishing WinRMHTTP / HTTPS connections or RDP remote desktop connections with the target host and completing authentication, verifying the validity of the server certificate by default. The command executor is responsible for sending the packaged PowerShell script or CMD commands to the target host for execution. The execution monitor monitors the connection status and command execution timeout in real time, immediately terminating the task and returning an error message if any abnormality occurs.

[0022] The multi-dimensional security check module interacts with the target host through the WinRM remote execution engine and includes five parallel check sub-modules: password policy check sub-module, account status check sub-module, permission and configuration check sub-module, log and audit check sub-module, and account lockout policy check sub-module.

[0023] The embedded account scanning module is executed by an independent thread pool allocated by the concurrent scheduling engine, and includes four sub-components: file system traversal, file type filtering, regular expression matching, and false alarm filtering.

[0024] The baseline comparison module receives the current user information output by the multi-dimensional security check module, and at the same time receives verified historical baseline data from the control center, executes item-by-item comparison logic, and generates change details.

[0025] The resulting data model integrates the outputs of all modules and converts them into a standardized JSON format, which is then returned to the control center.

[0026] The following example demonstrates the detailed implementation of this system by performing an account security check on a Windows Server 2019 server with IP address 10.10.10.58 and port 5986 (WinRMHTTPS): Step 1: The system receives user input parameters, including the administrator username, password, host IP address 10.10.10.58, WinRM port number 5986, and baseline data of the historical user list generated during the last check. The system establishes a WinRMHTTPS connection with the target host through the WinRMWrapper class, verifies the validity of the server certificate (if it is a self-signed enterprise certificate, the imported CA certificate is used for verification), and completes authentication. If the WinRM connection fails, the system automatically attempts to establish a remote desktop connection via the RDP protocol (port 3389).

[0027] Step 2: The concurrent scheduling engine first obtains the target host's CPU core count (assuming 8 cores), current CPU utilization (assuming 25%), and memory utilization (assuming 40%) via the WinRM protocol. Based on the maximum concurrent thread count calculation formula: W = min([C / 3] × k, 5); W is the maximum concurrent thread count, C is the target host's CPU core count, [] indicates rounding down, and k is the load factor; The maximum number of concurrent threads was calculated to be 2. The system concurrently starts the log collection thread, and uses PowerShell commands to retrieve records with event IDs of 4624 (successful login), 4723 (attempted to change account password), and 4724 (attempted to reset account password) from the security log in different time periods. The thread pool is used to execute the log query tasks in parallel for different time periods.

[0028] Step 3: The main thread executes each security check item in sequence: Execute the command `secedit / export / cfgC:\temp\secpol.cfg` to export the system security policy configuration file. Use regular expressions to parse configuration items such as password complexity requirements, minimum password length, minimum password expiration time, maximum password expiration time, mandatory password history, account lockout threshold, and account lockout time, and compare them with the preset security baseline.

[0029] Execute the `netuserguest` command to obtain Guest account information and check if the Guest account is disabled.

[0030] The command `wmicuseraccountwhere"name='Administrator'"getname` checks whether the administrator account uses the default name "Administrator".

[0031] Check the User Account Control (UAC) level, Remote Desktop enabled status, and Network Level Authentication enabled status by reading the registry key HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System.

[0032] Check whether anonymous enumeration restrictions are enabled by reading the registry key HKLM:\SYSTEM\CurrentControlSet\Control\Lsa.

[0033] Execute the `netuser` command to obtain a full list of all users on the system, and then execute `netuser` on each user. <username>The command retrieves detailed user information, including home directory, last login time, and group affiliation, and uses the Get-Acl command to obtain the user's home directory permission configuration.

[0034] Filter out accounts that have not been logged in for nearly 90 days and accounts with empty passwords.

[0035] Step 4: The system performs an individual check on each user, generating a HuntWindows security check object for each user, which includes all check results and basic information for that user.

[0036] Step 5: After the log collection thread finishes execution, the system analyzes the acquired log records to identify risky behaviors such as high-frequency failed logins (≥5 consecutive failed login attempts), cross-account login attempts, logins outside of working hours, abnormal changes in login IP, abnormal geographical location, abnormal device fingerprints, abnormal login frequency, and abnormal privileged accounts, and adds the analysis results to the corresponding HuntWindows object.

[0037] Step 6: The system first verifies the integrity of the incoming historical baseline data using the SHA-256 hash value. After successful verification, it compares the currently acquired user list, home directory, local group, global group, and home directory permissions with the historical baseline data item by item to detect any changes to user home directories, home directory permissions, user groups, or user additions or deletions. When a change is detected, the system records the change details in the corresponding user's check results and sets the permission change risk item to False.

[0038] Step 7: The system starts an embedded account scanning task, using a thread pool to scan all disks on the target host in parallel. First, it traverses all disks, locating code directories containing keywords such as src, service, controller, and api, and the C:\Program Files installation directory. Then, it performs regular expression matching on the .py, .java, .c, and .js code files and .txt, .conf, .json, .yaml, .properties, and .sql configuration files in each directory; matching account name patterns (e.g., user(?:name)?\s [=:]、Username\s [=::]) and password field patterns (such as pass(?:word)?\s [=:]、Password\s [=::]); Performs three levels of false alarm filtering: Level 1 filters / / , # single-line comments and / The first level filters multi-line comments, the second level filters example values ​​containing test keywords such as "test", "example", "demo", and "123456", the third level filters if statement comment blocks and content in function documentation; finally, the filtered matching results are summarized and output to form an embedded account risk list.

[0039] Step 8: The system integrates all inspection results, including the HuntWindows security check result list, the user information list, and the embedded account risk list, serializes them into JSON format, and returns them to the caller. Simultaneously, the system automatically generates new baseline data from this inspection result, encrypts and stores it in the local database, and retains historical versions.

[0040] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.< / username>

Claims

1. An account security inspection system based on the RDP protocol, characterized in that, include: The WinRM remote execution engine is used to establish a remote connection with the target Windows host by encapsulating the WinRM protocol, execute PowerShell scripts or CMD commands and receive the return results. It supports the RDP protocol as an alternative remote connection method. When the WinRM service on the target host is not enabled, a remote desktop session is established through the RDP protocol to perform inspection tasks. The multi-dimensional security check module is used to perform multi-dimensional security checks on the target host, including password policy, account lockout policy, account status, permissions and configuration, logs and auditing. A cross-distribution compatibility mechanism is used to handle differences in security configuration paths and command outputs between different versions of Windows. The concurrent inspection engine is used to perform log analysis and embedded account scanning tasks in parallel using a multi-threaded concurrent architecture, and supports dynamically adjusting the number of concurrent threads based on the real-time load of the target host. An embedded account scanning module is used to scan hard-coded credentials in the target host file system, and it has a three-level false alarm filtering mechanism; The baseline comparison and permission change awareness module is used to compare the current inspection results with historical baseline data with integrity protection to identify abnormal changes in account information; The inspection results data model is used to serialize the inspection results into a structured JSON format for output.

2. The account security inspection system based on the RDP protocol according to claim 1, characterized in that, The WinRM remote execution engine manages connections and command execution uniformly through the WinRMWrapper class, supports both HTTP and HTTPS transmission protocols, enables server certificate verification by default, supports importing custom CA certificates, and does not require the installation of any proxy software on the target host.

3. The account security inspection system based on the RDP protocol according to claim 1, characterized in that, The multi-dimensional security inspection module includes the following inspection items: Password policy checks: password complexity requirements, minimum password length, minimum password expiration time, maximum password expiration time, and mandatory password history. Account lockout policy check: account lockout threshold, account lockout duration; Account status check: Guest account status, administrator account name, accounts that have not been used for a long time, and accounts with blank passwords; Permissions and configuration checks: User Account Control level, Remote Desktop enabled status, Network Level Authentication enabled status, Anonymous enumeration restrictions, User home directory permissions; Log and audit checks: Login audit event recording, abnormal login behavior analysis, and user login IP stability. Abnormal login behaviors include exceeding the limit for the number of failed login attempts, logging in outside of working hours, IP address changes, abnormal geographical location, abnormal device fingerprints, abnormal login frequency, and abnormal privileged accounts.

4. The account security inspection system based on the RDP protocol according to claim 1, characterized in that, The cross-distribution compatibility mechanism is implemented in the following ways: Use the common PowerShell commands Get-WmiObject and Get-ItemProperty to obtain system configuration; Differences in configuration file formats exported from different versions of secedit are handled through string parsing and regular expression matching; Perform a general keyword matching between Chinese and English on the output of the netuser command.

5. The account security inspection system based on the RDP protocol according to claim 1, characterized in that, The concurrent inspection engine uses threading.Thread to implement an independent thread for log analysis, and uses concurrent.futures.ThreadPoolExecutor to execute log time-segmented query tasks and embedded account scanning multi-directory tasks in parallel. The maximum number of concurrent threads is dynamically calculated based on the number of CPU cores of the target host and the real-time load.

6. The account security inspection system based on the RDP protocol according to claim 1, characterized in that, The formula for calculating the maximum number of concurrent threads is: W=min([C / 3]×k,5); Where W is the maximum number of concurrent threads, C is the number of CPU cores of the target host, [] indicates rounding down, and k is the load factor; the rules for determining the load factor k are as follows: When the target host's CPU utilization is less than 30% and memory utilization is less than 50%, k=1; When 30% ≤ CPU utilization < 60% and 50% ≤ memory utilization < 70%, k = 0.5; When CPU utilization is ≥60% or memory utilization is ≥70%, k=0.

2.

7. The account security inspection system based on the RDP protocol according to claim 1, characterized in that, The embedded account scanning module performs the scan through the following steps: Traverse all disks on the target host to locate the code directory containing the keywords src, service, controller, and api, as well as the C:\Program Files program installation directory; Perform regular expression matching on the .py, .java, .c, .js code files and .txt, .conf, .json, .yaml, .properties, .sql configuration files in each directory; Match username pattern and password field pattern; Perform a three-level false alarm filtering: the first level filters single-line and multi-line comments, the second level filters example values ​​containing test keywords, and the third level filters content in comment blocks and documentation. The file paths and matching content that contain both usernames and passwords and pass the filtering are summarized and output to form an embedded account risk list.

8. The account security inspection system based on the RDP protocol according to claim 1, characterized in that... The baseline comparison and permission change awareness module includes a baseline data management submodule, which realizes automatic baseline generation, version control, encrypted storage and integrity verification functions. The module compares the user list, home directory, local group, global group and home directory permissions in the current inspection results with the verified historical baseline data item by item, detects changes in user home directory, changes in home directory permissions, changes in user group additions or deletions, and records the change details and marks permission change risk items when changes are found.

9. The account security inspection system based on the RDP protocol according to claim 1, characterized in that, The inspection result data model defines a HuntWindows security inspection result object and a User information object, which includes Boolean results for each inspection item, details of permission changes, basic user information, and embedded account risk list fields.

Images