Signing, EPA, and channel binding: Which security feature protects what?

1. Core mechanism

This lesson builds on 07.01 (NTLM message flow) and 07.02 (NTLMv2 response/session key) and answers the question 'how protected is the chosen NTLM', following on from 'why was NTLM the protocol chosen' in 07.03. The boundary is clear: the focus here is on the protection layers (signing/sealing, MIC, channel binding/EPA) put on top of the NTLM session and under what conditions they break the relay/reflection. Kerberos delegation, the full details of SMB, or the inner workings of TLS itself are beyond the scope of this lesson; TLS only appears here as 'external channel to which channel binding binds'.

Interfaces and specifications

• MS-NLMP §2.2.2.5 (Negotiate flags): NTLMSSP_NEGOTIATE_SIGN requests message integrity (signature), NTLMSSP_NEGOTIATE_SEAL requests message confidentiality (encryption); The two are separate flags. With NTLMSSP_NEGOTIATE_KEY_EXCH the AUTHENTICATE message carries an EncryptedRandomSessionKey; The exported session key is RC4 encrypted with KeyExchangeKey.
• MS-NLMP §2.2.2.1 AV_PAIR: The MsvAvChannelBindings (0x000A) field is an MD5 hash of the gss_channel_bindings_struct value of the external secure channel (e.g. TLS); By putting this in the target information in AUTHENTICATE, the client binds the internal NTLM authentication to the external channel (channel binding component of EPA).
• MS-NLMP §2.2.2.1 / §3.1.5.1.2: MsvAvTargetName (0x0009) carries the SPN (service binding) of the target service; Bit 0x00000002 in MsvAvFlags (0x0006) indicates that a MIC is present. If a MIC is present and authenticated in the AUTHENTICATE message, this MIC protects the NEGOTIATE + CHALLENGE + AUTHENTICATE triple with the session key via HMAC-MD5 and prevents flags (e.g. removing signing) from being changed later; MIC may not be available/mandatory in every session.
• Microsoft KB4520412 (registry): Under NTDS\Parameters, LDAPServerIntegrity sets signing requirement (1 = not required, 2 = signing required); LdapEnforceChannelBinding Determines the channel binding enforcement on TLS (0 = never, 1 = on supporting clients, 2 = always).
• Event 2889 reports an unsigned SASL/cleartext simple-bind attempt with client IP, attempted identity and Binding Type. It requires diagnostic level 2 and alone proves neither bind acceptance nor enforcement state.
• Microsoft KB4520412 (channel binding events): 3039, LDAP-over-SSL/TLS reports that a client failed LDAP channel binding token validation (under the When Supported or Always policy; minimum logging level 2). When the policy is Never, 3040 reports the number of unprotected LDAPS binds in the last 24 hours, and 3041 reports the 24-hour posture warning (channel binding enforcement is recommended) (minimum logging level is 0).
• MS-SMB2 §2.2.4 (signing): In an SMB2 session, SMB2_NEGOTIATE_SIGNING_REQUIRED specifies that the server requires signing; If signing is mandatory, a session relayed over SMB cannot produce a valid signature. This is a parallel integrity layer outside of LDAP.

Signing is integrity, sealing is confidentiality — they are not the same thing

There are two different protections that can be placed on top of the NTLM session, and they are often confused. Signing (NTLMSSP_NEGOTIATE_SIGN) adds a signature (MAC) to each message; The receiver verifies that the message has not been modified en route. This is an integrity protection: the content can still be read, but cannot be tampered with.

Sealing (NTLMSSP_NEGOTIATE_SEAL) encrypts the message; This is a privacy protection. Sealing in Windows practically includes signing, but the reverse is not true: a session can be signed but unsealed — the content is visible on the network but cannot be tampered with. 'I signed' and 'I encrypted' are therefore not the same sentence.

The critical distinction in the relay context is this: most of the time, what breaks the relay is not sealing, but integrity (signing) requirements. When a target says 'I want a signed message', the interloper cannot produce a valid signature for subsequent protected messages because it does not have the negotiated session key — the relay will not hold even if the content is not encrypted.

Service binding and channel binding: binding identity

