0%

域渗透入门2.0

域渗透入门2.0

很多年以前由于科恩的任务简单的对域进行了基础的了解,但是学的很浅,网上抄的环境也很垃圾,上来就直接拿到了域管,并且自带永恒之蓝等一系列一键system的洞,加上实战一次域都没遇上过,所以实际上学的很差。最近打了一个小护网,遇到了一个无敌防御的域,这下才知道之前学的东西全是臭鱼烂虾,一点派不上用场。
所以重新入门,把以前没有很搞清楚的概念再强化一下

常用命令

常用的三个工具:自带的net,powerview.ps1,adfind.exe,adfind的最大缺点是exe基本上不免杀了,得rdp之类的上去关了杀软再操作

powerview这里有一个很完整的document,可以直接查这个,查询后面接| select name可以只显示对应的字段,并且字段支持通配符
powerview doc

net user xxx /domain

看一个人的具体信息,有点用的就是看其组成员吧,可能是本地的administrator之类的,也可以看密码过期策略,不过我感觉密码永不过期实际上看了也没什么用。。。
密码永不过期是用户属性中的userAccountControl的一位,可以改这个数字去查其他属性,-dn是只返回DN

Adfind.exe -b dc=god,dc=org -f "(userAccountControl:AND:=65536)" -bit -dn

偷wifi密码的命令。。。可能在钓鱼之后可以通过wifi密码推导其他密码?

for /f "skip=9 tokens=1,2 delims=:" %i in ('netsh wlan show profiles')  do @echo %j | findstr -i -v echo |  netsh wlan show profiles %j key=clear

域控

net group "domain controllers" /domain

域管

net group "domain admins" /domain

域控上的本地管理员,这里的localgroup不是指本地管理员,而是本地组,即当前计算机上的组,在域内按这个命令的时候就是查询域控上的本地组。该组内的用户即为域控的本地管理员(但域控的本地管理员并不意味着域内其他机器的管理员),并且改组包含了domain adminsenterprise admin两个域管组,即域管一定是域控管理员,但反过来,域控管理员并不一定是域管。

net localgroup administrators /domain

查域内机器,看完之后可以再ping或者nslookup查ip

net group "domain computers" /domain

看有没有用户在线,非常好用,以防rdp上去给管理员挤掉了的尴尬场面,但是给出的登录时间总感觉是乱写的,以及似乎只有server上有这个命令?也不是,好像是家庭版没有?win10家庭版没有,win7专业版有
然而并不能防止自己操作到一半后管理员突然登录发现桌面花花绿绿的尴尬场面,以及似乎并非非常准确,似乎用户锁屏了也会显示Active?

query user

验证凭据有效性。直接用凭据去连接远程计算机,只要凭据对就能连上,但如果不是本地管理员权限的话psexec,smbexec等一套命令都用不了。在连上去之后可以尝试通过dir \\ip\$C等命令观察自己是不是本地管理员

net use

查看目标机器远程共享文件夹
默认应该是会分享出去C$,IPC$和ADMIN$,所有用户都能连接IPC$,不过只有本地管理员才能访问C$和ADMIN$,才能用psexec一类的执行命令

net view COMPUTER /all

开关远程桌面,1开0关

wmic RDTOGGLE WHERE ServerName='%COMPUTERNAME%' call SetAllowTSConnections 1

设置远程桌面端口

reg add "HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /t REG_DWORD /v portnumber /d 3389 /f

查看当前机器上的票据(pass the ticket环节可能用的上,或者mmkz也可以抓票据出来)

klist

不知道有什么用的查看保存凭据的命令,好像是记录远程桌面时保存的密码之类的东西

cmdkey /list

LDAP

Active Directory是微软对目录数据库的实现,而LDAP协议就是用来对这个数据库进行访问的协议
AD中存储了域内所有用户计算机等实体相关的信息,域内ACL那一套权限都是通过LDAP存储的,经典的powerview和adfind也都是通过LDAP进行域内信息的查询

