usdt支付平台(www.caibao.it):内网渗透协议学习

来源:申博官方网 发布时间:2021-03-25 浏览次数:

USDT官网

菜宝钱包(caibao.it)是使用TRC-20协议的Usdt第三方支付平台,Usdt收款平台、Usdt自动充提平台、usdt跑分平台。免费提供入金通道、Usdt钱包支付接口、Usdt自动充值接口、Usdt无需实名寄售回收。菜宝Usdt钱包一键生成Usdt钱包、一键调用API接口、一键无实名出售Usdt。

kerberos协议

kerberos协议中的角色与简朴流程

Kerberos是一种由MIT(麻省理工大学)提出的一种网络身份验证协议。它旨在通过使用密钥加密手艺为客户端/服务器应用程序提供强身份验证。

在kerberos协议之中主要是有三个角色存在:

  • Client(用户):发出接见服务的角色
  • Server(服务):提供服务的角色
  • KDC(Key Distribution Center)密钥分发中央:分发密钥的角色

在一个域林之中,KDC服务默认会安装在域控之中,而client和server是域内的用户或者服务。在kerberos认证历程中client是否有权限接见server的服务就由KDC发放的票据决议

简化的Kerberos认证流程图

名词看法

AD(Account Datebase):账户数据库

Master Key: 用户密码的一种hash值

Ticket(票据):域网络工具相互接见的凭证

TGT(Ticket Granting Ticket 票据授予票据):用于向KDC获取服务票据的凭证

TGS(Silver Ticket 服务票据):用于向Server请求服务的凭证

Authentication Service(身份认证服务):认证Client 的身份,并为其发放TGT的服务,是KDC的一部门

Ticket Granting Service(票据发放服务):磨练Client发来的TGT,并为其天生某个Server的TGS,是KDC的一部门。

  1. AS_REQ(认证服务请求):Client向KDC发送AS_REQ,请求的凭证是Client的hash(这个hash是凭证输入的密码天生的)加密的时间戳。
  2. AS_REP(认证服务响应):KDC向发出AS_REQ的Client发出响应,去若是认证乐成就返回一个TGT
  3. TGS_REQ(票据发放服务请求):Client依附TGT向KDC发送对某一Server的TGS_REQ
  4. TGS_REP(票据发放服务响应):KDC验证TGT,若是验证准确就凭证请求的服务返回对应的TGS,不管是否有权向接见Server
  5. AP_REQ(服务请求):Client依附TGS向Server提议服务请求
  6. AP_REP(服务响应):Server验证TGS,若是验证准确就向KDC询问,Client是否有权限获得服务,若是有就返回响应

AS_REQ

数据包结构拆解