Extended Protection for Authentication (EPA) brings together two different ideas of 'binding'. Service binding is when the client puts the SPN of the target service (MsvAvTargetName, 0x0009) in the AUTHENTICATE message: it says 'I am authenticating to this service'. The server compares the SPN it expects with the one it receives; If the identity is relayed to another service, the SPN will not match.

Channel binding binds internal authentication to the external secure channel (TLS). The client puts a hash of the TLS channel (the MD5 hash of the gss_channel_bindings_struct) in the MsvAvChannelBindings (0x000A) field. The target verifies that the incoming authentication carries the digest for its TLS channel. If the attacker relays the identity over its own TLS channel, the digest does not match the target's channel and is rejected.

These two together target the very 'moving identity from one channel to another' mechanic of reflection and relay: MIC captures the flags being dropped, service binding captures the wrong target, channel binding captures the wrong channel. The strength of EPA depends on whether these bonds are enforced by the target.

LDAP: connection integrity and channel binding

A port number does not identify every protection on a connection. Plain LDAP commonly uses 389; LDAPS starts TLS on 636, while StartTLS upgrades an LDAP connection on 389. Inspect the actual transport and negotiated protection before drawing conclusions.

Require signing rejects unsigned SASL without TLS. Signed SASL protects message integrity; an established TLS connection also satisfies the LDAP connection-integrity requirement. TLS protection and a validated CBT are separate properties: encryption does not automatically bind the inner authentication to that channel.

CBT policy matters. Never does not enforce it. When Supported permits a legacy client that cannot provide CBT, but rejects a capable client omitting it or an invalid token. Always requires valid CBT from every client. The scene contrasts these cases for established TLS; it does not assert a Windows default, validate certificates or reproduce server check ordering.

Why relay breaks: session key, MIC and channel binding

The mechanics of NTLM relay are this: the attacker forwards the victim's authentication messages to the target and hijacks the session established with the target. For this to work, the target must unconditionally accept the transmitted identity. Three guards break this unconditionality.

The first is mandatory signing: if the target requests signed messages, a negotiated session key is required to sign subsequent messages. Because the relaying party does not have the victim's identity material (the key material derived from the NTLMv2 response), it cannot publicly access this session key and cannot generate a valid signature — even if it transmits the handshake, it cannot maintain the signed session. In a negotiated variant, the session key is encrypted under KeyExchangeKey in the EncryptedRandomSessionKey carried by KEY_EXCH; In this way, the relaying party cannot decipher the key because it cannot derive the KeyExchangeKey. The general obstacle is not due to this one way: if signing is mandatory, the relaying party lacks the appropriate session key.

Second is the MIC: if a MIC is present in the negotiation and is being authenticated, the MIC in the AUTHENTICATE protects all three messages and if the relaying party tries to lower the protection by removing the 'request signing' flag, the MIC authentication will not hold. MIC may not be available/mandatory in every session; binds the integrity of the negotiation. Third, channel binding: since the identity comes from the relaying party's TLS channel, it does not match the target's channel digest. What these three have in common is that they do not make the relay 'impossible', but 'invalid' under the conditions required by the target.

Difference between mandatory protection and negotiated protection

Existing a protection is not the same as being mandatory. NTLM signing is negotiated in most sessions (the NEGOTIATE_SIGN flag appears), but if the target does not enforce this, an attacker can lower the flag and attempt to establish an unprotected session. What breaks the Relay is not that the protection is negotiable, but that the target stipulates it.

Separate negotiated features from target-enforced policy. LDAPServerIntegrity, LdapEnforceChannelBinding and SMB SigningRequired govern distinct conditions. Event 2886 describes signing posture; 2887 summarizes permitted unsigned/cleartext binds over 24 hours; 2888 summarizes rejected attempts when signing is required. Event 2889 provides per-client attempt detail and alone establishes no enforcement state.

Event 2889 reports a client’s unsigned SASL or cleartext simple-bind attempt on port 389 with IP, attempted identity and binding type. It establishes neither bind acceptance, authentication success nor absence of signing enforcement. Under applicable policy/logging conditions, 3039 reports failed CBT validation on LDAP over SSL/TLS. These observations belong to distinct branches; policy and connection outcomes require separate evidence.

State and data flow

