Renamed ZOHO Dctask64 Execution -> 100.000 alerts / hour

[Carlos-mb]

Hi again... I'm a bit desperate.

I'm having 100.000 alerts per hour of this alert: "Renamed ZOHO Dctask64 Execution"

I'm investigating and it's supposed to be related to Endpoint and elastic fleet bug.. I guess... but not sure.

I have searched in the forum and all internet and I haven't found an explanation or any solution.

I'll thank any help

Best regards,
Carlos

[InfosecGoon]

This is the rule:

https://detection.fyi/sigmahq/sigma/windows/process_creation/proc_creation_win_renamed_dctask64/

Are all of your alerts for the same executable name? You could add a filter to exclude it.

[nasbench]

See SigmaHQ/sigma#4979 for additional context

[Carlos-mb]

This is the rule in my installation:

title: Renamed ZOHO Dctask64 Execution
id: 340a090b-c4e9-412e-bb36-b4b16fe96f9b
status: test
description: |
    Detects a renamed "dctask64.exe" execution, a signed binary by ZOHO Corporation part of ManageEngine Endpoint Central.
    This binary can be abused for DLL injection, arbitrary command and process execution.
references:
    - https://twitter.com/gN3mes1s/status/1222088214581825540
    - https://twitter.com/gN3mes1s/status/1222095963789111296
    - https://twitter.com/gN3mes1s/status/1222095371175911424
author: Florian Roth (Nextron Systems), Nasreddine Bencherchali (Nextron Systems)
date: 2020/01/28
modified: 2024/04/22
tags:
    - attack.defense_evasion
    - attack.t1036
    - attack.t1055.001
    - attack.t1202
    - attack.t1218
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        Hashes|contains:
            - 6834B1B94E49701D77CCB3C0895E1AFD
            - 1BB6F93B129F398C7C4A76BB97450BBA
            - FAA2AC19875FADE461C8D89DCF2710A3
            - F1039CED4B91572AB7847D26032E6BBF
    filter_main_legit_name:
        Image|endswith: \dctask64.exe
    condition: selection and not 1 of filter_main_*
falsepositives:
    - Unknown
level: high

I think it's the same.

Right now I have ** 529,997** alerts.

All are

• event.dataset = sigma.alert
• rule category = process_creation

This is the table for event_data.event.dataset

  | 95,006 | system.syslog
  | 65,603 | soc.server
  | 27,914 | soc.sensoroni
  | 15,204 | zeek.conn
  | 13,412 | endpoint.events.file
  | 11,377 | endpoint.events.registry
  | 9,339 | zeek.dns
  | 9,310 | endpoint.events.network
  | 8,815 | elastic_agent.filebeat
  | 4,883 | kratos.access
  | 4,783 | system.security
  | 3,938 | zeek.ssl
  | 3,834 | endpoint.events.library
  | 3,733 | elastic_agent.endpoint_security
  | 2,547 | endpoint.events.process
  | 1,998 | elastic_agent.osquerybeat
  | 1,778 | zeek.weird
  | 1,100 | soc.detections
  | 862 | zeek.file
  | 789 | elasticsearch.server
  | 648 | zeek.http
  | 631 | system.application
  | 282 | system.auth
  | 251 | elastic_agent.fleet_server
  | 234 | kratos.application
  | 234 | kratos.audit
  | 216 | elastic_agent
  | 216 | endpoint.events.security
  | 84 | zeek.notice
  | 80 | zeek.x509
  | 74 | system.system
  | 48 | zeek.syslog
  | 17 | zeek.dhcp
  | 13 | zeek.software
  | 4 | suricata.alert
  | 3 | soc.salt_relay
  | 3 | zeek.tunnel
  | 2 | winlog.winlog
  | 1 | zeek.ssh

About executable name, I have found this:

In the ALERTS screen the event_data.process.executable is always empty

