A method and system for anti-obfuscation of LDAP query statements

Abstract

The application discloses an anti-confusion method and system for LDAP query statements, and relates to the technical field of network security. The method comprises a preprocessing stage, a statement structure optimization stage and a fuzzy matching elimination stage. The preprocessing stage performs character-level normalization processing on an LDAP filter string. The statement structure optimization stage converts the preprocessed string into an abstract syntax tree, and restores the abstract syntax tree into an LDAP filter string after performing logical structure simplification. The fuzzy matching elimination stage performs semantic clarification processing on the string output by the statement structure optimization stage. Through systematic and cooperative processing of the three stages, the application can eliminate character-level confusion, logical structure-level confusion and LDAP protocol semantic-level fuzziness at the same time, restore highly confused malicious queries into a form with clear semantics, and effectively improve the identification ability of a security detection scheme for LDAP attacks.

Description

Technical Field

[0001] This invention relates to the field of network security technology, and specifically to a method and system for deobfuscating LDAP query statements. Background Technology

[0002] Lightweight Directory Access Protocol (LDAP) is widely used in enterprise intranets for identity management, organizational structure lookup, and resource access control. LDAP servers store complete enterprise organizational structure and account information. Clients send query requests to the server by constructing LDAP filters, and the server matches directory entries based on the filter conditions and returns the query results. Because LDAP queries generate relatively little network traffic and can efficiently retrieve sensitive information, this protocol has become an important tool for attackers to collect information within enterprise intranets.

[0003] Currently, cybersecurity products typically employ keyword matching or regular expression-based detection rules to perform security checks on LDAP queries. However, LDAP filtering syntax supports multiple equivalent expressions, allowing attackers to alter the literal form of queries without changing their semantics through various obfuscation techniques. This renders detection rules based on fixed keywords or simple patterns ineffective. Therefore, a technical solution capable of semantically restoring obfuscated LDAP queries is urgently needed.

[0004] Chinese invention patent application CN121958347A proposes a general method for implementing multi-condition search based on LDAP. This method uses a parser to parse user-configured query conditions into a query condition model containing logical nodes and condition nodes, and dynamically generates filtering statements that conform to LDAP syntax specifications. However, the input of this scheme is structured query condition configuration (such as JSON or XML format), and its parsing and generation process depends on predefined specification inputs; for unstructured LDAP filtering statement strings that have already been generated, especially statements that have been obfuscated by attackers, this scheme cannot parse and semantically restore them.

[0005] Therefore, it is evident that the existing technology has the following technical problems: 1) When existing LDAP security detection schemes use keyword matching or regular expressions to detect obfuscated LDAP query statements, the obfuscation methods change the literal form of the statement, making it difficult for the detection rules to effectively identify malicious queries, resulting in a high rate of false negatives.

[0006] 2) Existing technologies lack effective means to restore the semantics of unstructured LDAP filter strings. In particular, when the same query statement is simultaneously subject to multiple types of obfuscation, such as character-level, logical structure-level, and semantic-level, existing solutions cannot normalize the statement to restore its true semantics. Summary of the Invention

[0007] To address the aforementioned technical problems, this invention provides a method and system for deobfuscating LDAP query statements.

[0008] To achieve the above objectives, this invention provides a method for deobfuscating LDAP query statements, comprising the following steps: Step 1, Preprocessing stage: Perform character-level normalization on the input LDAP filter string.

[0009] The preprocessing stage includes the following sub-steps: (1) Remove useless characters: Remove all whitespace characters and double quotes that have no actual semantic function from the LDAP filter string to eliminate the bypass achieved by attackers by injecting invisible characters.

[0010] (2) Unified case conversion: Convert the attribute names and attribute values ​​in the filter string to lowercase to eliminate the literal differences caused by mixed case.

[0011] (3) Eliminate leading padding for integers: Identify integer literals in the filter string, remove the leading invalid zero characters, and restore the true integer value.

[0012] (4) Eliminate timestamp obfuscation: Identify strings that conform to the LDAP timestamp format, extract the valid timestamp body, discard the additional noisy suffix characters, and restore the valid timestamp format.

[0013] (5) Hexadecimal encoding and decoding: Identify escape sequences in the filter string that appear in the format of backslash followed by two hexadecimal digits, and restore the escape sequence to the corresponding ASCII character; for escape sequences that represent reserved characters in LDAP syntax, temporarily replace them with internal placeholders, and restore them to the original characters after the other processing steps are completed.

[0014] (6) Object identifier replacement: Identify object identifiers that appear in the filter string in the form of dotted decimal number strings, and replace them with the corresponding attribute names through the preset OID mapping table.

[0015] Step 2, Statement Structure Optimization Stage: Convert the preprocessed LDAP filter string into an abstract syntax tree, perform logical structure simplification on the abstract syntax tree, and then restore the simplified abstract syntax tree back to the LDAP filter string.

[0016] The statement structure optimization phase includes the following sub-steps: (1) Syntax parsing and abstract syntax tree construction: The preprocessed LDAP filter string is used as input, and recursive parsing is performed with parentheses as boundaries to identify the logical operators AND, OR, NOT and leaf conditions in the filter and construct an abstract syntax tree containing logical nodes and leaf nodes. For illegal inputs that do not conform to the standard LDAP syntax, a hierarchical degradation strategy is adopted to process them, including: for statements with mismatched parentheses, extracting the parsable legal parts to form a valid subtree; for leaf nodes containing unescaped parentheses or NUL bytes, determining that the node is invalid and deleting it from the syntax tree.

[0017] (2) Invalid statement deletion: Traverse the abstract syntax tree and delete logically contradictory nodes and syntactically invalid nodes; wherein, the logically contradictory node refers to a combination of nodes in the same AND logic group where the same single-value attribute is assigned different attribute values; the syntactically invalid node refers to a leaf node containing mismatched parentheses, unescaped parentheses, or NUL bytes.

[0018] (3) Delete redundant logical operators: For AND or OR nodes that contain only a single child node, delete the logical node and promote its child node to the current level.

[0019] (4) Eliminate double negation: For NOT nodes with more than two nested layers, according to the rule that even multiple negations are equivalent to affirmations and odd multiple negations are equivalent to single negations, multiple negations are simplified to equivalent forms.

[0020] (5) De Morgan's logical transformation: For the case where NOT nodes contain AND nodes or OR nodes, perform logical equivalence transformation according to De Morgan's law, transform NOT(AND(A,B)) into OR(NOTA,NOTB), transform NOT(OR(A,B)) into AND(NOTA,NOTB), and recursively perform double negation elimination on the newly generated NOT nodes after the transformation to simplify the logical structure.

[0021] (6) Abstract syntax tree restoration: The simplified abstract syntax tree is reverse serialized into LDAP filter strings according to the node type.

[0022] Step 3, Eliminating Fuzzy Matching: Perform semantic explicitation processing on the LDAP filter string output in Step 2.