1. WS01 connects to LDAP on DC01 using SASL-NTLM. NEGOTIATE travels from client to server; signing, sealing and KEY_EXCH are distinct negotiated features.
2. DC01 sends CHALLENGE back to WS01. In this example, the LDAP target and domain-account validation authority are on the same DC; there is no third network recipient.
3. WS01 sends AUTHENTICATE to DC01. KEY_EXCH and MIC are conditional. Over TLS, CBT submission depends on client support; channel matching is checked separately.
4. DC01 evaluates the account with its local security authority. The scene’s accepted/rejected selection is a fixture outcome; a secret or account password does not become an additional network message.
5. Inspect connection integrity separately: unsigned SASL without TLS fails Require signing. Signed SASL or established TLS satisfies this integrity condition, independently of CBT validation.
6. Over TLS, Never requires no CBT. When Supported permits absent CBT for an incapable legacy client, but rejects an absent CBT from a capable client or a mismatching CBT. Always rejects absent CBT for any client. Bind acceptance is not authorization for a later directory operation.
7. With applicable diagnostic level 2 enabled, an unsigned attempt can appear as 2889 and a CBT validation failure as 3039. Event 2889 does not prove acceptance; 2887/2888 are 24-hour summaries, not counts derived from one attempt.

2. Exploitation

Broken trust assumption

Broken assumption: 'I can capture NTLM authentication and relay it to another target; I accept the target ID and take over the session.' This is true in the special case where the target enforces no integrity/binding protection. If mandatory signing is enabled, the relaying party cannot sign the messages because it does not have the negotiated session key required to generate the protected follow-up messages (in a negotiated variant, this key is carried under KeyExchangeKey in the EncryptedRandomSessionKey with KEY_EXCH and again cannot be derived); A MIC present and verified in the negotiation prevents dropping the signing flag; channel binding/EPA rejects the relayed identity as being bound to the wrong TLS channel. The same misconception exists on the defense side: 'I turned on LDAPS/TLS, the relay ends' — TLS encrypts the transport but does not bind the internal identity to the channel; What breaks the relay on LDAPS is channel binding, not signing.

Technical prerequisites

• The target does not require integrity protection: LDAPServerIntegrity=1 (no signing required) in LDAP or no signing required in SMB — otherwise the relayed session cannot produce a valid signature.
• For relay to continue over TLS, the target must not require a matching CBT from this client: LdapEnforceChannelBinding=0 (Never) does not require it; When Supported (1) validates it for capable clients; Always (2) requires it from all clients. Enforced policy rejects identities relayed across different TLS channels.
• The client side does not enforce signing or the attacker finds a way to drop the NEGOTIATE flags; If there is an existing and verified MIC in the negotiation, this downgrade is detected.
• Authentication can be funneled to the target via an attacker-interceptable path (e.g., forced authentication, name resolution redirect) — the scope of this lesson is the acceptance condition of the relay, not the trigger.

Exploitation mechanism

This layer explains why relay is a conditional attack, not just CVE. Relay is based on the unconditional acceptance of the transmitted identity by the target. Forced signing breaks this unconditionality: when the target requests signed tracking messages, a negotiated session key is required to generate them, and the relaying party generally lacks this key because it does not have the victim's NTLMv2 identity material. In a negotiated variant, the exported session key is encrypted with KEY_EXCH under KeyExchangeKey and carried as EncryptedRandomSessionKey; In this path, the key cannot be resolved because KeyExchangeKey cannot be derived. The general obstacle cannot be reduced to this one way — if signing is mandatory, the relaying party lacks the appropriate session key. A subsequent attempt to remove the 'request signing' flag will break the authentication, as a MIC present and verified in the negotiation binds the NEGOTIATE+CHALLENGE+AUTHENTICATE triple (the MIC may not be present/mandatory in every session). Channel binding (MsvAvChannelBindings) and service binding (MsvAvTargetName) bind the internal identity to the external TLS channel and target SPN, respectively; The relayed identity is rejected because it has the wrong channel/destination. The actual leverage of the attack is therefore not the 'universal power of relay', but whether the target enforces these protections — and the most common vulnerability is bypassing signing on LDAPS and not enforcing channel binding.

Relay's condition: if the target does not require guarding

It is wrong to think of Relay as a technique that 'always works'. The relay only holds when the target accepts the transmitted ID without imposing any additional binding/signature requirements. If the target wants mandatory signing, the attacker can transmit the handshake but cannot generate subsequent signed messages because he does not have the session key; The session becomes unusable.

