Question about PSEXEC usage

BatchPatch Forums Home Forums BatchPatch Support Forum Question about PSEXEC usage

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • #13246
    LittleDevil7576
    Participant

    Hello,
    I’m new to using BatchPatch. I just started at a company and we’re patching outdated systems from various mergers (some haven’t been patched since 2015 – don’t ask why they’re still in use being that old). The decision was made far above me to block PSEXEC.EXE from running. I got sneaky and used PAEXEC.EXE for a while and somebody caught on and basically said “dude? come on” and it too is now blocked. I’ve made a case to get an exemption for PSEXEC and nobody has said no, but they haven’t said yes either. I am new to this, so please forgive me if this is a dumb question. I believe I can get an exemption if I can help them out a bit. Does it need to be unblocked on the system I am running BatchPatch frpom as well as any system I want to deploy software/patch/script/regkey etc to? Basically do all the enduser systems need to have it unblocked too?

    thanks,
    Chris

    #13247
    doug
    Moderator

    PsExec.exe runs on the BatchPatch system. Its remote agent, PsExeSvc.exe, runs on target systems. In BatchPatch if you use ‘Tools > Settings > Remote Execution > Use PsExec -r switch’ which is both recommended and is also the default setting, then instead of PsExeSvc.exe running on target systems, BatchPatchExeSvc.exe will run on target systems (or whatever name you input in the aforementioned setting box).

    #13248
    LittleDevil7576
    Participant

    Doug,
    Does BatchPatchExeSvc.exe contain PSEXEC.EXE? The system in place doesn’t look for the name psexec, but the guts of the file. You can name a text file psexec.exe and it will be fine. Rename the actual psexec.exe to readme.txt and it still vanishes in less than a minute. If it is a matter of allowing the .exe on just the main BP system, I think I can sell that.
    thanks,
    Chris

    #13249
    doug
    Moderator

    There is a file, PsExec.exe, that runs on the BatchPatch system. On every target system there will be a different file that runs, which is named PsExeSvc.exe. If you use the aforementioned setting to specify a new name for PsExeSvc.exe, then on target systems you won’t see PsExeSvc.exe but rather will see it named BatchPatchExeSvc.exe or whatever you choose to call it.

    #13250
    doug
    Moderator

    To be clear… I’m making no comment about how your system detects the file. I’m just telling you the files that are involved and their names and where they run. You’ll have to assess if and how your system identifies the files in question.

    #13253
    LittleDevil7576
    Participant

    Doug,
    I understand that part about the name and -r. I’m saying the protection in place isn’t looking at names of files but the internals of files. I’m asking if BatchPatchExeSvc.exe is simply a veiled attempt to disguise the psexec.exe file or if it is its own animal.
    Thanks,
    -Chris

    #13254
    doug
    Moderator

    I’m honestly not sure how else to explain it. There are two different files. There is PsExec.exe and there is PsExeSvc.exe. PsExec.exe runs on the BP system. PsExeSvc.exe runs on the target systems while an action is executing. The -r switch effectively enables you to change the name of the PsExeSvc.exe to something else, such as BPExeSvc.exe, when it runs on target systems. But for the sake of this discussion, forget about the -r value for a moment. The point is that there are two files. PsExec.exe on the BP system, and PsExeSvc.exe on the target systems. You keep asking if -r is a veil for PsExec.exe, and what I keep trying to describe to you is that -r has nothing to do with PsExec.exe on the BP system because -r is there to change the name of PsExeSvc.exe when it runs on target systems.

    Whether or not your protection application will flag PsExeSvc.exe in the same way that it flags PsExec.exe is not something that I can tell you. You will need to test it. PsExec.exe and PsExeSvc.exe are two different files, but PsExeSvc.exe is contained inside of PsExec.exe, so there certainly could be overlap when it comes to a detection algorithm looking at them, but it’s by no means a guarantee. With all that said, from what we have seen, these detection systems are generally not at all sophisticated. Even with PsExec.exe containing PsExeSvc.exe inside of it, it’s still very possible that PsExeSvc.exe will bypass detection. Furthermore, in cases where PsExeSvc.exe does *not* bypass detection, using the -r switch to change the name will in 90% of those cases actually cause detection to be bypassed due to the lack of sophistication in how the detection works in most applications. While your test of renaming PsExec.exe to readme.txt does not enable readme.txt to bypass detection, you should definitely still test PsExeSvc.exe both with and without -r to see how it behaves and if your detection system detects it when it’s PsExeSvc.exe and/or if it detects it when the -r value has been used to rename it to something else such as BPExeSvc.exe or whatever. We simply don’t know enough about exactly how your application will perform detection of these files, and we don’t know exactly what’s happening under the hood of the renaming process when using the -r value, and this is why it’s important to test it. We could go back and forth on it all day long, but until you test it, you won’t know the bottom line.

Viewing 7 posts - 1 through 7 (of 7 total)
  • You must be logged in to reply to this topic.