Closed bcnx closed 4 years ago
This issue is closed because it does not meet our issue template. Please resubmit with the correct template.
Reopening issue. Just for future reference, the issue template requires all of the sections.
You might want to change the "If applicable" part of the template then.
Some further research suggests that this could be related to Windows 10 update 1809 update.
@bcnx thank you for the feedback. We will consider loosening the requirements in the future.
@Cx01N Is there a way to still get it to work?
I tried testing it on a few of my machines (1803, 1903, 1909, 2004) and they all appear to be working fine. Unfortunately, I do not have an 1809 box at the moment. Could you provide a few more details so I can try to mirror the setup?
What version of Empire? (3.2.3?) Which listener? Which stager? Windows? (I can assume Windows 10 1809 but just wanted to double-check) Is the agent executing the task or is it just hanging prior to tasking? (screenshot might help answer this)
Thanks and hopefully we can get this sorted out. We also tend to be able to work through technical issues a bit faster on Discord, if that is an option you don't mind using.
Hi, this related to a box in the OSCP labs. Empire version: 3.2.3 supplied with apt on Kali, but I also did a git clone of what I think probably is the latest version. HTTP listener. windows/launcher_bat Windows: I only have CLI access and doing a sysinfo pointed to a 14393 build. Not sure how this relates to the 4-number version numbers. The task is executed, I see a job number, but then it returns to the prompt. Screenshot:
Let me know if you need anything else, Cheers, BC
Hi, I used my same Empire install to another OSCP lab box and there it runs without problems (Microsoft Windows Server 2016 Standard). So it is linked to this particular Windows version,
BC
@bcnx if this is in an OSCP lab it's pretty hard for us to help you trouble shoot as they set up boxes to intentionally break things to force lab participants to either modify their tools by hand or use a different method. As such it's almost impossible for us to know if the issue is a problem with Empire or some intentional configuration in the lab
Hi, well, the standalone Mimikatz executable did function correctly on that particular host, so I'm not sure the problem is related to the host being deliberately broken.
@bcnx Have you been able to able to reproduce this on any other machines? As @Cx01N told you we have tested this on about a half dozen different machines and have not been able to reproduce. OSCP labs are about creating weird quirks in the environment that you have to solve. There could be an AV product that kills powershell touching LSASS , powershell could be running in some kind of constrained mode, etc.
If you are able to reproduce this on another machine can you please provide details as to how the environment is set up, what software is running, etc so that we can try to reproduce the error.
Empire Version
OS Information (Linux flavor, Python version)
Describe the bug After giving the mimikatz command the program is not launched, no mimikatz splash screen is observed and the command prompt does not change.
To Reproduce Steps to reproduce the behavior:
Expected behavior Ascii splash screen and mimikatz prompt.
Screenshots If applicable, add screenshots to help explain your problem.
Additional context Add any other context about the problem here.