So the attacker's choice of target is really a question of 'which target does not enforce protection': an LDAP service that does not enforce signing, an LDAPS end that does not enforce channel binding, or unsigned SMB. The success of the attack depends on the configuration of the target, not the 'power' of the attacker.

What does MIC and channel binding disrupt?

The attacker's classic move is to weaken the negotiation and 'drop' the guard: like removing the signing from the NEGOTIATE flags. A MIC present and verified in negotiation prevents just that; Since the MIC in AUTHENTICATE covers all three messages, subsequent modification of the flags in the first message breaks the authentication (MsvAvFlags 0x2 marks the presence of the MIC). MIC may not be available/mandatory in every session; This protection only applies to cases where the MIC is generated and verified, and does not by itself universally prevent all signing downgrades.

Channel binding, on the other hand, attacks a different axis: it binds which TLS channel the identity comes from. Because the attacker establishes his own TLS channel with the victim and another channel with the target, the MsvAvChannelBindings digest produced by the victim does not match the target's channel. Reflection (reflecting the identity back to its source) and cross-channel relay are rejected with this binding. Service binding (MsvAvTargetName) implements the same idea at the SPN level.

Limit: does not stop every TLS relay

A common mistake is to say 'LDAPS/TLS already encrypts, so relay is impossible'. TLS encrypts traffic and authenticates the server, but it does not inherently bind which channel the internal NTLM authentication belongs to. If channel binding is not enforced, the attacker can lure the victim to his own TLS channel and relay his identity over the target's TLS channel.

So the output of this layer is not an exploit recipe, but a condition map: relay is possible if 'the target does not enforce signing/channel binding'. The defense's job is to eliminate these conditions; The attack's job is to find targets where these conditions are still open. Triggering techniques (identity enforcement) are beyond the scope of this course.

3. Defense & Detection

Telemetry scope

• Event 2889 reports a per-client unsigned SASL or cleartext simple-bind attempt with IP, attempted identity and binding type. It requires “16 LDAP Interface Events” level 2. Infer neither bind acceptance nor enforcement state from it; read policy/2886, 2887 and 2888 in their separate contexts.
• AD DS Directory Service log (3039/3040/3041): Event 3039 records specific CBT validation failures under When Supported or Always (minimum logging level 2); it is not an audit-only list of clients that would fail after enforcement. Events 3040/3041, under Never, are the 24-hour count of unprotected LDAPS binds and a posture warning; they do not include per-client details.
• Posture records (2886/2887): As a security warning, 2886 states that the server does not enforce signing (LDAPServerIntegrity=1); 2887 Returns a summary of the number of unsigned/cleartext binds in the last 24 hours. These answer the question 'Is protection mandatory', not 'Is there protection?'
• Whether signing on the SMB side (MS-SMB2 SigningRequired) is required by server and client policies is a separate axis; unsigned SMB is a parallel relay surface to that of LDAP and should be measured by the relevant GPO settings.
• A single 2889 or 3039 record does not constitute an 'attack'; these are configuration indicators. Evaluation requires distinguishing with context which clients are persistently connecting without signature/CBT and whether they are legitimate legacy applications or unexpected sources.

Events and relevant fields

• 2889: client IP, attempted identity and Binding Type for an unsigned/cleartext LDAP bind attempt. Diagnostic level 2 is required; it proves neither acceptance, success nor attack.
• 3039 (AD DS · Directory Service): under When Supported or Always, records failed LDAP-over-SSL/TLS CBT validation caused by malformed CBT, a CBT-capable client omitting CBT under When Supported, or any client omitting CBT under Always; minimum logging level 2. The event may be written even when the bind is rejected.
• 2886 (AD DS · Directory Service): security posture warning that the directory server does not enforce LDAP signing (LDAPServerIntegrity=1).
• 2887 (AD DS · Directory Service): summary record of the number of unsigned/cleartext binds that occurred in the last 24 hours (count without client details).
• 3040 (AD DS · Directory Service): summary count of binds that occurred in the last 24 hours without channel binding token verification.
• AD DS Diagnostics · '16 LDAP Interface Events' = 2: Diagnostic level required to produce client level records such as 2889/3039; At the default level this detail is not produced, so 'no logs' may be a lack of telemetry, not security.
• 2888: 24-hour summary of rejected unsigned SASL/cleartext simple-bind attempts on a server requiring signing; not per-client detail.