域使用LDAP协议对数据进行查询,然后存在一些对应的名词,在用powerview等工具的时候会遇到
DN(distinguish name,标识名称)域内描述某个对象的唯一标识符,应该是指用来查询的完整语句,如CN=xxx,DC=z33,DC=cn这种
CN(Common Name,通用名称),大部分的对象最后都会有一个通用名称,而这里不单指对象,组或者其他的对象都可以用CN描述
OU(organization unit,组织单元),用于被管理的一个分组
DC(Domain Component,域组件),就是把域名一个一个拆下来

LDAP的语法也有点玄学,支持与或非(&|!)三个经典运算加上等于和通配符*,adfind.exe就是使用这个语法进行查询的
其中与或非操作的位置是在两个运算的前面而非中间,如(|(uid=1)(uid=2))指代uid为1或2的项

ACL相关

ACL就是用来配置权限的,不过这里需要首先明确的一点是,对于一个对象的ACL来说,限定的是其他对象对当前对象的访问权限,而非当前对象对其他对象的访问权限。

powerview下命令,查看对用户zhang拥有完全控制权限的acl项,结果中的SecurityIdentifier项表示了对查询用户拥有完全控制权限对象的SID,还需要解析出这个SID对应的是谁。。。-ResolveGUIDs说是能解析GUID成可读的形式,但这里面也没有GUID啊,全是SID。。。

Get-ObjectAcl -SamAccountName test -ResolveGUIDs | ? {$_.ActiveDirectoryRights -eq "GenericAll"}

可以用如下命令查看用户的SID

Get-NetUser | select samaccountname,ObjectSID

然后套一层SID查询查某个对象对另一个对象的ACL

Get-ObjectAcl -SamAccountName test -ResolveGUIDs | ? {$_.SecurityIdentifier -eq "<sid>" -and $_.ActiveDirectoryRights -eq "GenericAll"}

sid的前面那一长串是域的id,只有最后面这个数字和当前用户关联,域id可以用Get-DomainSID查询,当前用户的

推荐阅读,介绍了几个不同权限的利用方法
AD域中的ACL攻防探索
BloodHound 1.3 – The ACL Attack Path Update
Abusing Active Directory ACLs/ACEs

乱点的时候发现everyone对域内的每个账户都有修改密码(Change Password)的权限,还以为是什么顶级配置错误,后来发现修改密码是指知道原密码的情况下修改。。。无视条件改密码那个叫重置密码(Reset Password)。但是试了一下单独添加一个重置密码权限是不能重置密码的。。。至少需要重置密码,写入全部属性和修改权限三个权限才行,其中后面两个属性是在特殊属性里面。网上有文章说有一个属性叫Force Reset Password,但是图形界面这边好像没看见这种属性

组是权限的集合,组内成员会拥有组内的权限,而组分为域本地组,通用组和全局组。后面这两个是在和林交互的时候有特殊的规则,域本地组就是单个域内生效的组。
域管理员的组为Administrators(本地组),而该组下包含两个实际的组,Domain Admins(全局组)和Enterprise Admin(通用组),默认情况下,Domain Admins会被加入域内所有 机器的本地管理员组
Domain Users这个组也是全局组,改组默认情况下会被加入域内所有机器的本地用户组,所以可以到处登录
机器用户是位于Domain Computers,所以不能随意登录,机器用户的用户名是当前机器名后加$,当发现机器在域内而该机器上没法拿到域内用户时,提权到system就可以用机器用户去进行域内的访问

当然,不排除有奇怪的配置把机器用户配的到处能登录,或者安全拉满限定哪些用户能登录哪些机器或者哪些机器可以被某个用户登录
域用户和机器用户
域用户和计算机用户介绍

OU

OU中文名组织单元,是用于被管理的组,组策略一般就被应用于OU之上,对OU的完全控制可以延伸为对OU下所有对象的完全控制,只要目标对象支持从父项中继承权限(例外会在AdminSDHolder中提到)。这里是我朋友给我的一个例子,其中ou和user要替换可完全控制的OU和想添加权限的用户(需引入powerview后执行)

