NT hash ile NTLMv2 response neden aynı şey değildir?

1. Core Mechanism / Temel mekanizma

Karar noktası, bir NTLM olayına veya yakalanmış bir response'a bakan kişinin 'elimde hangi materyal var ve onunla ne yapabilirim' sorusudur. NT hash, response ve SessionBaseKey birbirinden türese de farklı güvenlik değerine sahiptir; birini diğerinin yerine koymak hem Red hem Blue tarafında yanlış çıkarımlara yol açar.

Arabirimler ve belirtimler

• NT hash: MD4(UTF-16LE(parola)). Tuzlanmamıştır ve yalnız paroladan türer; aynı parola her hesapta aynı NT hash'i verir. Parola değişmedikçe sabittir; domain hesabında DC tarafındaki dizinde, yerel hesapta SAM'de tutulur. Credential-equivalent'tir: ele geçirilirse parolayı bilmeden kimlik kanıtı olarak kullanılabilir (pass-the-hash).
• NTOWFv2: HMAC_MD5(NT hash, UNICODE(Uppercase(User) + UserDom)). NTLMv2'de asıl anahtar budur; NT hash'ten ve kullanıcı+domain adından türer. 'Salt' burada rastgele değil, kullanıcı adı ve domain adıdır.
• NTProofStr, response’un kanıt bileşenidir. Taze challenge girdileri onu etkiler; timestamp’in kaynağı server TargetInfo koşuluna bağlıdır. Kablodaki response NTProofStr ile temp’i taşır, NT hash’i değil.
• temp / NTLMv2_CLIENT_CHALLENGE: response'a gömülen yapı; RespType 0x01, zaman damgası (FILETIME), 8 baytlık client challenge ve TargetInfo AV_PAIR'lerini içerir. Response'un neden her seferinde değiştiğini bu değişkenler açıklar.
• SessionBaseKey: HMAC_MD5(NTOWFv2, NTProofStr). Oturum anahtarı türetiminin temelidir; kabloda açık gitmez ve response'tan doğrudan okunamaz.

NT hash: tuzlanmamış, paroladan türeyen, credential-equivalent

NT hash parolanın tek yönlü bir özetidir: MD4, parolanın UTF-16LE kodlamasına uygulanır. Tuzlama (salt) veya yineleme (iteration) yoktur; aynı parola her zaman aynı NT hash'i verir. Bu, hash'in hesaba değil parolaya bağlı olduğu anlamına gelir: aynı parolayı paylaşan iki farklı hesabın NT hash'i birebir aynıdır. Bu yüzden NT hash, parolanın kendisi kadar hassas bir sırdır: onu bilen, parolayı bilmeden kimlik doğrulayabilir.

Bu özelliğe 'credential-equivalent' denir ve pass-the-hash saldırısının temelidir. Saldırgan NT hash'e sahipse, NTLM alışverişinde doğru response'u üretmek için gereken tek girdiye sahiptir; parolayı kırmasına gerek yoktur.

NT hash oturumdan oturuma değişmez. Bir ortamda görülen response'lar farklı olsa da, arkalarındaki NT hash parola değişene kadar aynıdır. Bu, response ile NT hash arasındaki en temel farktır: biri oturumluk, diğeri kalıcı sırdır. Parola yeniden kullanımı burada doğrudan bir risk yaratır: aynı parolayı paylaşan hesaplar aynı NT hash'e sahip olduğundan, bir hash'in ele geçmesi o parolayı paylaşan tüm hesapları etkiler.

NTLMv2 response: NTProofStr MAC'i artı temp blob'u

NtChallengeResponse, NTProofStr ile temp yapısını birlikte taşır. temp içindeki ClientChallenge istemcinin ürettiği girdidir. TimeStamp ise her zaman istemcinin saatinden gelmez: CHALLENGE TargetInfo içinde MsvAvTimestamp varsa bu server değeri kopyalanır; yoksa Currenttime kullanılır. Bu ayrım, response’un değişmesini veya saat farkını yorumlarken önemlidir.

