【HVV实战复盘】面对防护完备的高校CAS与泛微OA,一次全程受阻的渗透记录"

admin 2026-11-10 16:24:31 网络安全文章 来源:ZONE.CI 全球网 0 阅读模式

【HVV 实战复盘】面对防护完备的高校 CAS 与泛微 OA,一次全程受阻的渗透记录

zhousir
zhousir

神农Sec

2026年11月10日 09:00
安徽

去阅读

课程培训

扫码咨询

五、CORS与Swagger——门户侧意外的两个缺口

5.1 CORS配置审计——一句话拉满风险

CAS和OA的防线非常严密,但在智慧珞珈门户(zhlj.whu.edu.cn)上,我碰到了一个意料之外的宽松配置:

$ curl -sk -D- 'https://zhlj.whu.edu.cn/api/user/info' -o /dev/null \\
  | grep -i 'access-control'

access-control-allow-origin: *
access-control-allow-methods: POST, GET, PUT, OPTIONS, DELETE
access-control-allow-headers: Content-Type, Authorization, X-Requested-With
access-control-max-age: 3600

Access-Control-Allow-Origin:\*——允许任意域名的跨域请求。更关键的是,允许的HTTP方法中包含了PUT和DELETE,不仅仅是只读的GET和POST。

HTTP/1.1 200 OK Access-Control-Allow-Origin: Content-Type: application/json

{\"users\": [...], \"total\": 42}

如果门户中存在任何不需要认证、也不需要Cookie的公开API接口,它们可以被任何域名的网页直接读取。结合knife4j Swagger中暴露的API端点列表(下一节),这是一个潜在的**数据泄露渠道**。

CSRF场景推演: 假设门户内有用户已登录(Session在),且存在POST接口接收数据(比如修改个人信息)。由于浏览器在 `credentials: 'include'` 且 `Access-Control-Allow-Origin: *` 的情况下,会拒绝读取响应——但**请求本身仍然会被发送到服务端**。这就构成了单纯的**CSRF攻击**:攻击者无法读取响应数据,但可以触发状态变更操作。

### 5.2 knife4j Swagger——暴露在生产环境的API清单

在门户路径扫描中,我发现了knife4j的页面:

$ curl -sk -o /dev/null -w '%{http_code}' 'https://zhlj.whu.edu.cn/api/doc.html'
302  # 跳转到CAS登录

$ curl -sk -L -o /dev/null -w '%{http_code}' 'https://zhlj.whu.edu.cn/api/doc.html'
200  # 跟随302后到达CAS登录页

页面存在但需要CAS认证。不过,查看前端加载的JS文件,API端点信息已经暴露在客户端代码中了:

// 前端JS中 knife4j 自动生成的API路由注册
\"paths\": {
    \"/api/user/info\": {\"get\": {\"tags\": [\"用户管理\"], ...}},
    \"/api/user/search\": {\"get\": {\"tags\": [\"用户管理\"], ...}},
    \"/api/user/profile/update\": {\"put\": {\"tags\": [\"个人信息\"], ...}},
    \"/api/auth/token/refresh\": {\"post\": {\"tags\": [\"认证\"], ...}},
    \"/api/auth/logout\": {\"post\": {\"tags\": [\"认证\"], ...}},
    \"/api/role/list\": {\"get\": {\"tags\": [\"角色管理\"], ...}},
    \"/api/role/assign\": {\"post\": {\"tags\": [\"角色管理\"], ...}},
    \"/api/permission/check\": {\"get\": {\"tags\": [\"权限\"], ...}},
    \"/api/upload/avatar\": {\"post\": {\"tags\": [\"文件\"], ...}},
    \"/api/export/data\": {\"get\": {\"tags\": [\"数据导出\"], ...}},
    \"/oauth2/authorize\": {\"get\": {\"tags\": [\"OAuth2\"], ...}},
    \"/oauth2/token\": {\"post\": {\"tags\": [\"OAuth2\"], ...}},
}

从暴露的端点来看,门户层是一个比较标准的Spring Boot RESTful API,包含了用户管理、角色分配、权限校验、文件上传、OAuth2授权等全套功能。特别是/api/role/assign(角色分配,认证后如果无二次鉴权即可提权)和/api/upload/avatar(文件上传,如果目录无执行限制即可传webshell)。

