A new hash is not a new behavior.

What expires overnight

A hash of the file. The icon. The filename in a user's downloads folder. A YARA rule aimed at a unique string the author can delete in one pass. Those are useful the week you get the sample, and they are how a repack gets reported as a "new family" by someone who did not look at the run.

This desk does not publish samples, and it does not publish the steps a packer takes. If the only artifact you have is a hash, say that. Do not promote it to a campaign.

What usually survives

These are questions, not proof. A single hit is a ticket to read the process tree, not a conclusion.

• A signed operating-system binary starting an unsigned child that the vendor does not start. The signature on the parent is the disguise. The child is the tell, and a repack of the child does not put the parent's signature on it.
• A process that is quiet for a long stretch and then opens a network connection, with no user input in between. Delaying the noisy part is a common way to outlast a sandbox that gives up. The delay changes length. The shape, idle then network, is the part worth graphing.
• A module loaded from a directory the user can write, into a process that normally loads from a program directory. Renaming the file does not move it into System32.

What a dashboard should refuse

A tile that counts "malware detections" by hash will climb when the packer runs and fall when you write a new hash, and you will call both of those progress. Count the three questions above by host, over fourteen days, and annotate the day you deployed a hash rule. If the hash rule moved and the three questions did not, the repack worked and the behavior did not change.

None of this identifies a family. Identification needs a sample in a lab that is not this website, and a write-up that still does not include the build. Until then the honest status is: behavior class, not a name.

• Research lanes
• Related detection note, on login method rather than files