Searching in Kibana - Discover - Logs: "Renamed ZOHO Dctask64 Execution"
It found 369 hits

Using this search break down by event_data.Effective_process.executable reports 0 entries.

Searching in Kibana - Discover - Logs: rule.name:"Renamed ZOHO Dctask64 Execution"
739,927 hits

Searching in Kibana - Discover - Logs: rule.name:"Renamed ZOHO Dctask64 Execution" AND event_data.process.executable : *
It found 48.900 hits

Using the last search break down by event_data.Effective_process.executable

• C:\Windows\System32\svchost.exe
• C:\Program Files\Microsoft Office\root\Office16\OUTLOOK.EXE
• C:\Program Files\Microsoft OneDrive\OneDrive.exe
• C:\Program Files\Microsoft Office\root\Office16\EXCEL.EXE
• C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
• C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe
• C:\Program Files\Microsoft Office\root\Office16\SDXHelper.exe
• C:\Program Files\Microsoft Office\root\Office16\WINWORD.EXE
• C:\Windows\System32\RuntimeBroker.exe
• C:\Windows\System32\taskhostw.exe
• C:\Program Files\Microsoft OneDrive\24.156.0804.0002\FileSyncConfig.exe
• C:\Windows\WinSxS\amd64_microsoft-windows-servicingstack_31bf3856ad364e35_10.0.22621.4027_none_e971c41442bfbd4d\TiWorker.exe
• C:\Windows\explorer.exe
• Other

Break down by event_data.process.executable

• C:\Windows\System32\svchost.exe
• C:\Program Files\Google\Chrome\Application\chrome.exe
• C:\Program Files\Microsoft Office\root\Office16\OUTLOOK.EXE
• C:\Program Files\Microsoft OneDrive\Update\OneDriveSetup.exe
• C:\Program Files\Microsoft Office\root\Office16\SDXHelper.exe
• C:\Windows\System32\CompatTelRunner.exe
• C:\Windows\System32\SearchIndexer.exe
• C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe
• C:\Program Files (x86)\Google\GoogleUpdater\129.0.6651.0\updater.exe

Break Down by event_data.file.name:

• syncdata8.db-wal
• syncdata8.db-shm
• Spyder3
• cache.lock
• store.db-journal
• FileSync.LocalizedResources.dll.mui
• Other
  and so on...

Grouping alerts by event_data.source.ip

| 18,228 | 10.0.0.53
  | 14,591 | 10.0.0.251
  | 10,509 | 10.0.0.249
  | 10,313 | 192.168.1.193
  | 6,500 | 10.0.0.105
  | 3,333 | 10.0.0.103

And more..

53 and 103 are windows with ElasticAgent.
251, 249 and 193 are SO nodes with search, manager and IDH

This is the data.message form an alert from .259 (SO Manager)

{"fields":{"contentLength":0,"elapsedMs":0,"impl":"/build/server/nodehandler.go:55:github.com/security-onion-solutions/securityonion-soc/server.(*NodeHandler).postNode","remoteAddr":"172.17.1.1:44054","requestId":"29d78b01-c797-41c4-ab24-8299beeeab44","requestMethod":"POST","requestPath":"/api/node","requestQuery":{},"requestor":{"id":"00000000-0000-0000-0000-000000000000","createTime":"2024-08-19T20:51:02.105806236Z","updateTime":"0001-01-01T00:00:00Z","email":"00000000-0000-0000-0000-000000000000","firstName":"","lastName":"","totpStatus":"","oidcStatus":"","webauthnStatus":"","note":"","roles":null,"status":"","searchUsername":"","password":"","passwordChanged":false},"sourceIp":"10.0.0.249","statusCode":200},"level":"info","timestamp":"2024-08-19T22:10:17.810638043Z","message":"Handled request"}

Some ones from .53 (host with ElasticAgent)

event_data.event.dataset: zeek.com

