IB fakapy 2019-典型但不是很



“但这并不无聊!”-这是我们的Solar JSOC网络威胁监控中心员工的非正式座右铭(我必须说,2019年与之完全对应)。 在新年伊始,许多人都喜欢盘点并设定新的目标,但我们决定告诉一些“我们镇的恐怖”-2019年的案例,这甚至给经验丰富的分析师留下了深刻的印象。 这些故事的结论仅仅是一个:技术在发展和发展,人类的懒惰,疏忽和粗心是永恒的。

访客无线上网


在将客户连接到监视程序时,我们首先要求提供最重要的信息:关键帐户,域组,不受信任的网段,白色地址,DMZ,关键子网等。 不受信任的子网只是访客Wi-Fi,以及承包商网络,具有允许任何目的的许可的测试网段等。...通常,我们发现与此类网段互动的可能性不存在或受到严重限制,因为对其进行控制非常困难,即使不是不可能。 在客户网络上,除了来宾网络中的授权页面外,不可能进行此类交互。 我们通过禁止在WLAN中与TOR,C&C服务器和其他恶意软件进行Wi-Fi交互来平静下来,这样我们就不会受到潜在客户不感兴趣的运营的轰炸(尽管我们仍在收集这些事件的统计数据作为摘要报告)。 在试点项目的第三天早上,我们注意到了一个异常:来自防火墙的事件流增加了4倍!



他们开始寻找“阻塞”的原因,并惊讶地发现它出现在访客Wi-Fi细分市场中。 某个主机每小时产生400万个(!)事件。 这些事件非常有趣-端口445上的连接到Internet空间的随机白色地址。 四百万,卡尔!



通知客户有关信息后,由于DHCP(它是授权服务器)未连接到SIEM,他们开始等待有关主机和事件的信息。 大约3-4小时后,客户报告主机是一部手机。 说我们很惊讶就是什么也没说。 普通的手机无法生成这样的事件流。 他们开始找出细节,结果发现手机与手机无关—有人只是用其中一个注册设备作为封面。 无法找到真正的活动来源,我们的客户说他对这种情况不感兴趣,因此必须将活动最小化。 尽管如此,我们还是警告客户专家可能存在的风险:由于活动(显然是恶意的)来自他们的地址,因此他们可以例如进入反病毒供应商的C&C服务器列表,并收到执法机构的投诉(他们知道该主机将扫描哪种基础架构) -毕竟可能存在KII,并且扫描漏洞是指需要报告给GosSOPKA的事件。 经过这样的争论,客户仍然决定更详细地理解并满足我们的建议。 它们如下:

  1. 关闭除80和443之外的所有端口(这是正确的决定,因为在445之后执行了对端口22的扫描),
  2. 我们引入了对分布式Internet速度的限制,
  3. 激活UTM芯片(包括应用程序控制),并剪切诸如torrent,TOR浏览器,检测到的扫描仪等奇特类别,
  4. 打开每个时间间隔的连接数限制。

