Skip to content

Armory commands return no output #1864

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.

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

Open
karlmax1342 opened this issue Jan 25, 2025 · 5 comments
Open

Armory commands return no output #1864

karlmax1342 opened this issue Jan 25, 2025 · 5 comments

Comments

@karlmax1342
Copy link

karlmax1342 commented Jan 25, 2025

Describe the bug
When I try to use extensions from the armory on active windows sessions, I receive no output, no matter the extension or argument.

I am on version 1.6.0 and built from source. the armory commands work when I use 1.5.4

To Reproduce
Steps to reproduce the behavior:

  1. start sliver server in daemon mode, connect client on localhost
  2. armory install seatbelt
  3. connect to open windows session
  4. seatbelt -- -groups=system

Expected behavior
Seatbelt returns an ascii banner and info about the system

Screenshots
[*] seatabelt output: and nothing else```

Desktop (please complete the following information):
-pentoo linux

@Oni-kuki
Copy link

Oni-kuki commented Feb 3, 2025

I'm just here to help the devs at my level, I'm facing the same problem and I've had a look, the problem seems to come from go/donut in binject.

When you activate debug mode in the implant, you see that access is denied and the command to stop a sacrificial process doesn't work, simply because the process died before receiving the command because it wasn't loaded.
and i thought of the execute-assembly loader, but the whole loading process seemed to be working fine, and that's when i thought of donut, because it seems to me that it's activated by default and hard in the code.

in short, the temporary solution is to return to the previous functional state of go/donut, in particular to the following state
I tried it quickly, so let's see if it works for everyone. You can use the master version at the time of this message and change the 2 go/donut x64,and x86 files in this commit. here

@omair2084
Copy link

Most likely it's the AMSI bypass being detected.
seatbelt -M -i -- -groups=system
Does this work? Does Defender kill the process?

@Oni-kuki
Copy link

Oni-kuki commented Feb 4, 2025

I did several tests before publishing my message, and what I can say is that even with windows security turned off I don't get the output, and indeed in --in-process it works and I thought of the same thing amsi kills us even before the answer, but I also tried to put the recent version of the donut loader on sliver 1.5.42 and well same worries no output on functions based on execute-assembly

@c2biz
Copy link
Contributor

c2biz commented Feb 4, 2025

@omair2084
Copy link

I did several tests before publishing my message, and what I can say is that even with windows security turned off I don't get the output, and indeed in --in-process it works and I thought of the same thing amsi kills us even before the answer, but I also tried to put the recent version of the donut loader on sliver 1.5.42 and well same worries no output on functions based on execute-assembly

I believe there are two different places AMSI is used, one which donut uses (loader stub) and the other which execute-assembly uses. One seems to be detected and flagged, the donut one seems to fail silently or is not present in the newer loader stub.

Could it be related to this: https://hshrzd.wordpress.com/2025/01/27/process-hollowing-on-windows-11-24h2/ ?

Since I am not using 24h2, it shouldn't be the case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants