Hacker News new | ask | show | jobs
by quanticle 3388 days ago

    DO explicitly remove sensitive data (encryption keys, raw collection data, 
    shellcode, uploaded modules, etc) from memory as soon as the data is no 
    longer needed in plain-text form. DO NOT RELY ON THE OPERATING SYSTEM TO DO 
    THIS UPON TERMINATION OF EXECUTION.

    DO NOT explicitly import/call functions that is not consistent with a tool's 
    overt functionality

    DO NOT perform operations that will cause the target computer to be 
    unresponsive to the user

    DO make all reasonable efforts to minimize binary file size for all binaries 
    that will be uploaded to a remote target

    DO provide a means to completely "uninstall"/"remove" implants, function 
    hooks, injected threads, dropped files, registry keys, services, forked 
    processes, etc whenever possible.

    DO use end-to-end encryption for all network communications. NEVER use 
    networking protocols which break the end-to-end principle with respect to 
    encryption of payloads.

    DO NOT break compliance of an RFC protocol that is being used as a blending 
    layer.

    DO NOT read, write and/or cache data to disk unnecessarily. Be cognizant of 
    3rd party code that may implicitly write/cache data to disk.

    DO NOT use hard-coded filenames or filepaths when writing files to disk. 
    This must be configurable at deployment time by the operator.
It's remarkable how many of these guidelines are just good software development guidelines and have nothing to do with malware, necessarily.
2 comments

It's funny when you think about it. Many of these guidelines are there to prevent the program from being detected; in other words, it's to give the impression that it's not there.

You would think that good software which performs background tasks should be just as discreet, and follow similar guidelines: do your task, don't bother the user too much, definitely try not to block UI when the user is doing another thing. But a lot of software definitely does not. The classical example is AV software, but a lot of mobile applications are very guilty too. There is so much software that fails so hard at being efficient at background tasks...

It used to be even more prevalent about 10-15 years ago, but I suspect that it has a lot more to do with increased computational capabilities than to higher quality software.

It's also interesting how many of these guidelines have malware-related rationales, though.