Kerberos
    Record Mark: 294 bytes
        0... .... .... .... .... .... .... .... = Reserved: Not set
        .000 0000 0000 0000 0000 0001 0010 0110 = Record Length: 294
    as-req
        pvno: 5
        msg-type: krb-as-req (10)
        padata: 2 items
            PA-DATA PA-ENC-TIMESTAMP
                padata-type: kRB5-PADATA-ENC-TIMESTAMP (2)
                    padata-value: 3041a003020112a23a04384e3857102e1da38ea37695b42c…
                        etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
                        cipher: 4e3857102e1da38ea37695b42cc877f2dfbc29a67c6c8f21…
            PA-DATA PA-PAC-REQUEST
                padata-type: kRB5-PADATA-PA-PAC-REQUEST (128)
                    padata-value: 3005a0030101ff
                        include-pac: True
        req-body
            Padding: 0
            kdc-options: 40810010
                0... .... = reserved: False
                .1.. .... = forwardable: True
                ..0. .... = forwarded: False
                ...0 .... = proxiable: False
                .... 0... = proxy: False
                .... .0.. = allow-postdate: False
                .... ..0. = postdated: False
                .... ...0 = unused7: False
                1... .... = renewable: True
                .0.. .... = unused9: False
                ..0. .... = unused10: False
                ...0 .... = opt-hardware-auth: False
                .... 0... = unused12: False
                .... .0.. = unused13: False
                .... ..0. = constrained-delegation: False
                .... ...1 = canonicalize: True
                0... .... = request-anonymous: False
                .0.. .... = unused17: False
                ..0. .... = unused18: False
                ...0 .... = unused19: False
                .... 0... = unused20: False
                .... .0.. = unused21: False
                .... ..0. = unused22: False
                .... ...0 = unused23: False
                0... .... = unused24: False
                .0.. .... = unused25: False
                ..0. .... = disable-transited-check: False
                ...1 .... = renewable-ok: True
                .... 0... = enc-tkt-in-skey: False
                .... .0.. = unused29: False
                .... ..0. = renew: False
                .... ...0 = validate: False
            cname
                name-type: kRB5-NT-PRINCIPAL (1)
                cname-string: 1 item
                    CNameString: testuser
            realm: HACKE
            sname
                name-type: kRB5-NT-SRV-INST (2)
                sname-string: 2 items
                    SNameString: krbtgt
                    SNameString: HACKE
            till: 2037-09-13 02:48:05 (UTC)
            rtime: 2037-09-13 02:48:05 (UTC)
            nonce: 19228112
            etype: 6 items
                ENCTYPE: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
                ENCTYPE: eTYPE-AES128-CTS-HMAC-SHA1-96 (17)
                ENCTYPE: eTYPE-ARCFOUR-HMAC-MD5 (23)
                ENCTYPE: eTYPE-ARCFOUR-HMAC-MD5-56 (24)
                ENCTYPE: eTYPE-ARCFOUR-HMAC-OLD-EXP (-135)
                ENCTYPE: eTYPE-DES-CBC-MD5 (3)
            addresses: 1 item WIN10-X64-TEST<20>
                HostAddress WIN10-X64-TEST<20>
                    addr-type: nETBIOS (20)
                    NetBIOS Name: WIN10-X64-TEST<20> (Server service)
  • pvno

kerberos版本号

  • msg-type

windows新闻类型,AS_REQ的自然是krb-as-req

  • padata(pre-authentication data 预认证数据)

是一些认证信息,是一个列表,内部有若干个认证新闻,每一个认证新闻有type和value。

详细可看:Kerberos PA-DATA

  • req-body

    • kdc-options

    这是一些KDC的option开启情形,属于一种标识位。 mit文档

    • cname

    这是Client的主机名,接纳的是PrincipalName 类型和string类型的组合。sname也是接纳这种花样

    PrincipalName 类型

    KRB_NT_PRINCIPAL 用户主体名称类型

    KRB_NT_SRV-INST 服务和其他唯一实例(krbtgt)的名称类型

    KRB_NT_SRV_HST 服务主机名称为实例名的名称类型

    KRB_NT_SRV_XHST 服务与主机作为剩余组件名称类型

    KRB_NT_UID 唯一ID名称类型

    KRB_NT_UNKNOWN 未着名称类型

    • realm

    服务端域名

    • sname

    这是是服务端的身份和所属域,注重在AS_REQ中服务端指的是提供AS的KDC,以是正常的sname-string字段的值就应该是krbtgt和其所属域.

    • till

    到期时间

    • etype

    加密类型,在请求报文之中每个有加密的数据都有一个etype字段对应,KDC就是从这段数据中加密方式,来从AD之中选择对应的hash来举行身份验证

    • addresses

    地址相关信息@

KDC吸收AS_REQ的行为

两个主要的padata(pre-authentication data 预认证数据)

PA-ENC-TIMESTAMP

这个预认证数据是Client用自己的Master key加密时间戳获得的一串字符, AS拿到这个段数据之后就会凭证etype去AD内里寻找对应的用户hash(用户名取自cname),并使用这个hash解密时间戳, 若是解密乐成, 而且时间戳在一定局限之内,则这个预认证数据通过.

PA-PAC-REQUEST

这个预认证数据是关于微软的一个扩展---PAC, 这个扩展的基本作用就是为kerberos添加"权限认证"的能力. 开启这项扩展,AS完成时间戳的认证之后就会将PAC(内部原谅Client的sid和所在组)放TGT的认证数据之中, 一起返回给Client, PAC关系到之后Server判断Client是否有权限接见服务

AS_REP

拆解数据包

Kerberos
    Record Mark: 1550 bytes
        0... .... .... .... .... .... .... .... = Reserved: Not set
        .000 0000 0000 0000 0000 0110 0000 1110 = Record Length: 1550
    as-rep
        pvno: 5
        msg-type: krb-as-rep (11)
        padata: 1 item
            PA-DATA PA-ENCTYPE-INFO2
                padata-type: kRB5-PADATA-ETYPE-INFO2 (19)
                    padata-value: 3020301ea003020112a1171b154841434b452e544553544c…
                        ETYPE-INFO2-ENTRY
                            etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
                            salt: HACKE.TESTLABtestuser
        crealm: HACKE.TESTLAB
        cname
            name-type: kRB5-NT-PRINCIPAL (1)
            cname-string: 1 item
                CNameString: testuser
        ticket
            tkt-vno: 5
            realm: HACKE.TESTLAB
            sname
                name-type: kRB5-NT-SRV-INST (2)
                sname-string: 2 items
                    SNameString: krbtgt
                    SNameString: HACKE.TESTLAB
            enc-part
                etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
                kvno: 2
                cipher: 07b5d35de5b1ac006b831ff508a5ced14a010563418fd736…
        enc-part
            etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
            kvno: 4
            cipher: 70246fe54be2b6395f20dc6845b970d16bb3319ab304e3bb…

主要关注与AS_REQ差其余点

  • ticket

    这就是AS派发的TGT票据,内部所有密文的密钥都是krbtgtNTLM hash,若是能拿到krbtgtNTLM hash我们既可以伪造TGT,这就是黄金票据

    • tkt-vno

      票据版本

    • realm

      派发票据的KDC的所属域

    • sname

      ,

      Usdt第三方支付接口

      菜宝钱包(www.caibao.it)是使用TRC-20协议的Usdt第三方支付平台,Usdt收款平台、Usdt自动充提平台、usdt跑分平台。免费提供入金通道、Usdt钱包支付接口、Usdt自动充值接口、Usdt无需实名寄售回收。菜宝Usdt钱包一键生成Usdt钱包、一键调用API接口、一键无实名出售Usdt。

      ,

      派发票据的角色再KDC的身份,一样平常是kbrtgt

    • enc-part

      使用kbrtgtNTLM hash作为密钥天生的TGT主体

  • enc-part

    这部门是使用Client的hash为key加密Session key获得的,主要用于作为下阶段(TGS阶段)的认证密钥。

AS阶段的平安问题

用户名枚举

在AS认证截断,用户名存在和密码错误的响应报文错误码差异,

  • 用户名不存在的响应错误码是6:KDC_ERR_C_PRINCIPAL_UNKNOWN 未知的主机名

  • 密码错误,用户名存在的响应错误码是24:KDC_ERR_PREAUTH_PAILED 预认证失败

通过这个对照AS_REP里的错误码就可执行 用户名枚举 .

黄金票据

AS_ERP里的tikcet的encpart是使用kbrtgtNTLM hashkey加密而成的,以是只要拿到了kbrtgtNTLM hash就可以伪造TGT,这个伪造出来的票据就叫做 黄金票据

TGS_REQ

拆解数据包