Taze server challenge ve client challenge, response’un normal exchange’lerde farklılaşmasını sağlar; timestamp’in kaynağı yukarıdaki koşula bağlıdır. Aynı paroladan aynı NT hash türese de oturuma ait girdiler farklıdır. Yakalanmış baytlar yeniden gösterildiğinde kendiliğinden yenilenmez; taze girdiler ile replay edilmiş kayıt aynı şey değildir.

NTProofStr bir MAC'tir; NT hash'i içinde barındırmaz ve tersine çevrilerek NT hash'e ulaşılamaz. Response'tan doğrudan NT hash veya SessionBaseKey okunamaz. Bu yüzden bir response yakalamak, NT hash'i ele geçirmekle aynı şey değildir.

# MS-NLMP 3.3.2 (NTLMv2), sembolik gosterim; gercek bayt uretimi degildir.
# Anahtar: NT hash'ten turer, salt kullanici+domain'dir, iterasyon yoktur.
NTOWFv2 = HMAC_MD5( MD4(UNICODE(Passwd)), UNICODE( Uppercase(User) + UserDom ) )

# temp: response'un icine gomulen client challenge yapisi (zaman, client challenge, hedef bilgisi)
temp = RespType(0x01) || HiRespType(0x01) || Reserved || TimeStamp(8) ||
       ClientChallenge(8) || Reserved || TargetInfo(AV_PAIRs) || Reserved

# NTProofStr: sunucu challenge'ina, NT hash'ten turemis anahtarla uretilen MAC
NTProofStr = HMAC_MD5( NTOWFv2, ServerChallenge || temp )

# Kablodaki NtChallengeResponse = NTProofStr (16 bayt) || temp
NtChallengeResponse = NTProofStr || temp

# Oturum anahtari materyali; NT hash'ten turer, kabloda acik gitmez
SessionBaseKey = HMAC_MD5( NTOWFv2, NTProofStr )

SessionBaseKey ve üçün ayrı tutulması

SessionBaseKey, NTOWFv2 ve NTProofStr'den HMAC-MD5 ile türeyen üçüncü bir materyaldir ve oturumun signing/sealing anahtarlarının temelidir. Kabloda açık gitmez; response'a bakan biri onu doğrudan çıkaramaz. NT hash'i bilen taraf ise SessionBaseKey'i yeniden hesaplayabilir.

Bu üç kavramı ayrı tutmak pratikte önemlidir. Elinde bir NTLMv2 response olan biri, ne NT hash'e ne SessionBaseKey'e otomatik sahiptir; en fazla, parola zayıfsa offline tahminle parolayı bulmayı deneyebilir. Elinde NT hash olan biri ise hem response üretebilir hem SessionBaseKey'i türetebilir.

Kısacası materyalin türü, saldırganın ne yapabileceğini belirler. 'NTLM materyali' diye tek bir şey yoktur; NT hash, oturumluk response ve SessionBaseKey farklı yetenekler açar. Bu ayrım, Red tarafındaki saldırı sınıflarını ve Blue tarafındaki olay yorumunu doğrudan etkiler.

Durum ve veri akışı

1. Parola girildiğinde istemci NT hash'i hesaplar: MD4(UTF-16LE(parola)); bu değer parola değişene kadar sabittir.
2. İstemci NT hash ve kullanıcı+domain adından NTOWFv2 anahtarını türetir (HMAC-MD5, salt = kullanıcı+domain).
3. FS01 ServerChallenge ve TargetInfo gönderir. ClientChallenge’ı WS01 üretir. TimeStamp: MsvAvTimestamp varsa FS01’den kopyalanır; yoksa WS01 Currenttime kullanır.
4. İstemci temp yapısını (client challenge, zaman, TargetInfo) kurar ve NTProofStr = HMAC_MD5(NTOWFv2, ServerChallenge || temp) hesaplar.
5. Kabloda NtChallengeResponse = NTProofStr || temp taşınır; NT hash ve SessionBaseKey açıkça gönderilmez.
6. SessionBaseKey iki girdiye bağlıdır: ResponseKeyNT ve NTProofStr. İstemci ile doğrulayıcı tarafında türetilir; response’u okumak key’i okumak değildir.
7. Doğrulayıcı (domain hesabında DC) aynı NT hash'ten NTProofStr'i yeniden hesaplayıp karşılaştırır.
8. Başarılı logon ve uygun audit ile hedefte 4624 görülebilir. LmPackageName/KeyLength package ve session-security bağlamıdır; NT hash veya SessionBaseKey değildir.

