Skip to content

Back to the catalog

bencteux.frwriteup

Evading command-line detection with doskey

Describes abusing the built-in Windows doskey command to define macros/aliases that hide the real executable (e.g. powershell.exe, or a chained download+ProcDump LSASS dump) from command-line-based detection. By defining macros on an attacker machine, exporting them with `doskey /m`, and importing them on the target via `doskey /macrofile=`, the sensitive command never appears on the target's command line, only the short alias does. The author notes this bypasses shallow command-line logging but not lower-level hooks, and suggests defenders monitor/alert on doskey usage since it's rarely used in modern environments.

TL;DR Windows `doskey` macros/aliases can hide sensitive command-line strings (e.g. powershell.exe, ProcDump LSASS dumps) from command-line-based detection by importing pre-defined macros via `/macrofile`.
Document

What it is

A technique post on abusing the built-in Windows doskey command to hide the real executable name from command-line-based detection rules by defining macros/aliases. Covers macro definition, loading macros from a file, command chaining, and changing the macro-resolving host binary.

How it works

doskey name="path\to.exe" $* defines an alias where $* forwards arguments, so name gci c:\ runs PowerShell without powershell.exe appearing when the alias is invoked. The definition itself still exposes the executable, so the evasion depends on the file-load path: define the macros on the attacker box, export with doskey /m > legit.txt, transfer the file, and load it on the target with doskey /macrofile=legit.txt. After loading, invoking the alias never puts the real command on the command line. Two additional mechanics the summary omits: $t chains multiple commands inside one macro, and /exename= changes the default resolving binary from cmd.exe to something else (e.g. ftp.exe).

Preconditions / Affected

Windows with doskey available. The LSASS-dump example (test2) requires admin rights. The macro file must be staged on the target before the alias is used.

What to do

Attacker-side define and export:

C:\Users\Attacker> doskey test1="%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe" $*
C:\Users\Attacker> doskey /m > legit.txt

Target-side load and run:

C:\Users\Target> doskey /macrofile=legit.txt
C:\Users\Target> test1 gci c:\

Chaining and alternate host examples:

doskey tx=cd temp$tdir /w $*
doskey /exename=ftp.exe go=open 172.27.1.100$tmget *.TXT c:\reports$tbye

Defensive: the author recommends checking a SIEM for how often doskey.exe executes in your environment, and — if it is rarely used legitimately — creating a detection rule on its execution. The macro file left on disk is itself an artifact containing the alias definitions.

Caveats

The evasion only defeats detection that reads command-line history; the author explicitly states it "will not work on detection hooks that are at a lower level than command-line history." It also leaves the macro file artifact behind. The author is unsure how widely doskey is still used on modern Windows, which is why the suggested detection is gated on measuring its baseline frequency first.

Technologies named here

Techniques named here

  • Command-line detection evasion via doskey macros
  • Macro import from file
  • LSASS memory dumping
  • Command chaining in macros
  • Changing default macro-resolution executable