During a recent pentest on a small business, gains into the client network were made via a flaw in the customers public website; however once innogen managed to traverse from the webserver to an internal employee host it became clear that there was some work to be done in order to escalate to a more trusted user account.
After a day of looking at escalation areas via internal services and applications little gains were made due to the domain policy in effect, a rethink was required!
While penning out the system that was understood from the scope and the current access made it was clear that the scope did not prevent phishing of the employees, so out came the rods!
After accessing the client pc pst and looking at the internal mails a picture of the staff and admins was created; time was then spent looking on linked in and other social networks to find our weak target, it didn’t take too long to find a member of the it dept that fit the following criteria:
Potentially the 3 points above could mean the IT staff would be keen to do the job and keen to keep on the good side of the employees; we then concocted the phishing mail and subsequently a rule set for the target was created meaning all mails received from the IT dept were directed to deleted messages.
A dialog was then opened which was around an issue with a service that was being worked on for a customer, the responses didn’t take long and soon we were poised to send the spear, which included a link to an AWS kali instance with a meterpreter exploit waiting…
The spear was sent and sure enough after approximately 15 minutes a connection was seen on the AWS instance and a meterpreter shell was spawned.
From this point we had access to the IT dept and once mimikatz was let loose it did not take long to become domain admin and have ownership of the entire company, all from an sqli vulnerability and lax rules on exchange clients.
Many more ways could have been investigated to escalate permissions, however it can be seen that this route proved the path less trodden and completely overlooked by the domain admins; its understood that rules assist us all in our busy lives to route mails into categories or folders but it can also be seen that the same rules can be used against us in order to create internal phishing campaigns.
NOTE: not all phishing campaigns are external!
Technet – Remove inbox rule on exchange: https://technet.microsoft.com/en-us/library/dd351272(v=exchg.160).aspx
Stackoverflow: Detecting malicious rules: https://serverfault.com/questions/733895/detecting-preventing-malicious-outlook-rules
Exploiting Sudo 1.8.27 The following brief is a quick demonstration of the issue faced by cve-2019-14287. This issue is presented when the user is allowed to run a specified command as any user other than the root user account, specified …
SMB LFI Exploitation The following outlines a very short overview of LFI using SMB in form of a crib sheet. Install Samba: apt-get install samba Remove default Samba config: rm -f /etc/samba/smb.conf Create New smb.conf: vi /etc/samba/smb.conf The following config …
Linux reverse shell without python. During a recent application exploit into an interactive shell the typical path to spawn a reverse shell and upgrade it to tty was sought. It was found that the go to technologies such as python, …