2. Exploitation / İstismar

Broken trust assumption

Kırılan varsayım şudur: 'Bir NTLMv2 response'u yakalamak, o hesabın NT hash'ini veya oturum anahtarını ele geçirmekle aynıdır.' Gerçekte response geri çevrilemez bir MAC'tir; en fazla, parola zayıfsa offline tahminle parola bulunabilir. NT hash'i gerektiren saldırılar (pass-the-hash) ise response'la değil, hash'in kendisiyle çalışır.

Technical prerequisites

• Offline parola tahmini için saldırganın NTLMv2 response'u (server challenge dahil) yakalamış olması ve hedef parolanın sözlük/kurallı denemeyle bulunabilecek kadar zayıf olması gerekir; güçlü parolada bu yol pratik değildir.
• Pass-the-hash için saldırganın NT hash'in kendisine sahip olması gerekir; bu hash response'tan türetilemez, ayrı bir kaynaktan (ör. bir uç noktadaki kimlik deposu) elde edilmelidir.
• Response'un NTLMv2 (v1/LM değil) olması saldırıyı zorlaştırır; downgrade edilmiş NTLMv1/LM materyali çok daha zayıftır ve farklı sınırlar getirir.
• Offline tahmin, ağ üzerinde ek yetki gerektirmez; saldırgan yalnız yakaladığı veriyle çevrimdışı çalışır, bu yüzden tespit ağ değil, yakalamanın nasıl mümkün olduğuna bakmalıdır.

Exploitation mechanism / İstismar mekanizması

İki saldırı sınıfını ayırmak gerekir. Birincisi offline parola tahmini: saldırgan yakaladığı NTProofStr'i doğrulamak için bir parola adayı seçer, ondan NT hash ve NTOWFv2 türetir, aynı server challenge ve temp ile HMAC-MD5'i yeniden hesaplar; sonuç yakalanan NTProofStr'e eşitse parola bulunmuştur. NTLMv2'de iterasyon olmaması ve salt'ın kullanıcı+domain olması bu denemeyi hızlı kılar; tek gerçek engel parolanın gücüdür. İkincisi pass-the-hash: bu saldırı response'u değil, NT hash'in kendisini kullanır; hash'e sahip olan taraf, herhangi bir server challenge'a doğru response üretebildiği için parolayı hiç bilmeden kimlik doğrular. Yakalanan bir response bu yeteneği vermez; ikisi farklı girdilerle çalışır.

Yakalanan response neyi verir, neyi vermez

Bir NTLMv2 response yakalayan saldırganın elinde geri çevrilemez bir MAC ve ona eşlik eden server/client challenge'lar vardır. Bu materyal, parolayı doğrulamak için bir 'oracle' işlevi görür: bir parola adayı doğruysa aynı NTProofStr üretilir. Ama bu, NT hash'i ifşa etmez; yanlış adaylar hiçbir bilgi sızdırmaz.

Bu nedenle güçlü, tahmin edilemez bir parolada yakalanan response pratikte kullanışsızdır. Saldırının değeri parolanın zayıflığına bağlıdır, response'un kriptografik gücüne değil. 'Response yakalandı, hesap düştü' çıkarımı yanlıştır.

Pass-the-hash neden ayrı bir dünyadır

Pass-the-hash, NT hash'in credential-equivalent olmasından doğar. Saldırgan hash'e sahipse, hedef sunucunun vereceği her server challenge'a doğru response üretir; parolayı bilmesine veya kırmasına gerek yoktur. Burada 'kırma' aşaması hiç yoktur.

Kritik ayrım şudur: pass-the-hash için gereken NT hash, yakalanan bir wire response'tan elde edilemez. Hash başka bir yerden (bir sistemdeki kimlik deposu) gelmelidir. Bu yüzden 'response yakalamak' ile 'hash ele geçirmek' savunma açısından farklı problemlerdir ve farklı kontrollerle ele alınır.

3. Defense & Detection / Savunma ve tespit

Telemetry scope

• 4624 (Audit Logon) NTLM ağ oturumunda LogonType 3 ve LogonProcessName 'NtLmSsp' ile üretilir; bu olay 'hangi sürüm NTLM kullanıldı'yı gösterir, hangi sır materyalinin türediğini değil.
• LmPackageName ('Package Name (NTLM only)') yalnızca AuthenticationPackageName 'NTLM' olduğunda dolar; değerleri 'NTLM V1', 'NTLM V2' veya 'LM' olabilir. Bu alan downgrade avında birincil sinyaldir.
• KeyLength, NTLM session-security key uzunluğudur. Kerberos için, Negotiate üzerinden seçilmiş Kerberos dahil, 0’dır; Negotiate adı tek başına 0 anlamına gelmez. Kaydedilen uzunluk bir sır ifşası değildir.
• 4624 olayları kaynak sunucuda üretilir; NT hash, NTProofStr veya SessionBaseKey hiçbir olay alanında yer almaz. Olaydan 'sır ele geçti' sonucu çıkmaz.

Events and relevant fields

• 4624 / AuthenticationPackageName: 'NTLM' değeri NTLM ile oturum açıldığını gösterir; LmPackageName alanının anlamlı olması bu değere bağlıdır.
• 4624 / LmPackageName: 'NTLM V2' beklenen güçlü durumdur; 'NTLM V1' veya 'LM' downgrade veya eski istemci işaretidir ve avlanması gereken zayıflıktır.
• 4624 / KeyLength: NTLM oturum güvenliği anahtar uzunluğu (128 güçlü, 56 zayıf). Düşük değerler zayıf yapılandırma sinyali olabilir; olay bir sır ifşası anlamına gelmez.
• 4624 / LogonType 3 + LogonProcessName 'NtLmSsp': ağ üzerinden NTLM oturumunu ayırt eder; yerel/interactive oturumlardan bu alanlarla ayrılır.
• 4624 / TargetUserName ve TargetDomainName: NTLM ile kimliği doğrulanan hesap; 'hangi sır türedi' değil, 'hangi kimlik oturum açtı' bilgisini verir.

Olay 'sürümü' gösterir, 'sırrı' değil

4624'ün NTLM alanları (LmPackageName, KeyLength) hangi sürüm ve anahtar uzunluğunun kullanıldığını söyler. Bu değerli bir bilgidir çünkü downgrade ve zayıf yapılandırmayı ortaya çıkarır. Ama bu alanlar NT hash, NTProofStr veya SessionBaseKey gibi sır materyalini içermez; olaydan bir sırrın 'ifşa olduğu' sonucu çıkmaz.

Örnek monitoring policy’si NTLM V2 ve 128-bit session-security key bekler. LM/NTLM V1 veya başka bir uzunluk inceleme gerektirir. KeyLength=0 tek başına zayıf exchange veya saldırı kanıtı değildir; package, negotiated session security ve toplama bağlamıyla yorumlanır.

Downgrade avı ile sır avı farkı

Blue tarafında iki farklı soru vardır. Birincisi 'zayıf bir NTLM sürümü mü kullanılıyor' (downgrade avı): bunun cevabı 4624'teki LmPackageName/KeyLength ile verilir ve yapılandırmayı düzeltmeye yönlendirir. İkincisi 'bir sır ele mi geçti': bunun cevabı NTLM oturum olaylarında değil, kimlik deposuna erişim ve kimlik bilgisi hırsızlığı telemetrisinde aranır.

Bu iki soruyu karıştırmak yaygın bir hatadır. NTLM oturum olayı ne pass-the-hash'i kanıtlar ne de bir hash'in çalındığını gösterir; yalnızca hangi protokol sürümüyle oturum açıldığını belgeler. Sır ele geçirme sorusu ayrı kaynaklarla kovalanır.

Detection logic · XPath

<!-- Örnek policy: NTLM V2 ve 128-bit session-security bekleniyor. -->
<!-- LM/NTLM V1 veya KeyLength != 128 inceleme için seçilir; saldırı/secret kanıtı değildir. -->
<!-- KeyLength=0 bağlamla yorumlanır; tek başına zayıf NTLM sonucu çıkarılmaz. -->
<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">*[System[(EventID=4624)] and EventData[Data[@Name='AuthenticationPackageName']='NTLM'] and EventData[Data[@Name='LmPackageName']='NTLM V1' or Data[@Name='LmPackageName']='LM' or Data[@Name='KeyLength']!='128']]</Select>
  </Query>