Frame 40: 62 bytes on wire (496 bits), 62 bytes captured (496 bits) on interface DeviceNPF_{FBDB2B2D-DEF3-473C-87EF-787E4B606694}, id 0
Ethernet II, Src: VMware_f0:d8:2b (00:0c:29:f0:d8:2b), Dst: VMware_e6:ab:e6 (00:0c:29:e6:ab:e6)
Internet Protocol Version 4, Src: 192.168.1.2, Dst: 192.168.1.1
Transmission Control Protocol, Src Port: 49731, Dst Port: 88, Seq: 1461, Ack: 1, Len: 8
[2 Reassembled TCP Segments (1468 bytes): ,39(1460), ,40(8)]
Kerberos
    Record Mark: 1464 bytes
    tgs-req
        pvno: 5
        msg-type: krb-tgs-req (12)
        padata: 2 items
            PA-DATA PA-TGS-REQ
                padata-type: kRB5-PADATA-TGS-REQ (1)
                    padata-value: 6e8204f4308204f0a003020105a10302010ea20703050000…
            PA-DATA PA-PAC-OPTIONS
                padata-type: kRB5-PADATA-PAC-OPTIONS (167)
                    padata-value: 3009a00703050040000000
        req-body
            Padding: 0
            kdc-options: 40810000
                0... .... = reserved: False
                .1.. .... = forwardable: True
                ..0. .... = forwarded: False
                ...0 .... = proxiable: False
                .... 0... = proxy: False
                .... .0.. = allow-postdate: False
                .... ..0. = postdated: False
                .... ...0 = unused7: False
                1... .... = renewable: True
                .0.. .... = unused9: False
                ..0. .... = unused10: False
                ...0 .... = opt-hardware-auth: False
                .... 0... = unused12: False
                .... .0.. = unused13: False
                .... ..0. = constrained-delegation: False
                .... ...1 = canonicalize: True
                0... .... = request-anonymous: False
                .0.. .... = unused17: False
                ..0. .... = unused18: False
                ...0 .... = unused19: False
                .... 0... = unused20: False
                .... .0.. = unused21: False
                .... ..0. = unused22: False
                .... ...0 = unused23: False
                0... .... = unused24: False
                .0.. .... = unused25: False
                ..0. .... = disable-transited-check: False
                ...0 .... = renewable-ok: False
                .... 0... = enc-tkt-in-skey: False
                .... .0.. = unused29: False
                .... ..0. = renew: False
                .... ...0 = validate: False
            realm: HACKE.TESTLAB
            sname
                name-type: kRB5-NT-SRV-HST (3)
                sname-string: 2 items
                    SNameString: host
                    SNameString: win10-x64-test.hacke.testlab
            till: 2037-09-13 02:48:05 (UTC)
            nonce: 19595592
            etype: 5 items
                ENCTYPE: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
                ENCTYPE: eTYPE-AES128-CTS-HMAC-SHA1-96 (17)
                ENCTYPE: eTYPE-ARCFOUR-HMAC-MD5 (23)
                ENCTYPE: eTYPE-ARCFOUR-HMAC-MD5-56 (24)
                ENCTYPE: eTYPE-ARCFOUR-HMAC-OLD-EXP (-135)
  • msg-type

    windows新闻花样,krb-tgs-req

  • padata

    这部门携带了TGS_REQ最主要的数据—TGT票据,TGT票据以ap-req的形式存放在数据包之中。KDC会校验TGT,若是准确就返回TGS票据

    这部门数据和还包罗PAC和S4U2SELF,这个之后其他文章单独说

  • req-body

    花样和之前的请求报文基本一致,只是这里的sname换成了Client想要请求服务的Server的名字

TGS_REP

数据包拆解

Kerberos
    Record Mark: 1495 bytes
        0... .... .... .... .... .... .... .... = Reserved: Not set
        .000 0000 0000 0000 0000 0101 1101 0111 = Record Length: 1495
    tgs-rep
        pvno: 5
        msg-type: krb-tgs-rep (13)
        crealm: HACKE.TESTLAB
        cname
            name-type: kRB5-NT-PRINCIPAL (1)
            cname-string: 1 item
                CNameString: testuser
        ticket
            tkt-vno: 5
            realm: HACKE.TESTLAB
            sname
                name-type: kRB5-NT-SRV-HST (3)
                sname-string: 2 items
                    SNameString: host
                    SNameString: win10-x64-test.hacke.testlab
            enc-part
                etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
                kvno: 1
                cipher: 1fc40f7b907bea22e5606abf4f0575c113b8f5ee8d87ce4f…
        enc-part
            etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
            cipher: e4705cfafb271944be50c33f4576bb4b4e449357fbdbb18f…
  • msg-type

    windows新闻花样,krb-tgs-rep

  • crealm

    Client所属域

  • cname

    Client的身份名

  • ticket

    这就是最终的票据,是使用Client请求服务的Server的hash作为key来加密获得的。内部包罗:Server session keyClient info (Domain nameclient)end time (到期时间)

  • enc-part

    这一部门是使用AS认证中得Session key为key加密成得内部有Server session key,主要用于下轮用户认证(AP阶段)
    , NTML协议

