最近看到一篇文章，说的是AMSI已经将Godzilla的dll拉黑，导致webshell尽管存在，却无法连接。由于是dll被拉黑，所以其实你webshell再怎么免杀也都无动于衷，这让我不禁感叹时代的变迁。 此工具二开了相关dll，就可以了。
在内网渗透中，如果遇到非得RDP的情况，一般会出现如下两种情形： 1.创建新用户，登录无需原登录用户同意 -> 服务器版本 2.创建新用户，登录需原登录用户同意 -> 非服务器版本 一般遇到这种非服务器版本的多用户同时登录，最快的方式是使用mimikatz的ts::multirdp就可以实现 之前一直非常麻烦的用改那个termsrv.dll的方式
这篇文章主要就现在的终端对抗圈子中的一些乱象做了阐述，讲述了哪些规避手法行之有效，哪些规避手法毫无卵用，可以一读。
一篇介绍JWT攻击面的文章，其中我最感兴趣的是他给出了一个项目，该项目收集了很多的JWT硬编码key，有没有shiro key那味了？ https://github.com/wallarm/jwt-secrets 其余的可以看一看，感觉还是颇有收获的。
好久没学习web的相关知识了，今天先来看看这个一直以来被我忽略的Druid攻击面 文章：https://xz.aliyun.com/news/18080 忽略他前期的各种概念介绍，直达核心： 一、Druid默认密码： 本文中是因为见到了那个站是ruoyi的，所以它使用了ruoyi/123456进入了Druid后台 这里放上几个常见的，来源是：https://blog.csdn.net/weixin_72543266/article/details/139512111常见用户:admin ruoyi druid 常见密码:123456 12345 ruoyi admin druid admin123 admin888接着他在URI监控这里，找到了三个未授权接口，并完成了30W+敏感数据的获取。 进入这个界面，重点就是三个：URI监控、SESSION监控、Spring监控 URI找未授权路由 SESSION批量测试，希望找到管理员的SESSION Spring监控目前还不知道干啥的。 具体的可以看看这两篇文章，先知的是带真实案例的。确实有启发，因为之前遇到druid就是未授权，带密码的只会尝试admin admin 不行就撤退，完全不知道这个ruoyi的ruoyi/123456 这点确实很欠缺呀！