[0023] The fuzzy matching elimination stage includes the following sub-steps: (1) Eliminate approximate equal sign fuzzy matching: Replace the approximate matching operator in the filter with the equal sign operator.

[0024] (2) Eliminate ambiguity of range comparison operators: For numerical comparison conditions containing greater than or less than operators, exhaust all integer values ​​corresponding to the comparison condition within the preset value range, and merge the upper and lower bound conditions on the same attribute into an equality matching condition; For string comparison conditions containing greater than or less than operators, when the comparison boundary is a global boundary value, convert the comparison condition into an existence check condition.

[0025] (3) Implicit multi-attribute expansion of ambiguous name resolution attributes: Identify the ambiguous name resolution attribute conditions in the filter, obtain multiple target attributes associated with the ambiguous name resolution attributes, and expand the ambiguous name resolution attribute conditions into a multi-condition combination composed of the equal-value matching conditions of the multiple target attributes connected by OR logic.

[0026] (4) Bit mask simplification of User Account Control Attributes: Identify the User Account Control Attribute conditions of the object identifiers in the filter that contain extended matching rules, traverse the AND logic groups of the filter, and extract the negative forms of the bit and matching rule conditions and bit or matching rule conditions in the current AND group; when the current AND group does not contain any attribute conditions other than the User Account Control Attribute conditions, perform simplification according to the combination of the negative forms of the bit and matching rule conditions and bit or matching rule conditions: if there are only multiple bit and matching rule conditions, combine them into a single bit and matching rule condition by bit OR; if there are both bit and matching rule conditions and negative forms of bit or matching rule conditions, detect the bit intersection of the two, and output the exact equivalent matching condition of the User Account Control Attribute when there is no intersection; if there are only bit or matching rule conditions or their negative forms but no bit and matching rule conditions, keep the original conditions and do not simplify.

[0027] To implement the above method, the present invention also provides an LDAP query statement deobfuscation system, comprising: The preprocessing module is configured to perform character-level normalization on the input LDAP filter string and output the processed string to the statement structure optimization module.

[0028] The statement structure optimization module is configured to receive the string output by the preprocessing module, convert the string into an abstract syntax tree, perform logical structure simplification on the abstract syntax tree, restore the simplified abstract syntax tree to the LDAP filter string, and output the restored string to the fuzzy matching elimination module.

[0029] The fuzzy matching elimination module is configured to receive the LDAP filter string output by the statement structure optimization module, perform semantic explicitation processing on the string, and output the deobfuscated LDAP filter string.

[0030] Compared with the prior art, this application has the following advantages: First, the preprocessing stage of this application, through a systematic combination of six sub-steps, comprehensively covers all currently known character-level obfuscation techniques. Unlike existing technologies that can only handle standard input, this application can directly process various modified statements actually constructed by attackers. The step of deleting useless characters eliminates the bypass achieved by attackers through injecting spaces, tabs, and double quotes; the step of unifying uppercase and lowercase eliminates literal differences caused by mixed uppercase and lowercase; the step of eliminating integer leading padding restores the true value masked by leading zeros; the step of eliminating timestamp obfuscation can accurately identify the LDAP timestamp format and discard arbitrary noise suffixes added by attackers; the hexadecimal encoding and decoding step, in conjunction with the internal placeholder replacement strategy, restores readable characters while avoiding damage to the bracket structure of the filter; the object identifier replacement step restores the obscure OID numeric string into semantically clear attribute names through a pre-set mapping table. The above six steps work together to automatically complete the comprehensive cleaning of character-level obfuscation without manual intervention, providing a standardized input foundation for subsequent processing.

[0031] Secondly, this application, by introducing abstract syntax tree technology, achieves for the first time in the field of LDAP deobfuscation the structured parsing and logical simplification of unstructured filter strings. The syntax parsing and abstract syntax tree construction steps adopt a recursive descent parsing algorithm, which can handle various irregular inputs constructed by attackers; for illegal inputs such as mismatched brackets, unescaped brackets, and NUL bytes, a hierarchical degradation strategy is adopted to process them, preserving as much parsable legal parts as possible and avoiding the entire statement being discarded due to local errors.

[0032] The invalid statement removal step automatically identifies and removes logically impossible AND groups (such as the same single-valued attribute being assigned different values) and nodes containing syntax errors, eliminating noise conditions introduced by attackers. The redundant logic operator removal step directly removes AND or OR nodes containing only a single child node, shortening statement length and making the logical structure clearer. The double negation elimination step simplifies multiple negations to equivalent forms according to Boolean algebra rules, solving the semantic masking problem caused by attackers through nested negation chains. The De Morgan logic transformation step performs equivalent transformations and recursively simplifies AND or OR structures under NOT nodes, restoring complex logical structures deliberately reversed by attackers to their intuitive form.

[0033] The above five steps, using the abstract syntax tree as a unified data structure carrier, are executed sequentially without interfering with each other, and together achieve a thorough simplification of the obfuscated logical structure classes.

[0034] Third, this application designs a dedicated fuzzy matching elimination stage specifically for the fuzzy semantic mechanism unique to the LDAP protocol, a capability completely absent in existing technologies. The step to eliminate approximate equality fuzzy matching, based on analysis of the Active Directory protocol implementation, safely replaces the semantically indistinguishable approximate matching operator with an equal sign, eliminating the semantic uncertainty introduced by the approximate equality sign. The step to eliminate the ambiguity of range comparison operators distinguishes between numeric and string-based scenarios: for numeric types, it exhaustively enumerates integer values ​​within the range and merges the upper and lower bounds of the same attribute into equality matches, refining range queries into equality queries; for string types, it converts global boundary values ​​into existence checks. This processing clarifies the query intent that originally relied on range conditions.

[0035] The implicit multi-attribute expansion step for disambiguating name resolution attributes expands the special filtering condition ANR into an OR combination covering nearly twenty related attributes, transforming the implicit multi-attribute fuzzy search into an explicit multi-condition equality matching, enabling the detection rule to identify each expanded attribute separately. The bitmasking simplification step for user account control attributes specifically processes the OIDs of the extended matching rules, performing bitwise OR merging or exact equality replacement based on the combination of bits with conditions and bitwise OR conditions within the AND group, restoring the obfuscation achieved by attackers through bit-by-bit splitting to clear single-value matches.

[0036] The above four steps together solve the semantic ambiguity problem caused by the advanced features of the LDAP protocol, so that the deobfuscated statement is semantically equivalent to and clear to the original query.

[0037] Fourth, the three processing stages of this application exhibit systematic synergy. The preprocessing stage provides the statement structure optimization stage with cleaned character-level input, enabling it to accurately identify attribute names and operators and avoid parsing errors caused by character distortion. The statement structure optimization stage provides the elimination of fuzzy matching stage with flattened logical structures, enabling it to correctly identify AND group boundaries and attribute name patterns and avoid misjudgments and omissions caused by excessively deep logical nesting. The execution order of the three stages is strictly logically necessary; any adjustment of the order or the absence of any stage will lead to a significant decrease or even complete failure of the deobfuscation effect.

