凌晨三点，服务我盯着那个SSH会话，器中手指在键盘上停了几秒。根目对面是录下一台刚拿下的Ubuntu 20.04，权限只到www-data。服务flag不在web目录，器中不在数据库，根目不在环境变量。录下直觉告诉我，服务它藏在根目录某个不起眼的器中角落。

很多人拿到shell后第一反应是根目翻/home、/var/www、录下/tmp。服务这些地方确实常放东西，器中但真正有意思的根目题目，往往把flag塞进根目录下那些你天天路过却从不细看的文件夹。比如/opt，比如/srv，甚至直接扔在/下面，文件名伪装成.flag或者readme.txt。我见过最损的一个，flag写在/lost+found里——那个只有root能进的目录，权限卡得死死的。

先说/本身。用ls -la /扫一眼，别只看bin、etc、home这些熟脸。注意那些权限奇怪的文件。有一次我看到根目录下有个flag.txt，权限是444，owner是root，但group是www-data。巧了，我正好在那个组里。cat一下，flag到手。这种配置失误比漏洞还常见，管理员图省事，chmod时手滑给了不该给的组读权限。

/opt是个重灾区。很多第三方软件默认装这儿，比如Tomcat、Jenkins、各种自研脚本。翻/opt的时候别只盯着目录名，看看里面的.git文件夹。有次我找到一个/opt/backup/.git，整个仓库没删干净，git log翻到历史提交里有个flag.md，后来被删了但对象还在。git show直接还原。这种属于运维疏忽，但考试里经常出现，因为出题人知道大部分人不会去翻隐藏目录。

/srv也值得看。按FHS标准，这里放服务数据。实际部署中，有人把flag放在/srv/ftp下面，匿名FTP能读。或者/srv/www里有个secret目录，权限没配好。我遇到过一台机器，/srv下有个flag文件，owner是root，但ACL里给www-data开了读权限。getfacl一看就明白了。ACL这东西，很多人查权限只看ls -l，漏掉加号后面的内容。

再说个偏门的。/proc下面也能藏flag。不是让你去改内核参数，而是看/proc/self/environ或者某个进程的cmdline。有次flag直接写在启动参数里，ps aux就能看到。还有/proc/sys/kernel/下面某些可写文件，出题人把flag写进去，你得有root才能读。这种就属于提权后的目标了。

提权到root之后，根目录反而简单了。find / -name "*flag*" 2>/dev/null一把梭。但别只搜文件名，内容也得搜。grep -r "flag{ " / --exclude-dir=proc --exclude-dir=sys 2>/dev/null，虽然慢，但有时候flag就藏在某个日志文件或者配置文件里，文件名完全不相关。我见过flag写在/etc/update-motd.d/00-header里的，每次登录都打印出来，但你就是没注意。

说个真实案例。某次靶场，根目录下有个/.dockerenv，说明是容器环境。flag不在容器里，在宿主机上。通过挂载的/var/run/docker.sock逃逸出去，最后在宿主机的/root/flag找到。这种就是套娃，你以为在玩单机，其实后面还有一层。根目录的flag有时候只是个诱饵，真正的目标在更深处。

最后提醒一句：别忽略/root。虽然默认700权限，但如果你已经提权到root，ls -la /root看看。很多题目把最终flag放这儿，文件名就叫flag，简单粗暴。我见过最离谱的，flag写在/root/.bash_history里，前面的人cat flag的命令还留着，你直接cat那个文件就行。

根目录下的flag，拼的不是技术多高深，是细心。把ls -la /的输出从头到尾看三遍，权限、时间戳、文件名，任何一个不对劲的地方都值得cat一下。别总想着找漏洞提权，有时候flag就躺在那儿，等你伸手。