一、背景
最近接到一客户电话，客户反馈：“单位A服务器数据库信息被修改，原本字段的内容被修改为其它”。同时我收到一张字段被修改的照片，原本该数据为数字，现在被替换为了nv0K7x4u。
得到上述信息后开始了解该系统情况（故作淡定）：
1、服务器是否对互联网提供应用？
2、是否库站分离；
3、是否映射3389端口到互联网；
……
通过对上述信息进行沟通后得到以下信息：
1、A服务器有对互联网提供X应用；
2、库站未分离；
3、3389端口可以访问，但未映射到互联网上。
二、应急响应思路
通过对网络环境进行了解，结合有可能发生字段被篡改的情况和常见应急响应思路，我确认了3种情况，分别如下：
1、确认是否是由于运维人员误操作导致；
2、确认是否是通过远程登录系统，在系统中做非法操作导致；
3、确认是否是由于官网存在漏洞，在漏洞利用过程中导致。
确认响应思路后，便开始进行分析。
三、应急思路排查
3.1确认是否为误操作
针对是否为误操作问题，主要是通过和运维人员进行沟通，了解是否有做其他操作，导致数据被篡改，通过沟通，未发现存在误操作现象。
在对系统应用日志进行分析发现在客户反馈出现异常的时间段存在数据备份操作，有点怀疑是否是数据备份的过程中会导致数据紊乱，从而造成数据被篡改现象，这里保持疑问，进行其他项分析。
3.2确认是否存在远程登录
对系统安全日志和远程登录日志进行分析，未发现存在远程登录情况（日志的默认大小为68kb，因此无数据）。
3.3确认是否存在web应用漏洞
首先查看web应用日志，在web访问日志中发现大量SQL注入攻击日志。
另外存在5个小时日志空缺，只记录了当天上午9：47：41之前的数据，后面的数据则未空：
看到大量sql注入日志，因此暂时怀疑X系统存SQL注入漏洞，黑客在执行SQL注入时导致的数据篡改或者黑客获取数据库权限后进行的恶意数据篡改。到这里也仅仅是怀疑。
3.4定位分析
这里可以暂时定位为数据篡改是由于X系统存在SQL注入漏洞导致，下一步分析即针对该系统进行漏洞验证，检测是否存在SQL注入漏洞，从而验证我们的猜想。通过对X系统进行漏洞检测时发现该系统登录框处存在SQL注入漏洞。
通过对X系统进行漏洞验证，发现该系统真实存在SQL注入漏洞；由于数据库信息已通过被恢复，查找不到相关数据库操作记录，结合web访问日志中存在200状态码返回值和缺少5小时web日志进行综合分析，推断本次事件分析结果为：黑客在执行SQL注入时注入语句导致数据篡改或者黑客获取数据库权限后进行的恶意数据篡改。
到此完成应急工作。
四、总结
遇到安全事件时，可根据安全事件的表现现象进行根因分析，提出最有可能导致该现象的几种假设，并针对假设进行逐一分析、排查，最终确认最有可能的原因。
*本文作者：bbbbbbig，转自FreeBuf