How to protect elastic-agent service? (Anti-tampering protection)

Elastic Security Endpoint Security
1

Is there a way to prevent (using kernel-mode drivers) the administrator from stopping the elastic-agent service?
I want to use Elastic-Agent combined with Elastic Defense for EDR, but the administrator can turn off the service, which means it no longer ensures fast incident response.
I will be grateful for any help.

1 Like
2

Hello @Hoang_Hoang

Welcome to the Community!!

If i understand your requirement as per the documentation it does not seem possible :

For Elastic Stack version >= 7.11.0, self-protection defines the following permissions:

* Users — even Administrator/root — **cannot** delete Elastic Endpoint files (located at `c:\Program Files\Elastic\Endpoint` on Windows, and `/Library/Elastic/Endpoint` on macOS).
* Users **cannot** terminate the Elastic Endpoint program or service.
* Administrator/root users **can** read Elastic Endpoint's files. On Windows, the easiest way to read Elastic Endpoint files is to start an Administrator `cmd.exe` prompt. On macOS, an Administrator can use the `sudo` command.
* Administrator/root users **can** stop the Elastic Agent's service. On Windows, run the `sc stop "Elastic Agent"` command. On macOS, run the `sudo launchctl stop elastic-agent` command.

So basically we will have to setup a rule to raise an alert incase the service is stopped.

Thanks!!

1 Like
3

Interesting. So Elastic Agent service can be stopped by an administrator, but Elastic Endpoint service can't be stopped. But if Elastic Agent is stopped, Elastic Endpoint can no longer be managed / updated?

Just tried:

sc stop "Elastic Agent"

SERVICE_NAME: Elastic Agent
        TYPE               : 10  WIN32_OWN_PROCESS
        STATE              : 3  STOP_PENDING
                                (NOT_STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0

Get-Service -name "Elastic Agent"

Status   Name               DisplayName
------   ----               -----------
Stopped  Elastic Agent      Elastic Agent

sc stop "ElasticEndpoint"
[SC] ControlService FAILED 5:

Access is denied.

So, as you suggested, we better monitor the Elastic Agent service then..

Attackers with local admin rights can stop the Agent to block centralized control, possibly preventing:

  • Agent updates
  • Policy updates
  • Enrollment changes
  • Communication with Fleet
  • Live queries
  • Host isolation / unisolation commands

Or will the above still work without Elastic Agent service running?

Fyi, it seems like FLeet does detect something is wrong, the state of my test Agent went to Orphaned.

image
image508×1150 62.9 KB

.\elastic-endpoint.exe status
- elastic-agent
  - status: (FAILED) Not connected
- elastic-endpoint
  - status: (DEGRADED) Running
  - artifacts channel: default
  - policy
    - actions:
      - agent_connectivity: warning
        - Failed to connect to Agent

So luckily there appears to be some builtin monitoring of this situation.

2 Likes
4

Expanding the level of protection that Agent receives is something that we've discussed numerous times. It comes with hard trade offs between security and usability and the level of support cases it can generate when users are unable to uninstall/reinstall/update agent (legitimately, not rogue local admins). One of the changes we made relatively recently was adding the orphaned status and ensuring that Endpoint can report and set the orphaned status if Agent isn't communicating properly.

Rogue local admins are a very difficult case to protect against, in many cases fully preventing their actions may be too disruptive in most environments. However if there are actions that a local admin can do that warrant more detection/eventing so that stack side rules could provide notifications, its definitely worth throwing in as a feature request/enhancement. I can't guarantee it will get added, but if its relatively easy to add or just requires some additional information be added to something we already send then it's more likely.

2 Likes
5

Thanks for the clarification, I know this is not an easy topic. And good job on the Orphaned status. So we can just monitor for that state?

In what index can we find these state changes? I looked in logs-elastic_agent-* where I couldnt directly find anything related after replicating this. It took 4 minutes before it went to Orphaned.

6

I think this would be present on the internal fleet indices, if I'm not wrong is this one: .fleet-agents-7

7

I'm currently working in Elastic Security Serverless where there does not appear to be a .fleet-agents-7 index when running

GET _cat/indices/*fleet*?v&expand_wildcards=all&h=health,status,index,pri,rep,docs.count,docs.deleted,store.size,pri.store.size,memory.total,pri.indexing.index_time&s=index:asc

But a GET on .fleet-agents-7 gives:

action [indices:admin/get] is unauthorized for user [2xxxxxxxx9] with effective roles [admin,detections_admin,editor,endpoint_operations_analyst,endpoint_policy_manager,platform_engineer,rule_author,soc_manager,t1_analyst,t2_analyst,t3_analyst,threat_intelligence_analyst,viewer] on restricted indices [.fleet-agents-7], this action is granted by the index privileges [view_index_metadata,manage,all]

Any other place where we can query this info? :slight_smile:

8

Yeah, I'm not on serverless, it works for me.

Maybe you will need to use the Fleet API to get this information.

9

I reached out to that team to ask them if it would be possible to do on serverless or not and they suggested the following: GET kbn:/api/fleet/agents?kuery=status:orphaned

edit: fixed typo in the query. Thanks @leandrojmp

1 Like
10

Not sure if it is different on serverless, but at least on version 8.18 on Cloud and on the documentation it needs to be kuery instead of query.

11

Thanks. I updated it. My brain went on autopilot.

12

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.