Strange issue with AWS instances.

[martinl...@gmail.com]

Hi,

We are using Velociraptor in AWS with two Linux VMs, one running Velociraptor and the other a client and two Windows clients.

They came from the same base OS AMI images as appropriate. Something odd is happening with the Windows instances, first it picks up one of the Windows VMs and we can see its entry when we request the clients but then when we pick up the second one it overwrites the entry for the first one like this:

[{'client_id': 'C.95663721cc039b77', 'agent_information': {'version': '2021-02-08T20:10:48+10:00', 'name': 'velociraptor', 'build_time': ''}, 'os_info': {'system': 'windows', 'node': '', 'release': 'Microsoft Windows Server 2008 R2 Standard Service Pack 16.1.7601 Build 7601', 'version': '', 'machine': 'amd64', 'kernel': '', 'fqdn': 'INTERNAL1', 'install_date': 0, 'libc_ver': '', 'architecture': ''}, 'first_seen_at': 1621573214, 'last_seen_at': 1621573302949746, 'last_booted_at': 0, 'last_clock': 0, 'last_crash_at': 0, 'last_ip': '10.0.30.179:52863', 'last_interrogate_flow_id': 'F.C2JJSNI9OSTA4', 'last_ip_class': 'EXTERNAL', 'labels': []}, 

 [{'client_id': 'C.95663721cc039b77', 'agent_information': {'version': '2021-02-08T20:10:48+10:00', 'name': 'velociraptor', 'build_time': ''}, 'os_info': {'system': 'windows', 'node': '', 'release': 'Microsoft Windows Server 2008 R2 Standard Service Pack 16.1.7601 Build 7601', 'version': '', 'machine': 'amd64', 'kernel': '', 'fqdn': 'INTERNAL1', 'install_date': 0, 'libc_ver': '', 'architecture': ''}, 'first_seen_at': 1621573214, 'last_seen_at': 1621573310330303, 'last_booted_at': 0, 'last_clock': 0, 'last_crash_at': 0, 'last_ip': '10.0.30.37:51879', 'last_interrogate_flow_id': 'F.C2JJSNI9OSTA4', 'last_ip_class': 'EXTERNAL', 'labels': []},

The 10.0.30.179 host does have the hostname INTERNAL1 but 10.0.30.37 has a different hostname.

Does anyone have any idea on what is causing this strange behaviour?

TIA.

[Mike Cohen]

When running on cloud environments or VMs it is very easy to accidentally base the write back file into the base image somehow. In this case what will happen is that each instance from that base image will think it is that client and use that client id. Velociraptor will refuse to talk to more than one client with the same id at the same time, but depending on who connects first it might be that different vms are connecting as that client id (while the other client is rejected).

It is very important to make sure the writeback files are **not** shared between machines because this is how we uniquely identify the clients.

Thanks

Mike

Mike Cohen  Digital Paleontologist,  Velocidex Enterprises M  ‭+61 470 238 491‬  E mi...@velocidex.com

--
You received this message because you are subscribed to the Google Groups "velociraptor-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to velociraptor-dis...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/velociraptor-discuss/e45e95d6-d5e8-4447-abd8-233bc6c84828n%40googlegroups.com.

[martinl...@gmail.com]

Thanks Mike,

 

I’ll delete the writeback file when we fire up the instance and then it should create a new one and that should fix the problem.

 

Regards,

Martin.