NetBIOS Hacking

 In this lab, I was given the public IP address of a machine in an organisation (10.130.40.70) and an IP range for an internal subnet (172.30.111.0/24). The task was to see if confidential data could be stolen from the internal network which was not accessible (directly!) from the public internet. The machine @ 10.130.40.70 could communicate with the machines on the netblock of 172.30.111.0/24 using an IPsec tunnel.


First of all, I scanned the ports on the machine @ 10.130.40.70 and discovered that it had ports 139 and 445 open. This was a good finding as it meant that I might well be able to hack the machine using NetBIOS and / or SMB based attacks.


NetBIOS is a protocol which allows resources and machines to communicate with one another inside Windows environments. It uses a naming convention which is similar to DNS in that a NetBIOS name is resolved to an IP address. This naming convention uses port 137. A NetBIOS name is 16 bytes longs (15 characters are defined by the user and the last byte is reserved to indicate the type of resource using hexadecimal notation). Messages can be sent using port 138. This uses UDP so it is stateless and allows messages to be sent to all NetBIOS resources as well as individual resources. Most NetBIOS communication occurs over port 139, however, as this uses TCP connections to establish sessions. NetBIOS sessions use the Service Message Block protocol to communicate with one another. SMB can also be used directly over TCP without the need for a NetBIOS session to be established - this can be achieved using port 445. Considering that NetBIOS allows data to be shared on networks, it is an attractive target for hacking purposes.



Once I had discovered that ports 139 and 445 were open, I decided to try to attack the remote machine using a null session attack. This uses the default IPC$ share (Inter Process Communication). This was successful at connecting, but I did not have the authority to access any of the shares, so it was useless.



Next, I used enum4linux to enumerate the share further. I did not gain much useful information from this, though the NetBIOS code of <20> showed me that the remote machine was indeed serving shared resources as this hexadecimal code shows that server services are enabled.




I had also discovered (via nmap port scanning and the workstation name using enum4linux) that the remote machine was running Windows 7 as an OS. This led me to consider using eternal blue based attacks. First of all, I checked to see if the machine was vulnerable. I found out that it was probably vulnerable, but I needed to have valid credentials. I therefore used a brute force attack against the SMB login and found two sets of username:password credentials. This shows the importance of properly enforcing secure passwords as I was able to crack these weak passwords in no time at all using simple wordlists.









Now that I had credentials to try, I attempted to access the remote shares using the administrator account. This time, I could see the share names, but I still could not access them fully, so I went back to the idea of using an eternal blue based attack (psexec) in order to gain a shell. This was successful using the cracked admin credentials.




I quickly checked the privileges of the shell, and found that it was NT AUTHORITY\SYSTEM. I then found a different process ID to migrate my session onto. During this part of the hack, I saw that I had used a 32 bit payload to attack a 64 bit machine, so I killed the session and reset the payload to be 64 bit and attacked again. I then migrated to a different 64 bit process running as SYSTEM. Once I had done this, I dumped the NTLM hashes from the SAM database and started to crack them using hashcat. There was no real need to do this, as I had already cracked the two accounts on the machine, but I wanted to see if I could use hashcat to achieve the same goal. I left hashcat running as I went on to enumerate the remote machine further.








Now I was on the machine @ 10.130.40.70, I went on to see if it was sharing any resources. I found out that it was. There was a share @ C:\Users\eLS\Documents which I thought might contain interesting data, so I checked it out but found nothing of any real interest. I then searched around the machine's directories for some key words but found nothing.





Since I couldn't find anything of interest on the machine @ 10.130.40.70, I set up a route to the internal network @ 172.30.111.0/24 so I could pivot onto it from the compromised machine. After I had created a route to the internal subnet, I set up a SOCKS4a proxy server so I could use proxychains to enumerate the internal subnet using tools such as nmap. The proxy server worked, but when I scanned the internal subnet using nmap I found that all the ports were filtered.








Since my idea of using nmap via a SOCKS4a proxy server had not worked, I tried a different way to port scan the internal subnet. This time, using the msfconsole module portscan/tcp I was able to find a machine which had ports 139 and 445 open. This machine was @ 172.30.111.10




I went back into a regular shell on the machine @ 10.130.40.70 and tried to find out if the machine @ 172.30.111.10 was serving any interesting files but I could not connect to it. I found this odd, but thought it might be to do with the user my shell was running as. I therefore searched for user tokens I could steal and use to impersonate other users. I found the local admin account token and successfully impersonated the local admin user. I then tried to enumerate the shared resources @ 172.30.111.10 and was now able to do so!







This was great news as I was now able to access the internal network shares via the compromised machine @ 10.130.40.70. These internal resources were not meant to be accessed from the public internet, but by hacking a machine and then using it to pivot onto the internal network, I was able to hack the NetBIOS shares on the internal network and capture confidential data. I had a look at the shared files and found Confidential.txt which was clearly the goal of the lab. I had a look at it and then downloaded it to my attacking machine as proof that confidential data could be looted from the organisation's internal network.








In the meantime, hashcat had successfully cracked the two accounts for the machine @ 10.130.40.70. Of course, this had no real value for this lab, but in other situations it is very useful to crack other user credentials as they can then be used to dig deeper into the domain which is being attacked.






I enjoyed doing this lab as it showed me how we can use compromised machines to further attack networks. This is important as lots of organisations do not pay as much attention to securing their internal networks as they do devices which are on the public internet. This reminds me of how most people spend lots of time securing their external facing doors and windows to prevent intruders from getting access to their property. but leave all of their internal rooms to be freely accessible to anybody inside the house!

Popular posts from this blog

Hacking Reset (thm)

Image
  NOTE: I am currently migrating my writeups and notes regarding hacking aka pentesting to  my github - my reset writeup can be found here     Reset is a fun active directory based box on thm   We start with an nmap scan which shows us that the target machine is probably a domain controller as it has port 88 open. Domain controllers typically have this port open since they are involved in kerberos based authentication. We also find some useful data regarding the domain and machine we are attacking. In addition, we find port 5985 is open - this is of interest as it is a port which is used by winrm which in turn is a service which could potentially give us a remote session on the target machine if we find valid credentials.    Since smb is being used, we start our enumeration of the haystack machine by taking a look at it - can we get a null session and thereby enumerate useful data? We find that we can. The IPC$ share has read access to non-authentica...
Read more

Hacking Year of the Owl (thm)

Image
NOTE: I am currently migrating my writeups and cybersecurity notes to  my github This writeup can be found in a new and shiny form at puzz00 year of the owl writeup  --- The Year of the Owl is a machine by MuirlandOracle on tryhackme   We start by using nmap to scan the TCP ports. The results show us that this appears to be a windows machine because we see netbios on port 139, SMB on 445 and winrm on its default port of 5985. We take a closer look but don't find much of interest. Since SMB is running, we can try a null session attack, but this does not work. We cannot connect using rpcclient without valid creds, either. Web app enumeration does not reveal anything of interest, so I have not included it in this post. We need to find another way to enumerate usernames and potential passwords. We can try common UDP ports using nmap. The results come back in the open|filtered state which is not very useful. We do not know if the ports are open or if the UDP datagrams are bei...
Read more

Simple CTF (tryhackme)

Image
  I started with a quick SYN scan of all ports on the target machine. The -T4 flag speeds up the scan from the default -T3 and the -p- flag specifies all ports to be scanned. As can be seen from the results, ports 21, 80 and 2222 had services listening on them. It was now time to take a closer look at those three ports, so I used the -A flag with nmap to find out more. The anonymous login allowed using FTP on port 21 seemed interesting, so I connected to it in passive mode using the username anonymous and no password ftp -p 10.10.179.144 The connection was successful, but I could not get any listing of the directories or files using ls so I turned my attention to port 80 by navigating to the home page in my browser. I was greeted with a default Apache "It Works!" page. I then checked the robots.txt file and fired up a directory buster. I used gobuster as it is fast, but dirb, dirbuster or a home-grown one would also do. The /simple directory stood out as interesting, so I na...
Read more