LM Hash&NTML Hash

windows内部是不保留明文密码的,只保留密码的hash值

本机的用户密码hash是放在内陆的SAM文件内里,域内用户的密码hash存在域控的NTDS.DIT文件的。

windows密码hash保留模式,类似如下

Administrator:500:AAD3B435B51404EEAAD3B435B51404EE:31D6CFE0D16AE931B73C59D7E0C089C0:::

AAD3B435B51404EEAAD3B435B51404EELM hash

31D6CFE0D16AE931B73C59D7E0C089C0NTML hash

LM hash (LAN Manager Hash) 老密码

LM Hash 的算法

  1. 将用户密码转化为大写,再将转化后的密码转化成十六进制字符串,不足14字节将会使用0再末尾补全。
  2. 上一步获得的十六进制字符串分成两个7byte的部门,每部门转化成byte流,长度为56bit,长度不足的使用0在左边补齐。
  3. 再分为7bit一组,每组末尾加0,凑足8bit,重新组回两组。
  4. 上步骤获得的二组,划分作为Key对KGS!@,$%举行DES加密。
  5. 加密后的两组拼接到一起,获得最终的LM Hash

LM Hash的一些坏处

  • 密码方面的限制
    • 密码长度最大只能为14个字符
    • 密码不区分巨细写
  • 加密历程中的一些破绽
    • 若是密文的后半部门是aad3b435b51404ee,那么就意味着,这个密码的长度是小于即是7位的,密码强度大大削减
    • des密码强度并不高

NTLM hash

NTLM hash 的算法

  1. 将用户的密码转化成16进制形式
  2. 把转化成16进制的密码举行unicode编码
  3. 使用MD4摘要算法对上一步获得的unicode编码举行hash盘算

NTLM hash内陆的认证

当用户注销、重启、锁屏之后,windows会让winlogon显示上岸界面,吸收用户的输入之后,会将将密码交付给lsass历程,这个历程会将明文密码加密成NTLM hash,再与SAM数据库里对应的用户密码做对比。

  • winlogon(Windows logon process)windows注册历程:是windows NT 用户的上岸程序,用于治理用户的上岸与退出

  • lsass( Local Security Authority Service): 用于内陆平安与上岸战略

  • SAM(Security Account Manager 平安账户治理):windows接纳的账户治理战略,这个战略会将内陆组的用户的账户和hash加密之后保留到SAM数据库中,SAM数据库文件路径是%systemroot%system32configSAM文件

NTLM 身份验证机制

NTLM 身份验证接纳的是 Challenge(挑战)/Response(响应)验证机制,有三步组成:协商,质询,身份验证

客户机与服务器的交互历程示意图(域控不加入的情形)

  • 协商:Client会发送一个带有用户信息(用户名)和服务器请求的功效列表
  • 质询:Server对Client发出的协商 做出回应,返回的内容包罗服务器赞成而且支持的功效列表,更主要的是包罗了服务器发生的challenge
  • 身份验证:Client对Server返回的质询 做出回应,使用根具输入的密码天生的NTMLM hash质询 中的challenge举行加密运算获得response,然后将response、用户名、challenge一起返回给Server

关于challenge:服务端天生的一个随机字符用于验证Client的身份,NTLM v1中为8位,NTLM v2中为16位

关于Net-NTML hash:基于用户hash经由一定算法发生的。

关于response:本质上就是一个net-NTLM hash

发表评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 验证码:点击我更换图片