$Guids = Get-DomainGUIDMap; 
$AllObjectsPropertyGuid = $Guids.GetEnumerator() | ?{$_.value -eq 'All'} | select -ExpandProperty name;
$ACE = New-ADObjectAccessControlEntry -Verbose -PrincipalIdentity <user> -Right GenericAll -AccessControlType Allow -InheritanceType All -InheritedObjectType $AllObjectsPropertyGuid;
$OU = Get-DomainOU -Raw <ou>; 
$DsEntry = $OU.GetDirectoryEntry();
$dsEntry.PsBase.Options.SecurityMasks = 'Dacl';
$dsEntry.PsBase.ObjectSecurity.AddAccessRule($ACE);
$dsEntry.PsBase.CommitChanges()

AdminSDHolder

一个用于保护特权组的对象,众所周知,每个对象都会有一组ACL,描述其他对象对它的访问权限,而AdminSDHolder的ACL,和受保护组(windows内置的一组特权组)的ACL是一致的,AdminSDHolder中的ACL,即为受保护组的ACL,这组权限每隔60分钟会通过一个叫做SDProp的进程同步到受保护的特权组中,保持特权组的同步。所以网上的文章大多专注于获取域管权限后,通过AdminSDHolder留存后门,位于保护组的对象在用户属性中会有一项admincount为1。但除此之外,关于AdminSDHolder和保护组还有更多的东西可以学

如下是使用adfind和powerview查看特权组的方法

Adfind.exe -f "&(objectcategory=group)(admincount=1)" -dn
Adfind.exe -f "&(objectcategory=user)(admincount=1)" -dn
Get-NetUser -AdminCount |select samaccountname    //只显示用户名
Get-NetGroup -AdminCount
Get-NetUser -AdminCount

但是如果一个对象曾经在保护组中后来又被移除,这个值也不会改变,仍然是1

微软文档中有这么一段

First, the permissions applied to users belonging to protected groups are more stringent than the default permissions applied onto other user accounts. Next, the default behaviour is that inheritance is disabled on these privileged accounts, ensuring that permissions applied at the parent level aren’t inherited by the protected objects, regardless of where they reside. Finally, the background process running every 60 minutes identifies manual modifications to an ACL and overwrites them so that the ACL matches the ACL on the AdminSDHolder object.

AdminSDHolder, Protected Groups and SDPROP
AdminSDHolder, Protected Groups and Security Descriptor Propagator

即保护组的成员默认拥有更强的安全限制,并且设置上不允许继承来自上层的权限,权限被修改的情况下也会每半个小时重新同步

这次就遇到了一个域,然后域内配置了一个everyone对某个OU拥有generic all的权限,而这个OU下是有管理员账户的,当时朋友用上面的powershell操作给OU及其全部后代加了个generic all的权限,结果普通账户可控,域管仍然不可控,百思不得其解,今天自己搭环境复现才发现是这么回事。对上级容器的完全控制应该可以延伸到子级对象,除非子级对象拒绝继承权限。

如下图,test账户左下角有一个小勾,内容为包括可从该对象父对象继承的权限,而被选中的内容即为从其所在的OU继承的,normal用户对其的完全控制权限,而AdminSDHolder项中该对勾没有被选中,也可以看到所有的权限中继承与这一列均为不是继承的。不过没有翻到怎么查这个地方勾没勾上的语法,不然还可以过滤一下组下面哪些账户能直接控制(BloodHound里有admincount那个属性,可以自己写个查询)

image-20230608204109629

image-20230608204249327

GPO

组策略对象,组策略主要由GPO,OU和GPLink组成,GPO 规定策略内容,OU是组策略应用的目标,而GPLink将组策略和OU关联起来。

Get-DomainGPO | select name,displayname

组策略中,这个查询只能查到组策略的名字相关的属性,具体的内容需要连到域控的网络共享上面才能看,路径是\\<DomainController>\SYSVOL\<DomainName>\\Policies\\<name>

