rootkit

Linux Rootkit躲避内核检测

一曲冷凌霜 提交于 2020-07-28 02:54:54
来自 Linux Rootkit如何避开内核检测的 Rootkit在登堂入室并得手后,还要记得把门锁上。 如果我们想注入一个Rootkit到内核,同时不想被侦测到,那么我们需要做的是精妙的隐藏,并保持低调静悄悄,这个话题我已经谈过了,诸如进程摘链,TCP链接摘链潜伏等等,详情参见: https://blog.csdn.net/dog250/article/details/105371830 https://blog.csdn.net/dog250/article/details/105394840 然则天网恢恢,疏而不漏,马脚总是要露出来的。如果已经被怀疑,如何反制呢? 其实第一时间采取反制措施势必重要!我们需要的只是占领制高点,让后续的侦测手段无从开展。 我们必须知道都有哪些侦测措施用来应对Rootkit,常见的,不外乎以下: systemtap,raw kprobe/jprobe,ftrace等跟踪机制。它们通过内核模块起作用。 自研内核模块,采用指令特征匹配,指令校验机制排查Rootkit。 gdb/kdb/crash调试机制,它们通过/dev/mem,/proc/kcore起作用。 和杀毒软件打架一样,Rootkit和反Rootkit也是互搏的对象。 无论如何互搏,其战场均在内核态。 很显然,我们要做的就是: 第一时间封堵内核模块的加载。 第一时间封堵/dev/mem,

7.8. 入侵检测

橙三吉。 提交于 2020-07-27 00:12:21
文章目录 7.8. 入侵检测 7.8.1. IDS与IPS 7.8.2. 常见入侵点 7.8.3. 监控实现 7.8.3.1. 客户端监控 7.8.3.2. 网络检测 7.8.3.3. 日志分析 7.8.4. 参考链接 7.8. 入侵检测 7.8.1. IDS与IPS IDS与IPS是常见的防护设备,IPS相对IDS的不同点在于,IPS通常具有阻断能力。 7.8.2. 常见入侵点 Web入侵 高危服务入侵 7.8.3. 监控实现 7.8.3.1. 客户端监控 监控敏感配置文件 常用命令ELF文件完整性监控 ps lsof … rootkit监控 资源使用报警 内存使用率 CPU使用率 IO使用率 网络使用率 新出现进程监控 基于inotify的文件监控 7.8.3.2. 网络检测 基于网络层面的攻击向量做检测,如Snort等。 7.8.3.3. 日志分析 将主机系统安全日志/操作日志、网络设备流量日志、Web应用访问日志、SQL应用访问日志等日志集中到一个统一的后台,在后台中对各类日志进行综合的分析。 7.8.4. 参考链接 企业安全建设之HIDS 大型互联网企业入侵检测实战总结 同程入侵检测系统 Web日志安全分析系统实践 Web日志安全分析浅谈 网络层绕过IDS/IPS的一些探索 上一篇: 下一篇: 来源: oschina 链接: https://my.oschina.net

将你的Rootkit代码注入到一个Linux内核模块

坚强是说给别人听的谎言 提交于 2020-05-08 09:55:34
前段时间从完成“实时获取系统中TCP半连接数量”这个永远无法上线的半吊子需求开始,一发不可收拾地栽进了Rootkit深坑,有点走火入魔,写了好多篇这方面的随笔并结识了很多朋友,感觉不错。 前面的系列文章中,大多数都是描述某个技术点的,而你想利用这个技术点做点实际的好事或者坏事,其实还有一段很长距离的路要走,比如: 谁给你的root权限? 你会编程并且编写Linux内核模块吗? 系统中有gcc和make吗? 内核模块要求签名验证吗? 经理姓刘吗?或者经理姓吴吗? … 以上的每一个单点都是易守难攻,所以说,把自己的Rootkit代码注入系统还是颇有难度的。 本文介绍一种简单的注入方法,即 将你的Rootkit代码注入到一个现有的Linux内核模块中。 很多初学者都干过一件事,即 修改ELF文件或者PE文件的入口函数,让它跳到自己的逻辑。 想做到这个其实很容易,将我们自己的stub obj文件link到既有的可执行文件,然后修改文件的entry即可。只要手边有ELF文件或者PE文件的手册,还有什么不能改的呢。 有趣的是,对于Linux内核模块的注入,要比上面可执行文件的注入容易得多! 因为Linux内核模块根本不靠entry来确定入口,而是依靠init_module symbol确定入口的。 本文以一种轻松的方式叙述,和以往一样,依然不分析内核源码,我希望通过小实验来描述我想表达的东西。

Linux如何动态添加新的系统调用

家住魔仙堡 提交于 2020-05-07 12:55:50
来自 《Linux动态为内核添加新的系统调用》 先来个满满的回忆: https://blog.csdn.net/dog250/article/details/6446192 2011年写这篇文章的时候,我的女儿小小还没有出生。 评价一下这篇文章,总体写得还不错,但排版不行。时间如白驹过隙,快十年过去了,今天我来旧事重提。 添加新的系统调用 ,这是一个老掉牙的话题。前段时间折腾Rootkit的时候,我有意避开涉及HOOK劫持系统调用的话题,我主要是想来点新鲜的东西,毕竟关于劫持系统调用这种话题,网上的资料可谓汗牛充栋。 本文的主题依然不是劫持系统调用,而是添加系统调用,并且是动态添加系统调用,即在不重新编译内核的前提下添加系统调用,毕竟如果可以重新编译内核的话,那实在是没有意思。 但文中所述动态新增系统调用的方式依然是老掉牙的方式,甚至和2011年的文章有所雷同,但是 这篇文章介绍的方式足够清爽! 我们从一个问题开始。我的问题是: Linux系统中如何获取以及修改当前进程的名字?? 你去搜一下这个topic,一堆冗余繁杂的方案,大多数都是借助procfs来完成这个需求,但没有直接的让人感到清爽的方法,比如调用一个getname接口即可获取当前进程的名字,调用一个modname接口就能修改自己的名字,没有这样的方法。 所以,干嘛不增加两个系统调用呢: sys_getname:

通过trace stack检测内核函数是否被hook

末鹿安然 提交于 2020-05-01 13:06:36
Rootkit需要及时发现是否有程序抓它,而侦测程序本身也需要时刻警惕Rootkit的注入,左右互搏。 侦测程序发现Rootkit的手段是非常多的,前面我介绍过通过内核text段互相调用的地址范围来静态扫描的方式: https://blog.csdn.net/dog250/article/details/105474909 本文我将介绍一种动态trace stack的方式来捕捉内核函数的调用异常。 以一个中性程序为例来讲吧。无关褒贬善恶。 上个月,我实现了一个功能,统计被iptables在INPUT链上DROP掉的数据包的数量: https://blog.csdn.net/dog250/article/details/105206753 具体细节请看那篇文章吧。 我的意思是,如何查出ip_local_deliver的中间被hook了呢? 这其实很难,但也不是没有办法。 假设在不考虑性能损耗的情况下,我为内核的每一个函数头部添加一个jmp stub,在该stub中dump当前的stack,那么只要该stack的RBP下面附近有非内核text段地址区间范围的地址,那就需要详查,排除掉回调函数,剩下的就是非法的。 内核text段地址区间大致就是: ffffffff81000000 T _text .. . ffffffff81649abb T _etext 我们摆出DROP统计里的例子

我的电脑不联网,很安全,黑客:你还有风扇呢

穿精又带淫゛_ 提交于 2020-04-21 12:14:58
从1988年第一个网络蠕虫病毒诞生以来,「互联网危机四伏」的观念就已经深入人心。如果只是这样,不给电脑联网、禁止使用任何可移动储存介质,数据就安全了吗?但专门研究黑客攻击技术的研究者告诉我们,这个想法太天真了。他们用实验证明,即使不联网,机箱里的风扇也能泄露你的机密信息。 机器之心报道,参与:张倩、蛋酱、杜伟。 这项研究的作者 Mordechai Guri 来自以色列本·古里安大学。在最近发表的一篇论文中,他提出了一种名为 AiR-ViBeR 的数据窃取技术。令人颇为震惊的是,这种技术的「窃取」方式是借助电脑内部的风扇振动。 简单地说,这一攻击分为三个步骤。首先,利用植入电脑中的恶意软件来控制风扇转速,以此来调节电脑产生的机械振动,数据会被编码到这些振动中;接下来,将智能手机放置在电脑桌上或靠近电脑主机的其他位置,手机中的加速度传感器可以用来收集振动信号;最后,通过 app 解码获取的信号。 过去五年来,Mordechai Guri 一直致力于找到一种让不联网的计算机向外界发送数据,但又不被发现的方法。AiR-ViBeR 是他设计的一堆稀奇古怪方法里最新的一种。 这项研究非常重要,因为那些存储了机密文件和知识产权的政府和公司内网,如今会面临着被攻破的危险。 这之前,Guri 教授的团队还提出过很多种从未联网计算机中窃取数据的方法,比如: LED-it-Go:通过硬盘驱动器的 LED

当CPU过热时让你的风扇不再狂转(Rootkit之最后)

六月ゝ 毕业季﹏ 提交于 2020-04-11 16:51:30
进程隐藏了,CPU利用率隐藏了,TCP连接隐藏了,临时文件也隐藏了… https://blog.csdn.net/dog250/article/details/105292504 https://blog.csdn.net/dog250/article/details/105394840 https://blog.csdn.net/dog250/article/details/105421530 但是机器非常卡顿,经理的进程执行非常慢。 此时的机器资源已经被你掏空,经理却不知道: CPU已经过载,但是top和sysstat却显得非常平静。 ps -elf,ls /proc看不出任何怪异的进程。 ss/netstat/diag看不出任何异常的端口和连接。 文件系统看不出任何怪异的文件。 内核模块oneshot加载注入二进制码后自我销毁,不留痕迹。 … 经理没有什么思路,经理不明白发生了什么。所以我需要给经理一个思路。 查CPU的温度啊! 呃,CPU温度非常高,但是top/sar显得CPU利用率非常低,原来机器放点燃🔥的煤气灶上了… 但经理同样看不见煤气灶在哪里。 即便用Rootkit把该隐藏的都隐藏了, 物理性质导致的事情的变化 是隐藏不了的。比如CPU的温度,风扇的转速。一旦经理发现CPU,风扇异常,就意味着机器可能被植入了不好的东西。 至于ps,top,sar这些

Metasploit发布了版本5.0.76

此生再无相见时 提交于 2020-02-26 06:25:08
Metasploit发布了版本5.0.76 在该版本中,增加了以下模块: (1)增强了set payload命令的输入。用户在指定payload时,在payload名称前可以使用/payload、payload/和/前缀。 (2)post/windows/manage/sshkey_persistence和post/ linux/manage/sshkey_persistence模块:利用SSH Key实施渗透。 (3)post/multi/recon/local_exploit_suggester模块:提升Diamorphine Rootkit信号权限。 (4)module exploit/ linux/smtp/apache_james_exec模块:利用Apache James 2.3.2漏洞创建文件。 更新了以下模块: (1)post/windows/gather/enum_patches 模块:收集所有Windows补丁。 (2)更新了generate命令:避免分段显示攻击载荷信息。 (3)post/ linux/gather/enum_system模块:通过从/sys/devices/system/ cpu/ vulnerabilities目录收集的信息,来检查CPU漏洞。 (4)更新了msfconsole和msfvenom的Zsh completions。 来源:

SSDT-hook,IDT-hook原理

我们两清 提交于 2020-01-07 08:16:19
【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 【详细过程】 这次主要说说核心层的hook。包括SSDT-hook,IDT-hook,sysenter-hook。欢迎讨论,指正!内核层需要驱动,有这方面的基础最好,如果不会,了解下其中的思路也可以的。 II. SSDT-hook,IDT-hook,sysenter-hook 一.SSDT-hook (一)一般思路: 1.先来了解一下,什么是SSDT SSDT既System Service Dispath Table。在了解他之前,我们先了解一下NT的基本组建。在 Windows NT 下,NT 的 executive(NTOSKRNL.EXE 的一部分)提供了核心系统服务。各种 Win32、OS/2 和 POSIX 的 APIs 都是以 DLL 的形式提供的。这些dll中的 APIs 转过来调用了 NT executive 提供的服务。尽管调用了相同的系统服务,但由于子系统不同,API 函数的函数名也不同。例如,要用Win32 API 打开一个文件,应用程序会调用 CreateFile(),而要用 POSIX API,则应用程序调用 open() 函数。这两种应用程序最终都会调用 NT executive 中的 NtCreateFile() 系统服务。 用户模式(User mode)的所有调用

Understanding rkhunter warnings

纵饮孤独 提交于 2020-01-03 15:30:46
问题 I got paranoid and ran both chkrootkit and rkhunter to scan for rootkits. Doesn't look like chkrootkit found anything, but rkhunter returned some warnings. I think many might be false positives, but I'm mostly worried about the 'possible rootkit strings' and the three suspect files. Any explanations would be greatly appreciated!! Thank you! Performing file properties checks /usr/bin/fuser [ Warning ] /usr/bin/whatis [ Warning ] /usr/bin/shasum [ Warning ] Performing additional rootkit checks