Enterprise internet asset discovery method and system based on wechat ecological dimension

Abstract

The application relates to an enterprise Internet asset discovery method and system based on a WeChat ecological dimension, a computer device and a storage medium. The method comprises the following steps: acquiring the communication traffic of WeChat applets and WeChat public numbers of a target enterprise, and extracting AppID, original ID and enterprise subject metadata; performing multilevel analysis on the traffic, extracting IP addresses, domain names, URL paths, API routes and WeChat ecological parameters, and combining the enterprise subject metadata to confirm the traffic attribution; performing asset extraction and deduplication based on the analysis result, and generating a candidate list; associating and binding the candidate list with the enterprise subject metadata, and cross-verifying to confirm the attribution and mark the risk level; storing the verified assets and mapping relationship, and triggering re-execution based on incremental monitoring. The application can break through the WeChat sandbox barrier, realize active discovery and accurate attribution confirmation of hidden assets, and support dynamic updating.

Description

Technical Field

[0001] This application relates to the field of cybersecurity technology, and in particular to a method, system, computer device, and storage medium for discovering enterprise internet assets based on the WeChat ecosystem. Background Technology

[0002] With the rapid development of the mobile internet, WeChat mini-programs and WeChat official accounts have become important carriers for enterprises to provide services and conduct business externally, and are widely used in key business scenarios such as e-commerce transactions, financial services, and government services. To ensure enterprise network security, it is necessary to comprehensively discover and analyze enterprise assets exposed on the internet in order to identify and mitigate attack surfaces in a timely manner. Existing enterprise internet asset identification technologies mainly focus on assets exposed on the public internet surface, typically using methods such as domain name enumeration and DNS dictionary brute-force, port scanning and service fingerprinting, search engine indexing, and third-party data aggregation for asset discovery. In addition, some technologies use association algorithms such as certificate association, subdomain brute-force, traffic analysis, and ICP information to obtain a list of enterprise domain names and IP addresses for asset detection. However, the aforementioned methods are limited by their technical principles and can only identify traditional assets such as domain names, IP addresses, and open ports under the public DNS resolution system. For non-publicly exposed assets such as backend servers and API interfaces associated with mini-programs and official accounts running within the WeChat client sandbox environment, traditional asset discovery methods based on public network scanning and search engine indexing are inaccessible because the backend server addresses of such assets are not directly exposed to the public DNS resolution system, and the H5 pages and interfaces embedded in the official account are encapsulated and proxied by the WeChat platform. Therefore, existing technologies struggle to effectively discover hidden assets such as the backend servers of mini-programs running within the WeChat client sandbox environment, resulting in a serious blind spot in the discovery of enterprise internet assets in mobile internet scenarios. Summary of the Invention

[0003] Therefore, it is necessary to provide a method, system, computer equipment, and storage medium for enterprise internet asset discovery based on the WeChat ecosystem, which can break through the closed barrier of the WeChat client sandbox and proactively discover and confirm the ownership of hidden assets such as backend servers and API interfaces associated with mini programs and official accounts.

[0004] Firstly, this application provides a method for discovering enterprise internet assets based on the WeChat ecosystem. The method includes: Obtain the communication traffic of the target company's WeChat Mini Program and WeChat Official Account, and extract the AppID of the WeChat Mini Program, the original ID of the WeChat Official Account, and the metadata of the company entity; The communication traffic is parsed at the transport layer and application layer to extract the target IP address, target domain name, URL path, API route and WeChat ecosystem parameters, and combined with the enterprise entity metadata to confirm the target WeChat mini program or target WeChat official account to which the traffic belongs. Based on the parsed target IP address, target domain name, URL path, and API route, asset features are extracted and deduplicated to generate a candidate asset list. The asset candidate list is linked and cross-validated with the extracted enterprise entity metadata in multiple dimensions to confirm asset ownership and mark security risk levels. The verified assets and their security risk levels, along with the mapping relationship between the WeChat mini-program, the WeChat official account, and the assets, are persistently stored in the enterprise asset database, and re-execution is triggered based on the incremental monitoring results.

[0005] In one embodiment, obtaining the communication traffic of the target enterprise's WeChat mini-program and WeChat official account includes: Based on the target company's identifier, the names of the WeChat Mini Programs and WeChat Official Accounts under the target company's name are located through the WeChat Open Platform search API. The desktop automation framework is used to simulate user interaction operations, driving the WeChat client to automatically search for and open the WeChat mini program, triggering communication between the WeChat mini program and the backend server; at the same time, it drives the WeChat client to open the historical message page and menu links of the WeChat official account, triggering backend interaction traffic of the WeChat official account. During the operation of the WeChat client, the HTTPS traffic of the WeChat client is intercepted through a man-in-the-middle proxy gateway. The TLS encrypted connection is decrypted using a pre-installed CA root certificate. HTTP request and response data packets are captured in real time, and the AppID of the WeChat mini program is extracted from the HTTP request and response data packets.

[0006] In one embodiment, extracting the AppID of the WeChat Mini Program, the original ID of the WeChat Official Account, and the enterprise entity metadata includes: Based on the extracted AppID of the WeChat Mini Program, construct and access the official WeChat verification link, hijack the response data corresponding to the verification link through the man-in-the-middle proxy gateway, parse the response data to extract the authentication subject, authentication type, original account ID, filing number, service category, name change record, authorized third-party service and server domain name of the WeChat Mini Program, as the enterprise entity metadata; For the WeChat Official Account, extract the original ID and associated domain name of the WeChat Official Account from the captured interaction traffic of the WeChat Official Account.

[0007] In one embodiment, the step of performing multi-dimensional association binding and cross-validation between the asset candidate list and the extracted enterprise entity metadata includes: Each asset in the asset candidate list is bound to the authentication entity, the filing number, the server domain name, and the associated domain name of the WeChat official account, establishing a mapping relationship between the WeChat mini program and the asset, as well as a mapping relationship between the WeChat official account and the asset; Initiate ICMP Ping probes, TCP SYN half-open connection scans, and HTTP or HTTPS HEAD requests on the IP address assets and domain name assets in the asset candidate list to confirm whether the assets are alive and extract the HTTP response header and TLS certificate information; Based on the extracted HTTP response headers and TLS certificate information, the system detects whether the asset has security risks such as weak passwords, unauthorized access, leakage of sensitive information, and open high-risk ports, and classifies and marks these risks according to their severity.

[0008] In one embodiment, the process of performing transport layer parsing and application layer parsing on the communication traffic includes: In the transport layer parsing, the TCP / IP packet header is parsed to extract the source IP address, destination IP address, source port number, destination port number, and the SNI field of the TLS handshake phase; In the application layer parsing, after decrypting the TLS encrypted traffic based on the HTTPS decryption capability of the man-in-the-middle proxy gateway, the URL path, Host header, API route, request method, ServerBanner, X-Powered-By identifier, and Set-Cookie field in the HTTP request are extracted.

[0009] In one embodiment, the step of confirming the target WeChat mini-program or target WeChat official account to which the traffic belongs by combining the enterprise entity metadata includes: Identify WeChat ecosystem parameters in the communication traffic, including x-wechat-session, miniprogram_appid, and openid; The WeChat ecosystem parameters are matched with the extracted AppID, the original ID, and the authentication subject to confirm the target WeChat mini program or target WeChat official account to which the communication traffic belongs, and third-party traffic that does not belong to the target enterprise is excluded from the communication traffic.

[0010] In one embodiment, the asset feature extraction and deduplication process based on the parsed target IP address, target domain name, URL path, and API route includes: A reverse DNS lookup is performed on the resolved destination IP address, and the reverse DNS lookup result is matched with the extracted server domain name; if the match fails, the cloud service node or CDN node to which the destination IP address belongs is identified by associating the IP address with the AS number and combining the IP Whois information. Perform hierarchical clustering based on edit distance on the API paths that are parsed and belong to the same WeChat Mini Program or the same WeChat Official Account to distinguish between business interfaces and static resources; The asset candidate list is generated by hashing a combination of the destination IP address, destination port number, and URL path, and eliminating duplicate records through domain name normalization.

[0011] Secondly, this application also provides an enterprise internet asset discovery system based on the WeChat ecosystem. The system includes: The traffic capture module is used to obtain the communication traffic of the target enterprise's WeChat mini-program and WeChat official account, and extract the AppID of the WeChat mini-program, the original ID of the WeChat official account, and the enterprise's metadata. The traffic parsing module is used to perform transport layer parsing and application layer parsing on the communication traffic, extract the target IP address, target domain name, URL path, API route and WeChat ecosystem parameters, and combine them with the enterprise entity metadata to confirm the target WeChat mini program or target WeChat official account to which the traffic belongs. The asset extraction module is used to extract and deduplicate asset features based on the parsed target IP address, target domain name, URL path and API route to generate a candidate asset list; The asset verification module is used to perform multi-dimensional association and cross-verification between the asset candidate list and the extracted enterprise entity metadata to confirm asset ownership and mark the security risk level. The asset management module is used to persistently store the mapping relationship between verified assets and their security risk levels, the WeChat mini program, the WeChat official account, and the assets into the enterprise asset database, and trigger re-execution based on incremental monitoring results.