客户永远无法找出这个活跃的Wi-Fi用户是谁,但至少他们用氧气阻止了他(很可能攻击者正在寻找下一个可用的Wi-Fi。

几个月后,该飞行员被成功关闭并转移到合同中,但是我们在完全不同的公司中仍然遇到类似的案例,因此上述建议可以归为通用。

默认情况下,或供应商破坏


在与Solar JSOC监控进行试点连接的同时,客户委托了一个新的UTM。 迁移过程是分阶段的:首先通过子网传输ACL,然后通过应用程序策略进行传输。 甜点是最有趣的。

根据经典故事,一切都发生了-在星期五晚上。 第一行记录了与TOR节点的客户基础结构联系时的不幸事件,在FinCERT邮件列表之一中显示为C&C。 由于该项目是一个试点项目,并且客户将所有事件都转移到了低危级别,因此,除了通过邮件通知外,没有提供事件卡。 因此,从不同主机到一个地址的第一次操作虽然引起了监视工程师的怀疑,但并没有进一步升级。 当旅行次数达到三次时,这些家伙感觉到有些不对劲,并通知了负责该事件的分析师。



首先,分析师联系了客户的负责员工,并建议在本地日志级别连接主机,以识别活动的来源。 在与客户专家讨论时,主机的数量已增加到7。这种情况与流行病非常相似,但是主机上的防病毒软件正在工作并且保持沉默,网络上没有活动的动作和主机交互。

在本地日志级别连接三台主机也无法理解是哪个进程生成了该活动。 焦虑越来越大,唯一可行的选择是通过并行删除RAM转储和硬盘映像来隔离主机。 分析师开始准备说明,并同时决定搜索主机访问的IP,以获取其他邮件和事件的可用性(因为我们观察到的活动类型不同于FinCERT新闻中描述的活动类型)。 在大多数情况下,这个想法是很痛苦的,但这次不是。

请注意标题中列出了IP地址和UTM供应商名称的文章。 总结出版物的实质,供应商购买了以前属于TOR节点的IP地址,该地址已在FinCERT新闻稿中进行了介绍。 这不仅是全部! 此外,供应商决定将该地址设置为默认值,以将所有可疑呼叫从其客户的基础结构重定向到潜在的恶意地址。 也就是说,UTM将任何与一个奇怪IP地址的连接都视为非法连接,并将其重定向到该神奇地址。



确定反恶意软件保护模块是否已启动并获得确认后,分析人员和客户专家会向他们吐气。

PS对UTM检测到的故障的分析确认所有7个活动均为“假阳性”。

我们答应了针对每种情况的建议,但在这里,也许我们只给出一个建议:不要在星期五部署。 并警告所有有兴趣和同情者。



历史上


这种主旋律汇集了各种各样的情况。 以退役为例。 通常,与公司失去联系的流程常常被遗忘:没有人“解析”旧的基础架构,而留下旧的虚拟机,服务器和网络访问权限。 同时,没有人监视这些主机上的更新,防病毒和事件,甚至管理员通常也不知道系统的所有者。 因此,过了一会儿,此类基础架构元素并没有带来最令人惊喜的惊喜。 仅将一个环境组织在2005年完成的一个项目上的重要遥测发送到一个不友好国家的FTP服务器上,要花多少钱!

尽管仍在使用已使用10年的系统,但通常没有人进行维护。 例如,使用古老引擎并为用户方便起见的密码重置门户查看Internet或RDP,承包商需要使用Internet或RDP来配置业务应用程序并持续5-6年。

通常在以下情况下会知道此类问题的存在:

  1. 主机遭到黑客攻击,并且加密行为进一步受到勒索(最近发生了很多此类事件),
  2. 从外围的一种解决方案迁移到了另一种解决方案,
  3. 我们来到飞行员那里,收集周边开放端口的配置文件。

但也有完全是神话般的情况:2013年,该公司与承包商一起为其金融系统建造了一条隧道。 合同结束了,但是隧道仍然存在,因为它是由承包商从中租赁房屋和IT基础设施的公司制造的。 一家新公司也占据了同一个位置,很惊讶地找到了其他人的基础结构的可用地址。 好奇心接手了,然后是诱惑和渴望获利。 他们倾销了对手方和合同的数据库,以免产生竞争-竞争的好处很有趣,但是没有人在受害公司中发出声音。 这个故事持续了一年多(不可能沿着原木进一步追踪),但最后,调查,解雇和蛋糕上的樱桃都是刑事案件。

AWOL,或者因为它更方便


整个案例相当琐碎,不能说“实现方法论”。

鉴于:

  1. 客户监控试点项目;
  2. 外围以及公司和技术部门之间的连接源;
  3. 在工作场所管理值班并为封闭的网段提供服务;
  4. 管理员的迫切愿望是减少工作量,增加睡眠时间并舒适地做所有事情。

就像我已经说过的那样,在连接时,我们要求客户提供各种信息,包括白色地址,以便从Internet收集有关与它们的连接的统计信息,从而形成一个外部边界配置文件。 创建一条规则填充SIEM中的列表后,我们大约需要一两个星期的时间来收集有关外围所有开放端口的统计信息,将其卸载给客户,观察并固定在一起(同时关闭非法端口)。 收集配置文件的信息后,我们会定期浏览列表,以确认端口对白名单上的所有地址或仅部分地址开放。 引起注意的是端口43388,该端口似乎并不明显,但在3389年广播,其灰色地址当时是我们所不知道的。

经过检查,结果表明该地址与我们的地址无关。 我们以为他在白名单上是开放的,但是白天我们没有观察到他有任何成功的联系。 第二天早上,他们再次注意到一连串的事件已经在一夜之间到达。 这次,我们仔细查看了源地址,并看到了来自莫斯科的几场会议,这些会议的总时长超过5个小时,并且来自世界各地的短时间会议也很多。 然后很明显,问题并不在于该端口仅可访问白名单中的地址,而是仅在晚上开放-从大约00.00到早晨06.00。 从域和防病毒软件中挖掘日志(到那时它们才刚刚连接),我们惊讶地发现该地址属于值班管理员,他应该在此时间间隔内工作! 在分析了他的汽车的连接情况之后,我们发现了另一种有趣的情况:每天晚上,港口在封闭的专用航段中也开放(我认为不难猜测是哪个港口)。 几乎不可能在飞行员的第四天注意到这种活动,到那时,网段之间允许的连接数仍然比外围的开放端口多。 在将情况告知安全卫士后,他们以本地日志级别连接了主机,并确保管理员正在悄悄地逃离工作。 事实证明,他几乎住在附近的一所房子里,而远程连接当然成了太多的诱惑。

如果管理员描述了这种情况,则可以允许他通过SKDPU进行远程工作,前提是在事故发生时他能够在15分钟内上班并且完全没有问题。

合计


实际上,对信息安全的主要威胁之一是在地面上进行搜索。 因此,将风险降至最低:

  1. 跟踪外围和防火墙配置。
  2. 尝试将远程服务器置于公司管理下(通过终端服务器的VPN)。 并且如果已经存在,则控制谁使用它(通过删除主机上的各种RAT,它们现在可以轻松检测几乎所有的防病毒引擎)。
  3. 遵循特权用户的操作:他们常常失去警惕,认为他们可以控制一切,并且使攻击者更容易访问关键数据。

Source: https://habr.com/ru/post/zh-CN484676/


All Articles