All Hackers Go To Cloud

All Hackers Go To Cloud ☁️💻

During the investigation of an incident in a fully encrypted infrastructure, we identified an autonomous web server hosting the client’s website, not directly connected to the main infrastructure, on which a hacker tunnel GSocket was installed. This tunnel could have been used to launch attacks against both the current client and other Russian companies.

A significant amount of time has passed since the tunnel was installed, and from the log files we only have an entry in the auth log, indicating that a couple of minutes before the GSocket installation, the attacker logged into the system using the root account via the local console:

login[1206]: ROOT LOGIN  on '/dev/tty1'

💡 The server was located in the infrastructure of one of the Russian cloud service providers based on VMware Cloud Director.

What can be requested from the provider and what valuable data for the investigation can be obtained? Let’s figure it out.

✅ 1. Log files for access to the vCloud management web console. Typically located in the directories:

/opt/vmware/vcloud-director/logs
/opt/vmware/var/log/

They are named YYYY_MM_DD.request.log and follow the standard APACHE log format (more details about log files can be read here).

Analyzing them can yield the ID of the VM we need (usually in the format vm-xxxx-xxxx-xxxx-xxxxx-xxxxxxxxxxxx), the IP address of the requesting client, and its User-Agent.

Example event:

[IP-Address] - - [11/Jan/2025:05:36:17 +0000] "GET https://vcloudsite.com/cloudapi/1.0.0/sessions/current HTTP/1.1" 200 309 "https://vcloudsite.com/tenant/org_162736/vdcs/bg85164f-8df3-4df8-ed78-gt489521657a/vapp/bg85164f-8df3-4df8-ed78-gt489521657a/vcd-vapp-vms/vm-8700-5797-076e-582e-a4a9-e82919a8864c/general" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36" 118

✅ 2. Log files of events (tasks) occurring on the target VM. These can be exported via the vCloud management portal interface or requested from the provider using the VM ID (can be found in the VM properties on the portal).

In these logs, we are interested in the jobAcquireScreenTicket event, which records a user accessing the VM via the management web console (tenant portal):

https://vcloudsite.com/api/task/a983bdce-ee6f-4a7b-b36d-d079be22c7a8;a658adcd-dd5e-4d1d-b25d-d083be31c2a6;;;;2024-11-25T22:42:42.547Z;jobAcquireScreenTicket;https://vcloudsite.com/api/vApp/vm-8700-5797-076e-582e-a4a9-e82919a8864c;www-srv;vm;Acquired Screen Ticket of Virtual Machine www-srv(e3380056-ac0d-22a0-76d3-2888eeb8efb2);https://vcloudsite.com/api/org/8561881b-ef74-438b-a526-2e56473d0eb6;org_262549;user;;com.vmware.vcloud;2024-11-25T22:42:42.547Z;success;

✅ 3. Log files from VMware NSX Edge Gateway load balancers, which are located in front of the vCloud hypervisor and distribute user requests. These can also provide the user’s IP address requesting access to the console or management portal by correlating requests with the keywords GET / LOGIN / Tenant and the VM access time from the logs above.

Here is an example of such an event:

Nov 25 22:42:42 NSX-edge-2-0 loadbalancer[10058]: [default]: {ip-address} - - [25/Nov/2024:22:42:42 +0000] "GET /login?service=tenant:org_141783&redirectTo=%2Ftenant%2Forg_171438 HTTP/1.1" 302 182 "" "" 25165 801 "VCD-HTTPS~" "vcd-https" "a99vcd99" 0 0 5 0 5 ---- 6 5 0 0 0 0 0 "" ""

📌 In our case, by correlating the timestamps of data obtained in this way, we were able to identify the IP addresses of the attackers from which access to the infrastructure was carried out.

Happy Investigating! 🛡✨

#DFIR #Tips #Detect
@ptescalator