此处有一处错误，今天发现的另外一种情况，今天演示的时候，发现依旧不能成功访问域控共享目录，然后排错发现，原来是使用了system权限的mimikatz。
1 | kerberos::list： 列出在用户的内存中所有用户的票证（TGT 和 TGS）。不需要特殊的权限，因为它仅显示当前用户的票证。与 “klist” 的功能相似。 |
在使用域普通用户伪造的凭证注入时，应当使用该域普通账户权限的mimikatz注入，而不应该使用system权限的mimikatz来注入。是因为system权限的mimikatz注入时，会把凭证注入到system的内存中，而不是域普通用户的内存中，所以才会失败。
这张图是system权限下的mimikatz查看到的凭证，发现内存中只有一个凭证，也就是被注入的凭证
而这张图是同一时间，域普通用户权限下的mimikatz查看到的凭证列表，显示有3个凭证，这明显就不同了。所以根据上面kerberos::list命令的说明，猜测“不同用户权限下的mimikatz所操作的内存是不同的”不敢确定所有的命令是这样，但是至少kerberos::模块或者“kerberos::list”、“kerberos::purge”、“kerberos::ptc”是这样的。
另外还发现一个有意思的东西，那就是“注销”会清除/释放内存。
当在实验mimikatz抓取密码/hash的时候发现，只能抓到当前用户的密码/hash。多次实验发现依旧如此，并不能抓取到其他登陆过但是现在已注销用户的密码/hash（除了 机器名$ 用户）
实验步骤如下：
使用administrator用户登录，然后procdump出内存文件。
然后将文件放置物理机dump解密。如图所示，可以看到只有机器名$和administrator的密码和hsah
随后点击注销，登录本地普通用户ding，重复同样步骤dump出内存文件。（其中因为procdump需要权限，所以用1388提权到system了。）
拉到物理机解一下，可以看到这次的结果只有机器名$和ding用户的密码和hsah。
到这里就可以看出来了，注销是会把administrator用户的内存释放，这样下次使用其他用户抓密码的时候就抓不到administrator用户的hsah了。
下面做一个对比实验，这次不注销换成在任务管理器->用户 窗口中断开连接（或者在菜单不点击注销，点击切换用户），从而达到切换用户的目的。
这一次同样dump出内存文件，拉到本地解，结果如下
可以看到，在不注销的情况下，成功在内存中读取到了administrator和ding的密码。
所以，从防御的角度讲，运维人员能注销的就注销吧，这样可以避免被抓到关键账号的hash和密码，防止更大的风险产生。