{"id":2543,"date":"2023-10-24T11:54:46","date_gmt":"2023-10-24T09:54:46","guid":{"rendered":"https:\/\/security.humanativaspa.it\/?p=2543"},"modified":"2025-09-15T13:24:01","modified_gmt":"2025-09-15T13:24:01","slug":"customizing-sliver-part-2","status":"publish","type":"post","link":"https:\/\/hnsecurity.it\/it\/blog\/customizing-sliver-part-2\/","title":{"rendered":"Customizing Sliver – Part 2"},"content":{"rendered":"

Hello! This is the second part of the three-part blog series<\/a> explaining how to customize Sliver C2<\/a> by adding your own commands.<\/p>\n

In this part I\u2019m going to provide an overview of the communication model<\/strong> in Sliver C2, by examining the flow of function calls performed by the components when an operator launches a command.<\/p>\n

In part 3<\/a>, I\u2019ll provide a tutorial showing how to create the first simple command from scratch in Sliver C2.<\/p>\n

Communication model overview<\/h2>\n

As explained here<\/a>, Sliver works in the following way:<\/p>\n

\n

\"\"
Communication model diagram<\/figcaption><\/figure>
1. When the operator types a command in the console, the client serializes the command in a protobuf request and sends it, through gRPC, to the server.<\/p>\n

2. The server processes the message and forwards the protobuf request to the implant, through the communication channel<\/strong> in use with the implant<\/strong> (could be HTTP\/S, DNS, Wireguard; in the diagram above it’s HTTP).<\/p>\n

3. The implant unserializes <\/strong>the protobuf request, executes the specified task, serializes the output<\/strong> again in a protobuf message<\/strong>, and sends it to the server through the same communication channel used at step 2<\/strong>.<\/p>\n

4. The server receives the protobuf response and forwards it to the client through gRPC<\/strong>. At this point the client simply unserializes the protobuf response <\/strong>and prints the output to the screen.<\/p>\n<\/figcaption><\/figure>\n

Client-server communication<\/h3>\n

The services.proto <\/strong>file, by importing client.proto<\/strong> and sliver.proto, <\/strong>defines The gRPC messages<\/strong> and methods <\/strong>exchanged between client and server.<\/p>\n

The client stores all the commands in client\/command\/sliver.go<\/a>. All commands stored in the file will call functions defined under client\/command\/<command folder>\/<command_name>.go<\/strong>. For example, sliver.go defines the command execute-assembly<\/strong>, that when typed in by the operator, invokes function ExecuteAssemblyCmd()<\/strong>, defined in client\/command\/exec\/execute-assembly.go<\/a>.<\/p>\n

All these functions will end up calling gRPC functions<\/strong> defined in services.proto<\/a>. For example, ExecuteAssemblyCmd() <\/strong>calls con.Rpc.ExecuteAssembly() <\/strong>defined in services.proto.<\/p>\n

\n

\"\"
Mapping between con.Rpc.ExecuteAssembly() and definition in services.proto<\/figcaption><\/figure><\/figure>\n

Actually, services_grpc.pb.go<\/a>\u00a0defines con.Rpc.ExecuteAssembly()<\/strong>. Protoc<\/strong> automatically builds the file services_grpc.pb.go starting from the definitions inside services.proto.<\/p>\n

As I’ll outline later, we will only have to <\/em>modify services.proto, sliver.proto, and client.proto and then rebuild services_grpc.pb.go<\/em><\/strong> by just running m<\/strong><\/em>ake pb<\/em><\/strong>\u00a0, in order to add our custom commands.<\/em><\/p>\n

These gRPC functions send protobuf messages to the server through gRPC, where server\/rpc\/rpc-*.go<\/a> defines the corresponding server-side handlers for these gRPC functions. For example, server\/rpc\/rpc-tasks.go<\/a> defines ExecuteAssembly()<\/a>, the server-side function that handles the con.Rpc.ExecuteAssembly() <\/strong>request performed by the client.<\/p>\n

These server functions handling the gRPC requests will perform the required processing and then send the response with the statement:<\/p>\n

return resp, nil<\/pre>\n
For the ExecuteAssembly() <\/strong>handler function, this sends a protobuf message to the implant and then returns the response, as we will see in the following section.<\/p>\n
Server-implant communication<\/h3>\n
The sliver.proto<\/strong> file defines the messages that are exchanged between server and implant. Server and implant exchange these messages not through gRPC but through HTTP\/S, DNS depending on how the implant was generated, as previously mentioned.<\/p>\n
Let\u2019s inspect the function ExecuteAssembly()<\/a> in order to explain what the server is going to do in this case:<\/p>\n
\/\/\u00a0ExecuteAssembly\u00a0-\u00a0Execute\u00a0a\u00a0.NET\u00a0assembly\u00a0on\u00a0the\u00a0remote\u00a0system\u00a0in-memory\u00a0(Windows\u00a0only)\r\nfunc\u00a0(rpc\u00a0*Server)\u00a0ExecuteAssembly(ctx\u00a0context.Context,\u00a0req\u00a0*sliverpb.ExecuteAssemblyReq)\u00a0(*sliverpb.ExecuteAssembly,\u00a0error)\u00a0{\r\n\u00a0var\u00a0session\u00a0*core.Session\r\n\u00a0var\u00a0beacon\u00a0*models.Beacon\r\n\u00a0var\u00a0err\u00a0error\r\n\u00a0if\u00a0!req.Request.Async\u00a0{\r\n\u00a0\u00a0session\u00a0=\u00a0core.Sessions.Get(req.Request.SessionID)\r\n\u00a0\u00a0if\u00a0session\u00a0==\u00a0nil\u00a0{\r\n\u00a0\u00a0\u00a0return\u00a0nil,\u00a0ErrInvalidSessionID\r\n\u00a0\u00a0}\r\n\u00a0}\u00a0else\u00a0{\r\n\u00a0\u00a0beacon,\u00a0err\u00a0=\u00a0db.BeaconByID(req.Request.BeaconID)\r\n\u00a0\u00a0if\u00a0err\u00a0!=\u00a0nil\u00a0{\r\n\u00a0\u00a0\u00a0tasksLog.Errorf(\"%s\",\u00a0err)\r\n\u00a0\u00a0\u00a0return\u00a0nil,\u00a0ErrDatabaseFailure\r\n\u00a0\u00a0}\r\n\u00a0\u00a0if\u00a0beacon\u00a0==\u00a0nil\u00a0{\r\n\u00a0\u00a0\u00a0return\u00a0nil,\u00a0ErrInvalidBeaconID\r\n\u00a0\u00a0}\r\n\u00a0}\r\n\r\n\u00a0shellcode,\u00a0err\u00a0:=\u00a0generate.DonutFromAssembly(\r\n\u00a0\u00a0req.Assembly,\r\n\u00a0\u00a0req.IsDLL,\r\n\u00a0\u00a0req.Arch,\r\n\u00a0\u00a0req.Arguments,\r\n\u00a0\u00a0req.Method,\r\n\u00a0\u00a0req.ClassName,\r\n\u00a0\u00a0req.AppDomain,\r\n\u00a0)\r\n\u00a0if\u00a0err\u00a0!=\u00a0nil\u00a0{\r\n\u00a0\u00a0tasksLog.Errorf(\"Execute\u00a0assembly\u00a0failed:\u00a0%s\",\u00a0err)\r\n\u00a0\u00a0return\u00a0nil,\u00a0err\r\n\u00a0}\r\n\r\n\u00a0resp\u00a0:=\u00a0&sliverpb.ExecuteAssembly{Response:\u00a0&commonpb.Response{}}\r\n\u00a0if\u00a0req.InProcess\u00a0{\r\n\u00a0\u00a0tasksLog.Infof(\"Executing\u00a0assembly\u00a0in-process\")\r\n\u00a0\u00a0invokeInProcExecAssembly\u00a0:=\u00a0&sliverpb.InvokeInProcExecuteAssemblyReq{\r\n\u00a0\u00a0\u00a0Data:\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0req.Assembly,\r\n\u00a0\u00a0\u00a0Runtime:\u00a0\u00a0\u00a0\u00a0req.Runtime,\r\n\u00a0\u00a0\u00a0Arguments:\u00a0\u00a0strings.Split(req.Arguments,\u00a0\"\u00a0\"),\r\n\u00a0\u00a0\u00a0AmsiBypass:\u00a0req.AmsiBypass,\r\n\u00a0\u00a0\u00a0EtwBypass:\u00a0\u00a0req.EtwBypass,\r\n\u00a0\u00a0\u00a0Request:\u00a0\u00a0\u00a0\u00a0req.Request,\r\n\u00a0\u00a0}\r\n\u00a0\u00a0err\u00a0=\u00a0rpc.GenericHandler(invokeInProcExecAssembly,\u00a0resp)\r\n\u00a0}\u00a0else\u00a0{\r\n\u00a0\u00a0invokeExecAssembly\u00a0:=\u00a0&sliverpb.InvokeExecuteAssemblyReq{\r\n\u00a0\u00a0\u00a0Data:\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0shellcode,\r\n\u00a0\u00a0\u00a0Process:\u00a0\u00a0\u00a0\u00a0\u00a0req.Process,\r\n\u00a0\u00a0\u00a0Request:\u00a0\u00a0\u00a0\u00a0\u00a0req.Request,\r\n\u00a0\u00a0\u00a0PPid:\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0req.PPid,\r\n\u00a0\u00a0\u00a0ProcessArgs:\u00a0req.ProcessArgs,\r\n\u00a0\u00a0}\r\n\u00a0\u00a0err\u00a0=\u00a0rpc.GenericHandler(invokeExecAssembly,\u00a0resp)\r\n\r\n\u00a0}\r\n\u00a0if\u00a0err\u00a0!=\u00a0nil\u00a0{\r\n\u00a0\u00a0return\u00a0nil,\u00a0err\r\n\u00a0}\r\n\u00a0return\u00a0resp,\u00a0nil\r\n}\u00a0<\/span><\/pre>\n
The req parameter passed as input corresponds to the protobuf message ExecuteAssemblyReq, <\/strong>defined in sliver.proto<\/a>, in the following way (commonpb.Request is defined in common.proto <\/a>but I added it here for clarity):<\/p>\n
common.proto\r\n...\r\n...\r\n\/\/ Request - Common fields used in all gRPC requests\r\nmessage Request {\r\n  bool Async = 1;\r\n  int64 Timeout = 2;\r\n\r\n  string BeaconID = 8;\r\n  string SessionID = 9;\r\n}\r\n...\r\n...\r\n\r\n---------------------------------------------------------------------\r\nsliver.proto\r\n...\r\n...\r\nmessage ExecuteAssemblyReq {\r\n  bytes Assembly = 1;\r\n  string Arguments = 2;\r\n  string Process = 3;\r\n  bool IsDLL = 4;\r\n  string Arch = 5;\r\n  string ClassName = 6;\r\n  string Method = 7;\r\n  string AppDomain = 8;\r\n  uint32 PPid = 10;\r\n  repeated string ProcessArgs = 11;\r\n  \/\/ In process specific fields\r\n  bool InProcess = 12;\r\n  string Runtime = 13;\r\n  bool AmsiBypass = 14;\r\n  bool EtwBypass = 15;\r\n  commonpb.Request Request = 9;\r\n}\r\n...\r\n...<\/pre>\n
So what happens is that the handler performs the following actions:<\/p>\n
    \n
  1. retrieve the implant ID through req.Request.SessionID\/req.Request.BeaconID and check if it is valid.<\/li>\n
  2. create the go struct sliverpb.ExecuteAssembly<\/strong> that corresponds to the ExecuteAssembly <\/strong>protobuf message defined in sliver.proto. This struct will contain the response from the implant<\/strong>.<\/li>\n
  3. create the go struct sliverpb.InvokeInProcExecuteAssemblyReq<\/strong> that corresponds to the InvokeInProcExecuteAssemblyReq <\/strong>protobuf message defined in sliver.proto <\/strong>(we suppose the we executed execute-assembly in process, with the -i flag, otherwise the server will create ExecuteAssemblyReq). The implant will receive this struct as a request to process<\/strong>.<\/li>\n
  4. call rpc.GenericHandler(),<\/strong> passing as input the request and the response created at steps 2 and 3<\/strong>.<\/li>\n
  5. return resp<\/strong>, the response struct that the rpc.GenericHandler function populates with the response of the implant.<\/li>\n<\/ol>\n
    Here’s the body of function rpc.GenericHandler()<\/strong>, defined inside server\/rpc\/rpc.go<\/a>:<\/p>\n
    \/\/ GenericHandler - Pass the request to the Sliver\/Session\r\nfunc (rpc *Server) GenericHandler(req GenericRequest, resp GenericResponse) error {\r\n    var err error\r\n    request := req.GetRequest()\r\n    if request == nil {\r\n        return ErrMissingRequestField\r\n    }\r\n    if request.Async {\r\n        err = rpc.asyncGenericHandler(req, resp)\r\n        return err\r\n    }\r\n\r\n    \/\/ Sync request\r\n    session := core.Sessions.Get(request.SessionID)\r\n    if session == nil {\r\n        return ErrInvalidSessionID\r\n    }\r\n\r\n    \/\/ Overwrite unused implant fields before re-serializing\r\n    request.SessionID = \"\"\r\n    request.BeaconID = \"\"\r\n\r\n    reqData, err := proto.Marshal(req)\r\n    if err != nil {\r\n        return err\r\n    }\r\n\r\n    data, err := session.Request(sliverpb.MsgNumber(req), rpc.getTimeout(req), reqData)\r\n    if err != nil {\r\n        return err\r\n    }\r\n    err = proto.Unmarshal(data, resp)\r\n    if err != nil {\r\n        return err\r\n    }\r\n    return rpc.getError(resp)\r\n}<\/pre>\n
    You may notice that the function retrieves the beacon\/session implant, serializes the request, sends the serialized request to the implant<\/strong>, and finally returns the response from the implant inside the resp input parameter<\/strong>.<\/p>\n
    On the implant-side, the functions in charge of handling the requests coming from the server are defined inside handlers_<OS>.go<\/strong> and handlers.go. <\/strong>The file handlers.go contains handlers for tasks that can be executed on any OS<\/strong>, while handlers_<OS>.go contains handlers for tasks that can be executed only on a specific OS<\/strong>. For example, handlers_windows.go<\/a> contains impersonateHandler()<\/strong> that implements the impersonate command that would be useful only with a Windows OS<\/strong>, while handlers.go contains dirListHandler()<\/strong> that implements the ls command that is useful with any OS<\/strong>.<\/p>\n
    Let\u2019s inspect the inProcExecuteAssemblyHandler() <\/strong>defined in implant\/sliver\/handlers_windows.go<\/a>:<\/p>\n
    func inProcExecuteAssemblyHandler(data []byte, resp RPCResponse) {\r\n    execReq := &sliverpb.InvokeInProcExecuteAssemblyReq{}\r\n    err := proto.Unmarshal(data, execReq)\r\n    if err != nil {\r\n        \/\/ {{if .Config.Debug}}\r\n        log.Printf(\"error decoding message: %v\", err)\r\n        \/\/ {{end}}\r\n        return\r\n    }\r\n    output, err := taskrunner.InProcExecuteAssembly(execReq.Data, execReq.Arguments, execReq.Runtime, execReq.AmsiBypass, execReq.EtwBypass)\r\n    execAsm := &sliverpb.ExecuteAssembly{Output: []byte(output)}\r\n    if err != nil {\r\n        execAsm.Response = &commonpb.Response{\r\n            Err: err.Error(),\r\n        }\r\n    }\r\n    data, err = proto.Marshal(execAsm)\r\n    resp(data, err)\r\n}<\/pre>\n
    It takes as input data<\/strong>, the serialized request, as an array of bytes, and resp <\/strong>corresponding to a callback<\/strong>.<\/p>\n
    The function unserializes data in the struct InvokeInProcExecuteAssemblyReq<\/strong> (this corresponds to the request sent by the server). Now the implant processes the request (the variable execReq<\/strong>) and calls taskrunner.InProcExecuteAssembly(), passing as input the parameters contained in execReq.<\/p>\n
    At this point, the implant performs the following operations:<\/p>\n