name是用花括号包裹起来的一个uuid,但是这个不是唯一的,有另一个叫objectid的属性才是全局唯一的。组策略默认是继承的,即应用到一个OU上的组策略会应用到其所有子OU上。gplink被存储在gpo应用到的对象上,属性为gplink,其最后面的数字1表示该策略强制生效,否则不强制

可以使用net view <computerName>来查看目标机器的网络共享有哪些,一般来说SYSVOL是开启的

  • If a GpLink is enforced, the associated GPO will apply to the linked OU and all child objects, regardless of whether any OU in that tree blocks inheritance.
  • If a GpLink is not enforced, the associated GPO will apply to the linked OU and all child objects, unless any OU within that tree blocks inheritance.

也就是说组策略是一定会生效的,是否允许继承只会在组策略非强制部署的情况下阻断继承

Reminder: GPOs can only apply to users and computers, not security groups.

也就是说如果OU下面有组的话,组对象下的对象是不会受GPO影响的咯?

GPO这边推荐用powerview的New-GPOImmediateTask,可以直接powershell一键上线之类的,或者加两个用户进本地管理员。组策略目测是用目标机器的机器用户运行的,直接是system权限。但是滥用的前提是给用户提供了修改组策略的权限,而这个权限一般只有域管有。。。所以还是实战看情况吧

Abusing GPO Permissions
A Red Teamer’s Guide to GPOs and OUs

kerberos回顾

以前学过,然后忘了,做简单回顾

kerberos的特点就是服务过程中有三方认证,其中KDC中包括了AS和TGS,提供服务的server单独一边

认证过程为用户先向AS发起一个身份认证,若身份认证通过,AS返回一个TGT,该票据可用于识别用户身份。TGT使用krbtgt账号的hash进行加密,TGT里面会包含一个PAC,用于标识用户(似乎在哪提到过TGT是不常更新的,下发一个之后用户可以长时间不用再认证?)
当用户想访问某个服务时,需将TGT发送给TGS,TGS验证TGT正确后,会签发一份TGS票据,TGS票据由对应服务的hash进行加密(该票据无论用户是否有权访问服务都会签发)
最后用户将获得的TGS提交给server,server会把PAC解密出来再次去KDC验证是否该用户具有服务访问提供权限并提供服务

攻击中的黄金票据就是能够拿到KDC中的krbtgt的hash,这样子这样子就可以自己签发TGT,伪装成任意用户,并使用该TGT申请一切服务

白银票据则是获取了对应服务的hash,这样子可以签对应服务的TGS,响应的就只能伪造出对该服务的任意访问权限,但是PAC只能由KDC签出来,利用的前提是该服务不进行PAC校验

暂时只做粗糙的回顾,具体细节可参见windows protocol kerberos篇

非约束委派

这边想学的一个点是非约束委派攻击。

委派是指一个用户可以将权限委派给另一个用户(通常是服务类用户)展开活动,那么非约束委派就是指没用任何限制条件的委派了咯

由于委派使得被委派对象可以使用委派对象的权能,那么这其中就一定有某种形式的凭证传递。而这里传递的凭证就是用户的TGT。假设用户想通过service a访问service b,用户会先去AS申请TGT,再申请对service a的TGS,并将TGT附在TGS中访问service a,接下来service a会从中提取出TGT再从KDC处申请对service b的TGS,并使用该TGS代表用户对service b发起请求。

由于用户将TGT发送给了service a,service a会将TGT存在LSASS中,如果能将其dump出来就等于是获得了用户的TGT

完成该攻击有两个前置条件,1. 获得非约束委派机器的权限(用于dump TGT),2. 发起委派的用户需未设定不能委派属性

接下来只需要使需要获取权限的账户对非约束委派机器发起访问,即可获得对应的账户权限。等待管理员账户访问是不太现实的,所以比较合理的方案是利用经典的打印机bug,强制机器用户(比如域控机器)发起远程认证,进而获取其凭证。获取凭证后用mimikatz pass the tickle使用经典DCSync一键dump所有hash

非约束委派的账户的UserAccount属性会设定TRUSTED_FOR_DELEGATION位,值为0x80000,转成十进制524288,在powerview中可以使用如下语句查询,BloodHound也有内置的一键查询

