取得1个压缩文件,里边有一个客户端软件但压根不能运转,怕被反打被钓鱼,因此仅仅翻了翻程序执行设置和系统日志,设置中寻找1组账户密码,有数据加密可是估算问题不大,假如账户密码准确立即运转应该是能够 登录的。环境有一些极端,物理机自身都卡装vm虚拟机运转毫无疑问是不实际的,只能先拖入PEID查一查看一下是啥应用程序,探究一下下登陆密码密文能否解出,没准别的位置也可以用。
拖入PEID的过程中出乎意料发生了,不小心点了一下下造成 程序执行了。见到登录框有账户密码尽管检验了猜测,但运转是件非预计的事儿,赶快关掉,随后拖入电脑管家杀病毒扫了一下下,有两个.dll误报...这种焦虑感迄今难以忘怀。清查任务计划清查系统进程删脆弱文件,一整套操控下去仍不安心,就差断电换机器了。所幸事后在ES查出来误报的2个.dll全部都是很多年前就被标注的,显而易见不太可能是为了更好地现阶段情景准备的沙坑,反向看源代码也找不到哪些异常的字符串常量,故一切正常运转,账户也的确可登录,管理权限为某部们下的管理人员,可查询该单位下全部职工的数据及其跳转检验到某些别的系统,有关功能模块及网站未发觉可getshell的点,该单位也和推论的管理目标的单位有一些远,已经知道了账户规律性和默认设置登陆密码,故期待爆破获得到管理权限更高一些某些的账户,便捷点击查看的数据,登录大量的系统。抓包发觉数据流量是有数据加密的,无法立即爆破,须要解决数据加密难题。
源代码深入分析:
依据登录按钮的文本提示信息定位到相匹配的鼠标事件:向下再次跟会发觉较为有趣的点是它沒有立即传送文本框中取得的值,反而是塞入UserInfo里,再启用SendLoginMsg方式更进一步解决再次深化,将UserInfo塞到MsgSysInfo再调zip的目标中GetBuffer方法去解决最终交个给Login方式,见到这基本猜疑应用程序很有可能有什么问题,即使沒有立即传送有关值,那到最终发送有关的解决前应当要转为json这类的才合乎预计。本地顺利弹出来计算器的Gadget在目标上并没有一切正常执行,仍然是再次试了几个Gadget后指令才得到执行顺利,写文件浏览不了,Ysoserial.ed2k中给予的回显方式那时候未检测顺利,时长紧也无法资金投入时间精力去探究其缘故,Windows始终无回显执行命令就怪难过的...所幸网站服务器的发觉网站服务器别的端口开过iis.默认设置相对路径写aspx取得shell.
应用程序是公用的,从头至尾打了个六七个shell,因为其内置的数据加密给payload上了保护伞,攻击过程并未被发现过,有趣的是局域网扫描被发觉后最初防御人员排查的过程中采用的对策是删掉某一打payload时会检测的基本特征文件。
还没有评论，来说两句吧...