I think that meterpreter is being run directly from memory, and what migrate is doing is basically creating a new process using the memory of a different application, hopping to that process, and then shutting down the old process.
Reasons to migrate the meterpreter process:
- For persistence (pick a long-running process)
- To make sure that the meterpreter process has system privileges
- To hide (pick a process less likely to be examined)
- To stabilize the shell (initial exploits often produce somewhat unstable sessions)
- To move laterally or escalate privileges within a system (if you’re lucky)
- To gain additional capabilities
In particular, harvesting credentials from LSASS requires that meterpreter be living in a process with the same permissions (NT AUTHORITY/SYSTEM) and architecture as LSASS; migrating meterpreter can help us realize this. The print spooler service (spoolsv.exe) is often a good choice, as it runs with elevated permissions, has the same architecture as the system itself, and will restart itself automatically. You can also use lsass.exe directly if you feel like living dangerously.
Another example is that dumping keystrokes will only work when meterpreter is attached to a word processor or text editor.
Note that meterpreter will happily let you migrate from a privileged to an unprivileged process — which may cause you to loose control of the target system! Additionally, migrating meterpreter will change its current working directory to that of the process it’s attaching to.
Executing run post/windows/manage/migrate will cause meterpreter to try to migrate to another process in an automated fashion. I’m not sure how “smart” this is in practice.