advpack.dll ! DelNodeRunDLL32 and its flags

It’s one of these “I was looking at something else, and as usual, came across something else” cases. In this particular instance it was the good ol’ DelNodeRunDLL32 function exported by the advpack.dll.

A quick search followed, and I soon discovered that @bohops twitted about it a while ago, so there was not that much to add…

However…

Looking closer at the DelNodeRunDLL32W function I noticed that it tries to take two arguments, not one, as originally assumed. If the second argument is not present, it is assumed to be 0.

Why not checking what the second argument is all about though? And here we are…

A few more Google searches later we can (re-)discover that DelNodeRunDLL32 function can delete both individual files, and whole directories + change its behavior if we ask it too.

How?

Via its flags. Ones that we can choose to pass via a command line argument (the second one, as you guessed by now).

Again, googling around I came across this header file that lists all the flags that are documented:

// FLAGS:
#define ADN_DEL_IF_EMPTY 0x00000001 // delete the directory only if it's empty
#define ADN_DONT_DEL_SUBDIRS 0x00000002 // don't delete any sub-dirs; delete only the files
#define ADN_DONT_DEL_DIR 0x00000004 // don't delete the dir itself
#define ADN_DEL_UNC_PATHS 0x00000008 // delete UNC paths

Running

  • rundll32.exe advpack.dll,DelNodeRunDLL32 “c:\test” – will wipe out the whole ‘test’ directory
  • rundll32.exe advpack.dll,DelNodeRunDLL32 “c:\test\file” – will delete the ‘file’ only
  • rundll32.exe advpack.dll,DelNodeRunDLL32 “c:\test”,4 – will wipe out the whole ‘test’ directory except the ‘test’ directory itself
  • rundll32.exe advpack.dll,DelNodeRunDLL32 “c:\test”,1 – will wipe out the whole ‘test’ directory only if it is empty

Little trivia, but always…

Using Start Time of the existing guest OS processes as a possible Anti-* trick

When you run the WMI command:

wmic process get name, creationdate

you get a list of process names, and their creation dates.

When I was testing it on my VM I realized that the results expose my VM as a sandbox. Since I saved the VM snapshot a while ago, the creation dates of many running processes were really old. Only a few processes had today’s date.

So, if you see any process (or a cluster of processes) that is older than… say… 6-12 months, it is highly possible that the sample is executed inside a sandbox. While the uptimes are much longer now than in the past, systems that run processes for more than a year are suspicious; after all, patching affects all the systems and if there was no restart within last year it’s at least unusual…