[0038] This collaborative design enables this application to effectively handle complex scenarios where attackers simultaneously apply three types of obfuscation, which is unmatched by any solution that only handles a single type of obfuscation. Attached Figure Description

[0039] Figure 1 This is a flowchart illustrating an LDAP query statement deobfuscation method provided in an embodiment of the present invention. Figure 2 This is a system architecture diagram for deobfuscating LDAP query statements provided in an embodiment of the present invention. Detailed Implementation

[0040] In the following embodiments, for ease of understanding and description of the present invention, some terms are defined and explained as follows: LDAP filter string: A string expression conforming to the Lightweight Directory Access Protocol (LDAP) standard, used to define the query conditions for directory entries. This string is typically delimited by parentheses (), and includes the attribute name, operator, and attribute value.

[0041] Abstract Syntax Tree (AST): refers to a tree-like data structure used to structurally represent the logical structure of LDAP filter strings. In this invention, the node types of the abstract syntax tree include: leaf nodes (representing a complete, indivisible atomic condition), NOT nodes (representing logical NOT operations), AND nodes (representing logical AND operations), and OR nodes (representing logical OR operations).

[0042] AND logical group: In an LDAP filter, this refers to a logical unit consisting of one or more sub-conditions connected by the logical AND operator '&'. In this invention, its corresponding abstract syntax tree representation is the set of all child nodes of an AND node.

[0043] Internal placeholders: These are markers used during the preprocessing stage to temporarily replace specific reserved characters (such as left and right parentheses, asterisks, and backslashes) when decoding hexadecimal encoding, in order to avoid disrupting the syntax structure of the LDAP filter string (e.g., bracket matching). These placeholders are restored to their original form after the abstract syntax tree is reconstructed into the LDAP string and before the final output. Their complete lifecycle spans both the preprocessing and statement structure optimization stages.

[0044] Object Identifier (OID): In the LDAP protocol, it refers to a sequence of numbers used to uniquely identify an object class, attribute, or matching rule, usually represented in dotted decimal notation.

[0045] Ambiguous Name Resolution (ANR): In an Active Directory environment, this is a special LDAP filtering condition used to perform fuzzy searches across multiple user attributes simultaneously.

[0046] User Account Control (userAccountControl) is a key attribute in Active Directory used to store user account status, capabilities, and security features in the form of a bitmask.

[0047] Extended matching rules: In LDAP filters, a specific matching operation is specified by appending an object identifier (OID). For example, 1.2.840.113556.1.4.803 represents a bitwise AND matching rule (BIT_AND), and 1.2.840.113556.1.4.804 represents a bitwise OR matching rule (BIT_OR).

[0048] Multivalued attributes: These are attribute types in the LDAP directory that allow multiple values ​​to be stored simultaneously. For example, attributes such as objectClass and memberOf are multivalued attributes. Logically, the same multivalued attribute can have multiple different attribute values ​​at the same time, which does not constitute a logical contradiction.

[0049] Example 1 like Figure 1 As shown, this embodiment provides a method for deobfuscating LDAP query statements, including the following steps: Step 1, Preprocessing stage: Perform character-level normalization on the input LDAP filter string.

[0050] This preprocessing stage is fundamental to all subsequent processing steps and aims to eliminate obfuscation implemented by attackers by altering the literal form of statements. The normalized string output from the preprocessing stage serves as input for the statement structure optimization stage. If character-level distortions are not removed, the subsequent parser will be unable to correctly identify attribute names and operators, making logical analysis impossible.

[0051] The preprocessing stage includes the following sub-steps: (1) Remove useless characters: Remove all whitespace characters (including spaces, tabs, newlines, etc.) and double quotes that have no actual semantic function from the LDAP filter string. This step is used to eliminate bypasses achieved by attackers by injecting invisible or redundant characters. For example, the string (&(cn=admin)) is processed into (&(cn=admin)).

[0052] (2) Unified case conversion: Convert all letter characters in the filter string, including attribute names and attribute values, to lowercase. This step is used to eliminate literal differences caused by mixed case. For example, (cn=DoMainAdMIns) will be processed as (cn=domainadmins).

[0053] (3) Eliminate leading padding for integers: Identify integer literals in the filter string, remove invalid leading zero characters, and restore the true value of the integer. For example, (sAMAccountName=0000805306368) is processed into (sAMAccountName=805306368).

[0054] (4) Eliminate timestamp obfuscation: Identify strings that conform to the LDAP timestamp format, i.e., the pattern of 14 digits followed by .0Z, extract the valid timestamp body (the first 14 digits and .0Z), discard any noise characters appended to the suffix, and restore it to a valid timestamp format. For example, (whencreated=20181231235959.0Zabc??) is processed into (whencreated=20181231235959.0z).

[0055] (5) Hexadecimal Encoding and Decoding: Identify escape sequences in the filter string that appear in the format of a backslash followed by two hexadecimal digits (i.e., \XX), and restore the escape sequences to their corresponding ASCII characters. For escape sequences representing LDAP syntax reserved characters (including left parentheses (, right parentheses), asterisks, and backslashes \), do not replace them with ASCII characters for the time being, but instead replace them with an internal placeholder. After the abstract syntax tree is restored to the LDAP string and before the final output, these placeholders will be restored to their corresponding original reserved characters. This strategy ensures that while restoring readable characters, the bracket structure of the filter is not destroyed in the preprocessing stage, thereby ensuring that the subsequent recursive descent parsing algorithm can correctly identify the boundaries of the AST. For example, (cn=\61\64\6d\69\6e) is processed into (cn=admin).

[0056] (6) Object Identifier Replacement: Identify object identifiers appearing in dotted decimal number strings in the filter string and replace them with the corresponding attribute names using a pre-defined OID mapping table. For example, (2.5.4.3=admin) is processed into (cn=admin). This step must be performed after hexadecimal decoding is complete because the OID number string does not contain hexadecimal escape sequences. However, to unify the processing flow, placing it after the decoding step ensures that the input string has been restored to a readable ASCII form, facilitating accurate matching in the mapping table.

[0057] Step 2, Statement Structure Optimization Stage: Receive the normalized LDAP filter string output from the preprocessing stage, convert the string into an abstract syntax tree, perform logical structure simplification on the abstract syntax tree, and then restore the simplified abstract syntax tree back to the LDAP filter string.

[0058] This phase is used to eliminate obfuscation implemented by attackers through redundant logical structures and logical equivalence transformations. The input to this phase must be the string cleaned by the character layer in the preprocessing phase, because logical simplification relies on accurate identification of attribute names and operators, and this identification is only reliable after character restoration. The logically flattened LDAP filter string output from the statement structure optimization phase will serve as the input to the fuzzy matching elimination phase; its flattened logical structure enables subsequent phases to correctly identify AND group boundaries.