Get-NetComputer -Unconstrained -Domain z33.com
Get-NetUser -Unconstrained -Domain z33.com | select name

域委派攻击详解

约束委派

约束委派并不是限制了可以发起委派的用户,而是限制了委派后可以访问的服务。约束委派需要域管理员权限才能设置,设置后不需要用户交互就可以模仿用户权限。流程为用户按kerberos协议签出一个访问约束委派服务的TGS发给约束委派账户,然后约束委派可以用这个TGS去KDC再签出一个访问对应服务的TGS,并以用户的身份访问对应服务

由于这个过程中没有用户的TGT,用户访问约束委派的TGS本身就是用约束委派自身的hash加密的,所以不能偷域控TGT签黄金票据,但也使得利用也变得简单了起来。因为不需要用户来认证,也就不需要打印机bug之类的来诱导访问,只要拿下了约束委派的账户,就可以直接签任意TGS以任意身份访问可委派的服务,但后续只能根据委派的服务进行利用的分类讨论

下图即为约束委派和费约束委派的选项框

image-20230610122214139

基于资源的约束委派

上述两个委派的缺点在于需要域管理员配置才能进行,而基于资源的约束委派只需要对对应资源具有控制权即可进行。基于资源的约束委派与普通的约束委派相反,前者是在服务B上定义了服务B对服务A的信任,让A能以任何身份进行委派,而后者则是在服务A上定义了允许A传入B的委派。
是在windows server2012上引入的,所以当域控低于该版本的时候不能用

比如这台windows server2008 R2,就没有用于配置基于资源的约束委派所需的AllowedToActOnBehalfOfOtherIdentity

image-20230610122414603

当我们对一个计算机对象拥有写权限的时候,可以通过基于资源的约束委派,设置他信任我们自己添加的机器账户委派任何用户,然后使用该账户模仿域控控制目标机器
Kerberos Resource-based Constrained Delegation: Computer Object Takeover

In unconstrained and constrained Kerberos delegation, a computer/user is told what resources it can delegate authentications to;
In resource based Kerberos delegation, computers (resources) specify who they trust and who can delegate authentications to them.

Resource-based Constrained Delegation

但是在利用的时候需要注意模仿的账户是否可以被委派,在用户属性里有这么一条配置,不过默认好像是不会被勾选的

image-20230610142952365

利用细节

搭了个新一点的域环境尝试利用
域控winserver12, 攻击机win10,目标机器winserver16

大部分的命令都可以通过上述链接复制粘贴,但是到最后psexec处会失败,详情可以看这篇文章给出的情况,还给了利用完之后清理约束委派的命令
域渗透——基于资源的约束委派利用

使用Rubeus进行攻击的时候,生成cifs票据的时候就可以成功访问share目录了,但是psexec还是会被拒绝访问,这时需要额外再申请一个host票据即可实现psexec执行命令。文中有提到impacket就不会有这种问题,不过实际环境中python没有C#好用,所以懒得考虑。Rubeus的release没有二进制,直接编译出来的是.net3的版本,win10默认装的是.net4,所以需要改一下.net目标框架重新编一个.net4版本的来用。

然后是权限问题,似乎只有模拟成管理员才能执行psexec,原因好像是因为psexec需要用到共享的admin$文件夹?不知道有没有其他方法能pass the ticket并且不需要管理员的。
不过其实也没必要,因为能模仿任意用户,域内找一个是管理员的用户模仿就行了,有管理员为什么还要用普通用户呢?

这里还有一个玄学事件,是一开始我申请了两个票也打不通,最后把winserver16重启了一遍之后就百打百通了。。。

ms14 068

一个关于PAC的漏洞,允许任意用户被提升至域管。
PAC包含了用户的sid和gid,由于PAC由KDC生成,并用hash进行签名,用户在无法获得krbtgt的hash的情况下理论上是不能伪造PAC的,但是实现上出现了一点小问题,在签名校验时,可以指定任意的算法,比如md5,这样子就不需要任何hash简单的签一个md5就能伪造出一个PAC,然后伪造的PAC中修改gid,添加域管组到用户的gid中,用户就被提升到了域管