Which record says what?

The first step in reading the relay surface in AD DS is to separate three record families: 2886/2887 tells whether the server enforces signing (posture), 2889 tells which clients are actually connecting without signature (IP + identity), and 3039 tells which connection LDAP-over-SSL/TLS channel binding verification failed. 3040/3041 is 24-hour posture information when the policy is Never. This distinction ensures that the questions 'is the door open, who is passing through, which CBT verification failed' are not confused.

The second step is to verify the diagnostic level: 2889/3039 are only generated when '16 LDAP Interface Events'=2. If this setting is off, 'no logs' does not mean you are safe; It just means you don't see it. Lack of telemetry should not be confused with security.

Event  Meaning
2886   Signing is not required (posture)
2887   Permitted unsigned/cleartext binds; 24-hour summary
2888   Rejected unsigned/cleartext attempts; 24-hour summary
2889   Unsigned/cleartext attempt; does not prove acceptance
3039   CBT validation failure under applicable policy/logging
3040   Binds without CBT validation; aggregate summary

Is it mandatory or only available?

The decisive question in Relay defense is 'Is protection mandatory?' The appearance of the NEGOTIATE_SIGN flag in a session does not mean that the target has required the signature; If the target does not oblige, the attacker may try to lower the guard. So the 2886 (signing not required) warning is a more strategic signal than a single unsigned bind.

The same logic applies to LDAPS: TLS does not show that channel binding is mandatory. Event 3039 records failed CBT validation under When Supported/Always; it is not a pre-enforcement compatibility list. Under Never, Event 3040 gives the previous 24-hour count of binds without CBT and 3041 gives a posture warning; neither provides a per-client list of who would be affected. After appropriate compatibility review, require channel binding and verify both policy and client outcome.

Detection logic · XPath

