Added basic support for Sliver

[whitecod]

• provide basic support for Sliver(Issue Support for Sliver C2 #220)
• fix an error with cron for INSECURE MODE (group/other writable). The /etc/cron.d/redelk file inside the container is writable by group/other and that causes cron to skip the execution.

[MarcOverIP]

Hey thank you for this. Looks really cool.

Before merging, we would need to do some testing of this. The core RedELK developers do not use Sliver in their ops, and are limited in time to do testing. So for now, we want to postpone merging this just a bit until at least we have the other milestones completed.

if there is somebody else who can help with testing this Sliver integration, that help is very much appreciated!

[Kibouo]

The basics work. However, anything that requires fetching blobs is still missing:

• screenshots
• built implants
• downloaded files
• credential that is not an API key or user/pass combo

It's my 1st time setting up a lab with both redelk & sliver. Meaning it might be a config error. However, a quick comparison of what this PR processes and actual logs did show some discrepancies. Simple example: only CredentialType 1 is processed by this PR. Registering a remote file as loot is type 3.

[MarcOverIP]

Thank you for your work @Kibouo !

I have no experience with Sliver, so I have no idea on type 1 vs type 3. Maybe @whitecod can shed some light on this?

[whitecod]

@MarcOverIP
In Sliver there are three types of loots. Username/Password (marked in the sliver logs as type1), API Keys (type 2) and files (type3). In the PR I created I ingested loots for the first two types.

Anything that involved fetching blobs was not implemented since at the time of the PR files downloaded, implants created and screenshots were base64 encoded within the logs and required additional work to extract and upload the blobs in RedELK.

As sated in the initial comment my PR was mostly to provide basic support for Sliver.

[alcastronic]

@MarcOverIP & @whitecod which kind of testing would need to be done on this to have it merged?
I want to have a look into it.

[MarcOverIP]

Thank you @whitecod for your continued effort on this while we are slow in responding.

@alcastronic if you want to review: check if the relevant items mentioned in the wiki page are done and no errors are presented. In our experience, its mainly Logstash parsing errors and inconsistency in naming that are most likely to give issues.

[whitecod]

@MarcOverIP I noticed an error coming up lately related to filebeat requiring seccomp permissions for rseq. That happened on Ubuntu 22.04 LTS and I fixed it adding the snipped of code below at the end of c2servers/filebeat/filebeat_redelk_main.yml:

seccomp:
  syscalls:
    action: allow
    names:
        rseq

Some context here

Since it's not related to Sliver development I am not not sure if I should

• create another PR
• add a commit to this PR
• leave it as is since my error could be an edge case

Let me know what you prefer.

[alcastronic]

I have had a quick look into that. So far I can tell,

• The audit.log contains most of the relevant data
• Command output is included
• The c2server configuration including the config for filebeat and cron work as intended for audit.log
• Data is ingested into logstash without errors
• Data is present in the rtops index
• Data is present in the "Home" dashboard, no however CS data is missing there as well
• Data is shown in the "Summary" dashboard
• Data is shown in the "Credentials" dashboard for passwords
• Data is shown in the "Credentials" dashboard for API-Keys, the data is there but is not assigend to the field creds.credential
• Data is shown in the "Dowloads" dashboard
• Data is shown in the "Implants" dashboard
• Data is shown in the "IOC" dashboard
• Data is shown in the "Red Team Operations" dashboard
• Commands are parsed and assigned to the filed c2.messge
• Data is shown in the "Screenshots" dashboard
• Data is shown in the "Tasks" dashboard
• Data is shown in the "Traffic" dashboard, yes with redirector that however is rather out-of-scope for this MR
• Data is shown in the "Tactics, Techniques & Procedures" dashboard
• Data is shown in the "IOC" dashboard

[alcastronic]

The summary dashboard shows sliver sessions however there is a discrepancy since logs that are present only on the c2 sever are logged as a separate "host". The actual host md09876 has 3 implants one cs and two sliver. The host on which the c2 is installed 12-123456-123-beat-c2 is shown here as a separate host. However I believe that this should not be the case as "Hosts" probably should refer to the "infected" hosts only.

The same is the case in the "Red Team Operations" dashboard.

The additional host is also shown in the "Implants" dashboard

I'm not sure wether that is as issue or not. It however seems inconsistent with other c2. For example cobalt strike leaves the host empty in cases where the command can not be related to an infected host. @whitecod & @MarcOverIP what do you think about that?

[alcastronic]

All of the testing has been done on the current master branch of RedElk since I have simply used an existing installation and have added/changed the files that where touched by this MR.

Overall I think the commands and other loot types like API-keys could be parsed better and the missing command output is not nice. Also the hostname issue could be improved to show either no host or the target system. However the integration as such works and does not produce errors.

[whitecod]

@alcastronic did you apply the changes I pushed last week?

As of Sliver v1.5 the logs don't contain the command output so there is no way to add them to RedElk. Regarding having the C2 server as an additional host that would make sense in case a C2 operator run commands on the C2 server directly (e.g. create a new implant profile) and you want to keep track of when that happened but I wouldn't want to have the C2 server showing up as an implant.

[alcastronic]

@whitecod yes, I used the files from this merge request. They should also contain the changes that you had pushed last week.

It might be possible to create an export script for command output ran on beacons, which are stored in the sqlite.db.
That would however require substantial work with export, shipment, parsing and enrichment. So I'd suggest to add once the basics are merged.

Regarding having the C2 server as an additional host I agree with you. I think for this to be in the desired state, the mapping of the host.name field needs to be removed for commands that are run only on the temaserver and should be left empty. We'd still have that information in the field agent.hostname which will contain the host where the filebeat is running.

[MarcOverIP]

@MarcOverIP I noticed an error coming up lately related to filebeat requiring seccomp permissions for rseq. That happened on Ubuntu 22.04 LTS and I fixed it adding the snipped of code below at the end of c2servers/filebeat/filebeat_redelk_main.yml:

seccomp:
  syscalls:
    action: allow
    names:
        rseq

Some context here

Since it's not related to Sliver development I am not not sure if I should

• create another PR
• add a commit to this PR
• leave it as is since my error could be an edge case

Let me know what you prefer.

Thank you for raising this! Doesn't seem like an edge case, but Im surprised we didn't encounter this ourselves. I assume it concerns also the filebeat installations on redirs and not only on c2 servers?

Going forward I think it is best to make a dedicated PR. That way we can track this better.

[MarcOverIP]

The summary dashboard shows sliver sessions however there is a discrepancy since logs that are present only on the c2 sever are logged as a separate "host". The actual host md09876 has 3 implants one cs and two sliver. The host on which the c2 is installed 12-123456-123-beat-c2 is shown here as a separate host. However I believe that this should not be the case as "Hosts" probably should refer to the "infected" hosts only.

The same is the case in the "Red Team Operations" dashboard. The additional host is also shown in the "Implants" dashboard I'm not sure wether that is as issue or not. It however seems inconsistent with other c2. For example cobalt strike leaves the host empty in cases where the command can not be related to an infected host. @whitecod & @MarcOverIP what do you think about that?

On the wiki we have listed the meaning of most ES fields: https://github.com/outflanknl/RedELK/blob/master/example-data-and-configs/RedELKFieldnamesV2.md.

I this case host.* in rtops index concerns data from the infected host, not the host collecting the filebeat information. This is a deviation from Elastic ECS in some cases. This is done on purpose as we feel ECS makes no sense in some cases for our use case. AS such, it may require some rewriting of field data in logstash.

[MarcOverIP]

@whitecod yes, I used the files from this merge request. They should also contain the changes that you had pushed last week.

It might be possible to create an export script for command output ran on beacons, which are stored in the sqlite.db. That would however require substantial work with export, shipment, parsing and enrichment. So I'd suggest to add once the basics are merged.

Regarding having the C2 server as an additional host I agree with you. I think for this to be in the desired state, the mapping of the host.name field needs to be removed for commands that are run only on the temaserver and should be left empty. We'd still have that information in the field agent.hostname which will contain the host where the filebeat is running.

Agree with both you and @whitecod regarding remarks on host data of the C2 server. I think my above comment also helps a bit with explanation.

Too bad Sliver doesn't have implant output in log files. Having implant output data in RedELK is kind of core functionality in our use case of RedELK to be honest. Too bad this would require extra effort. But I agree that we could add this later as well.

Anything else that needs to be tested with this PR?

[alcastronic]

@MarcOverIP From my side the agent.name should be removed from the host.name field otherwise the MR is good to be merged.

@whitecod Can you fix that?

[whitecod]

@alcastronic If you have the fix already I can test it and add a commit in my PR or I will work on that in the next couple of weeks when I get some time.

[alcastronic]

@whitecod I have exams ahead so won't be able to work on this in the next two week. Currently I do not have a fix at hand.

[MarcOverIP]

@MarcOverIP From my side the agent.name should be removed from the host.name field otherwise the MR is good to be merged.

Not sure what you exactly mean. Overall, you want the agent.name to be present as it represents the name given during installation time. Later on this is used for scripts to make clickable links, etc. host.name is name of the host where the implant is running. Ideally you want both. But as Sliver doesn't have the implant logs, I guess you can just remove all the host.* fields (as they all relate to implant data, not intended for C2 server data).

[MarcOverIP]

@alcastronic @whitecod, do we still think this makes sense when the C2 framework has no implant logs available to ingest and show?

[whitecod]

@MarcOverIP For completeness I would like to see commands run on the server itself for auditing purposes (e.g. enabling listeners, creating implant profiles or adding operators). I tried to remove those logs setting the host.name to an empty string for the events originated by the C2 server but it looks like logstash require that field and if it's empty set it to the hostname of the machine where filebeat was running (i.e. the C2 server). Maybe I missed something during my testing.

[MarcOverIP]

@MarcOverIP For completeness I would like to see commands run on the server itself for auditing purposes (e.g. enabling listeners, creating implant profiles or adding operators). I tried to remove those logs setting the host.name to an empty string for the events originated by the C2 server but it looks like logstash require that field and if it's empty set it to the hostname of the machine where filebeat was running (i.e. the C2 server). Maybe I missed something during my testing.

Weird. I suppose it could be empty as its a non-ECS naming standard field. You sure there is no Logstash rule your are (mis) triggering?