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.

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

Fix ART payloads using the environment variable set at $PathToAtomicsFolder #1834

Closed
EllynBsc opened this issue Nov 8, 2024 · 1 comment · Fixed by OpenBAS-Platform/collectors#51
Assignees
Labels
bug use for describing something not working as expected solved The issue has been solved
Milestone

Comments

@EllynBsc
Copy link
Member

EllynBsc commented Nov 8, 2024

Description

The Atomic Red Team set the $PathToAtomicsFolder environment variable to store and retrieve resources needed for executing payloads. However, our application does not include this environment variable by default.

We need to replace this variable when collecting Atomic Red Team payloads. Note that this goes beyond simply ensuring the folder exists, it also involves managing resources that we may not have.

We’ve identified three scenarios:

  • Case 1: Commands use resources in $PathToAtomicsFolder that haven’t been pre-downloaded, and the path is not treated as a variable (e.g., "Process Hollowing in Go using CreateProcessW WinAPI"). => ❌
  • Case 2: Commands use resources in $PathToAtomicsFolder, but this path can be user-defined (e.g., "TinyTurla backdoor service w64time").=> ✅
  • Case 3: Some prerequisites download missing resources directly from GitHub, with additional behaviors:
    • A: Case 3 combined with Case 2 behavior (e.g., "Parent PID Spoofing using PowerShell"). => ✅
    • B: If the path doesn’t exist, all resources are stored in the ExternalPayloads directory that has been created just before. (e.g UltraVNC Execution ) => ✅

⚠ special case to check ;
Parent PID Spoofing using PowerShel
Persistence with Custom AutodialDLL

@EllynBsc EllynBsc added the bug use for describing something not working as expected label Nov 8, 2024
@EllynBsc EllynBsc added this to the Release 1.9.0 milestone Nov 8, 2024
@EllynBsc EllynBsc changed the title Fix the technical payloads giving us "used by another process" Fix the technical payloads giving us "$ before pathname" Nov 8, 2024
@EllynBsc EllynBsc changed the title Fix the technical payloads giving us "$ before pathname" Fix the technical payloads giving us a problem with the $ "$ before pathname" Nov 8, 2024
@EllynBsc EllynBsc changed the title Fix the technical payloads giving us a problem with the $ "$ before pathname" Fix technical payloads giving us a problem with the $ "$ before pathname" Nov 8, 2024
@MarineLeM
Copy link
Contributor

In Atomic Red Team, $PathToAtomicsFolde refers to a directory that contains many resources that used to execute many payloads.
The problem is in our application we lack these resources...

This is the folder of the resources : https://github.com/redcanaryco/atomic-red-team/tree/25e3c3956c4bd7d7232c7ce24a96fcc079e4c4a0/atomics

cf the installation documentation of atomic red team https://github.com/redcanaryco/invoke-atomicredteam/wiki/Installing-Invoke-AtomicRedTeam

@MarineLeM MarineLeM changed the title Fix technical payloads giving us a problem with the $ "$ before pathname" Fix ATR payloads using the environment variable set at $PathToAtomicsFolder Nov 14, 2024
@MarineLeM MarineLeM changed the title Fix ATR payloads using the environment variable set at $PathToAtomicsFolder Fix ART payloads using the environment variable set at $PathToAtomicsFolder Nov 14, 2024
@RomuDeuxfois RomuDeuxfois added the solved The issue has been solved label Nov 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug use for describing something not working as expected solved The issue has been solved
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants