Catching dropped executable files without a sandbox

One common technique used by a lot of exploits, malware, and obfuscated software is to dynamically generate or download an executable or DLL file, run it or load it, then delete it. I frequently catch even legitimate software doing this, but I am always curious as to what executable code the authors are trying to hide. Saving those automatically generated files is a core feature of any decent sandbox out there, but in many cases, you see this activity on a production system and don't know where the file is coming from. Especially if it only happens infrequently, it often doesn't make sense to try to put the whole system in a sandbox.

So instead, I just use a simple trick with NTFS file permissions. First go to the folder that the executable file is going to be dropped in and edit its permissions (advanced button). Uncheck the "include inheritable permissions" checkbox.

You can hit Remove to drop all of them, then add one new permission giving full control to your user account, or hit Add to convert them to new permissions, and then remove all but the permission giving your account full control.

Then edit that one entry that remains for your user account, and un-check the Delete boxes. Your account will now be able to add new files, but not delete any files that are there or get created in the future.


Now just wait for that file to drop, and it will be preserved in the folder for you to come back later and grab. Since you retained the change permissions privilege, you can simply revert permissions by re-enabling inherited permissions on the folder you modified later and you'll be back to normal.

, ,

  1. #1 by jduck on November 1, 2013 - 4:45 am

    Uhh. Couldn’t the person that drops this thing just delete it themselves (after changing the permissions)?

    • #2 by scriptjunkie on November 2, 2013 - 5:24 pm

      Of course (sometimes). It’s stupid simple. I should probably clarify you can’t rely on it if there’s a real person with control on the other end; but it’s fine for simpler tasks. The last time I used it was when a new version of a piece of software I was running wouldn’t work due to my restricted executable/dll whitelist. I saw that it was trying to extract and load a DLL from a temporary directory, but it would delete the DLL immediately. So I just flipped the ACL, re-ran it and grabbed a copy. It works best for obfuscated software like that or drop-and-run packers, but my use case would even work if you ran into an exploit like this: or like this: that relies on dropping and loading a DLL. The “bad guys” would not have obtained control, and you could get a copy of the payload.

Comments are closed.