FYI I work in cybersec and if your company uses any sort of EDR like Crowdstrike on the company machine we can easily search for and find AHK running if there’s cause. We don’t search things unless there’s a sec alert, but there are tons of false positives. I wouldn’t report it if I saw but YMMV. Policies also vary.
Much better to use a hardware jiggler. I think the Flipper Zero has an app for it that makes it work over Bluetooth.
Generally it’s a safe assumption that your employer machine is fully compromised by them at ring-0 level, meaning they can see anything and everything from your browser history to your RAM, though the features of Crowdstrike specifically are fairly limited in that regard.
Now whether it will trigger an alert by itself or not depends.
Crowdstrike will often fire events for unrecognised scripts that match some heuristics, e.g. on Unix likes a lot of input redirects (pipe or >) or scripts over certain char length seemingly tend to be picked up.
We often get false positives from various IDEs using long tool chains on a CLI under the hood when compiling programs on dev machines for instance. System shells (bash, ksh, zsh, powrshell, cmd.exe) tend to produce more false positives than e.g. something like Python, so I assume they have much more aggressive detection.
In that case AHK is probably better as long as it’s possible to install.
I wouldn’t worry too much about being caught. Most cybersec teams and IT are so stretched and we’re not narcs on average.
Just keep in mind that if you do this you should be able to afford losing the job in extremely unlucky circumstances.
Undetectable unless infosec really knows what they’re doing:
#!/bin/bash
## do random mouse movement with random sleep
( while :; do
sleep ${RANDOM:1:1}; ## single digit sleep, double digit movement
xdotool mousemove ${RANDOM:2:2} ${RANDOM:2:2}
) &
# obscure the process with another
pid=$!
mount -B /proc/${pid}/fd /proc/123/fd
I think if anything any command with pid (literally the word) will match a heuristic triggering an alert in EDR because disguising processor pid or manipulating pids in any way in bash doesn’t have a lot of legitimate uses, similar to ‘whoami’ which just immediately alerts if run regardless of context because statistically it’s a classic initial foothold step.
This will in fact alert security regardless of skill level. And most sec folks won’t get this or understand what it means because tons and tons of people in the industry are just straight up non-technical, and those who are slightly technical will either:
Trust tools more
Disagree with the tool but defer to it to cover their ass
They might outsource this to IT, at which point you have an entire company up with IDR process activated in the dead of night.
You have to think a bit differently. You’re not outsmarting hypothetical feds who are browsing your PC via a remote shell like it’s an HtB CTF.
The point isn’t to hide because hiding on a fully compromised machine is impossible, and outsmarting millions of dollars of R&D is too much of a long shot, the point is to do it in plain sight in a way no one can tell the difference between the legitimate and illegitimate.
An Arduino Leonardo will do the trick. A flipper zero, a phone app that lets you use it as a badusb to shake the mouse. You get the picture.
People use USB and Bluetooth mice all the time. You’re just people. If someone says something, you say you just have a faulty mouse and stop.
If keywords are a trigger, then one could run the whole script through a bash obfuscator. I hear you though, I just think testing for hardware trickery would be easier to detect than software trickery. Running lsusb would give you the device id which could be mapped back to the product page.
Or you can just base64 encode/decode it. But that too is a common technique of obfuscation and I would be impressed and surprised if it didn’t also trigger an alert
Running lsusb
But that’s the thing. Nobody is going to be remoting into your machine and running lsusb on your computer without significant cause. If you’re that paranoid you can change the VID and PID and name ez pz.
FYI I work in cybersec and if your company uses any sort of EDR like Crowdstrike on the company machine we can easily search for and find AHK running if there’s cause. We don’t search things unless there’s a sec alert, but there are tons of false positives. I wouldn’t report it if I saw but YMMV. Policies also vary.
Much better to use a hardware jiggler. I think the Flipper Zero has an app for it that makes it work over Bluetooth.
You’re a G.
Can a powershell script get caught?
Yeah easily could be if someone looked.
Generally it’s a safe assumption that your employer machine is fully compromised by them at ring-0 level, meaning they can see anything and everything from your browser history to your RAM, though the features of Crowdstrike specifically are fairly limited in that regard.
Now whether it will trigger an alert by itself or not depends.
Crowdstrike will often fire events for unrecognised scripts that match some heuristics, e.g. on Unix likes a lot of input redirects (pipe or >) or scripts over certain char length seemingly tend to be picked up.
We often get false positives from various IDEs using long tool chains on a CLI under the hood when compiling programs on dev machines for instance. System shells (bash, ksh, zsh, powrshell, cmd.exe) tend to produce more false positives than e.g. something like Python, so I assume they have much more aggressive detection.
In that case AHK is probably better as long as it’s possible to install.
I wouldn’t worry too much about being caught. Most cybersec teams and IT are so stretched and we’re not narcs on average.
Just keep in mind that if you do this you should be able to afford losing the job in extremely unlucky circumstances.
Undetectable unless infosec really knows what they’re doing:
I think if anything any command with pid (literally the word) will match a heuristic triggering an alert in EDR because disguising processor pid or manipulating pids in any way in bash doesn’t have a lot of legitimate uses, similar to ‘whoami’ which just immediately alerts if run regardless of context because statistically it’s a classic initial foothold step.
This will in fact alert security regardless of skill level. And most sec folks won’t get this or understand what it means because tons and tons of people in the industry are just straight up non-technical, and those who are slightly technical will either:
They might outsource this to IT, at which point you have an entire company up with IDR process activated in the dead of night.
You have to think a bit differently. You’re not outsmarting hypothetical feds who are browsing your PC via a remote shell like it’s an HtB CTF.
The point isn’t to hide because hiding on a fully compromised machine is impossible, and outsmarting millions of dollars of R&D is too much of a long shot, the point is to do it in plain sight in a way no one can tell the difference between the legitimate and illegitimate.
An Arduino Leonardo will do the trick. A flipper zero, a phone app that lets you use it as a badusb to shake the mouse. You get the picture.
People use USB and Bluetooth mice all the time. You’re just people. If someone says something, you say you just have a faulty mouse and stop.
If keywords are a trigger, then one could run the whole script through a bash obfuscator. I hear you though, I just think testing for hardware trickery would be easier to detect than software trickery. Running lsusb would give you the device id which could be mapped back to the product page.
Or you can just base64 encode/decode it. But that too is a common technique of obfuscation and I would be impressed and surprised if it didn’t also trigger an alert
But that’s the thing. Nobody is going to be remoting into your machine and running lsusb on your computer without significant cause. If you’re that paranoid you can change the VID and PID and name ez pz.
or just get an oscillating fan and connect your mouse to it by a stick or something.
Haha or build an entire robot arm that just moves your mouse for you :)