当然,PAC是包含在TGT里面的,不能制作TGT也就不能往里面塞PAC,那具体怎么操作就有其他的巧妙办法了,我是脚本小子,不学。只要知道有一个历史洞一键域内用户升到域管即可

NTLM hash

windows里面不用密码进行交互,走的都是hash,hash分为LM hash和NTLM hash,每次mimikatz之类的运行出来形如admin:500:aad3xxxx:xxxxx的结果中,aad3开头的就是LM hash,后面那个是NTLM hash,其中由于LM hash的强度太低,基本上已被弃用,aad3开头的这个值就是弃用后空密码加密出来的内容。

LM hash支持的最长密码是14位,且不区分大小写,在加密的时候还要把密码分成两个长度为7的部分分开加密,导致暴力破解的成功率极高
NTLM hash是用md4算法算的

感觉kerberos是用来进行服务鉴权的,NTLM是用来进行身份认证的?

NTLM采用的是挑战应答机制进行鉴权,client先向server发起请求,然后server会回复一个challenge,client使用hash对challenge进行加密,作为response返回,server对response进行校验,如果和challenge符合则通过,其中NTLM hash就是用来加密的hash,而发送的response一般被称为net ntlm hash

net NTLM获取

如果获取了用户的hash,就可以直接pass the hash为所欲为,但如果只是拿到一个net ntlm hash的话,就得上比较复杂的ntlm relay了。一般来说工作组中relay是没有用的,除非两个电脑的密码一样,但是域内的话域用户一般可以登录各种机器。那么对于非域的情况,可以考虑进行一个reflect,也就是将得到的net ntlm relay到自己,可惜微软通过一个补丁修了smb relay到smb的reflect,只能跨协议relay,比如smb到http之类的

那么如何让目标进行一个ntlm的认证呢,最简单的方法是让用户访问一个UNC路径,这样会发起一个smb的ntlm认证。当然,被动的攻击技术当然不怎么好用,放个什么UNC相关的文件上去等管理员访问之类的,就很难利用,一般来说是mysql可以load file,或者服务本身有xxe,ssrf之类的支持UNC路径。

比较好用的应该是那个经典的打印机bug,只要是域内的用户就可以使启动了对应服务的机器对用户提供的机器发起NTLM认证,并且这个是微软的feature,不会修复

net NTLM破解

分版本号,如果用的及其远古的LM hash的话,会使用v1的版本,密码会被限制到14的长度还分成两个7,只需要控制模板机器对攻击者发起认证,控制challenge的值,就可以做彩虹表来获取真正 的hash。

ntlm relay

impacket下面的几个py文件,不知道好不好用。。。没用过,理论上能够控制目标机器向攻击者发起认证请求就可以完成relay?不过如果是打印机bug发起的认证,由于机器用户默认情况下是不能登录到其他机器的,所以只能考虑relay到其他服务上

如果权限很高的话可以考虑relay回LDAP服务,就可以对域内用户权限 进行修改,比如加个域管什么的。不过域控的smb默认是要求签名的,没法直接relay,LDAP好像也会有签名要求,不是很清楚

加上微软对MS08-068的顶级修复,也不能smb relay回自身

机器用户不能登录远程,普通用户难以让其发起ntlm认证。总的来说感觉利用面不广。这里提到了可以用域控机器用户添加基于资源的约束委派然后接管机器用户,由于是域管机器然后dcsync完成利用

主要是实战没利用过,不知道好不好用

BloodHound

感觉应该是域内信息一把梭的最优工具,能用这个的话能大概的先对整个域的情况有一个了解,不然powerview一点点看还是有点坐牢了
真挺好用的,并且是C#的应用,可以内存运行,免杀性能++
一般来说应该使用SharpHound.exe -c All尽可能的收集信息,启动neo4j的时候建议改一下设置把内存拉到4G以上,跑起来可能会快一点
大哥的大哥说Bloodhound的ldap流量很难被抓,随便按。但是网上也有人说这个动静大,按了之后域控上面一万行日志。最大的缺点是BloodHound只支持.net 4.6以上,遇到低版本的机器跑不起来。。。以及neo4j有时候真的很慢,并且发生情况不规律,属于玄学问题。。。我觉得我的电脑性能应该不会这么差,以前用tabby的时候就觉得他有点问题