event_data.message: {"ts":1724105418.508023,"uid":"CxH3R13ulC2UL5e3G7","id.orig_h":"10.0.0.53","id.orig_p":63637,"id.resp_h":"10.0.0.1","id.resp_p":53,"proto":"udp","service":"dns","duration":0.1704099178314209,"orig_bytes":37,"resp_bytes":77,"conn_state":"SF","local_orig":true,"local_resp":true,"missed_bytes":0,"history":"Dd","orig_pkts":1,"orig_ip_bytes":65,"resp_pkts":1,"resp_ip_bytes":105,"community_id":"1:Pa4E6YZ7kRAtq2bEWbC9Crpds9o=","orig_mac_oui":"Intel Corporate"}

event_data.event.dataset: soc.sensoroni

{"fields":{"contentLength":0,"method":"POST","status":"200 OK","statusCode":200,"url":"https://10.0.0.251/sensoroniagents/api/node"},"level":"info","timestamp":"2024-08-19T22:10:17.832976357Z","message":"HTTP request finished"}

event_data.event.dataset: soc.server

event_data.message: {"fields":{"contentLength":0,"elapsedMs":0,"impl":"/build/server/nodehandler.go:55:github.com/security-onion-solutions/securityonion-soc/server.(*NodeHandler).postNode","remoteAddr":"172.17.1.1:44270","requestId":"a7dfe220-94d6-4409-baa7-0bffcad59d71","requestMethod":"POST","requestPath":"/api/node","requestQuery":{},"requestor":{"id":"00000000-0000-0000-0000-000000000000","createTime":"2024-08-19T20:51:02.105806236Z","updateTime":"0001-01-01T00:00:00Z","email":"00000000-0000-0000-0000-000000000000","firstName":"","lastName":"","totpStatus":"","oidcStatus":"","webauthnStatus":"","note":"","roles":null,"status":"","searchUsername":"","password":"","passwordChanged":false},"sourceIp":"10.0.0.249","statusCode":200},"level":"info","timestamp":"2024-08-19T22:10:25.821020389Z","message":"Handled request"}

Let me know if you need more information.

My big question is.... Am i the only one with this problem? If so... wouldn't it be a configuration problem?

Regards and thank you so much
Carlos

[InfosecGoon]

This is a problem with the rule -- the "Hashes" part is not being properly converted, so it's basically alerting on everything in your logs that doesn't have an image name of dctask64.exe. To see what I mean, use the Convert button at the bottom of Detection Logic to see the EQL query.

@defensivedepth - is this one of the mapping changes on your current list?

[Carlos-mb]

Wow!
@InfosecGoon , I really appreciate your collaboration.
I'm going to investigate it.
Thank you!

[Carlos-mb]

@InfosecGoon and @defensivedepth

I have seen that this is happening in many other rules: #13534

[Carlos-mb]

If you use this search in Detections:

"Hashes|contains" AND so_detection.language : "sigma" AND NOT "imphash" AND NOT "SHA256"

There will appear 4 rules (in my case).

I have tested all of them I have seen that the are not checking the HASHES.

I guess that all the other rules using "Hashes|contains" have a different way to detail the HASH to check.

They use this sintax:

detection:
    selection:
        - Imphash:
            - bcca3c247b619dcd13c8cdff5f123932
        - Hashes|contains:
            - IMPHASH=BCCA3C247B619DCD13C8CDFF5F123932

I hope this will help.

[Carlos-mb]

In this link: https://detection.fyi/sigmahq/sigma/windows/process_creation/proc_creation_win_renamed_dctask64/

The Hashes are declared with the comment # Imphash

I have change the rule this way:

        Imphash|contains:
            - 6834B1B94E49701D77CCB3C0895E1AFD
            - 1BB6F93B129F398C7C4A76BB97450BBA
            - FAA2AC19875FADE461C8D89DCF2710A3
            - F1039CED4B91572AB7847D26032E6BBF

What do you think? Could this be the answer?