Windows协议

NTLM协议

• NTLM：身份验证协议
• SSPI:接口
• SSP：key 不同ssp，身份验证机制不同
• LM Hash： DES，分为两组处理 2008开始默认禁用 明文密码14位以内，LM Hash aad3b。。。。说明空值或被禁用

• NTLM Hash：

  • 基于md4，转十六进制 转Unicode md4
  • 存储在C:\Windows\system32\config\SAM中
  • winlogon.exe接受输入后，交给lasass.exe，其中存储一份明文密码

• NTLM协议认证：质询响应

  • 协商 质询 认证 NTLMv1 v2 Challenge值和加密算法不同 都是用NTLMHash加密
  • Negotiate包 客户端发送启动NTLM认证
  • Challenge包 返回Chanllenge 码 16B字符串

  • Authenticate包 关键 NTLMv2 Response=NTProofStr+blob

    • LM，NTLMv1，。。。。。选择方式由LmCompatibility-Level决定
    • NTLM v2 Hash=HMAC-MD5(unicode(hex(upper(Username)+DomainName)),NTLM Hash)
    • NTProofStr=HMAC-MD5(challenge+blob,NTLMv2 Hash)
    • MIC
    • Net-NTLM v2 格式 username:domain:challenge:HMAC-MD5（指response）:blob

• 安全问题 PTH NTLM Relay

  • Net-NTLM v1 Hash破解 域控只发送NTLM响应，使用responsed监听，利用打印机漏洞或Petitpotam漏洞触发强制认证，接受v1hash，用ntlmv1获取NTLMHash,在http://crack.sh/get-cracking/解密，使用secretsdump导出所有域用户身份凭证

Keberos协议

• 三个角色

  • 客户端 服务端 KDC(服务账户krbtgt，是创建活动目录时系统自动创建的账户，密码系统随机，运行在域控上)
  • 认证模块：AS_REQ&AS_REP和TGS_REQ&TGS_REP，拓展模块S4U（委派）PAC

• PAC

  • 辨别用户身份权限
  • 好处是在之后的资源访问中，服务端不需要借助KDC提供完整的授权信息完成对用户权限的判断，直接根据PAC与本地的ACL比较
  • PAC顶部结构里面会有BUFFER数组
  • PAC_INFO_BUFFER装有Logon Info Client Info Type等
  • Logon Info中的PAC_LOGON_INFO包含客户端凭证信息，由KERB_VALIDATION_INFO中经过NDR编码来的,有y用户名，RID等值
  • 签名：PAC_SERVER_CHECKSUM（服务密钥签名）和PAC_PRIVSVR_CHECKSUM（KDC密钥签名）
  • KDC验证PAC，主机如果配置验证KDC PAC签名，服务端将客户端发来的ST中的PAC发给KDC校验， RPC通信，白银票据攻击

• AS_REQ&AS_REP

  • 向KDC的AS请求TGT，身份验证通过后，KDC发放TGT
  • req中字段PA-DATA pA-ENC-TIMESTAMP用用户密码Hash加密的时间戳发送给KDC的AS，KDC查出Hash，解密，在一定范围内，认证通过，可以进行PTH。 预认证，还可以用用户密码的AES Key加密
  • 请求用户名cname，用户名和密码正确均会影响响应包内容
  • 包含请求的服务名sname
  • rep中主要两部分是ticket（也就是TGT，里面有enc-part（内部，用krbtgt的密码Hash进行加密，如果有其hash，可以自己做ticket，也就是黄金票据））和enc-part(外部)
  • TGT中的enc-part里面还有加密的Logon Session Key，以及PAC（主要通过RID，UID来辨别权限），KDC生成PAC的过程，收到req之后，取出cname，查询ad库，找到cname对应的字段，用该身份生成PAC
  • 外部的enc-part是用户hash加密的Logon Session Key，用于下阶段通信

• TGS_REQ&TGS_REP

  • 客户端收到后，用hash解密logon_session key，本地缓存TGT和key，发送TGT票据和logonsessionkey加密的时间戳（authenticator），保护安全

  • KDC中的TGT收到后，进行三个验证

    • 用krbtgt密钥解密TGT加密的部分，得到logonsesssionkey和PAC，解密成功则说明TGT是KDC颁发
    • 验证PAC签名，正确证明未经篡改
    • 用logonsessionkey解密authenticator，解密成功，且在有效范围内，验证会话的安全性
    • rep不验证客户端是否有权限访问服务端，，只要TGT正确，都会返回ST
    • rep中主要是ST（主要也是encpart内部（service sessionkey和PAC））和encpart（外部，logonkey加密的sevicesessionkey）
    • 正常非S4u2Self请求的TGS，ST和TGT中PAC相同

• AP-REQ&AP-REP

  • 收到TGS的rep后，用缓存的logonsessionkey解密servicekey，同时缓存拿到的ST
  • req时会携带ST，servicekey加密的时间戳（authenticator）
  • 服务端收到后会用服务密钥解密ST，得到sessionkey和pac，用session解密authenticator，成功且在一定范围内，则成功验证，从PAC中取出用户权限数据，对比ACL，生成访问令牌，检测mutual-required的值决定是否返回响应

• 委派

  • s4u2self:任意用户请求针对自身的ST
  • s4u2proxy：用上一步获得的ST以用户的名义请求针对其他指定服务的ST

• 攻击点

  • as-req:pth,域内用户枚举，密码喷洒
  • as-rep:黄金票据（有krbrgt密码hash，制作TGT），as-rep roasting（域用户设置不需要预认证，域控直接把tgt和hash加密的logonsessionkey返回，解密得到明文）
  • s4u:委派攻击
  • tgs-rep:白银票据（有服务的hash，构造ST）Kerberoasting攻击（TGT正确，均会返回ST，解密得到服务HASH）
  • pac：ms14-068

LDAP

• 标准目录访问协议，面向对象
• 对象属性：独一无二的DN，RDN是DN中用逗号分隔的表达式
• 认证：匿名，简单密码，SASL认证
• CLDAP：匿名访问，非详细信息
• 可在powershell查询主机域，或用go语言编写