<!-- AD DS Directory Service belgesinde imzasiz bind (2889) veya channel binding (3039) kayitlarini secer. -->
<!-- Tek bir Event XML belgesi uzerinde secim yapar; korelasyon/temel cizgi yoktur. -->
<!-- Bu kayitlar yapilandirma gostergesidir; tek basina saldiri kaniti degildir. -->
<!-- Uretim icin '16 LDAP Interface Events'=2 gerekir; aksi halde kayit hic olusmaz. -->
//*[local-name()='Event']
  [*[local-name()='System']/*[local-name()='Provider'][@Name='Microsoft-Windows-ActiveDirectory_DomainService']]
  [*[local-name()='System']/*[local-name()='EventID']='2889'
     or *[local-name()='System']/*[local-name()='EventID']='3039']

Query assumptions

• XPath only selects on a single given Event XML document; does not correlate across multiple DCs, sessions, or time windows.
• Generation of records 2889/3039 depends on diagnostic level 2 '16 LDAP Interface Events'; If this setting is off, recording will not occur at all and the 'clean' appearance will be misleading.
• This expression was evaluated only on sample Event XML documents in this session; has not been run on a live system and has not been benchmarked against a baseline. Since the EventData field layout of the 3039 sample is not published by Microsoft, it was modeled with anonymous Data (synthetic rebuild).

False positives

• Unsigned/cleartext bind (2889) often comes from outdated or misconfigured legitimate applications (legacy LDAP clients, appliances); This is a restructuring debt, not an attack.
• Channel binding warning (3039) may be caused by older clients that do not support CBT; These clients must be inventoried before setting LdapEnforceChannelBinding to 2.
• Negative example: if a client connects via LDAPS with valid channel binding and signing, it will not produce these records at all; The absence of recording is not always security, sometimes it may just be that the diagnostic level is off.

Hardening

• Plan signing and TLS-channel binding independently. Require LDAP signing for connections without TLS; assess CBT compatibility over TLS and test enforcement gradually. Port 389 alone does not imply plaintext, because StartTLS also uses it. Inspect client results and effective policies separately.
• Use 2889 to identify unsigned LDAP binds. Treat 3039 as a CBT validation failure under When Supported/Always, not as a list of clients that would fail after enforcement; under Never, 3040/3041 give only a daily count/posture. Assess client compatibility with supported audit methods and staged testing before requiring CBT.
• Encourage or require LDAP signing on clients, but also enforce Require Signing on the server. A present and verified MIC detects message changes only in the negotiation that includes it; do not assume it is present in every session.
• Require SMB signing on server and client side (SigningRequired); unsigned SMB leaves a relay surface parallel to that of LDAP. This is managed by MS-SMB2 signing policies.
• Use sealing/TLS when data confidentiality is needed; to reduce NTLM relay over TLS, enforce channel binding where supported. LDAP signing, sealing/TLS, and channel binding are distinct controls; one does not replace the others.
• Verification step: with LDAPServerIntegrity=2, unsigned SASL binds should be rejected. With LdapEnforceChannelBinding=2, LDAPS binds without a valid CBT can be rejected and may produce Event 3039 when minimum logging level 2 is enabled. Verify both policy and client outcome; seeing 3039 does not mean enforcement failed.

Read the examples

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"><System><Provider Name="Microsoft-Windows-ActiveDirectory_DomainService"/><EventID>2889</EventID><Level>4</Level><Channel>Directory Service</Channel><Computer>DC01.outreason.example</Computer></System><EventData><Data>198.51.100.44:51873</Data><Data>CN=svc-reporting,OU=Service Accounts,DC=outreason,DC=example</Data><Data>0</Data></EventData></Event>

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"><System><Provider Name="Microsoft-Windows-ActiveDirectory_DomainService"/><EventID>3039</EventID><Channel>Directory Service</Channel><Computer>DC01.outreason.example</Computer></System></Event>

Two reality checks

Assumption: Signing and sealing are the same thing; If I sign, my traffic is also private.

In fact: No. Signing (NTLMSSP_NEGOTIATE_SIGN) provides integrity only: the message cannot be tampered with, but its content can be read on the network. Sealing (NTLMSSP_NEGOTIATE_SEAL) provides confidentiality (encryption). On Windows, sealing includes signing, but the reverse is not true; A session can be signed but unencrypted. This is the critical distinction in the relay context: most of the time it is not secrecy that breaks the relay, but the integrity (signing) required by the target. Since the attacker does not know the session key, he cannot produce a valid signature — even if the content is not encrypted, the relay will not hold. 'I signed' and 'I encrypted' are therefore separate sentences.

Assumption: Using LDAPS/TLS alone stops NTLM relay.

In fact: TLS protects the transport but does not, by itself, bind NTLM authentication to that channel. CBT validation supplies that binding under the selected policy. When Supported has an exception for clients incapable of CBT; Always requires valid CBT from all clients. Signing, TLS, account validation and resource authorization remain separate checks.

Sources

• Microsoft · LDAP channel binding and LDAP signing requirements (KB4520412)
  LDAPServerIntegrity (1/2) and LdapEnforceChannelBinding (0/1/2) registry values; channel binding events 3039/3040/3041 and 2889 for unsigned bind.
• Microsoft · How to enable LDAP signing (KB935834 · 16 LDAP Interface Events)
  '16 LDAP Interface Events' diagnostic level 2; posture events 2886/2887 and client-level 2889; LDAP server/client signing requirements policies.
• Microsoft Open Specifications · [MS-NLMP] NT LAN Manager (NTLM) Authentication Protocol
  §2.2.2.5 Negotiate flags (SIGN/SEAL/KEY_EXCH); §2.2.2.1 AV_PAIR (MsvAvTargetName 0x0009, MsvAvChannelBindings 0x000A, MsvAvFlags 0x0006/MIC bit); MIC and EncryptedRandomSessionKey.
• Microsoft Security Advisory 973811 · Extended Protection for Authentication (EPA)
  Channel binding (binding to the outer TLS channel) and service binding (SPN) concepts; purpose and scope of Extended Protection against relay/reflection.
• Microsoft Open Specifications · [MS-SMB2] Server Message Block (SMB) Protocol Versions 2 and 3 — signing
  SMB2 signing: SMB2_NEGOTIATE_SIGNING_REQUIRED/ENABLED; requiring signing and its parallel effect on relay surface.
• Microsoft Learn · Supporting Extended Protection for Authentication (EPA) in a service
  Session-key signing/encryption and EPA/channel binding are distinct; audit-only EPA does not prevent relay.
• Windows Event manifest standard level values
  Predefined level values: Information4,Warning3