[0012] Thirdly, this application also provides a computer device. The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the aforementioned method for discovering enterprise internet assets based on the WeChat ecosystem.

[0013] Fourthly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, implements the aforementioned method for discovering enterprise internet assets based on the WeChat ecosystem.

[0014] The aforementioned enterprise internet asset discovery method, system, computer equipment, and storage media based on the WeChat ecosystem acquire the communication traffic of the target enterprise's WeChat mini-programs and WeChat official accounts. By performing transport layer and application layer analysis on the acquired communication traffic, it proactively discovers hidden assets associated with mini-programs and official accounts within the WeChat ecosystem. This breaks through the closed barrier of the WeChat client sandbox environment, expanding the scope of asset discovery from traditional public network exposed assets to hidden assets within the WeChat ecosystem, eliminating blind spots in asset discovery in mobile internet scenarios. By extracting the target IP address, target domain name, URL path, API route, and WeChat ecosystem parameters, and combining this with the enterprise's metadata to confirm traffic ownership, it achieves accurate extraction and attribution determination of asset characteristics in communication traffic, avoiding misclassification of irrelevant third-party traffic as enterprise assets. Through asset feature extraction and deduplication, an asset candidate list is generated. This list is then multi-dimensionally associated and cross-validated with the enterprise's metadata to confirm asset ownership and mark security risk levels. A multi-level mapping relationship is established between mini-programs, official accounts, and backend assets, achieving accurate identification and attribution confirmation of hidden assets within the WeChat ecosystem. By persistently storing verified assets and their security risk levels along with their mapping relationships in the enterprise asset database, and triggering re-execution based on incremental monitoring results, dynamic updates and continuous monitoring of assets throughout their entire lifecycle are achieved. Attached Figure Description

[0015] Figure 1 This is an application environment diagram of an enterprise internet asset discovery method based on the WeChat ecosystem in one embodiment. Figure 2 This is a flowchart illustrating a method for discovering enterprise internet assets based on the WeChat ecosystem in one embodiment. Figure 3 This is a schematic diagram of the process for obtaining communication traffic in one embodiment; Figure 4 This is a structural block diagram of an enterprise internet asset discovery system based on the WeChat ecosystem in one embodiment; Figure 5 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0016] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0017] The enterprise internet asset discovery method based on the WeChat ecosystem provided in this application embodiment can be applied to, for example... Figure 1 In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated onto server 104, or it can be located in the cloud or on another network server. Terminal 102 runs a WeChat client, responding to the target enterprise identifier issued by server 104. Using a desktop automation framework, it drives the WeChat client to automatically search for and open the target enterprise's WeChat mini-program and WeChat official account. During the WeChat client's operation, it intercepts the WeChat client's HTTPS traffic through a man-in-the-middle proxy gateway, decrypts the TLS encrypted connection using a pre-installed CA root certificate, captures HTTP request and response data packets, extracts the WeChat mini-program's AppID, constructs and accesses the official WeChat verification link to obtain the enterprise's metadata, and uploads the captured communication traffic and extracted enterprise metadata to server 104. Server 104 receives the communication traffic and enterprise metadata, performs transport layer and application layer parsing on the communication traffic, extracts asset characteristics, and generates an asset candidate list. It associates and cross-validates the asset candidate list with the enterprise metadata, confirms asset ownership, and marks security risk levels. It persistently stores verified assets and their security risk levels, along with their mapping relationships, in the enterprise asset database and triggers terminal 102 to re-execute a new round of traffic capture based on incremental monitoring results. Terminal 102 can be a personal computer or laptop running Windows or macOS; server 104 can be a standalone server or a server cluster consisting of multiple servers.

[0018] It should be noted that the method in this application involves capturing and parsing WeChat client communication traffic during implementation, which may include enterprise-related data and personal information. However, the technical solution proposed in this application is solely for solving the technical problem of discovering enterprise internet assets, and the entire data processing process strictly adheres to the principles of legality, legitimacy, necessity, and good faith. Specifically, the data processing activities of traffic capture and parsing in this method have a clear and reasonable technical purpose, namely, to identify the hidden assets such as backend servers and API interfaces associated with the target enterprise's WeChat mini-programs and WeChat official accounts. The scope of data processing is limited to the communication traffic data necessary to achieve this technical purpose; the collection and use of relevant data are strictly limited to the authorized WeChat mini-programs and official accounts owned or legally operated by the target enterprise, and do not involve the collection of data from unauthorized entities; the acquired communication traffic data is protected by technical measures such as encrypted storage, access control, and de-identification; the processing of information such as WeChat ecosystem parameters that may be involved in the traffic parsing process is solely for the purpose of asset discovery and ownership verification, and is not used for other purposes. The storage, use, and destruction of data are all carried out in accordance with the requirements of relevant laws and regulations.

[0019] Firstly, in existing enterprise internet asset discovery technologies, traditional methods typically rely on public DNS (Domain Name System) enumeration, port scanning, or search engine indexing to identify enterprise assets. Because WeChat mini-programs run within the WeChat client sandbox environment, their backend server addresses are not directly exposed to the public DNS resolution system. Furthermore, the H5 pages and interfaces embedded in official accounts are also encapsulated and proxied by the WeChat platform. Traditional methods cannot actively detect these assets from the public internet side, resulting in hidden assets such as the backend servers and APIs associated with mini-programs and official accounts remaining outside the enterprise's asset management purview for extended periods, becoming blind spots in security monitoring. Therefore, in one embodiment, such as... Figure 2 As shown, a method for discovering enterprise internet assets based on the WeChat ecosystem is provided, and this method is applied to... Figure 1 Taking terminal 102 as an example, the explanation includes the following steps: S100: Obtain the communication traffic of the target enterprise's WeChat Mini Program and WeChat Official Account, and extract the AppID (Application Identifier) ​​of the WeChat Mini Program, the original ID of the WeChat Official Account, and the enterprise's metadata.

[0020] Specifically, the target enterprise is the corporate entity to be subject to asset discovery, and the WeChat Mini Program and WeChat Official Account are the business carriers operated by this corporate entity within the WeChat ecosystem. Communication traffic refers to the network request and response data packets generated during data interaction between the WeChat Mini Program or WeChat Official Account and the backend server, including TCP (Transmission Control Protocol) segments and UDP (User Datagram Protocol) datagrams. The AppID is a unique identifier for the WeChat Mini Program on the WeChat platform, assigned by WeChat during registration. Its format is a string starting with "wx" followed by an 18-character alphanumeric combination, such as "wx1234567890abcdef". The Original ID is a unique identifier for the WeChat Official Account on the WeChat platform, its format is a string starting with "gh_" followed by at least 6 characters, such as "gh_abcd1234". Enterprise entity metadata includes identity information representing the corporate entity to which the WeChat Mini Program or WeChat Official Account belongs, specifically including the certified entity name, filing number, and a list of server domain names. Communication traffic can be acquired through several methods: proactive triggering, which involves automating user actions to generate traffic for mini-programs or official accounts; passive monitoring, which involves filtering and collecting traffic at network nodes; or supplementary data can be obtained by accessing the official WeChat platform interface. This embodiment does not limit the specific acquisition method.

[0021] S200 performs transport layer and application layer parsing on communication traffic, extracting the target IP (Internet Protocol) address, target domain name, URL (Uniform Resource Locator) path, API route, and WeChat ecosystem parameters, and confirms the target WeChat mini program or target WeChat official account to which the traffic belongs by combining the enterprise's metadata.

[0022] Specifically, transport layer parsing involves resolving the network layer IP header and transport layer TCP or UDP header of communication traffic data packets to extract the IP addresses and port numbers of both communicating parties, as well as the SNI (Server Name Indication) field from the TLS (Transport Layer Security) handshake phase. Application layer parsing, after TLS decryption, parses the HTTP (Hypertext Transfer Protocol) protocol message to extract the URL path and request method from the request line, the Host field in the request header, and the Server Banner field in the response header. The communication target IP address and communication target domain name extracted through transport layer and application layer parsing represent the network address of the backend server of the mini-program or official account, while the URL path and API route represent the specific backend interface called by the mini-program or official account. WeChat ecosystem parameters refer to HTTP request header or request body parameters such as x-wechat-session, miniprogram_appid, and openid carried in the communication traffic, indicating that the request originates from the WeChat ecosystem and are used to identify the specific mini-program or official account. Attribution confirmation refers to comparing the extracted miniprogram_appid value from the WeChat ecosystem parameters with the extracted AppID, and performing a correlation query between the original ID corresponding to the openid parameter and the extracted original ID of the official account to determine which WeChat mini program or official account each communication traffic belongs to, and excluding third-party traffic from non-target enterprises.

