process-monitor

原文来自 SecIN社区 —作者：寅儿 0x01 开源情报收集 样本下载链接： https://app.any.run/tasks/ffc1ecff-e461-4474-8352-551db7e7b06f/ 常用平台:VT，微步，哈勃 app.any.run, joesandbox 图一：VT检测 木马实锤 沙箱跑一下看一下行为： 图二：沙箱行为分析 可以看到用GET请求访问C&C服务器下载了一个二进制binary文件。 点开binary文件查看详情： 图三：恶意binary dump下来wireshark数据包，过滤http请求同样可以发现该二进制文件 图四：抓包分析 查询C&C服务器ip： 图五：ip检测 现在对该恶意软件已经有了初步了了解，下面进行数据包分析，看看能不能找到有用的信息。最直观的看到就是使用了非常见的端口连接，还有发现一个有趣的现象： 图六：数据包分析 竟然是肉鸡主动连接的C&C服务器，让我联想到了CS马。这种手法类似于反弹shell，好处就是可以绕过防火墙限制，如果对方是内网ip，你无法直接发起连接请求，方便持久化控制等等。 0x02 样本基本信息 用exeinfo查壳，标准的32位VC编译的程序 图七：样本信息 用Process Monitor监控行为 图八：软件行为 具体每一项的图略了，大概看了一下读取了注册表的某些键值，设置了某些键值对的值

Mybaits判断使用if...else.. | 查询结果中可以这样使用 第一种if...else.. SELECT status, case status when 0 then '未开始' when 1 then '已开始' when 2 then '审批中' when 3 then '已通过' when 4 then '已驳回' when 5 then '已结束' else '未开始' end as statusName FROM zxcms_process_monitor; 第二种if...else.. SELECT status, case when status=0 then '未开始' when status=1 then '已开始' when status=2 then '审批中' else '未开始' end FROM zxcms_process_monitor; 第三种if..else.. IF(expr1,expr2,expr3) 释义： expr1=true ,结果为 expr2; expr1=false ,结果为 expr3; ps:MySQL非空判断 IFNULL(expr1,expr2) 释义： 假如expr1 不为 NULL，则 IFNULL() 的返回值为 expr1; 否则其返回值为 expr2 查询where条件中可以这样使用 <choose>

如果你想成为一名逆向分析或恶意代码检测工程师，或者对系统安全非常感兴趣，就必须要认真分析一些恶意样本。熊猫烧香病毒就是一款非常具有代表性的病毒，当年造成了非常大的影响，并且也有一定技术手段。本文将详细讲解熊猫烧香的行为机理，并通过软件对其功能行为进行分析，这将有助于我们学习逆向分析和反病毒工作。后续作者还将对其进行逆向调试，以及WannaCry勒索蠕虫、各种恶意样本及木马的分析。基础性文章，希望您喜欢！同时，本文部分实验参考姜晔老师的视频分析，真的非常佩服和值得去学习的一位老师。技术路上哪有享乐，为了提升安全能力，别抱怨，干就对了~ 从2019年7月开始，我来到了一个陌生的专业——网络空间安全。初入安全领域，是非常痛苦和难受的，要学的东西太多、涉及面太广，但好在自己通过分享100篇“网络安全自学”系列文章，艰难前行着。感恩这一年相识、相知、相趣的安全大佬和朋友们，如果写得不好或不足之处，还请大家海涵！ 接下来我将开启新的安全系列，叫“安全攻防进阶篇”，也是免费的100篇文章，作者将更加深入的去研究恶意样本分析、逆向分析、内网渗透、网络攻防实战等，也将通过在线笔记和实践操作的形式分享与博友们学习，希望能与您一起进步，加油~ 推荐前文： 网络安全自学篇系列-100篇 话不多说，让我们开始新的征程吧！您的点赞、评论、收藏将是对我最大的支持，感恩安全路上一路前行，如果有写得不好或侵权的地方

【0】前置概念参考 预写式日志（Write-Ahead Logging (WAL)） 【1】事务的持久化概念 ACID 是数据库的基本属性。其中的D是指"持久性"：只要事务已经提交，对应的数据修改就会被保存下来，即使出现断电等情况，当系统重启后之前已经提交的数据依然能够反映到数据库中。 那么D特性是如何在SQL Server中实现的呢？SQL Server使用write-ahead logging的方式，保证日志记录会先于数据记录固化到磁盘中。 当事务提交后，只有当日志记录固化到磁盘时，才会向客户端返回提交成功的消息，至于相应的数据记录，会通过异步的方式后续写入到磁盘中。 如果在此期间发生断电等故障，那么就会出现以下两种情况： 日志已经写入到磁盘（committed)，但数据没有写入： 系统重启后进行redo操作，通过读取日志，来将没有固化到数据文件的信息写入到数据文件。 部分日志已经写入到磁盘(uncommitted)，数据部分写入或没有写入 系统重启后执行undo操作，将没有提交的事务对应的数据从数据文件中清除。 这样就保证了已经提交的事务不会丢失。 【2】Delayed durability 延迟日志写入 官网概念： https://docs.microsoft.com/zh-cn/sql/relational-databases/logs/control