National Cyber Warfare Foundation (NCWF)

Digital Forensics: Tracing an HTA-Based Compromise


0 user ratings
2026-01-30 15:12:34
milo
Red Team (CNA)
Investigating a staged HTA infection, hidden persistence, and remote access. Everyday Windows artifacts and legitimate apps can reveal the full attack path when you know where to look.

Welcome back, aspiring digital investigators!





Today we take another case apart and walk through what we found on disk and in logs. The payload at the center of this investigation is an HTA file. HTA files run with “full trust” by default, which means they are outside normal browser sandboxing and are able to execute arbitrary system commands. That makes them attractive to attackers who want a one-file drop that executes code with the same privileges as the user who launched it. In our scenario a freelancer delivered a work sample and included a template. The customer opened that template and the machine was infected by an HTA stager in the background. The freelancer asked for two hundred dollars to provide additional work. The payment thread is interesting for attribution and timeline, but the important part for us is the artifact trail that was left behind.





Windows Notification Database





One of the first places that paid off in this case was an often-overlooked database called wpndatabase.db located at C:\Users\USERNAME\AppData\Local\Microsoft\Windows\Notifications. This SQLite database stores Windows toast and web notifications. Chrome and other browsers can surface site notifications through the Action Center and those notifications are recorded in this database. In our investigation we opened wpndatabase.db in DB Browser for SQLite and examined the Notification table.





showing the windows notification database file




finding the notification received by the victim with the zip and pass




There we found an entry that matched the time when the victim reported receiving a message with the template and a password for the archive. 





At this point a simple search of the user’s Downloads directory turned up two items.





finding the attached files by the hacker




The first was a benign looking document that matched the freelancer’s promised sample. The second was a templet.lnk file. LNK files are a long time favorite of attackers and phishing authors. Shortcuts can call programs with arbitrary arguments, and when placed on shared file servers or in download bundles they can be used to trick people into launching code. In enterprise environments LNK files are also occasionally abused for share poisoning and to hide payloads in plain sight. In this case the templet.lnk is the dangerous object, not the document itself.





Analyzing Attachments





To inspect the shortcut we used LECmd. LECmd is a handy Windows forensic utility that extracts the target binary, command-line arguments, working directory, and other metadata from a shortcut file. Running the command against the file produces the raw command line that the shortcut would execute when activated. In our case LECmd revealed a heavily obfuscated PowerShell one-liner. The payload was intentionally mangled to evade detection and to make static reading painful.





PS > LECmd.exe -f .\templet.lnk





running lecmd to extract the content of the malicious lnk file




After deobfuscation and commenting, the PowerShell code became clear. 





deobfuscating the powershell script file




The script contacts a command and control server, enforces TLS 1.2 for the download session, retrieves a file called se1.hta, writes it to disk, executes it, waits three seconds, and then deletes the file. The attacker enforces TLS 1.2 because older TLS versions are deprecated and many modern servers and client stacks refuse to negotiate insecure protocols. Explicitly setting TLS 1.2 ensures the stager will be able to download from a hardened server. The delete step the stager used to remove se1.hta means the author cared about hiding artifacts.





The templet.lnk here is a stager. In many incidents the initial scripted downloader is tiny and benign looking. Stagers are designed to be minimal and evasive. They do the work of fetching the next-stage payload which contains the active malicious logic. An organization can see the downloader and miss the real payload if they do not chase execution timelines, memory artifacts, and permanent persistence mechanisms. Slight edits to stagers generated by common tools can bypass many antivirus engines.





LOLAPPS Persistence





LOLAPPS project catalogs ways adversaries can exploit legitimate built-in and third-party applications for techniques like persistence, lateral movement, data exfiltration, and more. Examples include apps like Greenshot, Visual Studio Code and others where features can be hijacked or repurposed. That’s exactly what happened on the victim’s computer. 





To find this we mounted a forensic image in Autopsy and enumerated installed applications





finding installed apps on the image




Among the installed user applications was Greenshot, a legitimate open-source screenshot utility. The problem is that Greenshot includes an External Command plugin that allows a user to configure an arbitrary command line for post processing. 





greenshot can be used as a persistence method




Attackers use the plugin for persistence.





The plugin configuration lives in C:\Users\USERNAME\AppData\Roaming\Greenshot\Greenshot.ini. In our case the INI file had been modified to invoke the templet.lnk file from the temporary directory. The entry pointed at \AppData\Local\Temp\templet.lnk





finding persistence in the greenshot ini file




That explains the execution chain. When Greenshot starts or when its external command hook is triggered, it executes the LNK file.





finding the greenshot log file




The LNK in Temp was the same object we extracted earlier. The attacker’s HTA file may have dropped the same shortcut into Temp. With the Greenshot plugin abuse documented we now have a near complete kill chain. We know how the actor initiated their access, how the stager pulled se1.hta, how they erased traces, and how they anchored persistence on the machine in an legitimate app though its external command functionality.





Command and Control





While searching for persistence and artifacts, we also reviewed legitimate remote access logs. AnyDesk is everywhere in enterprises and personal computers because it provides convenient remote desktop features. Unfortunately that convenience can be abused. The AnyDesk client stores diagnostic and connection logs under C:\Users\USERNAME\AppData\Roaming\AnyDesk\. These traces record incoming session attempts, handshakes, relays, and remote operating system strings. In our image we found an ad.trace file that contained records matching the time of suspicious activity.





To extract relevant lines from the verbose trace we filtered for the needed lines.





PS > get-content .\ad.trace | select-string -list 'Remote OS', 'Incoming session', 'app.prepare_task', 'anynet.relay', 'anynet.any_socket', 'files', 'text offers' | tee adtrace.log





Searching the newly created log file for IP addresses returns many relay IPs used by the AnyDesk infrastructure and the actual IP used by users to access the machine. Let’s learn to differentiate them.





AnyDesk relay IPs are legitimate service hosts used to NAT and relay traffic so that connections work across NATs and firewalls. They can be found with this command:





PS > cat .\adtrace.log | findstr IP





While the IPs of users who accessed the machine are here:





PS > cat .\adtrace.log | findstr from 





finding ips in the anydesk log




Below is the IP that initiated the connection.





finding more information on the ip that was used to access the anydesk workstation




Reviewing legitimate application logs is critical. Popular remote access tools like AnyDesk are common in organizations and are often not monitored closely. Attackers exploit them by using preinstalled remote management tools as both covert access and persistence mechanisms. When you find suspicious login attempts or odd AnyDesk IDs in traces, cross-correlate them with network logs and SIEM events to determine if the connection originated from an attacker controlled endpoint rather than from a sanctioned remote worker.





Summary





Today’s case shows how modern intrusions often hide behind normal user behavior and legitimate software rather than obvious malware. A single trusted action can open the door to staged execution and long-term access. Effective forensics means looking beyond obvious binaries and treating everyday applications, logs, and user artifacts as part of the attack surface, because persistence today is built on blending in, not standing out.





Enjoying our work? We’re running a digital forensics training on May 19-21, 2026 for Subscriber and Subscriber Pro students. Come learn with us.





If you’ve experienced a breach or need expert help, contact our team and we’ll assist you every step of the way.



Source: HackersArise
Source Link: https://hackers-arise.com/digital-forensics-tracing-an-hta-based-compromise/


Comments
new comment
Nobody has commented yet. Will you be the first?
 
Forum
Red Team (CNA)



Copyright 2012 through 2026 - National Cyber Warfare Foundation - All rights reserved worldwide.