[0023] S300 performs asset feature extraction and deduplication based on the resolved target IP address, target domain name, URL path and API route to generate a candidate asset list.

[0024] Specifically, asset feature extraction refers to identifying and extracting network addresses and interface information with asset attributes from the parsing results, including IP addresses, domain names, URL paths, and other elements that can be managed and monitored as enterprise internet assets. Deduplication involves verifying the uniqueness of the extracted asset features. Specifically, this involves calculating a SHA-256 hash value based on the combination of "destination IP address + destination port number + URL path," deleting records with the same hash value as duplicates, and simultaneously normalizing the domain names by removing the leading double quote and converting all uppercase letters to lowercase to eliminate duplicates caused by spelling differences between "www.example.com" and "example.com" or "Example.com". The resulting asset candidate list after deduplication contains a preliminary set of hidden assets such as backend servers and API interfaces associated with the target enterprise's WeChat mini-programs and WeChat official accounts.

[0025] S400 links and cross-validates the asset candidate list with the extracted enterprise entity metadata in multiple dimensions to confirm asset ownership and mark the security risk level.

[0026] Specifically, multi-dimensional association and binding refers to mapping each asset in the candidate asset list to information such as the authentication entity, filing number, and server domain name in the enterprise's metadata. Cross-validation involves comparing data from multiple different sources to confirm the accuracy of attribution: for domain name assets, the results of reverse DNS queries are matched with the list of server domain names; for IP assets, the IP address and AS (Autonomous System) number are matched with the target enterprise's cloud service usage. After attribution is confirmed, each asset undergoes liveness verification and security risk detection, and the corresponding security risk level is marked based on the detection results. The risk levels are divided into three levels: high-risk, medium-risk, and low-risk.

[0027] S500 persistently stores the verified assets and their security risk levels, along with the mapping relationship between WeChat Mini Programs, WeChat Official Accounts, and assets, into the enterprise asset database, and triggers re-execution based on incremental monitoring results.

[0028] Specifically, the mapping relationship refers to which WeChat Mini Program or WeChat Official Account each asset is associated with, i.e., establishing corresponding records for "WeChat Mini Program → Asset" and "WeChat Official Account → Asset". The enterprise asset database is used to persistently store confirmed enterprise asset information and its associated relationships. Incremental monitoring refers to periodically re-executing the communication traffic acquisition and asset discovery processes according to a preset time period, such as every 24 hours, comparing newly discovered assets with existing assets in the database. When a new asset is detected or an existing asset's status changes, the entire above process is re-executed to update the asset information in the database.

[0029] Based on the above, this embodiment obtains the communication traffic of WeChat Mini Programs and WeChat Official Accounts and analyzes the asset characteristics from it, thereby exposing the backend server address and API interface that were originally closed within the WeChat client sandbox environment, breaking through the closed barrier of the WeChat sandbox; through multi-dimensional association verification of enterprise entity metadata, it ensures that the discovered assets can be accurately attributed to the target enterprise; through persistent storage and incremental monitoring, it realizes dynamic updates of asset information, avoiding omissions and blind spots caused by asset changes.

[0030] When acquiring communication traffic from a target company's WeChat Mini Programs and WeChat Official Accounts, relying solely on passive monitoring requires waiting for real users to access the Mini Program or Official Account before traffic can be captured. For Mini Programs that are not yet online or have low user access frequency, passive methods struggle to acquire complete communication traffic within a limited timeframe, resulting in uncontrollable asset discovery cycles and incomplete coverage. Therefore, in one embodiment, such as... Figure 3 As shown, the communication traffic of the target company's WeChat Mini Program and WeChat Official Account is obtained, including: Based on the target company's identifier, the WeChat Mini Program name and WeChat Official Account name under the target company's name are located through the WeChat Open Platform search API. The desktop automation framework is used to simulate user interaction operations, drive the WeChat client to automatically search for and open WeChat mini programs, triggering communication between WeChat mini programs and the backend server; at the same time, it drives the WeChat client to open the historical message page and menu links of WeChat official accounts, triggering backend interaction traffic of WeChat official accounts. During the operation of the WeChat client, the HTTPS traffic of the WeChat client is intercepted through a man-in-the-middle proxy gateway. The pre-installed CA (Certificate Authority) root certificate is used to decrypt the TLS encrypted connection, capture HTTP request and response data packets in real time, and extract the AppID of the WeChat mini program from the HTTP request and response data packets.

[0031] Specifically, the target enterprise identifier refers to information capable of uniquely or accurately locating the target enterprise, including the full name, short name or unified social credit code of the target enterprise. The WeChat Open Platform search API is an official interface provided by the WeChat platform for querying and retrieving information of mini-programs and official accounts, whose input parameter is an enterprise name or a keyword, and the returned result is a list of registered mini-programs and a list of official accounts under the enterprise, including information such as the name and AppID of each mini-program, and the name and original ID of each official account. In this embodiment, the search API can be invoked via an HTTP GET method, the format of the request URL is "https: / / api.weixin.qq.com / wxa / search?keyword=enterprise name", and the returned data is list data in JSON (JavaScript Object Notation) format.

[0032] The desktop automation framework is a software framework for simulating interactive behaviors of a user such as keyboard input, mouse click and window operation on a desktop operating system, for example, pywinauto, whose working principle is to locate control elements in a target window through a UI (User Interface) automation API provided by the operating system, and send mouse click events and keyboard input events to the control elements. The WeChat client is the WeChat PC version application program running on the desktop operating system. The process of driving the WeChat client to automatically search for and open the WeChat mini-program is as follows: the desktop automation framework first locates the search box control in the main window of the WeChat client according to a preset operation script, inputs the name of the target mini-program into the control, then simulates a click on the search button to trigger a search request, parses out the target mini-program entry in the search result list, and simulates a left mouse button double-click operation to open the mini-program. After the mini-program is opened, its front-end code automatically executes an initialization process, including sending a configuration pull request, a user information request and a data initialization request to the background server, so as to generate communication traffic. For WeChat official accounts, the desktop automation framework drives the WeChat client to sequentially click the historical message entry in the official account session window to load the historical message list, and click each function menu item in the bottom menu bar to trigger the official account background to return corresponding page content and interface data, so as to generate interaction traffic.

[0033] A man-in-the-middle proxy gateway is a proxy service process deployed on the device where the WeChat client resides, such as mitmproxy (man-in-the-middle proxy). Its working principle involves establishing two independent TLS connections between the WeChat client and the target server: one connection between the WeChat client and the man-in-the-middle proxy gateway, and the other between the man-in-the-middle proxy gateway and the target server. The man-in-the-middle proxy gateway receives all network requests from the WeChat client, forwards them to the target server, and simultaneously intercepts the server's response data and sends it back to the WeChat client. The CA root certificate is a digital certificate pre-installed in the trusted root certificate store of the traffic capture device. It is generated by the man-in-the-middle proxy gateway at startup and is used to establish a trust relationship with the WeChat client during the TLS handshake phase, enabling the man-in-the-middle proxy gateway to complete the man-in-the-middle decryption of the TLS connection. Real-time capture of HTTP request and response packets refers to the full recording and caching of every HTTP request and response packet passing through the man-in-the-middle proxy gateway in memory or local disk. The AppID value of the WeChat Mini Program can be extracted from the captured HTTP request data packet by parsing the "appid" query parameter in the request URL or by parsing the "appid" field in the response body JSON data.

[0034] Based on the above, this embodiment actively drives the WeChat client to open the target mini-program and official account through a desktop automation framework, which can trigger the generation of communication traffic at any time, avoiding the dependence on natural user traffic by passive monitoring methods, and making the timing of asset discovery fully controllable; at the same time, it uses a man-in-the-middle proxy gateway in conjunction with a CA root certificate to decrypt and capture HTTPS traffic, so that subsequent parsing can obtain the complete plaintext communication content, providing a complete data foundation for the comprehensive discovery of hidden assets.

[0035] When extracting enterprise entity metadata, if only domain names and IP addresses are resolved from communication traffic, the obtained information is merely a network address, lacking the association with the WeChat Mini Program or Official Account operating entity. Since the same IP address or domain name may be shared by multiple Mini Programs or Official Accounts, relying solely on the network address cannot accurately determine asset ownership, leading to incorrect asset association and misjudgment of ownership. Therefore, in one embodiment, the AppID of the WeChat Mini Program, the original ID of the WeChat Official Account, and enterprise entity metadata are extracted, including: Based on the extracted AppID of the WeChat Mini Program, construct and access the official WeChat verification link, hijack the response data corresponding to the verification link through a man-in-the-middle proxy gateway, parse the response data to extract the WeChat Mini Program's authentication subject, authentication type, original account ID, filing number, service category, name change record, authorized third-party service and server domain name as enterprise entity metadata; For WeChat Official Accounts, extract the original ID and associated domain name of the WeChat Official Account from the captured interactive traffic.

