自序
科来自2003年成立至今，不断深化技术研究与优化服务，积累了大量网络分析实战经验与优秀案例，这些案例对科来甚至网络流量分析技术本身都具有深远的意义。科来希望更多优秀人才通过这些案例接触到NTA技术，使得这项技术得到更好的传播与发展，切实提高国内技术水平。
本案例集所汇集的案例均为科来技术专家在服务客户时，对所遇到的各类问题做出的解决方案，其意义不仅仅是对案例进行解析，确切地讲，它为专业人士提供了解决各种问题的分析思路，有举一反三的作用。掌握了这些知识，也就具备了解决大部分网络安全与业务性能问题的能力。
科来于2005年创办CSNA网络分析认证培训。CSNA是网络分析领域的顶级认证，一名合格的网络分析认证专家必须掌握高级的网络分析技术并拥有丰富的分析诊断实战经验，才有资格获得CSNA网络分析认证证书。科来为了保证培训质量，每期培训均严格控制学员人数，确保优秀人才的输出，迄今为止已经有上万名优秀的人才通过认证，并在国家的重要岗位上运用所学。
对于中国网络分析技术的发展，与科来在教育领域付出的努力是分不开的。一直以来，科来积极联系各大高校，义务进行技术知识传播，推出各类资料帮助在校学生快速入门。同时，我们坚信在理论知识的基础上，配合实战案例的学习，是提高毕业生市场竞争力的一把利剑。
最后，感谢为此案例集贡献内容的一线技术工程师，是他们始终如一的奉献与坚持成就了此书；还要感谢科来忠实粉丝的一贯支持与帮助，你们的热情是科来勇往直前的动力。同时，科来希望大家能够将自己实际遇到的案例整理分享出来，为更多人提供解决实际问题的思路和方法，您可以投稿到：support@colasoft.com.cn，我们将酌情予以答谢。
前言
我们正身处在高度信息化社会、网络社会，更加多样、复杂且重要的数据和信息以网络流量的形态在第五空间中互传互通。 “十四五”规划纲要中提出迎接数字时代，激活数据要素潜能，推进网络强国建设，加快建设数字经济、数字社会、数字政府，以数字化转型整体驱动生产方式、生活方式和治理方式变革；同时，随着“两法一条例”的发布和实施进一步说明，网络的深度应用和安全性对社会的影响深度前所未有。
“等保2.0”、“关键信息基础设施安全保护条例”反映出国家对重要关基单位的网络安全保障要求上升到更高层次；“数据安全法”、“个人信息保护法”则体现了国家对网络数据安全的重视程度。在网络攻击技术与手段愈发复杂多样的大背景下，传统的网络安防体系难以进行有效防御。科来认为网络流量分析技术是保障网络安全的有效手段，因为再高级的攻击都会留下网络痕迹，而网络攻击者的行为和我们正常的网络访问行为所产生的数据是不一样的。通过对网络全流量的分析能够及时发现网络异常行为，从而做到对网络威胁的全面感知。
网络流量分析技术不仅是保障网络安全的有效手段，在业务性能管理方面同样发挥巨大的作用。运维的根本是保障业务的持续高效运行，而业务表现在网络中则是川流不息的数据。如今，我们要面对传输在庞大网络、云网络、云上云下多网络等复杂多样性网络环境中的业务数据，只有实现对网络中的全流量进行实时的、智能的、高度可视的监控与分析时，才能够提升对复杂业务系统运维的能力和效率，降低故障排查的时间成本，使运维人员更加从容主动的应对核心业务的运维需求。
那么，如何在遭受网络攻击时，实现对网络异常行为的取证及数据再现？如何在业务性能出现异常时，迅速定位异常根源，及时止损定责？如何在学习网络分析技术时，了解实战中会遇到的问题及解决思路？《CSNA网络分析经典实战案例》将通过对各类典型实战案例的汇总分析，为您解答上述疑问。
目录
第一部分 业务性能管理
第1章 如何快速定位应用系统无法访问问题
第2章 如何定位两地联调中出现的业务互访异常故障根源
第3章 如何定位营销秒杀活动卡顿的问题
第4章 如何保障远程视频会议顺利进行
第5章 如何解决二维码扫描读取等待问题
第6章 如何定位迁移后的核心业务访问缓慢问题
第7章 如何分析工业场景中网络故障的危急事件
第8章 如何分析容灾系统传输慢的原因
第9章 如何发现无规律性HTTP交易失败故障真相
第10章 如何定位网络访问出现的高延迟问题
第11章 如何解决业务系统文件上传失败问题
第12章 如何分析数字程控交换机无规律中断现象
第13章 如何定位网站中APP下载失败的故障原因 第14章 如何定位门户网站访问缓慢问题 第15章 如何分析监控画面通过内网调用超时问题
第16章 如何定位医疗系统中偶发卡顿问题 第17章 如何定位压力测试中的故障问题 第18章 如何解决网络身份认证系统信息上传故障 第19章 如何发现大型网络中路由环路问题 第20章 定位支付交易失败率高的原因
第21章 解决“双十一”前夕支付宝业务交易失败问题 第22章 如何定位应用中断的根源 第23章 如何解决SSL访问缓慢问题 第24章 如何解决远程VPN连接失败问题 第25章 如何解决业务应用访问失败的问题
第26章 如何找出偶发性系统宕机的根源 第27章 为何企业的OA系统访问缓慢 第28章 如何解决C/S架构应用访问缓慢问题 第29章 如何找出ERP访问缓慢或宕机的根源 第30章 如何分析无盘客户端无法正常启动
目录
第二部分 网络安全分析
第31章 如何通过识别资产发现境外IP入侵关基单位的隐秘行为
第32章 如何发现与分析某OA系统的0-Day漏洞攻击
第33章 如何分析攻防场景中的入侵成功行为
第34章 如何发现与分析某APT组织的窃取数据攻击
第35章 如何溯源扩线针对邮箱服务器的攻击行为
第36章 如何分析微信社工钓鱼成功的后续攻击行为
第37章 如何研判OA系统在攻防场景中出现的1-Day漏洞利用攻击
第38章 如何分析攻防场景中的攻击探测行为
第39章 如何发现并溯源攻防场景中的Webshell攻击行为
第40章 如何分析下级单位被“拿下”后向上级单位发起的攻击
第41章 如何对数据库UDF提权攻击进行溯源取证
第42章 如何发现利用WebLogic反序列化漏洞的攻击行为
第43章 如何对攻防场景中“断网”故障根因进行分析
第44章 如何通过流量分析发现攻击并溯源反制被控“肉鸡”
第45章 如何发现利用Apache Shiro漏洞的攻击行为
第46章 如何发现内网中被控的“挖矿”主机
第47章 如何通过流量分析发现勒索病毒的传染源
第48章 如何分析网络出口设备遭受的DDoS攻击
第49章 如何找出造成传输层拒绝服务的攻击行为
第50章 如何分析邮件系统遭受的攻击行为
第51章 如何分析入侵门户网站的攻击行为
第52章 如何分析恶意篡改网站内容的攻击行为
第53章 如何发现利用DNS放大攻击服务器的行为
第54章 如何找出造成应用层拒绝服务的攻击行为
第55章 如何找出内网被控主机
附录
科来解决方案
CSNA网络分析认证培训
科来公开课
《网络攻击与防范图谱》
《网络通讯协议图》
若您需要纸质版案例集，请准确填写下列信息，以便案例集能准确送到您的手中
您还可以关注科来公众号
1.获取更多高清电子版文件和印刷版资料
2.获得技术支持服务
3.购买咨询
4.有机会加入科来VIP群
试读
第一部分
业务性能管理
《数字中国建设整体布局规划》中，明确要求构筑自立自强的数字技术创新体系，筑牢可信可控的数字安全屏障，通过数字化方式提升效率，持续推进科技赋能与科技转型。数字化时代，业务与科技的融合正在进一步加深，运维的根本是保障业务的连续性，并确保高效、稳定的运行。
越来越多的企业通过大数据技术、核心业务上云为用户提供更加灵活高效的服务。一方面，随着网络技术的深度应用，大流量场景增加，业务与系统之间的访问关系变的错综复杂，增加了故障出现的风险及处理难度；另一方面，业务系统从传统的物理机时代向云化、微服务化发展，集中的交易系统正在被不断拆分成多个独立的交易模块，增强云上云下业务的可观测性迫在眉睫。
科来通过全流量分析技术对网络中的流量进行实时的、智能的、完全可视的采集与分析，并率先在国产化高传输流量采集与实时分析处理技术上取得突破，满足对关键业务运维的大流量承接与处置、实时监控分析、用户体验等高要求。同时，科来打造以业务为核心，覆盖云网上下的网络、业务、交易一体化的全链路可视化解决方案，通过全面详细的业务应用性能状态指标，实时监控应用系统的运行质量，在多云多网的复杂环境下主动发现业务运行异常、潜在风险，快速定位故障、清除隐患。科来在网络性能管理与监控方面的创新，能够帮助用户实现从被动运维到主动运维的转变，通过技术创新，赋能用户业务发展，让企业拥有更强的商业洞察能力。
第一章
如何快速定位应用系统无法访问问题
随着网络的高速发展，用户网络环境中的网络、安全设备越来越多，业务流量在网络设备中的传输路径越来越复杂。
当用户访问出现异常，业务系统维护人员往往在定位故障上使用的时间远远超出解决故障的时间。本案例介绍如何通过科来业务性能管理系统快速发现业务故障原因。
1.1 问题描述
某单位的OA系统10.X.X.95近期出现了故障，用户从外网或内网访问OA办公系统的部分模块时，频繁出现无法访问的故障。由于该单位部署了科来业务性能解决方案，因此决定采用UPM+RAS设备对故障原因进行分析。
1.2 分析过程
使用UPM系统对OA系统整日流量趋势进行回溯分析，业务系统流量整体较小亦均衡，但曾出现短时间的流量突增。经过与该单位运维人员沟通得知，该时间点的突增是运维人员下载文件，属于正常现象。
对OA服务器的整日网络状态进行分析，当天的客户端RTT趋势较为平稳，最高值1.66ms，平均值703us，当天访问的客户端网络时延较好。
再观察当天的服务器RTT趋势，最高值1.8ms，平均值387us，当天访问的服务器网络时延较好。
客户端和服务器的RTT整体较好，说明在取样分析的当天，网络状况优秀，因此可以排除网络故障原因导致的异常。
再观察服务器的窗口大小，窗口大小指标往往可以预示着服务器的硬件性能。取一天的数值进行分析，该日的服务器平均窗口大小为59.3KB，出现0窗口事件次数为0，服务器性能较好，因此可以排除服务器硬件原因导致的异常。
再观察服务器的窗口大小，窗口大小指标往往可以预示着服务器的硬件性能。取一天的数值进行分析，该日的服务器平均窗口大小为59.3KB，出现0窗口事件次数为0，服务器性能较好，因此可以排除服务器硬件原因导致的异常。
接下来对OA系统交易状态进行分析，当天共产生7333次交易，1次交易失败（无响应），交易成功率为99.99%，OA系统应用层平均响应事件为1.13s，交易峰值为95次/秒。通过趋势图观察，发现应用的并发请求数和应用响应时间基本成正比，请求数上升的时候服务器平均响应时间亦随之上升，基本属于正常情况。
对7333次交易按照请求的URL进行分类汇总分析，发现部分URL会出现响应时间长，经咨询运维人员属于正常现象，该部分URL需要查询历史数据导致响应时间会较长。
对OA系统在当天响应的状态码进行统计，有15.96%的响应是以403响应的，该部分响应状态异常。
对7333次交易按照请求的URL进行分类汇总分析，发现部分URL会出现响应时间长，经咨询运维人员属于正常现象，该部分URL需要查询历史数据导致响应时间会较长。
HTTP响应码为403的会话数据流如下图所示：
用户登录成功的会话数据流如下图所示：
综上所述，网站的登录和认证功能正常。但经过日志中可以看出，该用户在登录成功后，又被OA系统响应403状态码，要求登录。
再取多个被用户访问异常记录深入分析，发现服务器响应403的原因是用户的登录状态异常；用户初始登录时提交一次登录信息显示登录正常，登录后再次访问服务器却要求用户重登录。
1.3 分析结论
通过对应用的流量与交易状态分析，确认用户无法访问的原因为服务器记录用户登录状态异常，用户访问应用服务器频繁被提醒未授权状态，重复登录导致无法访问现象。
建议系统管理员对该服务器的应用状态检查，调整session id验证与保持机制，避免出现用户登录后丢失登录信息导致用户重复登录。
1.4 价值
在本案例中，使用科来业务性能解决方案，该方案具备将多个探针流量进行统一汇集、集中展示、集中回溯统计等功能。在本次故障排除中，无需分析底层数据包，通过指标展示即可排除网络原因与服务器性能原因。通过归类汇集分析，发现网络中403响应码数量较多，再结合原始数据流交互，能够为快速定位到问题原因。
第二章
如何定位两地联调中出现的
业务互访异常故障根源
当企业发展到一定规模后，经常需要在不同地区开设分支机构，如分公司或办事处等，包括集团性企业。随之而来的是总部与分支机构的互联，实现应用系统、业务系统的资源共享，实现企业互联的统一管理。对于异地数据的互联互通，由于各地运营商、数据转发设备很难做到统一，导致部署维护难度较大，在两地联调过程中经常会遇到问题。由于之间节点繁多，对问题的定位有很大难度。
下面的故障案例中涉及到一个知识点——MTU（Maximum Transmission Unit），直译为最大传输单元，表示转发设备物理接口能够处理并发的最大长度包。MTU在实际应用中并不多见，但被忽略的往往就是问题产生的关键因素。
2.1 问题描述
A单位和B单位之间即将上线一个互访业务（称为X业务），X业务上线前需要测试验证，因此AB两家单位的业务负责人分别各自搭建节点设备：A单位是发起访问端，即客户端；B单位是接收访问端，即应用服务端。
测试环境很快搭建完毕，AB两家单位合作联调，起初顺风顺水，但随后便不断出现访问异常现象。不论测试多少遍，A单位的客户端始终无法收到B单位的服务端响应数据。
双方业务人员很快进行了跳过远程网络的本地验证，发现本地验证都没有问题。至此，业务人员明确把问题抛给了网络，为了能够明确问题根源，双方网络人员决定通过流量分析排查定位问题。
2.2 分析过程
1）A单位部署有流量采集点，分别是Client连接SW交换机的镜像点1和FW防火墙连接的RT路由器镜像点2。问题发生时，分析同一条异常TCP会话，发现两个采集点的数据时序交互一致，可以排除A单位FW造成问题的可能。观察解码后的异常TCP会话，发现TCP三次握手正常，连接能够正常建立，数据请求也正常发出并观察到了数据回复包，但收到的数据回复包序列号Seq=2892134097，按照同方向数据包序列号连续性原则，服务器应该发完上一个确认ack（Seq=2892132649）后，发送序列号Seq=2892132649的数据包，但实际并未看到，如下图。
2）进一步观察发现，收到的数据回复包序列号Seq=2892134097减去上一个确认Ack序列号Seq=2892132649，差值正好是1448，可能存在TCP载荷长度为1448的数据包。随后查看了所有异常会话，发现数据包交互现象一致，推测回复的数据包中首个载荷为1448字节的数据包未被转发过来丢弃掉了。如下图。
3）什么原因造成会话中只是一个1448字节数据包无法正常转发过来，而后续字节为920的数据包却能够正常收到呢？是否由于1448字节的数据包在经过封装TCP包头（最长20字节）、IP包头（最长20字节）后由于数据转发设备MTU过小导致不能转发呢？当然这只是猜测，如果成立，需要明确一个前提条件，即数据包是否DF置位？即不允许分片。TCP会话在三次握手建链时（SYN包与SYN/ACK包IP头部DF标志位）会协商数据包是否超过网络转发设备接口MTU不允许分片而直接丢弃。经查验，发现确实两端在建立TCP会话时设置了DF位，满足第一条件，如下图。
第三章
如何定位营销秒杀活动卡顿的问题
随着网上支付的兴起，手机银行业务成了各银行关注的重点。为了吸引客户，电商及银行经常会举行营销秒杀活动，手机银行营销秒杀活动能否稳定运行，直接关系到用户体验。本案例将详细讲解如何通过科来业务性能管理系统迅速精准定位故障节点。
3.1 问题描述
某银行10点开始进行营销秒杀活动，手机银行营销秒杀界面出现访问卡顿情况。
运维人员通过部署的科来业务性能管理系统梳理出手机银行业务的访问逻辑，如下图所示。
同时对该业务做了手机银行关键性能指标的实时监控视图。
3.2 分析过程
回溯问题时段的网络关键指标变化，发现网络传输性能指标基本正常，但应用响应时间较大。
在网络时延基本不变的情况下，应用响应时延明显增大，多段对比可知，应用响应时延增大的主要原因是因为渠道营销支持APP响应时间增大导致，平均达到600ms以上；问题时段数据包表现如下。
应用响应时间有些已经达到了2-3秒。
与此同时还发现SSL卸载之后WAF两个抓包点的会话数目不同，WAF前167条TCP会话。
WAF后10183条。
解码分析看到客户端发出的数据包TTL不一样，WAF前为255，WAF后为64，明显有中间设备做了七层代理，一个TCP会话中的多个交易被拆分为多个TCP会话。
向客户反馈问题后，客户立刻协调人员排查这个问题，发现某厂商的WAF针对该IP的保护机制会导致SSL卸载后被聚合起来的会话重新拆分。如果会话数目较多会对F5的性能有所影响。先前SSL卸载后会话被聚合在一起也是出于优化F5性能考虑的。
关闭WAF针对该IP的保护机制后，F5性能有明显提升。
3.3 分析结论
通过以上分析，可以得出结论，营销秒杀活动界面访问卡顿问题是由于渠道营销支持APP响应时间较大导致。除此之外，还发现了一个由于WAF拆分会话影响F5性能的巨大隐患。
3.4 价值
科来通过对全流量的解码分析，辅以图形化的界面将业务的访问关系梳理出来，使业务访问可视化，然后通过自定义秒级监控业务的关键指标，在故障发生的第一时间定位问题点，快速高效的解决问题，极大提升了运维人员的工作效率。同时通过指标的多段对比，发现隐藏在网络中的其他风险，保障业务系统安全稳定的运行。
第二部分
网络安全分析
中国信息安全测评中心发布的《全球高级持续性威胁（APT）态势报告》中指出，针对我国的APT攻击持续上升，其中关键信息基础设施单位是APT攻击重要目标，并在未来有更明显趋势。面对以网络攻击、丧失功能、数据泄漏等为目的的关基风险，关基单位要做到确保关键业务连续运行及重要数据不被窃取破坏。
科来在流量检测与分析技术领域持续保持自主可控、深入研究，率先实现国产化高传输采集与实时分析处理能力，掌握该领域核心技术。科来认为，再高级的攻击，都会产生网络流量，网络安全防御的能力取决于安全感知能力，安全感知能力的重点在于对未知安全威胁的感知。通过科来全流量分析技术能够为用户提供“上帝视角”，感知未知威胁，实现对网络攻击回溯及入侵的研判和取证。同时，科来在被动流量识别与资产分析、主动监测预警与防御方面有着多年丰富经验，能帮助用户更清晰详尽的掌握资产情况。针对关基安全防护，科来能够有效收敛关基资产暴露面，提供攻击手段溯源取证分析，对告警进行深度研判，为攻击溯源和取证提供最直接、最重要的证据。同时提供供应链安全、通信网络安全及数据安全保障能力，为关基保护全面构建防护安全体系。科来全流量安全解决方案帮助用户构建自适应网络安全架构，实现对网络全方位无死角的监控与防护。
目前，科来全流量安全解决方案的应用场景包括：关基保护、资产识别与梳理、攻防研判、安全事件回查、异常流量检测、网络数据的完整记录、阻断防御、态势感知、元数据安全防护、工控安全等，该解决方案已经在政府、金融、能源、运营商等行业广泛应用。
第三十一章
如何通过识别资产
发现境外IP入侵关基单位的隐秘行为
在攻防对抗中经常提及“知彼知己百战不殆”，"知己"是对自身的深入了解，只有准确清晰的认知，才能更好地发挥长处，避免暴露短板。关基设施是黑客攻击的主要目标，当关基单位对于网络上的资产无法进行清晰的识别时，会导致暴露面扩大、威胁监测滞后等问题出现，便给了攻击者可乘之机。
31.1 问题描述
某能源单位在执行日常安全任务时对资产进行梳理，通过科来设备进行资产识别，筛选出一批小流量业务资产，为进行暴露面收缩做准备。过程中通过对比资产画像及其行为习惯后发现了一个流量极小的业务资产存在异常，并结合流量进行关联分析最终发现威胁事件。
31.2 分析过程
首先从资产会话热力图中对各资产流量大小分布情况进行快速确认，可确定小流量资产范围，联系管理人员确认后开始分析，以进行暴露面收缩。从会话热力图中发现了一个流量以及会话非常小的资产，经查询IP为XXX.XXX.XX.17。
该资产并不活跃，根据资产自查梳理结果中的“资产表”查看资产具体信息，该资产只开放了一个80端口，且流量极小，周一至周日均不足1MB。
通过对比该资产的资产画像及其行为习惯后发现存在访问异常，结合科来网络全流量安全分析系统，分析该资产在统计时间段内的流量情况，发现有境外IP对该资产进行访问。
分析后发现，荷兰的一个IP XXX.XX.XX.25 于某日晚间成功访问该资产的80端口，请求的页面较为可疑，类似命令执行。
在收到服务端的确认后客户端便关闭了连接。
将时间范围扩大，发现有同网段的境外IP XXX.XX.XX.219于某日下午同样访问了该资产。
对数据包进行分析后发现，该境外IP向资产的80端口传输了一段加密数据。
根据威胁情报查询该境外IP后发现其为恶意IP地址并对其进行流量分析，发现其对同一网段内多个资产的80、443端口进行了扫描。选择分析了其中流量数据较大的资产 XXX.XX.XX.253 。
发现双方成功建立了TCP连接并传输了加密数据。联系该设备管理人员进一步对终端进行排查，并将发现异常的相关资产纳入长期观察目标，从资产的流量、行为、内容等方面进行针对性的长期监测。
31.3 分析结论
通过科来资产被动流量识别方式对关基单位资产进行全面梳理，通过资产画像发现资产异常行为，即使流量极小的业务资产也不会遗漏并实现数据留存。经过对产生流量数据的一系列分析，确认为境外恶意行为，管理员对该资产进行紧急排查，并将该资产纳为长期流量监控目标。
31.4 分析价值
科来资产被动流量识别解决企业资产、关基资产发现难、感知难的问题。这种方式能够发现任何有网络活动的资产，不存在由于反探测技术或安全防护导致识别被阻断的问题。解决了主动扫描探测时静默资产不在线导致无法发现的难点。另外，旁路部署被动采集无需对目标网络进行扫描，可以避免对业务造成影响。
同时，科来将对资产的识别、画像、监测三个环节串联结合，通过对关基资产的识别解析、习惯记录、多维监测，发现资产隐藏风险，监测异常行为，确保了该关基单位关键业务、系统和服务的安全，避免了业务中断、数据泄露的风险。
第三十二章
如何发现与分析某OA系统的0-Day漏洞攻击
软件存在0-Day，这已是不争的事实，但可怕的不是漏洞存在的先天性，而是0-Day的不可预知性。人们掌握的安全漏洞知识越来越多，就有更多的漏洞被发现和利用。企业一般会使用防火墙、入侵检测系统和防病毒软件来保护关键业务的IT基础设施，这些系统提供了良好的第一级保护，但是尽管安全人员尽了最大的努力，仍不能避免遭受0-Day漏洞攻击。面对0-Day真的只有坐以待毙吗？当通过全流量的采集与分析拥有对未知威胁的感知能力后，我们便有机会斩断悬在头上的这柄“达摩克里斯之剑”。
32.1 问题描述
某大型企业的OA办公系统遭受恶意攻击，由于该企业部署了科来网络全流量分析设备，完整记录了攻击全过程。在这起恶性事件中，工程师在进行网络安全分析的过程中发现系统0-Day漏洞。
32.2 分析过程
32.2.1 分析首次攻击行为
09:00左右攻击者对OA系统进行暴破攻击，并不停变换互联网地址进行用户名、密码暴破；
09:16:52发现IPX.X.X.7链接URL/seeyon/htmlofficeservlet进行POST上传操作并成功，如下图。
此时，工程师已经可以确认这是系统存在的一个漏洞，并立即与软件厂商进行沟通，双方对该漏洞看法达成一致后不久，工程师便得到了相应的补丁。
【随后，该软件厂商对外公布了软件存在的一个漏洞，描述如下：“某某OA系统的一些版本存在任意文件写入漏洞，远程攻击者在无需登录的情况下可通过向URL/seeyon/htmlofficeservletPOST精心构造的数据即刻向目标服务器写入任意文件，写入成功后可执行任意系统命令进而控制目标服务器。”】
工程师所发现的“链接URL/seeyon/htmlofficeservlet进行POST上传操作并成功”正是0-Day的位置，这是一个典型的0-Day漏洞。
这是后话，我们继续看工程师接下来的分析和操作：
通过还原会话流，发现X.X.X.7上传WebShell，并使用变异base64方式加密：
09:17:17及09:17:24发现X.X.X.7成功连接test123456.jsp
之后执行查看当前用户名的指令，服务器成功返回
09:19:17攻击者弃用攻击X.X.X.7，并使用多个IP进行连接WebShell，每个IP仅连接2-4次。
经过一系列列目录操作后，将test123456.jsp复制到login-ref1.jsp：
攻击者利用login-ref1.jsp执行的命令，将上传的WebShell（test123456.jsp）删除，如图：
执行ShellCode：
通过对上传到服务器的Powershell样本进行分析，确认这是MSF框架生成的Payload，CS和MSF都能用，CC回连IP是：114.X.X.X:X。
通过查询该IP是来自北京某vps地址，由于114.X.X.0/24网段已经被封禁，未能成功回连。
本案例发生在9：17左右，9：30左右就已经发现相关攻击行为，进行IP地址封禁、服务器删除WebShell，但攻击者不停更换IP，并且WebShell在内存中执行，未能完全清除，直到10：10执行ShellCode左右，发现仍存在相关问题，重启服务器并禁止访问WebShell路径及/seeyon/htmlofficeservlet路径后，并且更新官方修复补丁，进行修复。
32.2.2 攻击者再次发起攻击
在18：31左右，58.X.X.133尝试绕过防护访问/htmlofficeservlet的目录，未成功。
第二次攻击以/seeyon/js/../htmlofficeservlet进行尝试绕过成功，并且再次成功上传相同的WebShell，test123456.jsp，如下图。
随即，攻击者不停变换攻击IP，连接WebShell，并且成功执行远程命令。
攻击者进行查看网卡信息、查看主机Host名称、查看主机目录等一系列操作，并尝试控制受害主机进行违规外联测试，进行进行ping X.X.X.X主机、telnet X.X.X.X主机的80端口等操作。
攻击方并试图从45.X.X.209上下载恶意程序，尝试失败后又尝试连接45.X.X.209的TCP 443、8443等端口，由于服务器配置了严格的策略，所有主动外联尝试均未成功。攻击方成功上传she.jsp、shell1.jsp等木马，但是均被发现。
32.3 分析结论
系统先后经历两次进攻，第一次攻击行为发生后，工程师重启服务器并禁止访问WebShell路径及/seeyon/htmlofficeservlet路径，随后修复补丁；第二次发现攻击行为后，将所有绕过路径进行拦截，清除恶意WebShell，完全修复漏洞及恶意程序。
31.4 分析价值
网络全流量分析技术能够帮助用户：
1、“看的全”——不仅仅能够发现常见的异常攻击，同样能够发现新型的未知威胁；
2、“看的清”——帮助用户完整还原攻击行为，分析攻击线索，评估处置效果；
3、“看的准”——为后续安全评估及取证提供全量原始数据包取证；
这将赋能网络的全方位安全感知能力，实现网络监测无死角。
第三十三章
如何分析攻防场景中的入侵成功行为
网络入侵是无声无息的，如果没有相关设备的监测与告警，等待网络管理员的可能不是攻击者的叫嚣，而是监管方的通报。诚然，攻击链中的部分环节可能触发监测设备的检测规则，产生碎片化的攻击告警。在发现碎片化的告警信息后，如何完整还原攻击者的攻击链，成为了防守方的难题。
“网络流量记录着一切真相，再高级的攻击也会留下痕迹。”通过科来网络回溯分析技术，即使只有碎片化的告警信息，科来也能够还原攻击者入侵的完整攻击链。
33.1 问题描述
某金融单位进行攻防演练，上午十点相关安全厂商人员发现金融单位某系统被攻击方植入了WebShell木马，单位相关负责人对此十分重视。
33.2 分析过程
因触发告警的失陷主机为X.X.56.100，无攻击IP地址信息。因此通过科来网络全流量安全分析系统对X.X.56.100的IP会话进行回溯查询。发现X.X.1.10和X.X.1.131两个IP与X.X.56.100的交互流量较大，如下图所示：
针对这两个地址产生的会话内容进行重点分析。利用告警设备产生的WebShell文件名1.txt信息，分别对两台主机的相关流量进行检索，发现X.X.1.131无相关流量。
对X.X.1.10主机的流量进行分析，发现历史流量中存在与1.txt有关的URL访问行为。这些流量是未触发相关安全设备告警的“正常流量”，如下图所示：
对1.txt有关的URL请求进行数据流分析，发现了SQL查询语句，并发现了X.X.1.10是一个代理IP，其背后的真实IP为X.X.204.204。
再对其真实IP X.X.204.204进行回溯分析，发现其曾经进行过更改密码的行为，且执行成功。与该系统的负责人及相关账号的使用者进行确认，该账号本人并没有进行过数据库查询和密码更改的操作。
既然本人没有进行过操作，那么上述行为一定是攻击者所为。攻击者更改了密码后，获得权限。向前分析，攻击者为什么可以对数据库进行操作？
很可能攻击者已经上传了相关木马获得了权限。于是SQL修改密码前一段时间的POST上传流量进行重点分析，发现了攻击者的上一步动作。
对URL请求日志进行分析发现攻击者有获取全部环境属性的行为，并且上传了test.jsp。
攻击者上传test.jsp后，多次尝试请求访问test.jsp文件，在凌晨3：54分左右请求成功，成功后攻击者停止了操作。
上午10点左右，攻击者利用WebShell操作数据库时，被防守方的安全设备发现，并触发告警。至此，攻击者的攻击链被完整还原。
33.3 分析结论
科来团队发现了可疑的数据库操作行为后，对告警信息进行回溯，攻击者在凌晨利用SQL查询漏洞，修改了网站用户的登录密码，并上传WebShell文件，在上午10点对WebShell文件进行利用与开展后续攻击行为。成功还原了攻击者的攻击手法并上报客户及时处置。
33.4 分析价值
利用全流量回溯分析技术，可以将攻击者任何的蛛丝马迹还原，为防守方对攻击行为回溯、攻击链还原提供有力依据。进行取证加分，并及时发现和处置防守暴露点位，收敛攻击面，建立纵深防御体系，防止进一步丢分。
点此回到书架
增值电信业务经营许可证：陕B2-20210327 | 
陕公网安备 61102302611033号