</QueryList>

Query assumptions

• Sorgu, Windows Event Viewer/wevtutil XPath alt kümesine göre yazılmıştır ve tek bir makinenin yerel Security günlüğünde çalışır; merkezi toplama şeması farklıdır.
• Audit Logon alt kategorisi etkin olmalı ve 4624 olayları LmPackageName alanını içermelidir; bu alan yalnız AuthenticationPackageName 'NTLM' olduğunda dolar.
• Alan adları (AuthenticationPackageName, LmPackageName) 4624 Version 2 şemasına göredir; farklı Windows sürümlerinde ek alanlar bulunabilir.
• Sorgu yalnızca sürüm/anahtar zayıflığını işaretler; bir oturumun kötü niyetli olup olmadığını belirlemez.
• Bu selector’ın 128-bit beklentisi örnek monitoring policy’sidir; tüm ortamlara ait bir zayıflık eşiği değildir. AuthenticationPackageName=NTLM koşulu Kerberos/Negotiate için geçersiz KeyLength yorumunu önler. Windows Event Log’da çalıştırılmadı.

False positives

• Eski istemciler veya uygulamalar meşru şekilde NTLM V1 kullanabilir; bu, saldırı değil teknik borç işaretidir.
• Bazı yazılım/appliance'lar NTLM V2'yi desteklemediği için düşük KeyLength ile bağlanır; beklenen bir istisna olabilir.
• Test ve bakım süreçlerinde geçici olarak zayıf NTLM ayarları etkinleştirilmiş olabilir; bağlam olmadan tek başına alarm yanıltıcıdır.
• İsteğe bağlı olarak yalnız belirli hesaplar için istisna tanımlanmış ortamlarda bu olaylar beklenen gürültü olabilir.

Hardening

• LAN Manager authentication level'ı 'Send NTLMv2 response only. Refuse LM & NTLM' (seviye 5) olarak ayarlayarak NTLMv1/LM'yi reddet; 4624'te 'NTLM V1'/'LM' görünmesini önle.
• NoLMHash politikasıyla LM hash'lerinin saklanmasını engelle; eski, çok zayıf materyalin hiç üretilmemesini sağla.
• Parola politikalarını güçlendir: NTLMv2 response offline tahmininin tek gerçek engeli parolanın gücüdür; uzun, tahmin edilemez parolalar/gizli anahtarlar zorunlu kıl.
• Servis ve otomasyon hesapları için gMSA gibi yüksek entropili yönetilen kimlikler kullan; böylece offline tahmin pratikte imkânsızlaşır.
• Parola yeniden kullanımını engelle: aynı parolayı paylaşan hesaplar aynı NT hash'e sahip olduğundan, tek bir hash'in ifşası birden çok hesabı etkiler; özellikle ayrıcalıklı ve yerel yönetici hesaplarında benzersiz, yüksek entropili parola/gizli anahtar zorunlu kıl.
• LmPackageName ve KeyLength'i düzenli avla: 'NTLM V1'/'LM' veya düşük KeyLength üreten istem ve uygulamaları envanterle ve gider.
• Mümkün olan yerde NTLM'i tümden azalt ve Kerberos'a yönel; NTLM'e düşen yolları ölç, gerekçelendir ve kademeli kapat.

Örnekler üzerinde oku / Read the examples

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" />
    <EventID>4624</EventID>
    <Version>2</Version>
    <Level>0</Level>
    <Task>12544</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8020000000000000</Keywords>
    <TimeCreated SystemTime="2026-09-29T07:41:12.902551700Z" />
    <EventRecordID>552013</EventRecordID>
    <Channel>Security</Channel>
    <Computer>FS01.outreason.example</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="SubjectUserSid">S-1-0-0</Data>
    <Data Name="SubjectUserName">-</Data>
    <Data Name="SubjectDomainName">-</Data>
    <Data Name="SubjectLogonId">0x0</Data>
    <Data Name="TargetUserSid">S-1-5-21-1004336348-1177238915-682003330-2117</Data>
    <Data Name="TargetUserName">abdulvehhab</Data>
    <Data Name="TargetDomainName">OUTREASON</Data>
    <Data Name="TargetLogonId">0x1f4c7a9</Data>
    <Data Name="LogonType">3</Data>
    <Data Name="LogonProcessName">NtLmSsp </Data>
    <Data Name="AuthenticationPackageName">NTLM</Data>
    <Data Name="WorkstationName">WKSTN-07</Data>
    <Data Name="LogonGuid">{00000000-0000-0000-0000-000000000000}</Data>
    <Data Name="TransmittedServices">-</Data>
    <Data Name="LmPackageName">NTLM V2</Data>
    <Data Name="KeyLength">128</Data>
    <Data Name="ProcessId">0x0</Data>
    <Data Name="ProcessName">-</Data>
    <Data Name="IpAddress">203.0.113.24</Data>
    <Data Name="IpPort">49712</Data>
    <Data Name="ImpersonationLevel">%%1833</Data>
  </EventData>
</Event>

İki yanlış kanı / Two reality checks

Sanılan: Bir NTLMv2 response yakalamak, o hesabın NT hash'ini ele geçirmekle aynıdır; response'tan hash çıkarılır.

Gerçekte: NTLMv2 response tek bir MAC değildir: kabloda taşınan NtChallengeResponse = NTProofStr || temp'tir; NTProofStr 16 baytlık bir HMAC-MD5 MAC, temp ise onu üreten client challenge/zaman damgası/TargetInfo blob'udur. Hiçbir parçası NT hash'i içermez ve geri çevrilerek NT hash'e dönüştürülemez. Yakalanan response en fazla offline parola tahmini için bir doğrulama aracı olur; parola güçlüyse pratikte kullanışsızdır. NT hash gerektiren pass-the-hash ise response'tan değil, hash'in kendisinden çalışır.

Sanılan: NTLMv2 tuzlanmış ve yinelemeli olduğu için modern parola hash'leri gibi offline tahmine dayanıklıdır.

Gerçekte: NTLMv2'de 'salt' rastgele değil, kullanıcı+domain adıdır ve anahtar türetmede iterasyon (yavaşlatma) yoktur. Bu yüzden yakalanan bir response'a karşı parola adayları çok hızlı denenebilir. Tek gerçek koruma parolanın gücüdür; NTLMv2'nin yapısı offline tahmini yavaşlatmaz.

Kaynaklar / Sources

• Microsoft Open Specifications · [MS-NLMP]: NT LAN Manager (NTLM) Authentication Protocol
  §3.3.2 NTLMv2 hesaplaması: NTOWFv2 = HMAC_MD5(MD4(UNICODE(Passwd)), UNICODE(Uppercase(User)+UserDom)); NTProofStr = HMAC_MD5(ResponseKeyNT, ServerChallenge || temp); SessionBaseKey = HMAC_MD5(ResponseKeyNT, NTProofStr).
• Microsoft Open Specifications · [MS-NLMP] §2.2.2.7 NTLMv2_CLIENT_CHALLENGE
  §2.2.2.7 NTLMv2_CLIENT_CHALLENGE (temp): RespType 0x01, HiRespType 0x01, TimeStamp (FILETIME), ChallengeFromClient (8 bayt), AvPairs; §2.2.2.8 NTLMv2_RESPONSE = Response(NTProofStr,16) + client challenge.
• Microsoft · NTLM overview
  NTLM'in challenge-response modeli, NT hash'in paroladan türeyen sabit özet olması ve kimlik doğrulamada parolanın kabloda gitmemesi; Kerberos'a yönlendirme.
• Microsoft · 4624(S) An account was successfully logged on
  Package Name (NTLM only) / LmPackageName değerleri ('NTLM V1','NTLM V2','LM'); Key Length; Authentication Package 'NTLM'; Logon Type 3; alanların yalnız NTLM oturumunda anlamlı olması.
• Microsoft · Access tokens
  Başarılı kimlik doğrulama sonucu oluşan access token kavramı; oturum açma sonrası kimliğin token ile temsil edilmesi (NT hash/response'tan bağımsız yetki bağlamı).
• MS-NLMP Client Receives a CHALLENGE_MESSAGE
  MsvAvTimestamp or Currenttime; conditional KEY_EXCH/sign/seal