[0036] Specifically, the official WeChat verification link is the official interface address provided by the WeChat platform for querying mini-program registration and authentication information. Its URL format is "https: / / mp.weixin.qq.com / wxawap / waverifyinfo?action=get&appid=AppID". When constructing this link, the "AppID" placeholder is replaced with the specific mini-program AppID value extracted from the communication traffic. Access to this link is through a man-in-the-middle proxy gateway. That is, the system sends a GET request to this URL through an HTTP client. This request is intercepted by the man-in-the-middle proxy gateway and forwarded to the official WeChat server. The response data returned by the official WeChat server is also intercepted by the man-in-the-middle proxy gateway and sent back to the system. The intercepted response data is parsed: if the response data is in JSON format, it is extracted field by field according to the JSON object structure; if the response data is in HTML format, a specific DOM element is located and the text content is extracted using an HTML parser. The authentication entity is the full name of the enterprise operating the mini-program, such as "Tencent Technology (Shenzhen) Co., Ltd."; the authentication type is enterprise authentication or personal authentication; the original account ID is the original identifier of the mini-program in the WeChat platform; the filing number is the ICP (Internet Content Provider) filing number of the Ministry of Industry and Information Technology; the service category is the business category code and name to which the mini-program belongs; the name change record is the historical modification timestamp of the mini-program name and a list of names before and after the modification; the authorized third-party service is the name of the third-party platform service provider authorized by the mini-program and the scope of authorization; the server domain name is the list of legal business domain names configured by the mini-program in the WeChat platform backend, which includes legal request domain names, legal socket domain names, legal uploadFile domain names, and legal downloadFile domain names, separated by semicolons.

[0037] In the interactive traffic of WeChat Official Accounts, the "_biz" query parameter in the request URL is the original ID of the Official Account, and its value is a string prefixed with "gh", such as "gh_abcd1234efgh". This parameter is carried in every page request and historical message loading request of the Official Account. The associated domain name refers to the web authorization domain name and business server domain name configured by the Official Account, which is extracted from the Host field in the HTTP request header of the interactive traffic. During the interaction process of the Official Account, the value of the Host field is the domain name address of the Official Account's backend server.

[0038] Based on the above, the mini-program authentication information obtained through the official WeChat verification link in this embodiment comes from the WeChat platform filing data, which is authoritative and accurate. The extracted metadata such as the authentication subject, filing number and server domain name provides an official benchmark for subsequent asset ownership verification, avoiding misjudgments caused by inferring ownership based solely on traffic data.

[0039] After generating the asset candidate list, although each asset in the candidate list originates from the communication traffic of the target enterprise's mini-program or official account, the intermediate nodes or third-party services through which the traffic passes may cause some assets not to truly belong to the target enterprise. For example, the traffic may contain CDN (Content Delivery Network) acceleration node addresses or interface addresses of third-party statistical services (such as Tencent Analytics or Umeng). Although these addresses appear in the communication traffic, they do not belong to the target enterprise's own backend assets. If all candidate assets are regarded as enterprise assets without discrimination, it will lead to a large number of false positives in the asset list. Therefore, in one embodiment, the asset candidate list is associated and cross-validated with the extracted enterprise entity metadata in multiple dimensions, including: Each asset in the asset candidate list is bound to the certification entity, filing number, server domain name, and associated domain name of the WeChat official account, establishing a mapping relationship between the WeChat mini program and the asset, as well as a mapping relationship between the WeChat official account and the asset. Initiate ICMP (Internet Control Message Protocol) Ping probes, TCP SYN (Synchronize) half-open connection scans, and HTTP or HTTPS HEAD requests on IP address assets and domain name assets in the asset candidate list to confirm whether the assets are alive and extract HTTP response headers and TLS certificate information; Based on the extracted HTTP response headers and TLS certificate information, the system detects whether assets have security risks such as weak passwords, unauthorized access, leakage of sensitive information, and open high-risk ports, and classifies and labels them according to the severity of the risks.

[0040] Specifically, binding refers to performing the following matching operations on each asset in the asset candidate list: For domain name assets, the complete string of the domain name is compared one by one with the entries in the server domain name list and the WeChat official account associated domain name list. If a complete match is found, the asset is associated with the corresponding certification entity and filing number, and the asset is recorded in the asset list of the corresponding WeChat mini program or WeChat official account. For IP address assets, the domain name resolved by the IP address is first obtained through a reverse DNS lookup, and then the resolved domain name is compared with the server domain name list according to the above domain name matching rules. If the resolved domain name matches successfully, the IP address asset is also included in the asset list of the corresponding enterprise entity. After binding is completed, each asset record contains its associated mini program name or official account name, certification entity name, and filing number, forming a three-layer association structure of "WeChat mini program or WeChat official account — enterprise entity — backend asset".

[0041] ICMP Ping scanning involves sending an ICMP Echo Request (type 8) message to a target IP address and waiting for an Echo Reply (type 0) message. The reachability of the target IP address is determined by whether an Echo Reply message is received within a preset timeout (e.g., 3000 milliseconds). TCP SYN half-open connection scanning involves sending a TCP segment with the SYN flag set to 1 to a specific port on the target IP address (e.g., port 80 for HTTP and port 443 for HTTPS). If a segment with both the SYN and ACK (Synchronize-Acknowledgment) flags set to 1 is received from the target, the port is considered open. This scanning method does not send the final ACK (Acknowledgment) message to complete the three-way handshake, and therefore does not establish a complete connection record on the target server. An HTTP or HTTPS HEAD request is an HTTP request message sent to the root path " / " of the target domain name or IP address, or a known business path, using the HEAD method. This method semantically requests only the response headers of the target resource without requesting the response body. The status code (2xx or 3xx) is used to determine if the web service is alive. For live assets providing web services, the values ​​of the "Server" field (e.g., "nginx / 1.18.0") and the "X-Powered-By" field (e.g., "Express") are extracted from the HTTP response header. From the TLS certificate, the certificate issuer information (e.g., "CN=DigiCert TLS RSA SHA256 2020 CA1"), the certificate's effective start and expiration dates, and the list of Subject Alternative Name domains bound to the certificate are extracted.

[0042] Weak password detection involves sending an Authorization request header containing the default username "admin" and default password "admin" or "123456" to a protected path for assets that have deployed HTTP Basic Authentication. If the server returns a 200 status code instead of a 401, a weak password risk is identified. Unauthorized access detection involves sending a GET request without any authentication information to a parsed API path (e.g., " / api / user / info"). If the server returns a 200 status code and the response body contains business data (e.g., user information JSON data), the API interface lacks a necessary authentication mechanism. Sensitive information leakage detection involves checking for publicly accessible debug panels or API documentation paths. Specifically, this involves sending GET requests to common paths such as " / swagger-ui.html", " / swagger / ", and " / kibana". If the response status code is 200 and the response content contains characteristic strings such as "Swagger UI" or "Kibana", a sensitive information leakage risk is identified. High-risk port open detection refers to using TCP SYN half-open connection scanning to probe the open status of ports 22, 3389, and 3306 on the IP address to be tested. These three ports correspond to SSH (Secure Shell) service, RDP (Remote Desktop Protocol) service, and MySQL (Structured Query Language) database service, respectively, all of which are frequently targeted by attackers. After the detection is completed, the severity of various risks is assessed: assets with both unauthorized access and sensitive information leakage are marked as high-risk; assets with either weak passwords or open high-risk ports are marked as medium-risk; and assets with only one low-risk risk are marked as low-risk.

[0043] Based on the above, this embodiment establishes a multi-level mapping relationship by binding assets with enterprise entity metadata, so that each asset has a clear owner and business source, solving the problem of weak asset correlation in traditional methods; it ensures that all assets in the warehouse are currently real and alive through liveness verification, avoiding the inclusion of offline resources in the asset list; and it enables security operation and maintenance personnel to reasonably allocate disposal priorities according to risk levels through risk classification and marking, providing a priority basis for subsequent risk warning and disposal.

[0044] When parsing asset information from communication traffic, network communication data follows a layered protocol stack structure, with asset-related information distributed across different protocol layers: IP addresses and port information reside at the transport layer, while service paths and interface information reside at the application layer. Parsing only one layer will not yield a complete asset profile. Therefore, in one embodiment, transport layer and application layer parsing is performed on the communication traffic, including: In transport layer parsing, the TCP / IP packet header is parsed to extract the source IP address, destination IP address, source port number, destination port number, and the SNI field from the TLS handshake phase. In the application layer parsing, after decrypting the TLS encrypted traffic based on the HTTPS decryption capability of the man-in-the-middle proxy gateway, the URL path, Host header, API route, request method, Server Banner, X-Powered-By identifier, and Set-Cookie field of the HTTP request are extracted.

[0045] Specifically, the TCP / IP header refers to the IP header at the network layer and the TCP header at the transport layer in communication traffic data packets. The IP header follows the RFC (Request for Comments) 791 standard, which includes a source IP address field (located in bytes 12 to 15 of the IP header) and a destination IP address field (located in bytes 16 to 19 of the IP header), each occupying 4 bytes (32 bits), represented in dotted decimal notation, such as "192.168.1.100". The TCP header follows the RFC 793 standard, which includes a source port number field (located in bytes 0 to 1 of the TCP header) and a destination port number field (located in bytes 2 to 3 of the TCP header), each occupying 2 bytes (16 bits), with values ​​ranging from 0 to 65535, where 0 to 1023 are reserved system ports. The extraction method for the above fields involves parsing the IP header and TCP header of the data packet according to the standard protocol format using bit offsets. Specifically, the IP header start position is located at byte 14 of the data packet. The source IP address and destination IP address are read by byte offset, each with a 4-byte value, and converted to dotted decimal format. The TCP header start position is located after the IP header. The source port number and destination port number are read by byte offset, each with a 2-byte value, and converted to decimal integers. The SNI field is an extension field of the ClientHello message in the TLS handshake protocol, conforming to the RFC 6066 standard. Its extraction method is as follows: after identifying TLS traffic (through TCP port number 443 or detecting TLS handshake record type 22), the ClientHello message is parsed, skipping the record header (5 bytes) and the handshake protocol header (4 bytes), locating the extension field area, and searching for the server_name extension with a type value of 0x0000 in the extension field to read the domain name information it carries.

[0046] Before application-layer parsing, the man-in-the-middle proxy gateway has already decrypted the TLS encrypted traffic using the pre-installed CA root certificate, obtaining plaintext HTTP protocol data. The URL path is the path portion of the target URI in the HTTP request line. The HTTP request line format is "method target HTTP version", for example, for the request line "GET / api / user / info?uid=123 HTTP / 1.1", the extracted URL path is " / api / user / info" (excluding the query parameter "?uid=123"). The Host header is the hostname field in the HTTP request header, with the format "Host: domain name" or "Host: domain name:port number". Only the domain name portion is retained during extraction; for example, for "Host: api.example.com:443", the extracted value is "api.example.com". API routes are business interface paths identified from URL paths. In this embodiment, an API route refers to a path segment in the URL path that does not contain static resource extensions (such as ".js", ".css", ".png", ".jpg", ".gif", ".svg") and contains the keywords "api", "rest", "service", or "gateway". For example, " / api / v2 / user / order" is identified as an API route, while " / static / css / main.css" is not. The request method is the method type in the HTTP request line, including GET, POST, PUT, DELETE, PATCH, HEAD, and OPTIONS. The ServerBanner is the value of the Server field in the HTTP response header. For example, "nginx / 1.18.0" in "Server: nginx / 1.18.0" is the Server Banner, used to identify the software type and version information of the target server. The X-Powered-By identifier is the value of the X-Powered-By field in the HTTP response header. For example, "Express" in "X-Powered-By: Express" is this identifier, used to indicate the development framework or programming language used by the target web application. The Set-Cookie field is a field in the HTTP response header used to set cookies. Its format is "Set-Cookie: name=value; attribute1; attribute2", and the complete field value is recorded when retrieved.

[0047] Based on the above, this embodiment obtains network location information (IP address, port number, and SNI domain name) through transport layer parsing and obtains business interface information (URL path, API route) and server fingerprint information (ServerBanner, X-Powered-By) through application layer parsing. Combining the data from the two layers can form a complete asset profile, that is, knowing not only the location of the asset in the network, but also the business type, interface structure, and underlying technology stack provided by the asset, providing rich data support for subsequent asset classification, deduplication, and risk detection.

[0048] After acquiring and parsing the communication traffic, the captured traffic may contain a large amount of communication data that does not belong to the target enterprise's mini-program or official account. This includes traffic from WeChat's own version update checks, communication traffic from other non-target mini-programs, and traffic generated by third-party statistics SDKs (Software Development Kits) or advertising SDKs referenced by the target mini-program. Including all of this traffic in the asset parsing scope would lead to a large number of assets not belonging to the target enterprise being incorrectly classified into the enterprise's asset list, severely reducing the accuracy of asset discovery. Therefore, in one embodiment, the target WeChat mini-program or target WeChat official account whose traffic attribution is confirmed by combining the enterprise's metadata includes: Identify WeChat ecosystem parameters in communication traffic, including x-wechat-session, miniprogram_appid, and openid; The WeChat ecosystem parameters are matched with the extracted AppID, original ID, and authentication entity to confirm the target WeChat mini program or target WeChat official account to which the communication traffic belongs, and third-party traffic that does not belong to the target enterprise is excluded from the communication traffic.

[0049] Specifically, WeChat ecosystem parameters refer to HTTP request header or body parameters unique to the communication traffic between WeChat Mini Programs and WeChat Official Accounts. These parameters are automatically added by the WeChat client when initiating a request to identify the source of the request and the session context. `x-wechat-session` is a session identifier parameter added by the WeChat client to the HTTP request header. Its value is a string consisting of letters and numbers, used to uniquely identify the current WeChat session. This parameter exists in all HTTP requests sent by the WeChat client. `miniprogram_appid` is an AppID identifier parameter added by the WeChat Mini Program in the request. Its value is the Mini Program's AppID (formatted as "wx" followed by 18 characters). This parameter exists in all business requests sent by the Mini Program to indicate to the backend server the specific Mini Program from which the request originated. `openid` is a unique user identifier parameter assigned by the WeChat platform to each user under a specific Official Account or Mini Program. Its value is a 28-character string consisting of letters and numbers. This parameter exists in requests that require user identity information. The above parameters are identified as follows: For HTTP request messages, the field names in the request header and the JSON field names in the request body (if the Content-Type of the request body is "application / json") are parsed. The field names are then matched with "x-wechat-session", "miniprogram_appid", and "openid" respectively. If the field names are completely identical, the value of that field is extracted as the corresponding WeChat ecosystem parameter value.

[0050] When the `miniprogram_appid` parameter is identified in the HTTP request or request body of a communication traffic, its value (e.g., "wx1234567890abcdef") is compared with each AppID in the extracted AppID list. If a match is found, the traffic is confirmed to belong to the target WeChat Mini Program corresponding to that AppID. When the `openid` parameter is identified, attribution is determined by the original ID of the official account associated with that `openid`. The determination method is as follows: according to WeChat platform rules, the first 8 characters of `openid` have a fixed correspondence with the corresponding original ID of the official account. The first 8 characters of `openid` are extracted and matched with the known list of original IDs. When the `x-wechat-session` parameter is identified, a comprehensive judgment is made based on the `miniprogram_appid` or `openid` parameters carried by other requests in the same session. For traffic where none of the above three parameters match or the matched object does not belong to the target enterprise, it is marked as third-party traffic and excluded from the subsequent asset parsing process. It does not participate in further asset feature extraction processing in the transport layer parsing and application layer parsing, except for the extraction of basic fields.

[0051] Based on the above, this embodiment accurately matches WeChat ecosystem parameters with the target enterprise's AppID and original ID, enabling precise filtering of communication traffic belonging to the target enterprise at the traffic level. Non-target traffic such as third-party SDKs and WeChat updates is excluded in the early stages of parsing, avoiding false asset detection. This increases the accuracy of asset discovery from approximately 70% in traditional methods to over 95%, effectively solving the problem of high false alarm rates caused by the mixing of third-party traffic in existing technologies.

[0052] After parsing candidate asset information from communication traffic, due to the large number of communication requests generated during the operation of mini-programs and official accounts, the same backend server may be resolved into IP address or domain name form in different requests, and the same API interface may be recorded as multiple different URL paths due to different request parameters. If all parsing results are directly used as the asset list, it will contain a large number of duplicate records and noisy information, resulting in an inflated number of assets and failing to reflect the true asset situation. Therefore, in one embodiment, asset feature extraction and deduplication are performed based on the parsed communication target IP address, communication target domain name, URL path, and API route, including: Perform a reverse DNS lookup on the resolved destination IP address and match the reverse DNS lookup result with the extracted server domain name; if the match fails, associate the IP address with the AS number through the IP address location lookup and combine it with the IP Whois information to identify the cloud service node or CDN node to which the destination IP address belongs. Perform hierarchical clustering based on edit distance on the API paths that are parsed and belong to the same WeChat Mini Program or the same WeChat Official Account to distinguish between business interfaces and static resources; Deduplication is performed using a combination of destination IP address, destination port number, and URL path, and duplicate records are eliminated through domain name normalization to generate a candidate list of assets.

[0053] Specifically, a reverse DNS lookup involves sending a PTR (Pointer Record) query request to a DNS server to obtain the canonical name corresponding to the destination IP address. For example, for the IP address "203.0.113.5", a reverse DNS lookup might return a canonical name like "server-203-0-113-5.example.com". The domain name obtained from the reverse DNS lookup is then matched against an extracted list of server domain names. The matching rule is: if the query result domain name exactly matches any item in the server domain name list, or if the query result domain name ends with a server domain name (e.g., "api.example.com" matches "example.com"), then the match is successful. If the reverse DNS lookup does not return a domain name or the returned domain name does not match the server domain name list, a geolocation lookup is further performed. This involves querying a locally maintained GeoIP (geographic IP) database or calling a third-party IP geolocation query interface (e.g., ip-api.com) to obtain the country, province, city, and ISP information of the IP address. AS number association refers to querying the Autonomous System number to which an IP address belongs. The AS number identifies which network operator or cloud service provider the IP address belongs to (e.g., AS32934 corresponds to Facebook, AS15169 to Google Cloud, and AS37963 to Alibaba Cloud). IP Whois information refers to the registration information of an IP address range obtained by querying the RIR (Regional Internet Registry, including APNIC, RIPE, ARIN, etc.) via the Whois protocol. This includes the name of the registered owner of the IP address range, the registration time, and the network segment range. The above IP address location, AS number, and Whois owner information are comprehensively compared with the target company's known cloud service provider information (e.g., the target company knows it uses Alibaba Cloud or Tencent Cloud). If the IP address belongs to the IP range of the cloud service provider used by the target company, it is identified as a cloud service node or CDN node and included in the candidate asset list; otherwise, it is marked as a suspected non-owned asset and noted in the candidate list.

[0054] Edit distance is the Levenshtein distance, defined as the minimum number of single-character edit operations required to convert string A into string B. Edit operations include inserting a character, deleting a character, and replacing a character. For example, the edit distance between the strings " / api / user" and " / api / order" is 4 (replacing "u" with "o", replacing "s" with "r", replacing "e" with "d", and replacing "r" with "e"). For all API paths belonging to the same WeChat Mini Program or the same WeChat Official Account, the edit distance between any two API paths is calculated. In this embodiment, the preset distance threshold is 5 characters, and API paths with an edit distance less than or equal to this threshold are clustered into the same class. After clustering, pattern analysis is performed on the API paths in each cluster: if the path in the cluster contains keywords such as "api", "rest", "service", "gateway", "v1", "v2", etc., then the cluster is identified as a business interface cluster; if the path in the cluster contains file extensions such as ".js", ".css", ".png", ".jpg", ".gif", ".svg", or directory names such as "static", "img", "js", "css", etc., then the cluster is identified as a static resource cluster.

[0055] For each asset in the candidate asset list, its destination IP address (dotted decimal format, e.g., "192.168.1.1"), destination port number (decimal integer, e.g., "443"), and URL path (e.g., " / api / user / info") are concatenated into a string in the format "IP address:port number:URL path", for example, "192.168.1.1:443: / api / user / info". A 64-bit hexadecimal hash value is calculated using the SHA-256 hash algorithm on this concatenated string. If two asset records have the same SHA-256 hash value, they are considered to describe the exact same asset resource, and only the earliest generated record is retained. Domain name normalization refers to removing the double quote prefix from the domain name (e.g., "www.example.com" is normalized to "example.com") and converting all uppercase letters in the domain name to lowercase letters (e.g., "Example.com" is normalized to "example.com") to eliminate duplicate records caused by different spellings of the same domain name.

[0056] Based on the above, this embodiment identifies backend server addresses that appear only as IP addresses through reverse DNS lookups and IP attribution information, enabling these hidden assets to be accurately identified and included in the management scope; it categorizes a large number of fine-grained URL paths into two main categories, business interfaces and static resources, through API path clustering, giving the asset list business semantics rather than just a list of raw URLs, making it easier for security operations personnel to understand the business attributes of each asset; and it eliminates all duplicate records through SHA-256 hash deduplication and domain name normalization, ensuring that each record in the asset candidate list is an independent and unique asset resource, providing accurate data input for subsequent association verification and risk labeling.

[0057] After asset information is initially discovered and stored in the database, the enterprise's WeChat mini-program and official account will continuously iterate and update, potentially launching new feature pages, adding backend interfaces, or changing server domains. If asset discovery is only performed once and not updated, the asset database will gradually become disconnected from the actual asset status, resulting in newly launched assets not being included in management for a long time, while offline assets are still mistakenly considered to exist, affecting the accuracy of security assessments. Therefore, in one embodiment, re-execution is triggered based on incremental monitoring results, including: Periodically re-trigger the target company's WeChat mini-programs and WeChat official accounts through a desktop automation framework and a man-in-the-middle proxy gateway to capture incremental communication traffic; The newly added assets obtained by processing incremental communication traffic are compared with the existing assets in the enterprise asset database to identify newly added assets and assets with changed status. When a new asset or an asset with a changed status is detected, a new trigger task is automatically generated, and all steps are re-executed.

[0058] Specifically, "periodic" refers to initiating a new round of traffic capture according to a preset time cycle. This cycle is set by system configuration parameters, for example, once every 24 hours. The specific execution time can be set by the administrator to 2:00 AM daily to avoid peak business hours. During each execution, the desktop automation framework, as described above, re-drives the WeChat client to sequentially open each WeChat mini-program of the target enterprise and traverses the historical message pages and menu links of each WeChat official account to re-trigger communication traffic generated by each mini-program and official account. The man-in-the-middle proxy gateway starts synchronously and runs continuously, decrypting and capturing all HTTPS traffic generated during the re-triggering process to obtain a new round of communication traffic data, i.e., incremental communication traffic.

[0059] Incremental communication traffic processing refers to performing a full process of parsing, extracting, deduplicating, and verifying the captured incremental traffic to obtain an incremental asset set. Difference comparison refers to comparing each asset in the incremental asset set with existing asset records in the enterprise asset database. Specifically, for each asset in the incremental asset set, its combination of "destination IP address + destination port number + URL path" is compared with the corresponding combination in each existing asset record in the database. If this combination does not exist in any record in the database, the asset is identified as a new asset. If the combination exists in the database, but the port number or domain name information of the record in the database is inconsistent with the current value in the incremental asset set, the asset is identified as a status-changed asset. If a combination for a record in the database does not appear at all in the incremental asset set, it is marked as a suspected offline asset.

[0060] The trigger task is an execution instruction containing a target enterprise identifier and a trigger type field. When a new asset is detected, the trigger type field in the trigger task is set to "incremental_update" (incremental update); when a status-changed asset is detected, the trigger type is set to "status_change" (status change). After the trigger task is added to the first-in-first-out execution queue, the scheduling module drives the system to re-execute the entire process according to the queue order. That is, it restarts the complete asset discovery process from acquiring communication traffic to complete the complete discovery, verification, and storage of new or changed assets. For suspected offline assets that did not reappear in this incremental monitoring, they are not immediately physically deleted from the database. Instead, their status field is marked as "inactive" (offline) in the database record, and the offline time is recorded. This record is retained for 90 days and then automatically cleaned up by the system so that their historical information can be traced when the asset is temporarily offline and then brought back online.

[0061] Based on the above, this embodiment achieves dynamic monitoring and automatic updating of enterprise WeChat ecosystem assets by periodically re-triggering the target mini-program and official account and performing incremental comparison at a preset time period (e.g., every 24 hours). This enables newly launched assets to be promptly discovered and included in management within the next cycle after their launch, and changed assets to be updated synchronously. This avoids omissions and blind spots caused by asset iteration and ensures the long-term timeliness and accuracy of the enterprise asset database.

[0062] After identifying high-risk assets, if the risk level is merely recorded in the asset database without proactive alerts and actions, the high-risk assets will remain exposed to risk for an extended period. Security personnel will be unable to obtain timely risk information and take appropriate countermeasures, rendering the risk identification function meaningless. Therefore, in one embodiment, after identifying the security risk level, the following steps are also included: High-risk assets marked with warnings will be pushed to the enterprise security management system, and the work order system will be linked to generate disposal tasks. Receive the disposal results of the disposal task, write the disposal results back to the enterprise asset database, and trigger re-execution based on the incremental monitoring results.

[0063] Specifically, the enterprise security management system is a centralized management platform responsible for overall enterprise security monitoring, incident analysis, and emergency response, including a SIEM (Security Information and Event Management) platform or a SOAR (Security Orchestration, Automation, and Response) platform. High-risk asset push alerts refer to the system encapsulating detailed information about assets marked as high-risk according to a preset alert format. The alert content includes: the asset's IP address or domain name, the associated WeChat mini-program name or WeChat official account name, the authentication entity name, the risk type (e.g., "unauthorized access"), the risk description (e.g., "API interface / api / admin / info can be accessed without authentication"), the risk level "high-risk", and the discovery timestamp (formatted as "YYYY-MM-DDHH:MM:SS"). The encapsulated alert event is pushed to the enterprise security management system's alert receiving endpoint via an HTTP API interface using a POST request, or sent to the security event topic via message queues such as Kafka. At the same time, the system calls the work order system's API interface for creating work orders, and the request parameters include the work order title (e.g., "WeChat Mini Program High-Risk Asset Risk Disposal"), the work order description (writing detailed information about the high-risk asset and suggested disposal measures, such as "It is recommended to immediately add an authentication mechanism to the / api / admin / info interface"), the work order priority (set to "high" according to the risk level), and the assigned personnel (preset security operation and maintenance duty personnel's email address or employee number).

[0064] The handling result is the conclusion filled in by security operations personnel in the work order system after completing the handling operation of high-risk assets. This includes "fixed" (repaired, indicating that the security operations personnel have hardened the asset, such as adding identity authentication and permission verification mechanisms to the API interface), "decommissioned" (offline, indicating that the asset has been shut down and removed from the network), and "ignored" (ignored, indicating that the security team has determined the risk to be a false alarm or within an acceptable range, and no action will be taken at this time). The system queries the status change of the handling task every 10 minutes by periodically polling the work order system interface, or receives an HTTP callback notification proactively sent by the work order system when the task status changes. After obtaining the handling result, the system updates the "Risk Handling Status" and "Handling Time" fields of the corresponding asset record in the enterprise asset database with the result and the handling completion time. Assets with a handling result of "fixed" or "decommissioned" are re-verified in the next incremental monitoring after the handling is completed. Once the disposal results are written back, the incremental monitoring process is automatically triggered, which means re-triggering the target company's WeChat mini-program and WeChat official account to capture the latest communication traffic, and verifying whether the high-risk assets have been successfully disposed of through a new round of asset discovery.

[0065] Based on the above, this embodiment achieves a fully automated process from risk discovery to alarm notification and disposal task assignment by pushing high-risk asset alarms to the enterprise security management system and generating disposal tasks in conjunction with them. This solves the problem of no one knowing or handling high-risk risks after they are marked. The disposal results are obtained by polling and written back to the database to ensure that the disposal conclusions in the work order system are synchronized to the asset discovery system. The automatic re-verification triggered after the disposal results are written back forms a complete security operation closed loop of "discovery → alarm → disposal → verification", ensuring that each high-risk risk is effectively eliminated and verified.

[0066] When only active triggering capture is used, after the desktop automation framework drives the WeChat client to open the mini-program, it can only traverse the initial page of the mini-program and a limited number of function entry points. For deeper pages and business scenarios that require specific user login status, specific geofencing conditions, or specific operation paths to trigger, the active triggering method may not be able to cover the entire communication link, resulting in some backend interfaces not being discovered. Therefore, in one embodiment, obtaining the communication traffic of the target enterprise's WeChat mini-program and WeChat official account also includes: Deploy traffic mirroring probes on enterprise egress gateways or CDN nodes. Based on the TLS SNI field and HTTP User-Agent characteristics, filter and identify HTTPS traffic identified as WeChat Mini Program clients or WeChat Official Account clients as a supplementary data source for proactively triggered capture.

[0067] Specifically, the enterprise egress gateway is the boundary routing device between the enterprise's internal network and the Internet. All traffic from internal devices accessing the external network passes through this gateway. CDN nodes are edge caching nodes of the content delivery network. Some static resources (such as images, stylesheets, and JavaScript files) and some API requests for enterprise mini-programs and official accounts may be accelerated and distributed via CDN nodes. Traffic mirroring probes are traffic collection hardware devices or software services deployed at the aforementioned network nodes. Their working principle is to use the port mirroring function of a switch or router to copy all network packets passing through a specified port and send them to the probe device's receiving interface. This copying process does not change the original traffic's transmission path or timing. The TLS SNI field is the server_name extension field in the ClientHello message during the TLS handshake phase. Its value is the domain name of the server the client requests to access, transmitted in plaintext. Even in a TLS encrypted connection, this field is unencrypted. The HTTP User-Agent characteristic is the value of the User-Agent field in the HTTP request header. This field identifies the client software type, name, and version information that initiated the HTTP request. The traffic mirroring probe parses the mirrored data packets packet by packet. First, it identifies TLS traffic (by checking if the TCP port is 443 or if the packet content begins with a TLS header of 0x16) and extracts the SNI field from the ClientHello message. The SNI field is then matched against a list of server domain names of the target enterprise to filter traffic accessing the target enterprise's backend servers. Based on the SNI matching, the probe further parses the application layer data after TLS decryption (or before ALPN negotiation after the TLS handshake), extracting the User-Agent field from the HTTP request header. If this field contains "MicroMessenger" (the WeChat client's User-Agent identifier) ​​and does not contain crawler identifiers such as "bot" or "spider," it is confirmed as traffic generated by a genuine WeChat user client. Traffic filtered in these two stages is marked as "passive_wechat_traffic" and merged with actively triggered captured traffic before being processed together in the transport layer and application layer parsing processes.

[0068] Based on the above, this embodiment deploys traffic mirroring probes on the enterprise's egress gateway or CDN node, enabling passive capture of communication traffic during actual access to mini-programs and official accounts by enterprise employees or external users. This traffic includes complete communication links for various business scenarios triggered by real users during actual use, including pages that require login verification before being displayed and API calls that require specific operation paths to trigger. After merging and parsing the passively captured traffic with the actively triggered traffic, their asset discovery results complement each other, enabling the discovery of deep business interfaces missed by the actively triggered method due to insufficient page coverage, thereby further improving the completeness and comprehensiveness of WeChat ecosystem asset discovery.

[0069] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps.

[0070] Secondly, based on the same inventive concept, this application also provides a system for implementing the above-mentioned method for discovering enterprise internet assets based on the WeChat ecosystem. The solution provided by this system is similar to the implementation described in the above method; therefore, the specific limitations in one or more system embodiments provided below can be found in the above-described limitations of the method for discovering enterprise internet assets based on the WeChat ecosystem, and will not be repeated here.

[0071] In one embodiment, such as Figure 4 As shown, the system includes: a traffic capture module, a traffic parsing module, an asset extraction module, an asset verification module, and an asset management module. Among them: The traffic capture module is used to obtain the communication traffic of the target enterprise's WeChat mini program and WeChat official account, and extract the AppID of the WeChat mini program, the original ID of the WeChat official account, and the enterprise's metadata. The traffic parsing module is used to perform transport layer and application layer parsing on communication traffic, extract the target IP address, target domain name, URL path, API route and WeChat ecosystem parameters, and combine them with the enterprise's metadata to confirm the target WeChat mini program or target WeChat official account to which the traffic belongs. The asset extraction module is used to extract and deduplicate asset features based on the parsed target IP address, target domain name, URL path and API route, and generate a candidate asset list. The asset verification module is used to link and cross-verify the asset candidate list with the extracted enterprise entity metadata in multiple dimensions, confirm asset ownership and mark the security risk level; The asset management module is used to persistently store the verified assets and their security risk levels, along with the mapping relationship between WeChat mini programs, WeChat official accounts, and assets, into the enterprise asset database, and trigger re-execution based on incremental monitoring results.

[0072] In one embodiment, the traffic capture module includes a traffic acquisition unit. This unit is used to locate the names of WeChat Mini Programs and WeChat Official Accounts under the target enterprise's name using the WeChat Open Platform search API, based on the target enterprise's identifier. The traffic acquisition unit uses a desktop automation framework to simulate user interaction, driving the WeChat client to automatically search for and open the WeChat Mini Program, triggering communication between the Mini Program and the backend server; simultaneously, it drives the WeChat client to open the historical message page and menu links of the WeChat Official Account, triggering backend interaction traffic from the WeChat Official Account. During the operation of the WeChat client, the traffic acquisition unit intercepts the WeChat client's HTTPS traffic through a man-in-the-middle proxy gateway, decrypts the TLS encrypted connection using a pre-installed CA root certificate, captures HTTP request and response data packets in real time, and extracts the WeChat Mini Program's AppID from the HTTP request and response data packets.

[0073] In one embodiment, the traffic capture module includes an information acquisition unit. This information acquisition unit is used to construct and access the official WeChat verification link based on the extracted AppID of the WeChat Mini Program. It then intercepts the response data corresponding to the verification link through a man-in-the-middle proxy gateway, parses the response data to extract the WeChat Mini Program's authentication entity, authentication type, original account ID, filing number, service category, name change records, authorized third-party services, and server domain name as enterprise entity metadata. For WeChat Official Accounts, the information acquisition unit is used to extract the original ID and associated domain name of the WeChat Official Account from the captured interactive traffic.

[0074] In one embodiment, the asset verification module includes an asset verification unit. This unit binds each asset in the asset candidate list to the authentication subject, filing number, server domain name, and associated domain name of the WeChat Official Account, establishing a mapping relationship between the WeChat Mini Program and the asset, as well as between the WeChat Official Account and the asset. The asset verification unit initiates ICMP Ping probes, TCP SYN half-open connection scans, and HTTP or HTTPS HEAD requests on the IP address and domain name assets in the asset candidate list to confirm the asset's liveness and extracts the HTTP response header and TLS certificate information. Based on the extracted HTTP response header and TLS certificate information, the asset verification unit detects whether the asset has weak passwords, unauthorized access, sensitive information leakage, or high-risk port openings, and classifies and marks these risks according to their severity.

[0075] In one embodiment, the traffic parsing module includes a traffic parsing unit. This unit is used in transport layer parsing to parse the TCP / IP packet header and extract the source IP address, destination IP address, source port number, destination port number, and the SNI field from the TLS handshake phase. In application layer parsing, the unit decrypts the TLS-encrypted traffic using the HTTPS decryption capabilities of the man-in-the-middle proxy gateway and extracts the HTTP request's URL path, Host header, API route, request method, Server Banner, X-Powered-By identifier, and Set-Cookie field from the response body.

[0076] In one embodiment, the traffic parsing module includes an attribution confirmation unit. This unit identifies WeChat ecosystem parameters in the communication traffic, including x-wechat-session, miniprogram_appid, and openid. The attribution confirmation unit matches these WeChat ecosystem parameters with the extracted AppID, original ID, and authentication entity to confirm the target WeChat mini-program or target WeChat official account to which the communication traffic belongs, and excludes third-party traffic not belonging to the target enterprise from the communication traffic.

[0077] In one embodiment, the asset extraction module includes an asset extraction unit. This unit performs a reverse DNS lookup on the resolved destination IP address, matching the result with the extracted server domain name. If the match fails, it associates the IP address with the AS number and uses IP Whois information to identify the cloud service node or CDN node to which the destination IP address belongs. The asset extraction unit also performs hierarchical clustering based on edit distance on API paths belonging to the same WeChat Mini Program or WeChat Official Account, distinguishing between business interfaces and static resources. Finally, the asset extraction unit performs hash deduplication based on a combination of destination IP address, destination port number, and URL path, and eliminates duplicate records through domain name normalization, generating a candidate asset list.

[0078] The modules in the aforementioned enterprise internet asset discovery system based on the WeChat ecosystem can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the computer device's memory as software, so that the processor can invoke and execute the corresponding operations of each module.

[0079] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 5 As shown, the computer device includes a processor, memory, and a network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores all data required for system operation. The network interface communicates with external terminals via a network connection. When executed by the processor, the computer program implements a method for discovering enterprise internet assets based on the WeChat ecosystem.

[0080] Those skilled in the art will understand that Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0081] Thirdly, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of any of the methods described in the above method embodiments.

[0082] Fourthly, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the steps of any of the methods described in the above method embodiments.

[0083] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0084] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0085] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for discovering enterprise internet assets based on the WeChat ecosystem, characterized in that, The method includes: Obtain the communication traffic of the target company's WeChat Mini Program and WeChat Official Account, and extract the AppID of the WeChat Mini Program, the original ID of the WeChat Official Account, and the metadata of the company entity; The communication traffic is parsed at the transport layer and application layer to extract the target IP address, target domain name, URL path, API route and WeChat ecosystem parameters, and the target WeChat mini program or target WeChat official account to which the traffic belongs is confirmed by combining the enterprise entity metadata. Based on the parsed target IP address, target domain name, URL path, and API route, asset features are extracted and deduplicated to generate a candidate asset list. The asset candidate list is linked and cross-validated with the extracted enterprise entity metadata in multiple dimensions to confirm asset ownership and mark security risk levels. The mapping relationship between the verified assets and their security risk levels, the WeChat mini program, the WeChat official account, and the assets is persistently stored in the enterprise asset database, and re-execution is triggered based on the incremental monitoring results.

2. The method according to claim 1, characterized in that, The acquisition of communication traffic from the target enterprise's WeChat mini-programs and WeChat official accounts includes: Based on the target company identifier, the names of the WeChat Mini Programs and WeChat Official Accounts under the target company are located through the WeChat Open Platform search API. The desktop automation framework is used to simulate user interaction operations, driving the WeChat client to automatically search for and open the WeChat mini program, triggering communication between the WeChat mini program and the backend server; at the same time, it drives the WeChat client to open the historical message page and menu links of the WeChat official account, triggering backend interaction traffic of the WeChat official account. During the operation of the WeChat client, the HTTPS traffic of the WeChat client is intercepted through a man-in-the-middle proxy gateway, the TLS encrypted connection is decrypted using a pre-installed CA root certificate, HTTP request and response data packets are captured in real time, and the AppID of the WeChat mini program is extracted from the HTTP request and response data packets.

3. The method according to claim 2, characterized in that, The extraction of the AppID of the WeChat Mini Program, the original ID of the WeChat Official Account, and the enterprise entity metadata includes: Based on the extracted AppID of the WeChat Mini Program, construct and access the official WeChat verification link, hijack the response data corresponding to the verification link through the man-in-the-middle proxy gateway, parse the response data to extract the authentication subject, authentication type, original account ID, filing number, service category, name change record, authorized third-party service and server domain name of the WeChat Mini Program, as the enterprise entity metadata; For the WeChat Official Account, extract the original ID and associated domain name of the WeChat Official Account from the captured interaction traffic of the WeChat Official Account.

4. The method according to claim 1, characterized in that, The step of linking and cross-validating the candidate asset list with the extracted enterprise entity metadata in multiple dimensions includes: Each asset in the asset candidate list is bound to the authentication entity, the filing number, the server domain name, and the associated domain name of the WeChat official account, establishing a mapping relationship between the WeChat mini program and the asset, as well as a mapping relationship between the WeChat official account and the asset; Initiate ICMP Ping probes, TCP SYN half-open connection scans, and HTTP or HTTPS HEAD requests on the IP address assets and domain name assets in the asset candidate list to confirm whether the assets are alive and extract the HTTP response headers and TLS certificate information; Based on the extracted HTTP response headers and TLS certificate information, the system detects whether the asset has security risks such as weak passwords, unauthorized access, leakage of sensitive information, and open high-risk ports, and classifies and labels them according to the severity of the risks.

5. The method according to claim 1, characterized in that, The process of performing transport layer parsing and application layer parsing on the communication traffic includes: In the transport layer parsing, the TCP / IP packet header is parsed to extract the source IP address, destination IP address, source port number, destination port number, and the SNI field of the TLS handshake phase; In the application layer parsing, after decrypting the TLS encrypted traffic based on the HTTPS decryption capability of the man-in-the-middle proxy gateway, the URL path, Host header, API route, request method, Server Banner, X-Powered-By identifier, and Set-Cookie field of the HTTP request are extracted.

6. The method according to claim 1, characterized in that, The target WeChat mini-program or target WeChat official account for confirming traffic ownership based on the enterprise entity's metadata includes: Identify WeChat ecosystem parameters in the communication traffic, including x-wechat-session, miniprogram_appid, and openid; The WeChat ecosystem parameters are matched with the extracted AppID, the original ID, and the authentication subject to confirm the target WeChat mini program or target WeChat official account to which the communication traffic belongs, and third-party traffic that does not belong to the target enterprise is excluded from the communication traffic.

7. The method according to claim 1, characterized in that, The asset feature extraction and deduplication process based on the parsed target IP address, target domain name, URL path, and API route includes: A reverse DNS lookup is performed on the resolved destination IP address, and the reverse DNS lookup result is matched with the extracted server domain name; if the match fails, the cloud service node or CDN node to which the destination IP address belongs is identified by associating the IP address with the AS number and combining the IP Whois information. Perform hierarchical clustering based on edit distance on the API paths that are parsed and belong to the same WeChat Mini Program or the same WeChat Official Account to distinguish between business interfaces and static resources; The asset candidate list is generated by hashing a combination of the destination IP address, destination port number, and URL path, and eliminating duplicate records through domain name normalization.

8. A system for discovering enterprise internet assets based on the WeChat ecosystem, characterized in that: The system includes: The traffic capture module is used to obtain the communication traffic of the target enterprise's WeChat mini program and WeChat official account, and extract the AppID of the WeChat mini program, the original ID of the WeChat official account, and the enterprise's metadata. The traffic parsing module is used to perform transport layer parsing and application layer parsing on the communication traffic, extract the target IP address, target domain name, URL path, API route and WeChat ecosystem parameters, and combine them with the enterprise entity metadata to confirm the target WeChat mini program or target WeChat official account to which the traffic belongs. The asset extraction module is used to extract and deduplicate asset features based on the parsed target IP address, target domain name, URL path and API route to generate a candidate asset list; The asset verification module is used to perform multi-dimensional association and cross-verification between the asset candidate list and the extracted enterprise entity metadata to confirm asset ownership and mark the security risk level. The asset management module is used to persistently store the mapping relationship between verified assets and their security risk levels, the WeChat mini program, the WeChat official account, and the assets into the enterprise asset database, and trigger re-execution based on incremental monitoring results.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the enterprise internet asset discovery method based on the WeChat ecosystem dimension as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the enterprise internet asset discovery method based on the WeChat ecosystem dimension as described in any one of claims 1 to 7.

Images