Apart from Upload.exe, which other process will communicate to OpenEDR SFTP port 2222?
To find out which process is communicating on which port, we can use the Resource Monitor tool in Windows.
As shown from the screenshot above, only Upload.exe was communicating on port 2222, which is the SFTP service port to receive endpoint events.
This means that the process is attempting to connect to the backend SFTP server. This could imply that an adversary is trying to connect to the SFTP server from the compromised endpoint to transfer malicious files to infect the OpenEDR backend server.
To prevent the occurrence of successful intrusions, the SFTP server has been configured to use a key-based authentication method in order to establish a connection. Without the id file, an adversary will not be able to connect to the SFTP server.
Using key-based authentication method is also much more secured as compared to using password-based authentication because passwords are more prone to brute-force attacks. Even if the adversary was able to transfer the malicious file, he/she will not be able to access/execute the file because the SFTP is configured to be "one-way" i.e. you can only write to it. Aside from Sysmon capturing NetworkConnect events, the SFTP container will capture SSH attempts into the SFTP server, which will be unsuccessful because the SFTP server has been configured to deny SSH access.
References:
https://github.com/jymcheong/OneWaySFTP
https://github.com/jymcheong/OpenEDR/blob/master/backend/sftp/dockerbuild/files/sshd.conf#L4
Initial attempt to query for NetworkConnect events generated by Upload.exe:
As shown in the screenshot above, Sysmon did not capture any NetworkConnect events generated by Upload.exe even though the process is communicating on port 2222. To figure out why this was happening, I went to look into Sysmon's configuration file.
As shown in the screenshot above, the first red box indicates that the onmatch include filter has been added to NetworkConnect.
Filters are added to Sysmon so that only specific processes are captured while the rest are dropped. The rationale behind filtering is to drop noisy processes that would flood Sysmon and ODB with lots of meaningless events. This will lead to resource overloading and eventually cause the backend to go down.