随着安全意识的提高，现在很多大公司或者企事业单位都配置有蜜罐系统，用来识别攻击，加强自身安全防御体系的建设。笔者前段时间对一些漏洞进行复现，也发现很多目标很容易拿到权限，但进入一看都是docker部署的，这种一般都是蜜罐。早期蜜罐系统很容易被发现，现在的蜜罐系统做的跟真的一样，端口扫描，漏洞利用都跟预期一模一样，就像前几天微软用linux来模拟代码服务器，在测试时也有一些异常，比如shadow文件查看不像正常的文件，域名指向等等。蜜罐的识别来自实战经验积累。
前几天朋友圈疯狂传Microsoft微软某个网站（code.microsoft.com）存在RCE，可直接执行命令：
http://code.microsoft.com/wp-content/plugins/wechat-broadcast/wechat/Image.php?url=/etc/shadow
笔者也曾经测试过，执行该命令后，当时有一个现象，就是shadow文件内容出来了，但不是正常的linux shadow文件格式。
今日再访问，已经无法访问了。
一、再次分析
1.dns查看
2.crt.sh查看
3.fofo搜索
fofa搜索code.microsoft.com结果是其他东东。
4.quake查看
5.zoomeye查看
{
"paths": [
"/api",
"/api/v1",
"/apis",
"/apis/",
"/apis/admissionregistration.k8s.io",
"/apis/admissionregistration.k8s.io/v1",
"/apis/admissionregistration.k8s.io/v1beta1",
"/apis/apiextensions.k8s.io",
"/apis/apiextensions.k8s.io/v1",
"/apis/apiextensions.k8s.io/v1beta1",
"/apis/apiregistration.k8s.io",
"/apis/apiregistration.k8s.io/v1",
"/apis/apiregistration.k8s.io/v1beta1",
"/apis/apps",
"/apis/apps/v1",
"/apis/authentication.k8s.io",
"/apis/authentication.k8s.io/v1",
"/apis/authentication.k8s.io/v1beta1",
"/apis/authorization.k8s.io",
"/apis/authorization.k8s.io/v1",
"/apis/authorization.k8s.io/v1beta1",
"/apis/autoscaling",
"/apis/autoscaling/v1",
"/apis/autoscaling/v2beta1",
"/apis/autoscaling/v2beta2",
"/apis/batch",
"/apis/batch/v1",
"/apis/batch/v1beta1",
"/apis/certificates.k8s.io",
"/apis/certificates.k8s.io/v1beta1",
"/apis/coordination.k8s.io",
"/apis/coordination.k8s.io/v1",
"/apis/coordination.k8s.io/v1beta1",
"/apis/discovery.k8s.io",
"/apis/discovery.k8s.io/v1beta1",
"/apis/events.k8s.io",
"/apis/events.k8s.io/v1beta1",
"/apis/extensions",
"/apis/extensions/v1beta1",
"/apis/networking.k8s.io",
"/apis/networking.k8s.io/v1",
"/apis/networking.k8s.io/v1beta1",
"/apis/node.k8s.io",
"/apis/node.k8s.io/v1beta1",
"/apis/policy",
"/apis/policy/v1beta1",
"/apis/rbac.authorization.k8s.io",
"/apis/rbac.authorization.k8s.io/v1",
"/apis/rbac.authorization.k8s.io/v1beta1",
"/apis/scheduling.k8s.io",
"/apis/scheduling.k8s.io/v1",
"/apis/scheduling.k8s.io/v1beta1",
"/apis/storage.k8s.io",
"/apis/storage.k8s.io/v1",
"/apis/storage.k8s.io/v1beta1",
"/healthz",
"/healthz/autoregister-completion",
"/healthz/etcd",
"/healthz/log",
"/healthz/ping",
"/healthz/poststarthook/apiservice-openapi-controller",
"/healthz/poststarthook/apiservice-registration-controller",
"/healthz/poststarthook/apiservice-status-available-controller",
"/healthz/poststarthook/bootstrap-controller",
"/healthz/poststarthook/crd-informer-synced",
"/healthz/poststarthook/generic-apiserver-start-informers",
"/healthz/poststarthook/kube-apiserver-autoregistration",
"/healthz/poststarthook/rbac/bootstrap-roles",
"/healthz/poststarthook/scheduling/bootstrap-system-priority-classes",
"/healthz/poststarthook/start-apiextensions-controllers",
"/healthz/poststarthook/start-apiextensions-informers",
"/healthz/poststarthook/start-cluster-authentication-info-controller",
"/healthz/poststarthook/start-kube-aggregator-informers",
"/healthz/poststarthook/start-kube-apiserver-admission-initializer",
"/livez",
"/livez/autoregister-completion",
"/livez/etcd",
"/livez/log",
"/livez/ping",
"/livez/poststarthook/apiservice-openapi-controller",
"/livez/poststarthook/apiservice-registration-controller",
"/livez/poststarthook/apiservice-status-available-controller",
"/livez/poststarthook/bootstrap-controller",
"/livez/poststarthook/crd-informer-synced",
"/livez/poststarthook/generic-apiserver-start-informers",
"/livez/poststarthook/kube-apiserver-autoregistration",
"/livez/poststarthook/rbac/bootstrap-roles",
"/livez/poststarthook/scheduling/bootstrap-system-priority-classes",
"/livez/poststarthook/start-apiextensions-controllers",
"/livez/poststarthook/start-apiextensions-informers",
"/livez/poststarthook/start-cluster-authentication-info-controller",
"/livez/poststarthook/start-kube-aggregator-informers",
"/livez/poststarthook/start-kube-apiserver-admission-initializer",
"/logs",
"/metrics",
"/openapi/v2",
"/readyz",
"/readyz/autoregister-completion",
"/readyz/etcd",
"/readyz/log",
"/readyz/ping",
"/readyz/poststarthook/apiservice-openapi-controller",
"/readyz/poststarthook/apiservice-registration-controller",
"/readyz/poststarthook/apiservice-status-available-controller",
"/readyz/poststarthook/bootstrap-controller",
"/readyz/poststarthook/crd-informer-synced",
"/readyz/poststarthook/generic-apiserver-start-informers",
"/readyz/poststarthook/kube-apiserver-autoregistration",
"/readyz/poststarthook/rbac/bootstrap-roles",
"/readyz/poststarthook/scheduling/bootstrap-system-priority-classes",
"/readyz/poststarthook/start-apiextensions-controllers",
"/readyz/poststarthook/start-apiextensions-informers",
"/readyz/poststarthook/start-cluster-authentication-info-controller",
"/readyz/poststarthook/start-kube-aggregator-informers",
"/readyz/poststarthook/start-kube-apiserver-admission-initializer",
"/readyz/shutdown",
"/version"
]
}二、蜜罐
1.蜜罐定义
蜜罐系统或蜜罐技术在网络攻防中扮演着重要角色，它是一种主动的防御策略，旨在通过模拟易受攻击的系统、服务或信息来吸引并诱骗潜在的攻击者。蜜罐系统是一种网络安全技术，旨在诱使攻击者攻击虚假或特意弱化的系统，从而收集有关攻击者行为和策略的信息。这些系统被用于网络防御和安全研究，有助于识别潜在的网络威胁并改进防御策略。
2.蜜罐系统分类
蜜罐系统可以分为两类：高交互蜜罐和低交互蜜罐。
高交互蜜罐：这种类型的蜜罐模拟完整的操作系统环境，提供了丰富的服务和功能，与真实系统几乎无法区分。攻击者与高交互蜜罐进行交互时，其活动被记录和监视，以获取关于攻击者技术、意图和策略的详细信息。
低交互蜜罐：低交互蜜罐模拟了有限的服务和功能，通常仅限于模拟特定的漏洞或服务。这种类型的蜜罐虽然不能提供与真实系统完全相同的体验，但由于其轻量级和易于部署的特点，仍然是收集攻击信息的有效工具。
3.基本概念
- 欺骗与监控：蜜罐的核心在于设置陷阱，这些陷阱对攻击者而言看似是具有吸引力的真实目标，但实际上是为了监控和记录攻击行为而特意设计的。
- 信息收集：通过蜜罐，防御者可以收集关于攻击者工具、战术、技术和程序（TTPs）的宝贵情报，包括攻击入口点、漏洞利用方式、横向移动策略等。
- 风险隔离：蜜罐通常不包含任何真实或敏感数据，因此即使被攻破也不会造成实际损害，同时保护了真实的系统和资产。
4.蜜网（Honeynet）
- 蜜网是蜜罐技术的扩展，它不是一个单独的系统，而是一个由多个相互连接的蜜罐组成的网络，能够提供更全面的监控和分析环境。
- 这个网络系统可能包括多种类型的蜜罐，每个都有特定的设计目标，用于捕捉不同类型的攻击或针对不同层次的威胁。
- 蜜网增加了攻击者识别的难度，同时提供了更深入的视角来观察攻击者的行为模式。
5.使用目的
- 早期预警：蜜罐能够作为网络安全的前哨站，预警潜在的威胁。
- 攻击分析：收集的攻击数据有助于安全团队理解新兴威胁，及时修补漏洞，优化防御措施。
- 消耗攻击资源：通过吸引并占用攻击者的注意力和资源，蜜罐可以分散对真正关键系统的攻击压力。
- 法律证据：记录的攻击活动可以作为法律诉讼中的证据。
6.实现原理
- 伪装与仿真：蜜罐模仿真实系统的服务和响应，让攻击者信以为真。
- 监控与日志：系统详尽记录所有与蜜罐的交互，包括网络包、系统日志、命令行操作等。
- 数据分析：利用自动化工具和人工分析来解析收集的数据，识别攻击模式和趋势。
三、蜜罐技术产品
1.国外蜜罐产品
一些常见的蜜罐产品包括：
- Cowrie: Cowrie 是一个基于 Python 的 SSH/Telnet 蜜罐，旨在模拟 SSH 和 Telnet 服务，并记录攻击者的行为。
- Honeyd: Honeyd 是一个虚拟蜜罐框架，可以模拟各种网络服务，并产生大量的虚假网络流量，以吸引攻击者。
- Kippo: Kippo 是一个交互式 SSH 蜜罐，可以模拟 SSH 服务，并记录攻击者的输入和行为，以便分析和防御。
- Glastopf: Glastopf 是一个 Web 应用蜜罐，可以模拟各种 Web 服务，并记录攻击者的 Web 请求和攻击行为。
- Thug: Thug 是一个低交互式蜜罐，可以模拟 Web 浏览器，并记录恶意网站的行为和攻击代码。
- DTK (Damn Vulnerable Linux)：一个故意设计漏洞的Linux发行版，常用于蜜罐部署和安全教育。
- Conpot：专注于工业控制系统的蜜罐，模拟SCADA系统来检测针对工控网络的攻击。
2.国内蜜罐产品
- 知道创宇-创宇蜜罐：这是知道创宇公司推出的一款蜜罐产品，专门设计用于模拟真实环境，吸引并监测攻击者的行为，提供攻击预警与行为分析功能。
- 长亭科技-谛听：长亭科技开发的谛听蜜罐系统，同样着眼于高仿真度和高交互性，能够有效吸引攻击者并收集其攻击手法与意图。
四、蜜罐技术识别及发现
识别一个系统是否为蜜罐涉及多种技术和方法，以下是一些常用的策略：
1.配置失真与资源抢夺
检查系统配置是否存在异常，比如在同一台机器上运行不同平台的服务，如Windows Web服务器与Linux FTP服务器共存，这可能表明配置失真。
尝试执行一些资源密集型任务或复杂命令，看系统是否有异常反应或资源分配不合理。
2.数据包时间戳分析
分析网络流量的时间戳，蜜罐可能因为虚拟化环境或模拟服务导致响应时间异常或不符合预期。
3.网络响应分析
仔细观察系统对不同请求的响应，真正的系统与蜜罐在响应速度、错误信息、服务版本细节等方面可能存在差异。
4.环境不真实导致的穿帮
寻找环境中的不一致性，比如不合理的文件结构、缺失的常见系统文件或过于“干净”的系统。
5.BOF(Buffer Overflow)识别
利用特定的缓冲区溢出攻击测试，蜜罐可能因为缺乏完整操作系统环境而对某些攻击无响应或响应异常。
6.假代理技术与Honeypot Hunter软件
使用工具如Honeypot Hunter来检测蜜罐特有的指纹或响应模式。
7.Honeyd识别
对于使用Honeyd等知名蜜罐软件搭建的系统，可以通过特定的检测手段识别其特征。
8.利用Sebek识别蜜网
Sebek是一种监控工具，广泛应用于蜜网中。通过检测系统中是否存在Sebek或类似监控软件的痕迹来判断。
9.Tarpits识别
观察系统是否故意延时响应，模拟缓慢的服务，这可能是Tarpit技术(故意拖延攻击者时间)的迹象。
10.外联数据控制识别
监测系统对外的通信，蜜罐往往限制或监控所有出站连接，异常的网络访问控制规则可能是线索。
11.虚拟机检测
由于蜜罐常用虚拟机部署，可通过检测硬件指纹、性能指标或特定虚拟化环境特征来识别。
结合以上方法，并结合经验和直觉，攻击者或安全研究人员可以提高识别蜜罐的准确性。然而，随着蜜罐技术的进步，识别难度也在增加，因此这些方法并非绝对可靠，需要不断更新知识和技术手段。
