Is your feature request related to a problem? Please describe.
Yes. I am requesting approval to implement HookChain, a technique that I originally developed and published, into the implant across its EXE, DLL, and Shellcode formats.
Currently, the implant relies on its existing execution mechanisms when interacting with the Windows Native API. This proposal aims to introduce HookChain as an additional execution/evasion mechanism, providing another option for controlled Red Team and adversary-simulation scenarios where endpoint monitoring and EDR behavior are part of the assessment.
The original HookChain research and implementation are publicly available here:
HookChain: A New Perspective for Bypassing EDR Solutions
https://github.com/helviojunior/hookchain
Describe the solution you'd like
I would like approval to implement native HookChain support directly into the implant, covering all currently supported payload formats:
The implementation would adapt the original HookChain technique to the project's architecture rather than simply embedding the existing Proof of Concept.
HookChain combines IAT Hooking, dynamic System Service Number (SSN) resolution, and indirect system calls to redirect selected Windows API execution paths.
My intention is to integrate this functionality cleanly into the implant's existing codebase and execution flow, while keeping the implementation modular enough to avoid unnecessary impact on the current architecture.
As the original author of HookChain, I can implement and adapt the technique directly, including any changes required to make it compatible with the project's EXE, DLL, and Shellcode build pipelines.
Describe alternatives you've considered
The main alternative would be to keep HookChain as an external or standalone component and require operators to manually adapt or integrate it when needed.
Another option would be to implement only individual concepts used by HookChain, such as indirect system calls, without integrating the complete technique.
However, I believe a native implementation provides a cleaner and more maintainable approach, avoids requiring operators to maintain custom implant builds, and allows the functionality to be properly integrated and tested across the supported implant formats.
Additional context
I am the original author and researcher behind HookChain. The technique was developed as security research focused on understanding EDR monitoring mechanisms and exploring alternative execution paths involving the Windows Native API.
The research, technical details, Proof of Concept, and white paper are publicly available at:
GitHub:
https://github.com/helviojunior/hookchain
Paper:
https://arxiv.org/abs/2404.16856
If this proposal is approved, I am willing to take responsibility for implementing the feature, adapting HookChain to the project's architecture, and testing the implementation across the EXE, DLL, and Shellcode variants.
This request is therefore primarily seeking maintainer approval before I start the implementation, so that the architectural approach and expected scope can be aligned with the project before development begins.
Is your feature request related to a problem? Please describe.
Yes. I am requesting approval to implement HookChain, a technique that I originally developed and published, into the implant across its EXE, DLL, and Shellcode formats.
Currently, the implant relies on its existing execution mechanisms when interacting with the Windows Native API. This proposal aims to introduce HookChain as an additional execution/evasion mechanism, providing another option for controlled Red Team and adversary-simulation scenarios where endpoint monitoring and EDR behavior are part of the assessment.
The original HookChain research and implementation are publicly available here:
HookChain: A New Perspective for Bypassing EDR Solutions
https://github.com/helviojunior/hookchain
Describe the solution you'd like
I would like approval to implement native HookChain support directly into the implant, covering all currently supported payload formats:
The implementation would adapt the original HookChain technique to the project's architecture rather than simply embedding the existing Proof of Concept.
HookChain combines IAT Hooking, dynamic System Service Number (SSN) resolution, and indirect system calls to redirect selected Windows API execution paths.
My intention is to integrate this functionality cleanly into the implant's existing codebase and execution flow, while keeping the implementation modular enough to avoid unnecessary impact on the current architecture.
As the original author of HookChain, I can implement and adapt the technique directly, including any changes required to make it compatible with the project's EXE, DLL, and Shellcode build pipelines.
Describe alternatives you've considered
The main alternative would be to keep HookChain as an external or standalone component and require operators to manually adapt or integrate it when needed.
Another option would be to implement only individual concepts used by HookChain, such as indirect system calls, without integrating the complete technique.
However, I believe a native implementation provides a cleaner and more maintainable approach, avoids requiring operators to maintain custom implant builds, and allows the functionality to be properly integrated and tested across the supported implant formats.
Additional context
I am the original author and researcher behind HookChain. The technique was developed as security research focused on understanding EDR monitoring mechanisms and exploring alternative execution paths involving the Windows Native API.
The research, technical details, Proof of Concept, and white paper are publicly available at:
GitHub:
https://github.com/helviojunior/hookchain
Paper:
https://arxiv.org/abs/2404.16856
If this proposal is approved, I am willing to take responsibility for implementing the feature, adapting HookChain to the project's architecture, and testing the implementation across the EXE, DLL, and Shellcode variants.
This request is therefore primarily seeking maintainer approval before I start the implementation, so that the architectural approach and expected scope can be aligned with the project before development begins.