Josh D's community posts

Conrad Sallian wrote:

Hello everyone,

Yes, it is our server at 172.241.164.247. RU uses end-to-end encryption, and the servers simply relay the encrypted traffic. They cannot inspect forwarded packets and do not store any data.

The reason for this alert is banal and very typical for the modern “security industry”. Apparently, someone was “hacked” using social engineering methods, which in this case simply means they voluntarily installed RU, gave their access credentials to a fraudster/attacker, and the attacker connected to their computer using RU. The victim then complained to their ISP, the ISP submitted an “abuse report” to the hosting provider Leaseweb, and that was enough for the IP address to be labeled as a “botnet server”, despite the fact that it is used by hundreds of thousands of perfectly legitimate connections.

I don't know if it's possible to guarantee the ip-addresses are actually official RU servers. I

It is possible. Just ask here and we will answer. However, we will not disclose our entire infrastructure because we do not want it to be DDoSed or otherwise targeted. That is quite understandable.

Do not hesitate to ask if you have any questions.

Thank you Conrad, that's perfect. Thank you for taking the time to reply :)

Christer Jakobsen wrote:

Since yesterday, we got alerts fr om Defender about 5 computers regarding this. It is not sufficient to create exceptions for the folders or processes. Fr om what I understand, we have to whitelist the RU Central server ip addresses. Unfortunately i have not found any dynamic server address that can be used, so I added ip address indicators to allow the traffic. (Defender portal->Settings->Endpoints-> Rules->Indicators->IP addresses.
64.20.61.146
172.241.164.247
216.158.232.18

There can be more IP addresses in use that might show up later, and they can be found by using Advanced hunting with this query:

DeviceNetworkEvents
| wh ere InitiatingProcessFileName == "rutserv.exe"
| wh ere RemotePort in (5650,5651,5652,5653,5654,5655)
| summarize count() by RemoteIP

Adding ip-address indicators to allow traffic will open up for all processes, so it probably should be used together with an endpoint firewall policy to only allow rutserv.exe to connect to these addresses and ports.

Hey Christer,

Thanks for your reply, I was going to do this (as it's not the software being blocked per se)

However I was more inclined to check if 172.241.164.247 was an active RU IP and not a some sort of middle botnet which has been hijacked.

Thanks for the help, I imagine that's what I'll do shortly

Hey all,

Just a quick on but are any of you suddenly (as of today) getting Defender blocking access to the Rutserver.exe and firing off a load of malicious C2 connections?

Pauline wrote:

Hi Josh,

Thank you for the clarification.

In that case, would you be able to send us the configuration file with the 2FA enabled on it? Or, if you haven’t saved the config file, you can also try sending us the installation file. You can send it to  support@remoteutilities.com  or open a ticket and submit the files there.


Looking forward to your reply.

Hey Pauline,

Sent you an email with the files :)

Pauline wrote:

Hi Josh,

It’s the following registry key:   HKEY_LOCAL_MACHINE\SOFTWARE\Usoris\Remote Utilities Host\ . Please note that you are not required to delete this registry key during the update process. You’ve mentioned here that you’ve deleted the key on the Host machines where the issue occurs:

I saw the article about deleting the Parameter reg key (which I have done on these remote machines) but still no change and still the same message?!

So this is why I wanted to check if you had deleted the reg key before the update by any chance and if the Hosts in question all have their default settings as of now? It seems like you might’ve accidentally reset your Hosts settings prior to the update.

Looking forward to your reply.

So for the process:
* I uploaded the new version of Remote Utilities to Intune to be pushed out (as normal)
* I changed the configuration of this version to include 2FA
* When the software arrived on the remote machines I was no longer able to remote into them (Getting the authentication message)
* I reinstalled the version without 2FA and it works fine again
* I read a support article on here about deleting the params reg key so I did that and reupdated a few of the clients but the same problem appeared
* I have pushed out the version without 2FA for now until I understand why it's happening (We need 2FA however so would be grateful for any help!)

:)

Pauline wrote:

Hello Josh,

Thank you for your message.

Have you deleted the Host registry key before updating your Hosts by any chance? Please note that deleting the registry key resets Host settings to default ones, so if you remove the registry key, you’re able to configure your Host settings from scratch.
Could you double-check if any of the Hosts in question has their Single password and the 2FA feature enabled in its settings?

Looking forward to your reply.

Hi Pauline,

Would you be kind enough to confirm the reg key in question?

So in my situation I would have to delete the reg key on the remote computers first (via script in Intune) and then re-install the Remote utility software?

This seems like something which could be written into the installer surely to remove that key and write a new one!?! It will be a nightmare for most people.

Hi all,

Rolling out 7.6.2.0 update to all machines via Intune and decided to do a trial run on a few machines with 2FA enabled.

Created the installer, scanned (and took a copy) of the QR code, pushed the software out to the machines (They updated fine)

When I now try to connect to those machines (the have been updated so no new ID codes needed to be generated) I am getting:

"At least one authentication method must be enabled on the remote host"

Single password along with 2FA is enabled on that host but I don't get any sort of pop up to enter the 2FA code!?

I saw the article about deleting the Parameter reg key (which I have done on these remote machines) but still no change and still the same message?!

(Equally, it seems insane I would have to write a script to delete this key, push it out via intune to over 200 machines then stage a reinstall of the software to enable 2FA) so if there is a better way please let me know!?

Conrad Sallian wrote:

Hello Josh,

Sorry for misleading a bit. The version on MS Store is a regular desktop app, the same Host .msi that you can download from our website. Our only purpose of putting it there (as well as the Viewer) was widening our distribution and getting rid of pesky MS Windows Defender false positives, assuming that the apps that passed certification for MS Store are less likely to be falsely detected as a threat.

Answering your question, it's a regular msi file and you can use the standard msi parameters for its deployment.

No worries,

Thanks again!

Thanks Conrad, much respect!

Bit of a simple question (and to save me the hassle of digging around) if I were to update the rollout of Remote Utilities using the Microsoft Store Option in Intune do you have the parameters / switches to do so (Currently deployed as Win32)

I've got in on the action too:

Done