Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Debugger doesn't work in KVM virtual machines. #30

Closed
kevoreilly opened this issue Mar 5, 2018 · 22 comments
Closed

Debugger doesn't work in KVM virtual machines. #30

kevoreilly opened this issue Mar 5, 2018 · 22 comments

Comments

@kevoreilly
Copy link
Contributor

It's been observed that CAPE's debugger does not work in KVM VMs - this is to do with the fact that KVM doesn't allow for use of the debug registers by the guest as discussed here:

https://patchwork.kernel.org/patch/4717311/
https://patchwork.kernel.org/patch/8436261/
https://bugzilla.redhat.com/show_bug.cgi?id=1068627

This means that several packages, most notably including the 'Extraction' behavioural package, will not work properly on these systems due to their dependence on the debugger.

If anyone knows of a workaround to allow use of debug registers within guest VMs on KVM, please let me know.
@redsand
Copy link
Contributor

redsand commented Jun 20, 2018

Could you clarify? All items referenced are marked as closed. We have this deployed in KVM and would love to understand which portion is failing.

@kevoreilly
Copy link
Contributor Author

I recently heard that someone had successfully tested it on QEMU and it worked but a contributor (enzo) had problems on his KVM setup which was described at the end of issue #13 when he was testing the Ursnif package. But if 'Extraction' jobs work (i.e. produce payloads) then it should be working as this package uses the debugger.

If you find this works then I can close the issue - I'll check with enzo too.

@redsand
Copy link
Contributor

redsand commented Jun 26, 2018

I can confirm that I have unpredictable behavior when running QEMU v 1.5.x with Centos 7 with the included backports.

Upgrading to 2.10 fixed all the errors and unpredictable crashes for me, however it's possible that v2.0.0 might fix it as well. I've included additional anti-antivm hardening scripts based upon @doomedraven original work.

Certainly relates to missing backports from the 2.x branch, leaving the 1.x QEMU branch crippled.
kvm-qemu-2.12-antivm-patch.sh.txt
kvm-qemu-2.0-antivm-patch.sh.txt

@enzok
Copy link
Contributor

enzok commented Jun 29, 2018

My setup is Ubuntu 16.04, QEMU v 2.6.1

What "included backports" are you referencing? My version of QEMU appears to be newer than what you are running. What do the anti-antivm hardening scripts accomplish?

Thanks.

@redsand
Copy link
Contributor

redsand commented Jun 29, 2018 via email

@redsand
Copy link
Contributor

redsand commented Jun 29, 2018 via email

@doomedraven
Copy link
Contributor

this week it also will be for debian based ;)

kvm using qemu in background, qemu uses kvm acceleration basically

@kevoreilly
Copy link
Contributor Author

Am I right in thinking this can be closed now? Has it been show that the debugger can indeed work with KVM? Is the latest generic version working, or does it need special patches?

@enzok
Copy link
Contributor

enzok commented Sep 17, 2018

I never was able to get this to work with Ubuntu KVM. I've since abandoned that server instance for ESXi based VMs.

@kevoreilly
Copy link
Contributor Author

I am now thinking KVM/QEMU might be the way forward, @doomedraven is using this and I think can achieve far better stealth against anti-vm than VMware ever will.

@enzok
Copy link
Contributor

enzok commented Sep 17, 2018

I am going to add a couple of bare metal systems to my sandbox network. I am using hardware firewalls and dedicated Tor nodes that fail safe. Couldn't make this work with KVM and rooter. I may look into adding an Ubuntu KVM running on the ESXi. No idea if that's even viable.

@doomedraven
Copy link
Contributor

Couldn't make this work with KVM and rooter. debugger part or kvm itself?

@kevoreilly
Copy link
Contributor Author

I too have been trying to get cape running on bare metal - I have been trying to set up FOG to do the remote re-imaging of the target hosts but ended up getting bogged down in PXE boot problems... How are you planning to tackle re-imaging?

@enzok
Copy link
Contributor

enzok commented Sep 17, 2018

Just the debugger. Rooter worked fine otherwise.

@enzok
Copy link
Contributor

enzok commented Sep 17, 2018

I was looking at FOG as well.

@redsand
Copy link
Contributor

redsand commented Sep 17, 2018 via email

@doomedraven
Copy link
Contributor

I’m having some big disappointments. interesting can you share it with us?

@redsand
Copy link
Contributor

redsand commented Sep 17, 2018 via email

@doomedraven
Copy link
Contributor

Thats maybe can be hardware issue, on my side im using it on 5 servers and it just flying

@redsand
Copy link
Contributor

redsand commented Oct 12, 2018

To follow up on this, my issue with performance with kvm/kvm remote is that I had over allocated resources to my target VMs.

I'm currently experiencing a seamless analysis experience on CentOS 7 with KVM Remote. I feel like this is ready to be closed, however I obviously need more user buyoff since I'm the only one reporting positive results.

@doomedraven
Copy link
Contributor

im using kvm but not remote and it works just fine <3

@kevoreilly
Copy link
Contributor Author

Sounds like it works for everyone! Happy days.

kevoreilly added a commit that referenced this issue Jun 18, 2019
@kevoreilly
Merge pull request #30 from ctxis/master
4157ff9 
Merge latest updates
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@redsand @doomedraven @enzok @kevoreilly