SharpHound is designed targeting .Net 4.6.2. SharpHound must be run from the context of a domain user, either directly through a logon or through another method such as RUNAS.

建议是直接从BloodHound自带的命令里点点点,然后自定义查询的话。。。要不问问ChatGPT辅助一下?
比如查询所有已被控制的节点(需要先手动标记节点被控制)

MATCH (n)
WHERE n.owned=True
RETURN n

如果在图形界面里看的话,被控制的属性名为Compomised,然而实际上没有这个属性,我edit node才看见那个属性叫owned。。。

设置里面有一个query debug mode,开了之后可以看到点点点时对应的查询语句,然后自行修改

在nodeinfo处有节点的基础信息,其中包含了组成员关系,对外的控制权,外部对当前目标的控制权,本地管理权限等,可以到处点来往外查看控制权限

BloodHound支持域外信息查询,所以目标机器跑不了的话可以考虑偷一个凭证出来用自己电脑接个网进去跑

域外命令执行

如果通过mimikatz或者其他方法dump哈希,在域外的机器上发现了rdp到域内机器的凭证的情况,可以考虑尝试使用该凭证进入域内

impacket套件

impacket是最好用的套件,因为本身是域外执行,所以可以直接攻击者自己电脑接网进去打。impacket提供了一套exec,ps/smb/wmi等一应俱全。psexec就和那个exe一样,动静较大,后面两个会稍微隐蔽一点点

但是利用的先决条件是获取到的用户是目标机器的本地管理员,一开始不知道这回事,拿了个凭据猛梭结果屁用没有。。。

因为这些操作都是要写共享文件夹中的C$或ADMIN$的,只有本地管理员才会拥有这些目录的写权限。机器默认会共享出IPC$,C$,ADMIN$三个文件夹,IPC是个人就能连,可以用来验证口令的有效性。

WMIHACKER好像和wmiexec没什么区别。。。

这里有两篇exec系列的介绍文章
Windows Remoting: Difference between psexec, wmiexec, atexec, *exec
Impacket Deep Dives Vol. 1: Command Execution

域外信息搜集

bloodhound也是支持域外使用的,并且信息查询只要一个普通用户权限就可以进行了,所以很是方便

adfind.exe也支持域外信息搜集,相比之下,powerview好像就没有这个功能?
贴一个adfind的链接
域渗透笔记-工具使用-Adfind

域外域控定位,感觉就是嗯扫,smb扫出来的时候会显示机器的名字,一般来说正常人都会把域控带上dc,或者看端口,域控要提供dns,ldap等服务,会开53,389那几个端口

一些乱七八糟的杂项内容

mssql可以走本地认证?如果有一个本地的mssql就算不知道数据库账号密码也可以走本地管理员身份认证进行访问?

远程执行命令的方法:psexec/smbexec,这个走445端口,wmi走135端口并且没有回显,还有一个winrm是5895/5896端口。winrm的缺点是一般来说不开,并且开了还只接受配置过的trust host的命令,感觉很难用上?

其中psexec好像是因为走ipc,所以无论是pass the hash还是pass the ticket,只要能建立起连接就能用
wmi目前手上的工具支持pass the hash。winrm没用过,不过搜索结果中也有可以pass the hash的。pass the ticket其实没怎么用过,不甚熟练,另一个问题是pass the ticket是kerberos里面和服务交互的方法,一般的攻击感觉都是走的ntlm的认证所以都是pass the hash。

域内登录指定用户名有两种方式,一个是域名\用户名,另一个是用户名@域名,理论上来说老机器用前者,但实际上都可以用前者

原来普通域用户默认是不能直接登录域控的啊,不过net share什么的还是可以看的