Til forsiden
02-09-2024

UEMS and ZoHo Meeting-edition

ManageEngines Unified Endpoint Monitoring and Security (UEMS) agent with its complementary component ZoHo Assist has terrible documentation about logs left behind on the local device.

Introduction:

Objective

ManageEngines Unified Endpoint Monitoring and Security (UEMS) agent with its complementary component ZoHo Assist has terrible documentation about logs left behind on the local device. In the event of a forensic investigation, the logging present on ManageEngines cloud platform is usually out of reach for the forensic process, thus the local logs become essential. This post conveys lessons learned and information about what logs are found where, and what logs contain forensic evidence of interest within the UEMS agent and ZoHo Assist client.

Not-exhaustive research

The post is not exhaustive in terms of forensic artefacts that may be collected, as the scope of our process was pre-defined, but the post should nonetheless yield sufficient information to further carry out forensic work and additional testing if need be.

Background

In a recent engagement where we were called in to investigate the breach of a Qlik sense server, we found the threat actor had installed UEMS on the device.

Our main goal of the forensic process was to find out what the threat actor had done on this particular machine. What files have they moved, what commands did they run, when did they do whatever, where they did come from, who are they, etc.

Sifting through the logs revealed more questions than answers “What is ‘unknown’ in the connection log? This tool ID ‘14’ in the log … what’s that? What has the threat actor used these remote access tools for?” and so on.

The Internet was not at all helpful describing what forensic artefacts would be available for the forensic process. Installing an UEMS agent on a test rig and conducting a narrow set of testing, in addition to using our victims logs, yielded some information about the functionality and logging of the software.

Conclusion

While logs are not readily available and in clear text spell out the entire picture, they do contain quite a bit of information that, together with complementary telemetry and logs, paints a decent picture.

The software solution

The description of the software, as seen on ZOHO Corps websites, are as follows “Endpoint Central from ManageEngine ensures 360-degree endpoint management and security of your IT network. Monitor, manage, secure and remotely troubleshoot your endpoints with this cloud-based UEMS solution.

The complementary ZoHo Assist (In the ZoHo Meeting catalogue) is installed when the threat actor initiates a remote desktop session. 

Binaries- and log locations

  • C:\Program Files (x86)\ZohoMeeting
  • C:\ProgramData\ZohoMeeting\log
  • C:\Program Files (x86)\ManageEngine\UEMS_Agent
  • C:\Program Files (x86)\ManageEngine\UEMS_Agent\logs

What artefacts can be found - ZoHo Meeting/ZoHo Assist

The files of interest in C:\ProgramData\ZohoMeeting\log\ are

  • FileTransferWindowAppLog.log
  • ScreenSharingModule.log
  • LogFile.log
  • UIApp.log

FileTransferWindowAppLog.log

  • File transfer – IP address of the account connecting to the victim machine
  • File transfer – email of the account connecting to the victim machine
  • File transfer – File name, path and size(bytes) of files being uploaded from victim machine
  • File transfer – File downloads to victim machine is not recorded in detail