关于暴露设计的一个思考:Swagger在生产环境中「用认证拦截而不是直接关闭」是目前大量Java项目的通病。开发团队通常在开发环境开启knife4j方便调试,部署时改用认证保护而不是移除依赖——因为knife4j与业务代码深度耦合,移除需要改构建配置。

六、弱口令测试——42次尝试,42次受阻,然后被拉黑

6.1 学号格式与情报收集

该校的学号格式为10位数字,规律如下:

2023XXXX1043
├─ 2023  ─ 入学年份
├─ XXX  ─ 学院代码
├─ XX   ─ 专业代码
├─ XXXX ─ 序号

通过公开渠道(院系公示名单、奖学金公示、学科竞赛获奖名单),可以批量收集到大量学号。

结合从公开渠道收集到的学号样本(某学院2023级一名学生),进行针对性的弱口令测试:

信息字段 值(已脱敏) 来源
学号 2023XXXX1043(10位数字) 公开公示名单
姓名 仅知姓氏,具体不披露 同上
身份证 仅知后6位<font style=\"color:rgb(3, 105, 161);\">xxx731</font> 不宜公开
生日 2005年12月(具体日不披露) 已脱敏
所属 某学院2023级 从学号推断

6.2 密码字典构建——从确定性到推测性

基于上述情报,构建了分层的密码字典——按确定性从高到低排列:

第一梯队(高确定性):基于完整身份证/学号本身的密码
  xxxxxxxxxxxxxx731  — 身份证完整18位(极可能设为初始密码)
  2023xxxx1043       — 完整学号

第二梯队(较高确定性):基于身份证派生
  200512xx            — 生日8位(该校常见初始密码格式)
  xxxx731             — 身份证后6位
  12xxxx              — 月日+年份尾数

第三梯队(中等确定性):基于学号派生
  xx1043              — 学号后6位(最常见的弱口令模式)
  xxxx1043            — 学号后8位

第四梯队(中等确定性):Whu + 年份 模式
  Whu2025#            — 该校2025级默认密码(常见格式)
  Whu2024#            — 该校2024级默认密码
  Whu2026#            — 该校2026级默认密码
  whu2025             — 全小写变体
  whu@2025            — 符号变体
  Whu@2025            — 大小写符号变体
  Whu2025!            — 感叹号变体

第五梯队(较低确定性):姓名拼音组合
  xiejianheng         — 全拼小写
  Xiejianheng         — 首字母大写
  XieJianHeng         — 完整大写
  xjhxxxx             — 姓名首字母+学号后4位
  Xjxxx731            — 姓名首字母+身份证后6位

第六梯队(低确定性):通用弱口令
  123456 / 000000 / 111111 / password / Passw0rd / P@ssw0rd

第七梯队(高校常见模式)
  whu123 / Wuhan123 / WHU123 / whu2023 / whu2024

总共整理了42个密码。

6.3 自动化测试——完整的请求/响应日志

用Python脚本进行自动化测试。每轮测试的完整请求/响应日志如下:

[*] 获取CAS登录参数...
[*] Salt: QAQVEU444clkxIXy
[*] execution: e3s1a2b3c4d5... (截断)

--- 测试开始 ---

[01/42]  密码: xxxxxxxxxxxxxx731
  POST -> 200, 响应长度: 14328 bytes
  页面包含: \"execution\" (参数刷新, 密码错误回显)
  → WRONG_PASS (页面显示: 用户名或密码错误)

[02/42]  密码: 2023xxxx1043
  POST -> 200, 响应长度: 14325 bytes
  页面包含: \"execution\"
  → WRONG_PASS

[03/42]  密码: 200512xx
  POST -> 200, 响应长度: 14328 bytes
  页面包含: \"execution\"
  → WRONG_PASS

[04/42]  密码: xxxx731
  POST -> 200, 响应长度: 14325 bytes
  → WRONG_PASS

...

[10/42]  刷新CAS参数...
[*] 新execution获取成功, salt不变

[15/42]  密码: Whu2025#
  POST -> 200, 响应长度: 14326 bytes
  → WRONG_PASS

...

[20/42]  刷新CAS参数...

[25/42]  密码: xiejianheng
  POST -> 200, 响应长度: 14328 bytes
  → WRONG_PASS

...

[30/42]  刷新CAS参数...

[35/42]  密码: 123456
  POST -> 200, 响应长度: 14325 bytes
  → WRONG_PASS

...

[42/42]  密码: whu2023
  POST -> 200, 响应长度: 14325 bytes
  → WRONG_PASS

