CD does not appear to be working

[ora]

Hello,

I am running the following:

Invoke-FalconRTR -command cd -arguments “C:\Somedir” -hostids $HostIds
Invoke-FalconRTR -command put -arguments “some.exe” -hostids $HostIds

It comes back with success on CD, but PUT puts the file in C:\ anyway. Same thing happens when I do this via Invoke-FalconAdminCommand with sessionid. Is this supposed to work or do these need to be chained in some way? The directory exists.

complete : True
offline_queued : False
stdout : C:\Somedir

Latest psfalcon, Windows 10 CS client.

Thanks!

[bk-cs]

Thanks! I think we're also discussing this on reddit: https://www.reddit.com/r/crowdstrike/comments/ofq991/refreshing_file_status_or_overwriting_file_on_put/

This appears to be an issue with the single host RTR session API, rather than something with PSFalcon. Whenever a new command is issued, the API is resetting the location to the root of the system drive.

The way to work around this is to not use Invoke-FalconRTR because it will use a single host session if given a single host. If you force a batch session (even if it's only for one host), this problem doesn't appear.

In other words, doing this will result in Arbitrary.file being placed in C:\ rather than C:\temp as expected...

Invoke-FalconRTR -Command cd -Arguments C:\temp -HostId <id>
Invoke-FalconRTR -Command put -Arguments Arbitrary.file -HostId <id>

But the following commands will properly place it in C:\temp:

$Session = Start-FalconSession -HostIds <id>
Invoke-FalconCommand -Command cd -Arguments C:\temp -BatchId $Session.batch_id
Invoke-FalconAdminCommand -Command put -Arguments Arbitrary.file -BatchId $Session.batch_id

This behavior is consistent with other commands too (like cd then ls). For this to be resolved, either the bug needs to be fixed on the API side, or Invoke-FalconRTR needs to always use batch sessions. The API getting changed is the better solution...

[bk-cs]

I've opened a ticket with the CrowdStrike API team to review.

[bk-cs]

I confirmed with the Real-time Response API team that Invoke-FalconRTR is causing this to happen. Because Invoke-FalconRTR is designed for one command at a time (not a multi-step workflow), it re-initializes the existing session when you run it a second time, causing your new commands to operate out of the system root folder.

To fix this problem, You can follow the batch example...

$Session = Start-FalconSession -HostIds <one or more ids>
$Cd = Invoke-FalconCommand -Command cd -Arguments <destination path> -BatchId $Session.batch_id
$Put = Invoke-FalconAdminCommand -Command put -Arguments <filename> -BatchId $Session.batch_id

Or you can use the single host commands and make sure that you confirm that each command is complete, which is what "updates the location" of the session and will allow put to place the file in the right place.

$Session = Start-FalconSession -HostId <id>
$Cd = Invoke-FalconCommand -Command cd -Arguments <destination path> -SessionId $Session.session_id
$ConfirmCd = Confirm-FalconCommand -CloudRequestId $Cd.cloud_request_id
$Put = Invoke-FalconAdminCommand -Command put -Arguments <filename> -SessionId $Session.session_id

Confirming in-between steps syncs the working directory during the session. If you don't confirm, it will reset to the base system directory, which is ultimately the same thing that's happening when running Invoke-FalconRTR a second time.

This isn't really a bug, but more due to how the RTR API and Invoke-FalconRTR work. I added some additional text to the wiki that spells out this scenario, and the API team is going to work to improve the documentation to indicate why this happens more clearly as well.

[ora]

Thanks!