[0059] This stage includes the following sub-steps: (1) Syntax parsing and abstract syntax tree construction: Using the preprocessed LDAP filter string as input, recursive descent parsing is performed with parentheses as boundaries to identify logical operators AND (&), OR (|), NOT (!) and leaf conditions in the filter, and to construct an abstract syntax tree containing logical nodes and leaf nodes. For illegal input that does not conform to standard LDAP syntax, a hierarchical degradation strategy is adopted to process it in order to retain the parsable legal parts to the greatest extent and avoid the entire statement being discarded due to local errors. Specifically: For statements with mismatched parentheses, the parsing algorithm checks at the entry point whether the string begins with (or ends with) a parenthesis; if not, the entire statement is preserved as a leaf node value. When splitting the child nodes of AND or OR nodes, a depth counter scans the string, cutting out a complete sub-filter whenever the parenthesis depth returns from 1 to 0. After splitting, if any unconsumed residual characters exist, they are validated as independent child nodes. During validation, the parenthesis depth is tracked: if the depth drops to a negative number during traversal (indicating the presence of redundant right parentheses) or is not zero at the end of traversal (indicating the presence of redundant left parentheses), the node is deemed invalid and deleted. If all child nodes of an AND or OR node are deleted, the node itself is deemed invalid and propagates upwards, ultimately setting the entire statement to an empty string.

[0060] For leaf nodes containing unescaped parentheses, the parsing algorithm first replaces the valid hexadecimal escape sequences (i.e., \28 and \29) with placeholders to mask their influence, and then checks whether there are any literal (or) characters in the remaining string. If so, it means that the parentheses have been mixed into the attribute value without proper escaping, and the leaf node is determined to be invalid and removed from the abstract syntax tree.

[0061] For leaf nodes containing NUL bytes (i.e., \x00), the parsing algorithm checks whether the attribute value field contains NUL bytes. NUL is a string terminator at the LDAP protocol level; its presence indicates an illegal construct, rendering the leaf node invalid and removing it from the abstract syntax tree.

[0062] For leaf nodes containing injected invalid characters (including ?, !, {,}), the parsing algorithm detects these characters using the regular expression [?!{}]. If a match is found, the leaf node is deemed invalid and removed from the abstract syntax tree to avoid affecting valid nodes at the same level.

[0063] (2) Invalid Statement Deletion: Traverse the abstract syntax tree and delete logically contradictory nodes and syntactically invalid nodes. A logically contradictory node refers to a combination of nodes within the same AND logical group where the same single-valued attribute is assigned different attribute values. It should be noted that multi-valued attributes (such as objectClass, memberOf, etc.) are allowed to have multiple values ​​simultaneously in LDAP. Multiple different attribute values ​​for the same multi-valued attribute within an AND group do not constitute a logical contradiction and are therefore not within the scope of this step. A syntactically invalid node refers to a node that was marked as invalid and propagated upwards in the aforementioned syntax parsing step. This step is used to eliminate noise conditions or logically impossible conditions introduced by attackers.

[0064] (3) Remove redundant logical operators: For AND or OR nodes that contain only a single child node in the abstract syntax tree, delete the logical node and promote its child nodes to the current level. For example, simplify (&(cn=admin)) to (cn=admin). This step shortens the statement length and makes the logical structure clearer.

[0065] (4) Eliminating double negations: For NOT nodes nested two or more levels in the abstract syntax tree, simplification is performed according to Boolean algebra rules, i.e., an even number of negations is equivalent to an affirmation, and an odd number of negations is equivalent to a single negation. For example, (!(!objectClass=)) is simplified to (objectClass=). This step solves the semantic masking problem caused by attackers through nested negation chains.

[0066] (5) De Morgan's logical transformation: For cases where a NOT node in the abstract syntax tree contains AND or OR nodes, a logical equivalence transformation is performed according to De Morgan's law, that is, NOT(AND(A,B)) is transformed into OR(NOTA,NOTB), and NOT(OR(A,B)) is transformed into AND(NOTA,NOTB). Double negation elimination is then recursively performed on the newly generated NOT nodes after the transformation to simplify the logical structure. This step can restore the complex logical structure deliberately reversed by the attacker to its intuitive form. The above sub-steps (3), (4), and (5) are all executed sequentially on the unified data structure of the abstract syntax tree, with the output of the previous step serving as the input of the next step, without interference.

[0067] (6) Abstract Syntax Tree Reconstruction: The final abstract syntax tree after all the simplification operations in sub-steps (2) to (5) above is reverse-serialized into an LDAP filter string according to the node type. Specifically, for AND nodes, a string starting with (&, ending with) and containing all child node strings is generated; for OR nodes, a string starting with (|, ending with) and containing all child node strings is generated; for NOT nodes, a string starting with (!, ending with) and containing child node strings is generated; for leaf nodes, their original bracket expressions are directly returned. After reconstruction, the internal placeholders introduced in the preprocessing stage to replace the reserved characters of LDAP syntax are restored to their corresponding original characters (i.e., (, ), and \), and the finally output structure-optimized LDAP filter string is output.

[0068] Step 3, Elimination of Fuzzy Matching Stage: Receive the logically flattened LDAP filter string output from the statement structure optimization stage, perform semantic explicitation processing on the string, and output the deobfuscated LDAP filter string.

[0069] This stage aims to eliminate semantic ambiguity caused by advanced features of the LDAP protocol. The input for this stage must be a string that has been logically flattened through the statement structure optimization stage, as operations such as AND group boundary identification and attribute name pattern matching in this stage rely on a clear and accurate logical structure.

[0070] This stage includes the following sub-steps: (1) Eliminate approximate equal sign fuzzy matching: Replace the approximate matching operator ~= in the filter with the equal sign operator =. The basis for this processing is that in the LDAP protocol implementation of ActiveDirectory, the actual behavior of the approximate matching operator is not substantially different from that of the equal sign operator.

[0071] (2) Eliminate ambiguity of range comparison operators: For numeric comparison conditions containing the greater than (>) or less than (<) operator, exhaustively list all integer values ​​corresponding to the comparison condition within the preset value range, and merge the upper and lower bound conditions on the same attribute into an equality matching condition. For example, (&(samaccounttype>=805306367)(samaccounttype<=805306369)) is simplified to (samaccounttype=805306368). For string comparison conditions containing the greater than or less than operator, when the comparison boundary is a global boundary value (such as ! or zzz), the comparison condition is converted into an existence check condition (i.e., (attr=)), for example, (name<=zzz) is simplified to (name=). When string comparison conditions exist and both greater than and less than conditions exist on the same attribute, exhaustively enumerate all possible values ​​of the sensitive keyword (such as admin, domain, etc.) and merge the range conditions into precise equality matching conditions. For example, (&(name>=DomainAd)(name<=DomainAe)) is simplified to (name=domainadmins).

[0072] (3) Implicit multi-attribute expansion of ambiguous name resolution attributes: Identify ambiguous name resolution attribute (i.e., ANR) conditions in the filter, obtain multiple target attributes associated with the ambiguous name resolution attribute, and expand the ambiguous name resolution attribute conditions into a multi-condition combination composed of the equality matching conditions of the multiple target attributes connected by OR logic. Specifically, the multiple target attributes include: cn, displayName, givenName, sn, initials, name, sAMAccountName, userPrincipalName, mail, proxyAddresses, legacyExchangeDN, physicalDeliveryOfficeName, msDS-AdditionalSamAccountName, msDS-PhoneticDisplayName, msDS-PhoneticFirstName, msDS-PhoneticLastName, mailNickname, targetAddress, and textEncodedORAddress. For example, (anr=administrator) is expanded into a composite condition composed of the equality matching conditions of the above 19 attributes connected by OR.

[0073] (4) Bitmasking of User Account Control Attributes: Identify User Account Control attribute conditions in the filter that contain object identifiers with extended matching rules, i.e., bit-and matching rule conditions in the form of userAccountControl:1.2.840.113556.1.4.803:=N (BIT_AND) and bit-or matching rule conditions in the form of (!(userAccountControl:1.2.840.113556.1.4.804:=M)) (NOTBIT_OR). Since bitmasking of User Account Control attributes needs to be performed only after the boundaries of the AND group are clearly defined, this sub-step must be executed after the statement structure optimization stage.

[0074] The specific simplification algorithm is as follows: Phase 1: Scan the entire LDAP filter string, using depth counting to precisely locate each AND group (i.e., each bracket group starting with '&'). Call the simplification function for each AND group. If an AND group is simplified, restart the scan of the entire string from the beginning until no AND groups are simplified in a single complete scan, ensuring that all simplifiable AND groups in the nested structure have been processed.

[0075] Phase Two: For a single AND group, perform the following operations: First, extract the value list `matches_803` for all BIT_AND conditions (i.e., `userAccountControl:1.2.840.113556.1.4.803:=N`) within the current AND group, and the value list `matches_not_804` for all NOTBIT_OR conditions (i.e., `(!(userAccountControl:1.2.840.113556.1.4.804:=M))`). If both are empty, no simplification is performed, and the original statement is returned directly.

[0076] Secondly, if both matches_803 and matches_not_804 are not entirely empty, all BIT_AND and NOTBIT_OR conditions in the current AND group are deleted, and the remaining content is checked to see if it is empty. If the remaining content is not empty, it means that the AND group contains conditions with other attributes. In this case, simplification is abandoned, and the AND group is returned as is. The purpose of this check is to avoid performing simplification operations that might change the overall semantics in complex AND groups containing conditions with other attributes.

[0077] If the remaining content is empty, meaning the current AND group only contains User Account Control attribute conditions, then it will be handled according to the following three scenarios: Case 1: Only multiple BIT_AND conditions exist (i.e., matches_803 has multiple values, and matches_not_804 is empty). In this case, the mask values ​​of all BIT_AND conditions are bitwise ORed and combined into a single mask value, and this AND group is replaced with a single BIT_AND condition. For example, (&(useraccountcontrol:803:=512)(useraccountcontrol:803:=65536)) is simplified to (useraccountcontrol:1.2.840.113556.1.4.803:=66048).

[0078] The second scenario: Both BIT_AND and NOTBIT_OR conditions exist simultaneously (i.e., both matches_803 and matches_not_804 are not empty). In this case, must_be_one is calculated as the bitwise OR of all BIT_AND condition mask values, and must_be_zero is calculated as the bitwise OR of all NOTBIT_OR condition mask values. The bit intersection of must_be_one and must_be_zero is checked: if the intersection is not zero, i.e., there exists a bit that is simultaneously required to be 1 and required to be 0, then there is a logical contradiction, simplification is abandoned, and the AND group is returned as is. If there is no intersection, the AND group is simplified to an exact equality matching condition (userAccountControl=must_be_one), where must_be_zero is only used as a constraint verification condition and does not participate in the final value calculation. For example, (&(useraccountcontrol:803:=4194304)(!(useraccountcontrol:804:=2))) can be simplified to (userAccountControl=4194304).

[0079] The third scenario: Only the NOTBIT_OR condition exists, or only the BIT_OR condition exists, but there is no bit and matching rule condition (i.e., matches_803 is empty). Since userAccountControl:804:=N is a range condition, the userAccountControl value that satisfies this condition is not unique, and a definite value cannot be derived. Therefore, this type of condition is not simplified and is returned as is.

[0080] Example 2 This embodiment provides an LDAP query statement deobfuscation system for implementing the method described in Embodiment 1. The system includes: The preprocessing module is configured to perform character-level normalization on the input LDAP filter string and output the processed string to the statement structure optimization module. Specifically, the preprocessing module includes: a useless character removal unit, used to remove all whitespace characters and double quotes without actual semantic function from the LDAP filter string; a unified case conversion unit, used to convert attribute names and attribute values ​​in the filter string to lowercase; an integer leading padding removal unit, used to identify integer literals in the filter string and remove their leading invalid zero characters; a timestamp obfuscation removal unit, used to identify strings conforming to the LDAP timestamp format, extract their valid timestamp body, and discard additional noise suffix characters; a hexadecimal encoding and decoding unit, used to identify hexadecimal escape sequences in the filter string and restore them to their corresponding ASCII characters, and replace escape sequences of characters reserved in LDAP syntax with internal placeholders, and restore the placeholders to their original characters after the abstract syntax tree is restored to the LDAP string; and an object identifier replacement unit, used to identify object identifiers in the filter string and replace them with their corresponding attribute names through a preset OID mapping table.

[0081] The statement structure optimization module is configured to receive the string output by the preprocessing module, convert the string into an abstract syntax tree (AST), perform logical structure simplification on the AST, restore the simplified AST to an LDAP filter string, and output the restored string to the fuzzy matching elimination module. Specifically, the statement structure optimization module includes: a syntax parsing and AST construction unit, used to recursively descent parse the preprocessed string as input, using parentheses as boundaries, to construct an AST containing logical nodes and leaf nodes, and employing a hierarchical degradation strategy to handle illegal input. The hierarchical degradation strategy includes: extracting the parsable legal parts of statements with mismatched parentheses to form a valid subtree and independently verifying the remaining characters; determining the invalidity of leaf nodes containing unescaped parentheses, NUL bytes, or injected invalid characters and deleting them; and an invalid statement deletion unit, used to traverse the AST and delete logically contradictory nodes and syntactically invalid nodes, wherein the logically contradictory nodes... The abstract syntax tree (API) is divided into several parts: a point determination unit to exclude multi-valued attributes; a redundant logic operator deletion unit to delete AND or OR nodes in the API that contain only a single child node and promote their child nodes to the current level; a double negation elimination unit to simplify NOT nodes nested two or more levels in the API to equivalent forms; a De Morgan logic transformation unit to perform equivalent transformations on NOT nodes containing AND or OR structures in the API according to De Morgan's laws and recursively simplify them; and an API restoration unit to reverse serialize the final API after the above simplifications into an LDAP filter string and restore the internal placeholders to the corresponding original LDAP syntax reserved characters after restoration.

[0082] The fuzzy matching elimination module is configured to receive the LDAP filter string output by the statement structure optimization module, perform semantic explicitation processing on the string, and output the deobfuscated LDAP filter string. Specifically, the fuzzy matching elimination module includes: an approximation equality elimination unit, used to replace approximation matching operators in the filter with equality operators; a range comparison operator ambiguity elimination unit, used to merge numerical range comparison conditions into equality matching conditions, convert string range comparison conditions with global boundary values ​​into existence check conditions, and merge string range comparisons with both greater than and less than conditions on the same attribute into equality matching conditions through exhaustive enumeration of sensitive keywords; an ambiguous name resolution attribute expansion unit, used to expand ambiguous name resolution attribute conditions into multi-condition combinations composed of equality matching conditions of multiple target attributes connected by OR logic; and a user account control attribute simplification unit, used to identify and traverse AND logic groups containing extended matching rules, and perform simplification on each AND group using an iterative scanning strategy. For AND groups containing only user account control attribute conditions, simplification operations are performed based on the combination of bits and conditions and bit or conditions within the group, using bitwise OR merging or exact equality replacement. For AND groups containing other attribute conditions or logical contradictions, simplification is abandoned.

[0083] Example 3 This embodiment will illustrate the application process of the technical solution of this application by combining a specific enterprise intranet security detection scenario.

[0084] A company deployed an LDAP traffic security monitoring system. During one inspection, the system captured an LDAP query request with a suspicious origin, whose filter string was as follows: (&(|(cn=\61\64\6d\69\6e)(objectClass=user))(!(!(sAMAccountName=0000admin)))) The statement literally mixes hexadecimal encoding, uppercase and lowercase letters, leading zeros, and double negations, making it very easy to miss when directly using keyword matching rules (such as detecting admin).

[0085] The system first calls the preprocessing module. This module removes all whitespace characters and converts them to lowercase, decodes the hexadecimal sequence \61\64\6d\69\6e to admin, and removes leading zeros from the sAMAccountName value. After preprocessing, the statement is cleaned up as follows: (&(|(cn=admin)(objectclass=user))(!(!(samaccountname=admin)))) Subsequently, the statement structure optimization module parses the string into an abstract syntax tree. The parsing algorithm performs recursive descent parsing with parentheses as boundaries, identifying the outermost AND node and its two child nodes: an OR node and a double NOT node. During the tree traversal, the invalid statement deletion unit checks for logical contradictions; the redundant logic operator deletion unit finds no detachable single child node; the double negation elimination unit identifies the structure (!(!(samaccountname=admin))) and simplifies it to (samaccountname=admin) according to the Boolean algebra rule that even-numbered double negations are equivalent to affirmations. The De Morgan logic transformation unit performs no operation in this scenario. After optimization, the abstract syntax tree is restored to: (&(|(cn=admin)(objectclass=user))(samaccountname=admin)) Finally, the fuzzy matching elimination module processes the statement. The approximate equality elimination unit and the range comparison operator ambiguity elimination unit operate in this scenario. The ambiguous name resolution attribute expansion unit does not detect the ANR keyword. The User Account Control attributeization simplifier also does not detect any relevant extended matching rules. Therefore, the statement remains unchanged.

[0086] Finally, the deobfuscation system outputs a clear LDAP filter string: (&(|(cn=admin)(objectclass=user))(samaccountname=admin)) The security detection engine then performed rule matching on this semantically clear statement, successfully identifying the malicious intent to query the administrator account and triggering an alert. This demonstrates that the deobfuscation processing of this invention effectively restores the true query semantics masked by various obfuscation techniques. In this scenario, the normalized string output in the preprocessing stage is a prerequisite for the statement structure optimization stage to correctly identify attribute names (such as cn and samaccountname) and operators; the logically flattened statement output in the statement structure optimization stage is a prerequisite for the elimination of fuzzy matching stage to correctly identify AND group boundaries. The sequential execution of the three stages has a strict logical necessity.

[0087] Example 4 This embodiment will use an attack sample containing a complex logical structure and protocol-specific ambiguous semantics to illustrate the processing flow of the technical solution of this application.

[0088] During a red team / blue team exercise, the monitoring equipment captured an LDAP query used to probe high-privilege accounts on the domain controller. The filter string was as follows: (!(|(!(adminCount=0))(&(userAccountControl:1.2.840.113556.1.4.803:=4194304)(!(userAccountControl:1.2.840.113556.1.4.804:=2))))) This statement is obfuscated by nested De Morgan logic transformations and bitmasking of the user account control (userAccountControl) property, making direct analysis extremely difficult.

[0089] The statement was input into the deobfuscation system. No characters requiring cleaning were found during the preprocessing stage, and it was directly output to the statement structure optimization module.

[0090] The statement structure optimization module parses the string into an abstract syntax tree. The parsing algorithm identifies the outermost layer as a NOT node, whose child node is an OR node. The two child nodes of the OR node are a NOT node and an AND node, respectively. After starting logical simplification, the De Morgan logic transformation unit first identifies the outermost NOT(OR(...)) structure and applies De Morgan's law to transform it into AND(NOT(...),NOT(...)). Subsequently, the double negation elimination unit processes the internal (!(adminCount=0)), simplifying it to (adminCount=0). After recursive simplification, the entire logical structure is flattened into an AND logic group and restored to: (&(adminCount=0)(userAccountControl:1.2.840.113556.1.4.803:=4194304)(!(userAccountControl:1.2.840.113556.1.4.804:=2))) Subsequently, the fuzzy matching elimination module processes the AND logic group. The User Account Control Attribute Simplification Unit first identifies the AND group as starting with "&" and precisely locates the bracket boundaries using depth counting. After extracting the conditions within the group, it is found that the AND group contains a BIT_AND condition (803:=4194304, where 4194304 represents the ADS_UF_TRUSTED_FOR_DELEGATION flag) and a NOTBIT_OR condition (!(804:=2), where 2 represents the UF_ACCOUNTDISABLE flag). After deleting these two conditions, the remaining content of the AND group is empty, meaning it does not contain any other attribute conditions. The simplification unit calculates must_be_one=4194304 and must_be_zero=2, and checks the bit intersection of the two (4194304&2=0), confirming no logical contradiction. Therefore, the entire condition combination is simplified into precise equality matching conditions. The final output is: (&(adminCount=0)(userAccountControl=4194304)) Ultimately, the deobfuscation system outputs a semantically clear filter string. This statement clearly expresses a query for accounts that simultaneously satisfy two conditions: adminCount is not equal to 0 and the userAccountControl attribute is exactly equal to 4194304. In other words, it queries for high-privilege accounts that have enabled delegation to this computer. In this scenario, the De Morgan logical transformation must be performed after preprocessing because the accurate identification of the transformed attribute names (such as adminCount and userAccountControl) depends on character-level cleaning. Conversely, userAccountControl simplification must be performed after the De Morgan transformation because only after the logical structure is flattened into AND groups can the simplification unit correctly identify the complete boundaries of the AND group and all its internal conditions. Based on this, the detection engine can accurately determine that the query is a malicious reconnaissance attempt, without being misled by the complex logical nesting and bitwise operations in the original statement.