2024/06/09 00:26:23 1607648 5256 [CRITICAL] [agentprotocolhandler.cpp" L: 3736] cp_tech_screen_name is not available in json : { "byte_size": 0, "c_version": "2", "c_module": "HTML5_WS", "c_email": "User@probablyhijackedaccount.example", "current_viewonlyaccess": false, "res_y": "-1", "c_role": "VIEWER", "c_ip": " 198.51.100.123", "res_x": "-1", "c_devicename": "-1", "c_os_type": "Windows", "protocol": "CONN", "c_tech": "HTML5_WS", "participant_role": 0, "c_id": "5000000055132027", "c_name": "Geir Olav Skei", "comment": "-1", "state": "UP" }

2024/06/09 00:31:12 290311930 5256 [CRITICAL] [filetransfercommandhandler.cpp" L: 1535] Sending file C:\Users\LowPriv\Desktop\W3SVC1.7z, File id : 945692568, Total parts : 1426, File size 364978428

Excerpt from the log file

ScreenSharingModule.log

  • Indicates connection time and time span of screen sharing.
  • Log file was updated every 10th second through the entirety of the RDS-connection in my tests.

7976 2024-05-28 10:52:15.840 INFO [740] [ScreenCaptureAdapter::ScreenCaptureAdapter@149] ScreenCaptureAdapter Initialized!!

7976 2024-05-28 11:21:22.846 INFO [7648] [ScreenImageDataHandler::terminateThread@2395] Terminating screen capture thread

UIApp.log

  • Indicates screen sharing timestamp
  • Logs screen area 

2024/05/28 09:40:46 4647084 4368 1 INFO MainWindow InvokeHandlersImpl Screen Area: x : 3588, y : 1918

LogFile.log

  • Screen size
  • Inaccurate Network telemetry

2024/05/28 10:52:15 679205 7976 [CRITICAL] [multimonitor.cpp" L: 130] MultiMonitorEnumProc :: Monitor details L : 0 T : 0 R : 1920 B : 1080

The values within AVERAGE_AGENT_UPLOAD_IN_KBPS does not seem to be correlated to actual file transfers, so NOT a good metric to use for calculating size of transfer.

2024/05/28 11:05:18 783581816 7976 [CRITICAL] [protocolhandler.cpp" L: 2366] NETWORK_USAGE_INFO { "AVERAGE_NETWORK_BANDWIDTH_IN_KBPS": 892, "AVERAGE_AGENT_UPLOAD_IN_KBPS": 1096, "AVERAGE_VIEWER_DOWNLOAD_IN_KBPS": 688, "NUMBER_OF_IMAGE_SETS": 12

What artefacts can be found - UEMS

Log files can be found at C:\Program Files (x86)\ManageEngine\UEMS_Agent\logs

When connecting to a tool, the following 5 logs are updated

  • dcondemandaccess.log (unknown, RDS ended)
  • ToolsRCP.log (Telemetry about cmd/pwsh usage. Data sent from client.)
  • ToolsSys.log (idle++++, Tool ID)
  • WsSyncSocket.log (not of particular interest)
  • ToolsIQ.log (not of particular interest)

From within UEMS you can connect to multiple tools:

dcondemandaccess.log

This log shows inaccurate data (see picture). It shows basically a few unknowns followed by RDS-Ended. I have found “Unknown” either means an RDS-connection or a tool (such as terminal) started.

ToolsRCP.log

This log seems to only update primarily when using cmd/PowerShell

We can see that commands are issued, but not what exact commands. And we can see the number of bytes it returns. The returned number of bytes does however not seem to accurately reflect the content of the terminal.

Running whoami /priv yields the following in the log file:

#whoami /priv
4840 00:37:27:663 LoadRequest: Loaded Request Data
4840 00:37:27:684 Successfully Written to Cmd
4840 00:37:27:703 DcRemcomHandler::RequestHandler: Command Successfully written to CMD
4840 00:37:27:733 data sent: 0 209
4840 00:37:27:810 data sent: 0 3911
4840 00:37:28:592 sending idle data " - "

The output counts 3642 characters, including white space. The log file logs 4119 - a difference of nearly 500 bytes, which accounts for 11,5% of the total.

I ran a few tests, using the command “tree” and found the logs to report something along the lines of:

4840 00:42:49:288 DcRemcomHandler::RequestHandler: Command Successfully written to CMD
4840 00:42:49:319 data sent: 0 824
4840 00:42:49:394 data sent: 0 5637 4
840 00:42:49:471 data sent: 0 7254
4840 00:42:49:549 data sent: 0 8633
4840 00:42:49:631 data sent: 0 7569
4840 00:42:49:706 data sent: 0 6568
4840 00:42:49:783 data sent: 0 6263

However, three subsequent “tree” commands from within the same folder yielded different results, that did not match the amount of KiloBytes displayed on the screen.

The log reported back totals of 42748, 42169 and 41968 respectively, while the actual text produced from the tree commands totaled 28,9KB including white spaces. The difference accounts for more than 30% of the logged bytes.

As a final test I issued the tree command from c:\ to get a higher amount of data. The commands issued were tree > tree.txt vs tree, with one piping everything to a file and the other outputting everything to the console.

Between the file size of tree.txt and the reported numbers in the log file, I found the difference to be 11.9MB v 18.7MB.

Going further down this path was not pertinent for my use case, but it is good to know there is not a 1:1 relation between what is in the log and what the threat actor sees on the screen.

ToolsSys.log

The main benefit of this log is the indication of which tool the threat actor has launched.

5356 14:32:49:748 Message Recived From Server : {"requestId":1,"requestMessage":{"requestCode":1101,"requestData":{}},"messageVersion":1.0,"toolId":1}

Within the ToolsSys-log you will also see similar to these, but they do not log all tools (such as terminal):

6208 00:33:04:354 [INFO] Csysmanager::connect : Received Tool ID : 6

Therefor the “Message Recived From Server :” log entry is more accurate as it logs the usage of all tools.

There is no clear indication in the logs what tool is associated with what ID. But from manual testing as well as checking one of the js files produced by the UEMS website, I found that the tool IDs are as follows:

1 Task Manager 2 Services 4 Cmd 9 Registry 10 Device Manager 8 Shares 7 Printers 6 Groups 14 Hardware 142 Software 3 Users

https://static.zohocdn.com/emscloudstatic/1122325422/DC//ember/dcapp/dist/assets/vendor-40b97d60b046f05c187b5632ba0cd203.js

Happy forensicating! Hopefully this will help this save you so time, should you be in a similar situation!