custom decoder for Anydesk log

[dmitri munteanu]

Hi all,

I want to collect the logs generated by AnyDesk when is a connection made from remote. The logs are stored in the file "%APPDATA%\Roaming\Anydesk\connection_trace.txt", with following content example:

Incoming    2023-03-15, 09:41    User                              327777770    327777770

Incoming    2023-03-15, 09:44    REJECTED                          327777770    327777770
Incoming    2023-03-15, 10:22    User                              327777770    327777770
Incoming    2023-03-15, 10:25    User                              327777770    327777770

I've created the following:

agent.conf 

<localfile>
    <log_format>syslog</log_format>
    <location>C:\Users\*\AppData\Roaming\AnyDesk\connection_trace.txt</location>
    <target>agent</target>
    <out_format target="agent">anydesk_log $(hostname) $(host_ip) : $(log)</out_format>
 </localfile>

decoder

<decoder name="anydesk_conn">
    <prematch>^anydesk_log \w+ \d+.\d+.\d+.\d+ : </prematch>
</decoder>
<decoder name="anydesk_conn_child">
  <parent>anydesk_conn</parent>
  <regex offset="after_parent">(\.*) (\.*), (\.*) (\.*) (\.*) (\.*)</regex>
  <order>connection,date,time,action,anyd_id1,anyd_id2</order>
</decoder>

rule

<group name="authentication_success,Anydesk,">
  <rule id="100570" level="12">
    <decoded_as>anydesk_conn</decoded_as>
    <match>anydesk</match>
    <description>anydesk test</description>
  </rule>
</group>

...but doesn't work

[Francisco Tuduri]

Hello Dmitri!

Do you know on what step it is not working?
I understand that you are not seeing any alert for rule 100570. That could be for several reasons:

Is the manager receiving the logs?
Is the event being decoded correctly?
Is the rule working as expected?

To check if the manager is receiving the log events you should enable the logall_json option on the manager's ossec.conf. Then restart the manager. (Remember to disable that option after the debugging is done)
This will store every received event on /var/ossec/logs/archives/archives.json.
Allow some time for new anydesk logs to be generated and forwarded to the manager. Check if there are any of those logs on that file. You can use:
cat /var/ossec/logs/archives/archives.json | grep anydesk_log

If there are no events that match that there must be a problem with the <localfile> configuration. Let me know if this is the case.

If there are matching events then we should check the decoder.

You can check the decoder and rule by using the wazuh-logtest tool.

Take one of the events that you found on the archives.json file, find the element with the name "full_log" and use its value to try the decoder and rule with wazuh-logtest. That tool will show you what decoder is picking up the event and what fields it is extracting, it will also tell you if it is triggering any rule or not.

If you have any problem with this, please share the log events as saved on the archives.json so I can give them a look.

I'll be waiting for your response.
Regards!

[dmitri munteanu]

Hi Francisco and thank you for helping me,

So, I enabled  logall_json option in ossec.conf -> made a test connection with Anydesk -> and looked in the  archives.json -> there is no any "anydesk_log" .....

The problem is 100% in <localfile>, because i've tested the following:
1. created a CSV file in same directory %APPDATA%\Roaming\AnyDesk\ with the name "connection_trace.csv";

2. just replaced the extension CSV of the file in <localfile> as <location>C:\Users\*\AppData\Roaming\AnyDesk\connection_trace.csv</location>

3. restarted the manager;

4. impoted the data from connection_trace.txt into connection_trace.csv;

5. and the rule fired up with the alert.

[Francisco Tuduri]

Hello Dmitri!

I missed this the first time, but there is a bug related to the expansion of wildcards in folders in Windows: https://github.com/wazuh/wazuh/issues/12351

If you check the ossec.log of the agent for error messages you should see one saying that it could not open that directory:
Select-String -Path 'C:\Program Files (x86)\ossec-agent\ossec.log' -Pattern "Error:"

A fix for this is under development. In the meantime, as a workaround, you could try adding different localfile blocks or perhaps trying to move the log files to another path.
Sorry for the inconvenience.

Regards!

[dmitri munteanu]

Hi Francisco,

I checked and there is no any Error about opening that directory,

the log is saved just in one TXT file  connection_trace.txt

Even if I use full path <location>C:\Users\User1\AppData\Roaming\AnyDesk\connection_trace.txt</location> on agent's ossec.conf and not using wildcards, the manager haven't received any logs....

But, if I use syscheck ->> <directories recursion_level="0" restrict="connection_trace.txt$" realtime="yes" report_changes="yes">C:\\Users\\*\\Appdata\\Roaming\\AnyDesk</directories> , 
and rule:

<group name="authentication_success,Anydesk,">
  <rule id="999103" level="12">
    <if_sid>550</if_sid>

    <match>anydesk</match>
    <description>anydesk test</description>
  </rule>
</group>

...everything works ->> I'm getting an alert:

syscheck.diff     --- > I > n > c > o > m > i > n > g > > > > > 2 > 0 > 2 > 3 > - > 0 > 3 > - > 1 > 6 > , > > 0 > 7 > : > 1 > 1 > > > > > U > s > e > r > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 3 > 2 > 7 > 7 > 7 > 4 > 6 > 3 > 0 > > > > > 3 > 2 > 7 > 7 > 7 > 4 > 6 > 3 > 0 > > > >

