前言
突然接到通知,甲方在HVV防守期间突然收到内网IP地址出现Socks代理通信,审计流量发现确实属于socks流量,不属于告警流量,告警地址为个人终端,直接准入工具阻断等待排查。
态感告警

流量分析属于正常的socks流量。
科来全流量探针流量分析
回溯分析socks流量

直接下载连接的socks端口流量,进行分析,csnas打开分析连接会话

在HTTP请求日志中发现请求的URL为我们关联单位的资产,基本确认了这个机器肯定是被控了。态感上针对被控终端无其它攻击记录,被钓鱼的可能性肯定是放在首位的。
测试Socks隧道
由于socks未设置用户名、密码,本地设置socks代理访问测试隧道

隧道可正常利用,准备准备写防守报告了,,,,,
溯源
对目的IP进行端口扫描

发现起的业务还挺多,业务端口发现是某个科技公司,还有他们公司的业务

在开放的端口找到了NPS业务

访问其它端口发现该公司业务后台管理

前端

某科技公司,搞网安的,穿透工具放在自己的业务服务器上,这种RedTeam这年头真不好遇见。
突破
上面扫描的端口可以发现,在socks端口位置,协议识别未TCP,跟他相邻的端口也是TCP端口

猜测也是socks协议,配置socks隧道后发现无法访问我们关联单位的内网业务,但是可以访问百度。

那么这个隧道的客户端又是在哪儿,这个也是令我比较好奇的。另外在测试后台是否能登录的时候在源码中出现了内网地址

直接挂上工具Proxifier+弱口令

挂上gorailgun
,弱口令一把梭。发现了一个mssql的弱口令

财务系统前后端分离,找到数据库,内有银行卡信息。

在企查查上查询到这家公司的股东信息人员和数据库内的人员一致,一般不会有这种巧合

写溯源报告上交,完事儿
总结
整个应急流程是没有问题的,着重记录的是溯源的过程,预警产生后准入设备是直接管控终端断网的。后期联系到终端使用人之后也确实发现有上传的fscan.exe。应该还没来的及扫描,推测应该是抓取了终端用户浏览器的记录连接测试。
整个应急以及溯源流程如图所示

其实很多情况下溯源到某公司或者某个个人都不会承认,现阶段的攻防演练确实存在很多不可控因素,每个授权攻击厂商或者说授权攻击队的合作商或者关联合作伙伴的支撑很常见,报告如实上交,其它交给裁判。
思考
- 本次防守虽然出现终端被控,安全意识从宣传到是否能够有效的贯彻实施本来就是一个不可控因素,人员因素永远是防守最大的不确定性。
- 攻击队应该是新团队,或者说攻击者是新手,打红队不担心溯源,拿企业机这种低错误也没注意,或者说是不担心溯源,另外起的socks隧道未配置用户名密码,裸奔的效果带来的不仅仅是方便,还有惊“喜”。