--- 测试结束 ---
[*] 42个密码全部测试完毕, 0个成功

关键观察:所有42次请求都返回了HTTP 200和相似的响应长度(14325-14328 bytes)。响应长度波动仅3字节——这可能是CAS页面中的时间戳或随机参数差异造成的,与密码正确与否无关。这也排除了通过响应长度差异来做用户枚举的可能性——该CAS系统在这方面做得很好。

6.4 IP被封锁——最致命的发现

在42次测试后的某个时刻,脚本突然开始返回401:

r = session.post(CAS_LOGIN_URL, data=data, allow_redirects=False)
print(f\"  HTTP {r.status_code}\")  # 401

# 尝试获取新的CAS参数
params = get_cas_params(session)
if not params:
    print(\"[!] CAS参数获取失败\")

返回码从200突然变成了401。而CAS登录页本身也返回了401——这意味着我的IP已经被CAS的前置防护机制列入了黑名单。

这个封锁不是OA的WAF做的——因为OA仍然可以正常访问。它是CAS前置防护做的针对性封锁。封锁的触发条件推测如下:

触发因素 设计目的 我的触发量
同一IP在短时间内多次获取<font style=\"color:rgb(3, 105, 161);\">execution</font> 防execution批量扫描 约5次(每10个密码刷新一次)
同一IP在短时间内多次POST登录 防密码爆破 42次
同一客户端提交了过期execution值 防CSRF重放 0次

最可能的触发机制是:CAS跟踪了每个IP在单位时间内的POST请求频率。42次登录尝试+5次参数刷新=47次POST请求,分布在约2分钟内。

封锁后,我尝试更换User-Agent、使用不同的Cookie、连接新的Session——仍然返回401。确认是IP级别的封禁。

这个发现对后续攻击者有重要的参考价值:

  • CAS的IP封锁阈值约50次/2分钟
  • 封锁后更换Session无效——是对端IP的防火墙规则,不是业务逻辑
  • 恢复时间未知(停止测试后30分钟再试仍然401)

七、攻击面全景——分三层的地图

┌─────────────────────────────────────────────────────────────────────────┐
│                    目标高校 IT系统 攻击面评估全景                         │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                         │
│  ═══ TIER 1: 高价值·需认证 ═══                                         │
│                                                                         │
│  ① 泛微OA (oa.xxx.edu.cn)                                              │
│  ├─ 攻击面: 前台SQL注入(CNVD-2021-28234) → 需有效JSESSIONID             │
│  ├─ 攻击面: JDBC反序列化(/api/ec/dev/check/checkurl) → 需有效JSESSIONID │
│  ├─ 攻击面: 文件上传(/page/officesetting/officehelp.jsp) → 需有效会话   │
│  ├─ 指纹: e-cology 9.x (React前端), openresty 1.27.1.2                 │
│  └─ 当前状态: 全部302跳转CAS,无未授权入口                              │
│                                                                         │
│  ② CAS统一认证 (cas.xxx.edu.cn)                                        │
│  ├─ 攻击面: 密码爆破 → captchaSwitch=2(验证码强制) + IP封锁机制         │
│  ├─ 攻击面: 动态码登录 → 理论上绕过密码, 但需合法手机号                  │
│  ├─ 逆向成果: AES-CBC加密已完整复现                                    │
│  └─ 当前状态: 测试IP已封锁                                              │
│                                                                         │
│  ═══ TIER 2: 中等价值·部分可访问 ═══                                    │
│                                                                         │
│  ③ 门户 (zhlj.xxx.edu.cn)                                              │
│  ├─ CORS: `Access-Control-Allow-Origin: *` → CSRF攻击面                │
│  ├─ knife4j Swagger: 端点暴露(12+API路径) → 需CAS认证后利用             │
│  └─ API网关: 通过前端JS发现用户管理/角色分配/文件上传/数据导出接口       │
│                                                                         │
│  ④ 人事系统 (rsb.xxx.edu.cn)                                           │
│  ├─ 技术栈: Apache 2.4.57 + PHP 7.4(EOL) + VSB9                        │
│  └─ CMS版本偏旧, 可能有通用漏洞                                         │
│                                                                         │
│  ═══ TIER 3: 低价值/可忽略 ═══                                         │
│                                                                         │
│  ⑤ 智能体平台 → 建设中                                                 │
│  ⑥ 科研系统 / 教务系统 → 需CAS认证                                     │
│  ⑦ VPN → 非该高校IP段, 可能独立管理                                    │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘

八、红队视角总结——红蓝双向攻防评估

8.1 攻击路径可行性矩阵

攻击路径 前置条件 预期收益 绕过难度 综合推荐指数 核心原因
泛微OA前台SQLi 需有效JSESSIONID 数据库数据泄露(含密码hash) 高 OA数据库包含大量业务数据
泛微OA JDBC反序列化 需有效JSESSIONID RCE + 内网横向移动 高 一旦拿到就是全内网通道
泛微OA文件上传 需有效JSESSIONID WebShell 高 需同时绕过认证+上传类型校验
CAS动态码社工 需有效手机号 CAS会话(全系统可用) 中 护网场景下,社工是最短路径
CAS密码爆破 需绕过IP封锁+验证码 单个账号权限 极高 锁定阈值极低, 投入产出比极差
CORS+CSRF钓鱼 需用户访问恶意页面 CAS会话劫持 中 护网用户配合度是关键变量
Swagger API文档利用 需先获取CAS会话 全套API接口路径 低(锁定CAS后) 认证后的利用价值非常高
人事系统CMS漏洞 需VSB9版本漏洞 有限权限 中 主要面向外网,与核心系统隔离
供应链/0day 0day储备 取决于漏洞类型 极高 不可控,但一旦命中收益巨大

8.2 红蓝双方对抗评估表

评估维度 红队(攻击方)视角 蓝队(防守方)视角 总评
资产暴露 15+子域名暴露,但大部分需CAS认证,有效攻击面有限 对C段做了端口控制,无意外暴露 蓝队+1
认证安全 CAS加密已完全逆向,但验证码+封锁+密码策略三防合一无法绕过 验证码强制开启,密码AES加密,IP封锁到位 蓝队+2
OA安全 泛微OA存在大量历史漏洞,但全部被CAS委派模式天然屏蔽 将OA认证委派给CAS,而非独立认证 蓝队+2
WAF配置 无明显WAF特征,但所有攻击面均被Spring Security二次拦截 WAF+应用层双保险,无单点绕过 蓝队+1
CORS配置 <font style=\"color:rgb(3, 105, 161);\">Access-Control-Allow-Origin: *</font>存在CSRF攻击面 未限制CORS来源,存在风险 红队+1
Swagger管理 前端JS中API路径已暴露,认证后可快速获取完整文档 Swagger未在生产环境关闭,仅用认证拦截 红队+1
人因安全 成功收集到学号信息,可做社工和目标攻击 弱口令检测未突破,密码策略执行有效 平手
频率控制 约50次请求后被IP封禁 IP封锁机制触发及时 蓝队+1

最终对抗评分:蓝队 7 : 3 红队

8.3 防守方做得好的——详细技术分析

① CAS委派架构——对OA历史漏洞的天然免疫

泛微OA众所周知地「漏洞多」,但该校将OA的认证委派给CAS统一管理——攻击者即使找到了一条OA的0day,如果没有有效的CAS会话,也无法利用。这种架构级安全设计比任何补丁管理策略都有效。

② 验证码+加密+封锁的三层密码防护

密码在传输层被AES-CBC加密(防窃听),在业务层被验证码保护(防自动化),在IP层被频率封锁(防批量)。三层防护的叠加意味着:在线密码爆破对这套CAS来说已经不是一个可行的攻击手段。

③ 响应一致性

所有失败的密码尝试都返回同样的200状态码和几乎相同的页面长度——不存在通过响应差异来做用户枚举或密码猜测的空间。这在高校CAS中属于做得相当好的。

④ 端口控制

C段内几乎所有主机只开放80/443/8080三个端口,无意外暴露。内网服务(数据库、缓存、管理面板)全部不暴露到公网。

8.4 防守方可改进的——应该收紧的螺丝

① CORS:*配置

Access-Control-Allow-Origin: *出现在门户的主页响应中。虽然当前没有XSS漏洞配合,但结合knife4j暴露的API路径,这个配置在攻击链扩展场景下价值巨大。建议配置为具体域名的白名单。

② Swagger生产环境残留

knife4j在前端JS中打包了完整的API路由定义。即使knife4j页面本身需要CAS认证,API路径信息已经通过JS文件被攻击者获取。建议在Maven/Gradle构建配置中通过profile机制区分环境,确保生产构建排除swagger依赖。

③ 密码找回接口行为

/authserver/retrieve-password/在没有合法参数时返回「请求不合法」(400)——说明该接口逻辑存在,密码找回接口通常是用户枚举的高价值目标。

④ 人事系统版本过期

PHP 7.4(2022年11月EOL)+ VSB9(版本偏旧)的组合虽然当前不是核心资产,但在攻击链扩展场景下可能成为跳板。建议升级PHP版本和CMS版本。

8.5 如果我是蓝队,我会在哪里加一道防线

如果允许我提一个最优先的加固建议,既不是CORS也不是Swagger——我会建议对CAS登录IP做一个更细粒度的评分机制:不是简单的一刀切封禁,而是结合设备指纹、请求行为模式、历史信誉度来做动态风险评估。一刀切封禁会让正常用户在某个网络出口被封时无法登录,而精细化的评分机制可以在阻断攻击的同时不影响用户体验。

8.6 最后的思考——一次「全程受阻」的真实记录

写到这里,我想聊聊这篇文章为什么值得发。

安全社区从来不缺成功的渗透复盘——「从信息收集到拿下Shell」的爽文遍地都是。但我认为,真实受阻记录的价值不比成功故事低。

这套CAS是我今年遇到的防护最完整的高校认证系统之一。它没有明显的配置失误(除了CORS和Swagger),没有已知的未授权漏洞路径,密码策略执行严格。在高版本的CAS + 正确的架构设计 + 合理的频率控制下,在线攻击几乎无法突破。

但这并不意味着没有突破口。以下是我认为最有可能的三条路径:

  1. 社会工程学——从外网用户入手。数万学生和教工,任何一个用户都可能成为社工目标。动态码/SMS登录是CAS体系中最薄弱的环节——密码攻不破,但从手机号入手就不一样了。
  2. 供应链攻击——第三方系统。泛微OA、VSB9、knife4j,这些都是第三方提供的组件。任何第三方系统的新漏洞都可能成为进入内网的跳板。
  3. HVV特殊性——0day。HVV的攻防博弈不仅是技术对抗,更是资源博弈。如果攻击方有泛微OA 9.x的0day储备,那整篇文章的分析框架就需要全部重写。

护网的胜负手,常常不在技术栈内,而在技术栈外。

02

0x2 培训课程介绍

26

SRC漏洞挖掘培训课程

1.课程价格目前是575(后面也会随着人数越多,涨价)🌟师傅们还可以上车补票,冲冲冲!

2.报名成功送知识星球一个,拉内部小圈子交流群+SRC直播通知群!✨

3.一周2节课程,直播+录播形式,课程内容大家可以看课表,目前是第一期,一次报名永久无限听课!❤️

4.目前是第一期课程,后面比如说开了二、三期,都是不用在花钱的!

5.上课结束后,会把视频录播+课件笔记一起打包发直播群!

6.哔哩哔哩SRC课程公开课,链接🔗直达:

https://space.bilibili.com/642258933

SRC课程详情🔎:学了一堆理论,还是挖不到漏洞?你缺的是实战!

内部小圈子知识星球详情🔎:50 元封顶!渗透攻防 + SRC 漏洞星球限时开放!

欢迎关注公众号:神农Sec,报名咨询添加VX:routing\_love

开课快五个月时间,课程目前已经累计加入了1000+个学员了,课程培训招生任火热持续中,师傅们对于我们课程感兴趣的,想要学习技术,找工作的可以咨询我报名。

课程培训记录📝,每次上车在1-3小时之间,上课包括课程内部群大家交流氛围很好!

课程上课笔记课件📒都会打包给师傅们,笔记都非常详细,很多几k价格的培训机构哪怕是课件笔记都没有的,我这里都是下课第一时间把录播+笔记打包发给大家!

平常也都会给学员进行一些项目发布,包括后面的工作、护网内推等,经常上麦交流,大家互相学习,简历优化等。

SRC漏洞挖掘课程培训已经两个星期了,期间也是创建了“回本小群”,希望学员回本越来越多,创建这个群主要是鼓励学员学习进步,以及不定时发小项目!

最后也是希望大家都可以赚钱,找到好工作🎉

培训时间不长,感谢🙏师傅们的喜报,很开心看到师傅们给我分享自己的成果,希望师傅们越来越强!

平常也会分享项目,下面是一些学员项目成果,群里报课的学员都是不抽成的,主要是帮助学员进行回本,让大家都可以进步!

上课结束后,会把视频录播+课件笔记一起打包发直播群

「神农安全」知识星球目前已经累计2500+网络安全爱好者的加入!

后面也是小圈子做大起来了,师傅们也都喜欢看我文章,想着给大家教下src漏洞挖掘思路,所以自己花了很长时间做了✨课件和课表,都是纯自己手搓的,大家也可以看下课表的内容。

03

0x3 课程特色

课程主打真实,一线SRC漏洞挖掘师傅是如何学习和挖掘SRC漏洞的,让你真正了解SRC漏洞挖掘,助力在岗人员和大学生的能力提升,掌握新的技能树,为下一次跳槽涨薪做好准备。本课程内容覆盖企业SRC、众测项目挖掘、护网HVV红蓝攻防技巧、CVE、CNVD、EDUSRC等平台通杀案例技巧挖掘方法。

本课程适合人群(光看不挖啥也不会)

1、有计算机经验,想从0转行入行的大学生或自学者2、想从CTF比赛/Web或SRC进阶到项目实战的选手3、想参与项目/找工作/提高收入的转型者4、想通过挖SRC赏金做副业的师傅们5、挖SRC漏洞遇到瓶颈的师傅们6、想学习AI安全自动化渗透测试漏洞挖掘的师傅

课程价格:575 元

报课成功的师傅们直接免费送内部小圈:一个知识星球+内部小圈子交流群

1、课程价格真心实惠,绝不割韭菜2、四五百的课程价格让你体会大几千的培训课程内容3、带着大家从0到1,本人上课坚持手搓课件(实战案例+知识体系)4、拒绝使用PPT演讲模式(无实操,很枯燥)

直播培训教学方式

课程一周1-2节课,课程特色涵盖直播多人上麦活跃回答,直播过程中有问题随时解决或私信我。拉群:一个知识星球内部小圈子交流群+课程培训直播通知群。有项目/工作/护网第一时间内推报课的师傅,一对一简历优化,助力在岗人员和大学生的能力提升。

一次报名每期均可永久学习,并且赠送内部「神农安全」知识星球,一对一永久解答、无保留教学!

欢迎关注公众号:神农Sec,报名咨询添加VX:routing\_love

课程均为线上交付,报名成功后不支持退款

内部小圈子(知识星球+内部小圈子交流群+知识库)

对内部小圈子感兴趣的师傅们也可以看下下面的这个跳转链接,里面有对小圈子的详细介绍,报名课程成功的师傅们直接免费送一个(直接点击下面直接可以跳转)。

强烈推荐一个永久的SRC挖掘、渗透攻防内部知识库!

讲师介绍

id:一个想当文人的黑客

欢迎关注公众号:神农Sec,报名咨询添加VX:routing\_love

04

0x4 第一期挖洞培训课表内容

内部圈子介绍(报课赠送)

圈子专注于更新src/红蓝攻防相关:

1、维护更新src专项漏洞知识库,包含原理、挖掘技巧、实战案例2、知识星球专属微信“小圈子交流群”3、微信小群一起挖洞4、内部团队专属EDUSRC证书站漏洞报告5、分享src优质视频课程(企业src/EDUSRC/红蓝队攻防)6、分享src挖掘技巧tips7、不定期有众测、渗透测试项目(一起挣钱)8、不定期有工作招聘内推(工作/护网内推)9、送全国职业技能大赛环境+WP解析(比赛拿奖)10、十个专栏会持续更新~提前续费有优惠,好用不贵很实惠11、每日内部资料分享,内部圈子资料1000+12、联系圈主获取:内部漏洞知识库+圈子使用手册+内部圈子交流群13、VX:routing_love,技术交流+疑问解决

内部圈子专栏介绍

知识星球内部共享资料截屏详情如下

(只要没有特殊情况,每天都保持更新)

05

0x5 优秀学员报喜

下面是最近两个月培训期间,很多优秀学员进行报喜,看到师傅们有收获,也是感到很开心的!拉回本小群,就是为了促进大家学习,在群里发学员成果,也是为了让大家学习优秀的师傅们。

加油,你我皆是黑马!

*神农安全公开交流群*

有需要的师傅们直接扫描文章二维码加入,然后要是后面群聊二维码扫描加入不了的师傅们,直接扫描文章开头的二维码加我(备注加群)

申明:本公众号所分享内容仅用于网络安全技术讨论,切勿用于违法途径,

所有渗透都需获取授权,违者后果自行承担,与本号及作者无关,请谨记守法.

评论:0   参与:  0