[Francisco Tuduri]

Hello Dmitri,

The case with syscheck is different because it uses another method to perform the wildcard expansion. It is mentioned here. So it is normal that it works differently than log collection.

Let's keep trying to configure the AnyDesk log collection first locally on the agent, once it is working we'll move it to agent.conf.

Let's try this:

On the agent:
 - Add windows.debug=2 to local_internal_options.conf to enable debug level for the logs.
 - If you are in a lab environment you could disable temporarily unnecessary functionalities on ossec.conf to reduce log noise. If not possible, don't worry.
 - Add to ossec.conf the localfile configuration, without wildcards in the subfolders.
 - Restart agent
 - Generate new logs on the monitored file.
 - Check the ossec.log for errors or warnings.

On the manager:
 - Check if you received any new alerts from these logs.
 - Check if the events are stored on archives.json of the manager
 
If you are not receiving the logs or the alerts please share the following information:

• Wazuh version of manager and agent.
• localfile configuration of ossec.conf of the agent
• sample log file with data (connection_trace.txt)
• ossec.log of the agent since the restart after enabling debug logging.
• Make sure to obfuscate any sensitive data.

Thanks!
Regards!

[Francisco Tuduri]

Hello Dmitri,
I received the files that you sent me privately. The ossec.conf file got corrupted somehow so I couldn't look at it, but nevermind I found something on the other files:

On the ossec.log there are many lines like this:

2023/03/17 10:29:44 wazuh-agent[21368] read_syslog.c:148 at read_syslog(): DEBUG: Read 2 lines from C:\Users\<USERNAME>\AppData\Roaming\AnyDesk\connection_trace.txt

This means that logcollector is monitoring that file and it is reading data from it.
However, logcollector is also logging this:

2023/03/17 10:29:48 wazuh-agent[21368] read_syslog.c:55 at read_syslog(): DEBUG: Line in 'C:\Users\<USERNAME>\AppData\Roaming\AnyDesk\connection_trace.txt' contains some zero-bytes (valid=1/ total=180). Dropping line.

That means that the data read was not in the expected format.

It turns out that the connection_trace.txt is encoded in UTF-16 and that is not supported by logcollector.

connection_trace.txt displayed as UTF-16:

But when looking at it as if it were UTF-8:


Could you check if there is any way for that log to be generated in UTF-8?

Regards!

[Francisco Tuduri]

Dmitri,

There is one more thing you can try. As described here, we can enable the ignore_binaries option of the localfile configuration. Yes, it is a little counterintuitive, but I just tried this and the logs were forwarded correctly to the manager.

So, your localfile configuration should be something like this:

<localfile>
    <log_format>syslog</log_format>
    <location>C:\Users\<USERNAME>\AppData\Roaming\AnyDesk\connection_trace.txt</location>

    <target>agent</target>
    <out_format target="agent">anydesk_log $(hostname) $(host_ip) : $(log)</out_format>

    <ignore_binaries>yes</ignore_binaries>

 </localfile>

Please, try this first locally on the agent. Remember to restart the agent after making these changes.

These are the logs that I'm getting (using a different path):

2023/03/17 17:01:27 wazuh-agent[4764] logcollector.c:2275 at w_input_thread(): DEBUG: File 'C:\test.log' is UCS-2 LE
2023/03/17 17:01:27 wazuh-agent[4764] read_ucs2_le.c:40 at read_ucs2_le(): DEBUG: Bytes read from 'C:\test.log': 182 bytes
2023/03/17 17:01:27 wazuh-agent[4764] read_ucs2_le.c:95 at read_ucs2_le(): DEBUG: Reading syslog message: 'I'...
2023/03/17 17:01:27 wazuh-agent[4764] read_ucs2_le.c:107 at read_ucs2_le(): DEBUG: Line converted to UTF-8 is 90 bytes
2023/03/17 17:01:27 wazuh-agent[4764] read_ucs2_le.c:158 at read_ucs2_le(): DEBUG: Read 1 lines from C:\test.log

Let me know if this works for you.

Regards!

[dmitri munteanu]

Hi Francisco,

With <ignore_binaries>yes</ignore_binaries> I also have logs with reading data: 

2023/03/20 09:07:27 wazuh-agent[16196] read_syslog.c:148 at read_syslog(): DEBUG: Read 2 lines from C:\Users\<username>\AppData\Roaming\AnyDesk\connection_trace.txt

but, also have the following logs:

2023/03/20 09:07:29 wazuh-agent[16196] read_syslog.c:76 at read_syslog(): DEBUG: Message not complete from 'C:\Users\<username>\AppData\Roaming\AnyDesk\connection_trace.txt'. Trying again: ''

2023/03/20 09:07:31 wazuh-agent[16196] read_syslog.c:55 at read_syslog(): DEBUG: Line in 'C:\Users\<username>\AppData\Roaming\AnyDesk\connection_trace.txt' contains some zero-bytes (valid=1/ total=180). Dropping line.

in Manager - no any logs have came.

[Francisco Tuduri]

Hello Dmitri!

Looking at the last logs you sent, it seems like the ignore_binaries option was not picked up.
The logs should mention that UCS-2 is being used. Similar to the sample I sent before.

Could you please double-check the localfile configuration, or perhaps the agent was not restarted after the changes (agent restart is needed to load new config)?
Regards!