[0091] Example 5 This embodiment will further verify the effectiveness and technical effect of the technical solution of this application through a set of control experimental data.

[0092] The experimental design is as follows: The experiment uses three datasets. Dataset D1 contains 8,000 normal LDAP queries collected from a real enterprise Active Directory environment, used to evaluate the false positive rate of the solution. Dataset D2 contains 1,500 plaintext malicious queries generated based on 24 known attack templates (such as Kerberoasting, AS-REPRoasting, unconstrained delegation probing, RBCD constrained delegation probing, LAPS password reading, GMSA account probing, domain trusted account enumeration, LDAPIN_CHAIN ​​recursive group membership query, objectSid binary enumeration, unicodePwd anomalous access, and GPO container enumeration, etc.), used to evaluate the baseline detection capability of the solution against unobfuscated attacks. Dataset D3 contains 1,500 queries generated from the D2 samples after obfuscation, used to evaluate the actual performance of the solution under adversarial conditions. The D3 obfuscation method involves: using an alignment obfuscator to apply fifteen types of alignment obfuscation to 750 samples, such as whitespace injection, random case, attribute name OID conversion, redundant AND / OR nesting, double negation wrapping, De Morgan transformation, replacing equal signs with approximate equal signs, replacing exact values ​​with range plus exclusion combinations, and appending noisy numbers to the end of timestamps; simultaneously, using an independent adversarial fuzz tester to apply seven types of adversarial obfuscation to another 750 samples, such as LDAP syntax character hexadecimal escaping, replacing exact values ​​with substring wildcards, Unicode homograph replacement, deep NOT chain nesting, OID conversion replacement of extended matching rules, deep AND / OR nesting structures, and timestamp garbage character injection. Each D3 sample is randomly superimposed with ten to twenty-one different obfuscation techniques.

[0093] The experimental procedure is as follows: First, datasets D1, D2, and D3 were input into the LDAP security detection engine deployed with the deobfuscation system of this application. For D1 and D2, direct detection results were statistically analyzed. For D3, the results of detection without deobfuscation (direct detection) and detection after deobfuscation were statistically analyzed respectively. The detection rules built into the detection engine remained unchanged.

[0094] The experimental results are as follows: Regarding the false positive rate, out of 8,000 normal queries in the D1 dataset, 551 were misjudged as malicious, resulting in a false positive rate of 6.89%. This indicates that the proposed solution can maintain a low false positive rate when dealing with normal queries that contain a large number of deliberately constructed high-risk patterns.

[0095] Regarding the plaintext malicious query detection rate, out of 1,500 plaintext malicious queries in the D2 dataset, 1,482 were correctly detected, with a detection rate of 98.80%, representing the theoretical performance ceiling of this detection rule set.

[0096] In the core adversarial tests, for 1,500 obfuscated malicious queries on the D3 dataset, only 799 queries were detected directly without deobfuscation, resulting in a direct detection rate of 53.27%, proving that the obfuscation method successfully interfered with conventional detection. However, after processing by the deobfuscation system of this application, 1,427 queries were detected, increasing the detection rate to 95.13%. The deobfuscation gain (i.e., the difference between the detection rate after deobfuscation and the direct detection rate) was 41.87 percentage points, directly demonstrating the significant improvement in detection rate achieved by this application. Using 98.80% of the D2 dataset as the perfect deobfuscation baseline, the deobfuscation quality score of this solution (the ratio of the detection rate after deobfuscation to the baseline detection rate) was 96.30, indicating that the statements restored by this solution are semantically highly close to the original plaintext queries.

[0097] Furthermore, the experiment also performed stratified statistical analysis on the D3 dataset based on the number of obfuscation types. When the number of obfuscation types was 10-12, the direct detection rate was approximately 46%, and the detection rate after deobfuscation was approximately 95%, with 406 samples. When the number of obfuscation types was 13-15, the direct detection rate was approximately 47%, and the detection rate after deobfuscation was approximately 95%, with 423 samples. When the number of obfuscation types was 16-18, the direct detection rate was approximately 45%, and the detection rate after deobfuscation was approximately 94%, with 387 samples. When the number of obfuscation types was 19-21, the direct detection rate was approximately 62%, and the detection rate after deobfuscation was approximately 97%, with 138 samples. The data shows that even under high-intensity obfuscation, this scheme can still maintain a stable detection rate of approximately 95%.

[0098] The experiment also performed stratified statistics on the sources of the D3 dataset. For the 750 samples from the alignment obfuscator, the direct detection rate was 46.90%, the detection rate after deobfuscation was 96.80%, the baseline detection rate was 99.10%, and the deobfuscation quality score was 97.70. For the 750 samples from the adversarial fuzz tester, the direct detection rate was 59.60%, the detection rate after deobfuscation was 93.50%, the baseline detection rate was 98.50%, and the deobfuscation quality score was 94.90. Combining all 1500 samples, the direct detection rate was 53.27%, the detection rate after deobfuscation was 95.13%, the baseline detection rate was 98.80%, and the deobfuscation quality score was 96.30. The data shows that the proposed scheme has excellent restoration performance against obfuscation from both sources, demonstrating its robustness to different obfuscation strategies.

[0099] The experimental data above fully demonstrates that the present invention can effectively handle the arbitrary superposition of three types of obfuscation methods: character layer, logic layer, and semantic layer, and restore highly obfuscated malicious queries to a semantically clear form, thereby significantly improving the ability of existing security detection schemes to identify LDAP attacks.

[0100] The embodiments described above are merely illustrative of the technical solutions of this application and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for deobfuscating LDAP query statements, characterized in that, include: Preprocessing stage: Perform character-level normalization on the input LDAP filter string. The character-level normalization includes deleting useless characters, uniformly converting uppercase and lowercase, eliminating leading padding for integers, eliminating timestamp obfuscation, hexadecimal encoding and decoding, and object identifier replacement. Statement structure optimization stage: The preprocessed LDAP filter string is converted into an abstract syntax tree, the abstract syntax tree is simplified logically, and the simplified abstract syntax tree is restored to the LDAP filter string. The logical structure simplification includes deleting invalid statements, deleting redundant logical operators, eliminating double negations, and De Morgan's logical transformation. Eliminating fuzzy matching stage: Semantic explicitation processing is performed on the LDAP filter string output from the statement structure optimization stage. The semantic explicitation processing includes eliminating fuzzy matching of approximate equality signs, eliminating ambiguity of range comparison operators, eliminating implicit multi-attribute expansion of ambiguous name resolution attributes, and bit masking simplification of user account control attributes.

2. The method for deobfuscating LDAP query statements according to claim 1, characterized in that, In the preprocessing stage: Removing useless characters includes removing all whitespace characters and double quotes that have no actual semantic function from the LDAP filter string; Unified case conversion includes converting both attribute names and attribute values ​​in the filter string to lowercase. Eliminating leading padding for integers involves identifying integer literals in the filter string and removing invalid leading zero characters. Eliminating timestamp obfuscation involves identifying strings that conform to the LDAP timestamp format, truncating their valid timestamp body, and discarding any additional noisy suffix characters. Hexadecimal encoding and decoding includes recognizing escape sequences in the filter string that appear in the format of a backslash followed by two hexadecimal digits and restoring them to the corresponding ASCII characters. For escape sequences that represent reserved characters in LDAP syntax, internal placeholders are used instead. After the LDAP filter string is restored, the placeholders are restored to the corresponding original characters. Object identifier replacement involves identifying object identifiers that appear in the filter string as dotted decimal number strings and replacing them with the corresponding attribute names using a pre-defined OID mapping table.

3. The method for deobfuscating LDAP query statements according to claim 1, characterized in that, In the statement structure optimization stage, converting the preprocessed LDAP filter string into an abstract syntax tree includes: recursively descent parsing with parentheses as boundaries, identifying logical operators AND, OR, NOT, and leaf conditions in the filter, and constructing an abstract syntax tree containing logical nodes and leaf nodes; for illegal input that does not conform to standard LDAP syntax, a hierarchical degradation strategy is adopted for processing, which includes: for statements with mismatched parentheses, extracting the parsable legal parts to form a valid subtree; for leaf nodes containing unescaped parentheses, NUL bytes, or injected invalid characters, determining the node invalid and deleting it from the abstract syntax tree.

4. The method for deobfuscating LDAP query statements according to claim 1, characterized in that, In the statement structure optimization stage, deleting invalid statements includes: traversing the abstract syntax tree and deleting logically contradictory nodes and syntactically invalid nodes; wherein, a logically contradictory node refers to a node combination in which the same single-valued attribute within the same AND logic group is assigned different attribute values, and multi-valued attributes do not constitute a logical contradiction; a syntactically invalid node refers to a leaf node containing mismatched parentheses, unescaped parentheses, or NUL bytes.

5. The method for deobfuscating LDAP query statements according to claim 1, characterized in that, During the statement structure optimization phase: Deleting redundant logical operators includes: for AND or OR nodes that contain only a single child node, deleting the logical node and promoting its child nodes to the current level; Eliminating double negations includes simplifying NOT nodes with two or more nested levels into equivalent forms according to the rule that even-numbered negations are equivalent to affirmations and odd-numbered negations are equivalent to single negations; De Morgan's logic transformation includes: performing an equivalent transformation on NOT nodes that contain AND or OR nodes according to De Morgan's laws, and recursively performing double negation elimination on the newly generated NOT nodes after the transformation.

6. The method for deobfuscating LDAP query statements according to claim 1, characterized in that, In the statement structure optimization stage, restoring the simplified abstract syntax tree to an LDAP filter string includes: reverse serialization according to node type; generating bracket expressions starting with the corresponding logical operators for AND, OR, and NOT nodes; directly returning the original bracket expressions for leaf nodes; and restoring the internal placeholders introduced in the preprocessing stage to the corresponding original LDAP syntax reserved characters after the restoration is completed.

7. The method for deobfuscating LDAP query statements according to claim 1, characterized in that, In the stage of eliminating fuzzy matching: Eliminating approximate equal sign fuzzy matching includes replacing the approximate matching operator in the filter with the equal sign operator; Eliminating ambiguity in range comparison operators includes: for numeric comparison conditions, exhaustively listing all integer values ​​corresponding to the comparison condition within a preset value range, and merging upper and lower bound conditions on the same attribute into an equality matching condition; for string comparison conditions, when the comparison boundary is a global boundary value, converting the comparison condition into an existence check condition; for string comparison conditions where both greater than and less than conditions exist on the same attribute, exhaustively listing all possible values ​​within the sensitive keyword range, and merging the range conditions into an equality matching condition.

8. The method for deobfuscating LDAP query statements according to claim 1, characterized in that, In the fuzzy matching elimination stage, the implicit multi-attribute expansion of the ambiguous name resolution attribute includes: identifying the ambiguous name resolution attribute conditions in the filter, obtaining multiple target attributes associated with the ambiguous name resolution attribute, and expanding the ambiguous name resolution attribute conditions into a multi-condition combination composed of the equal-value matching conditions of the multiple target attributes connected by OR logic; the multiple target attributes include cn, displayName, givenName, sn, initials, name, sAMAccountName, userPrincipalName, mail, proxyAddresses, legacyExchangeDN, physicalDeliveryOfficeName, msDS-AdditionalSamAccountName, msDS-PhoneticDisplayName, msDS-PhoneticFirstName, msDS-PhoneticLastName, mailNickname, targetAddress, and textEncodedORAddress.

9. The method for deobfuscating LDAP query statements according to claim 1, characterized in that, In the stage of eliminating fuzzy matching, bit masking simplification of user account control attributes includes: Iterate through the AND logical groups of the LDAP filter string, and extract all bit and matching rule condition value lists and bit or matching rule condition negation value lists within the current AND group; When the current AND group does not contain any attribute conditions other than the User Account Control (MAC) attribute condition, simplification is performed based on the combination of the bit-matching rule condition and the negation of the bit-or-matching rule condition: if there are only multiple bit-matching rule conditions, they are combined into a single bit-matching rule condition by bit-OR; if there are both bit-matching rule conditions and the negation of the bit-or-matching rule condition, the bit intersection of the two is detected, and if there is no intersection, the equivalent matching condition of the MAC attribute is output; if there is only a bit-or-matching rule condition or its negation but no bit-matching rule condition, the original condition is maintained.

10. A deobfuscation system for LDAP query statements, characterized in that, The system for implementing the method of any one of claims 1-9 comprises: The preprocessing module is configured to perform character-level normalization on the input LDAP filter string and output the processed string to the statement structure optimization module; The statement structure optimization module is configured to receive the string output by the preprocessing module, convert the string into an abstract syntax tree, perform logical structure simplification on the abstract syntax tree, restore the simplified abstract syntax tree to the LDAP filter string, and output the restored string to the fuzzy matching elimination module. The fuzzy matching elimination module is configured to receive the LDAP filter string output by the statement structure optimization module, perform semantic explicitation processing on the string, and output the deobfuscated LDAP filter string.

Images