4 ms·

The point of LOLBAS is not to identify exploitable programs but to identify useful programs for attackers. There is no issue of privilege here - if you are an a

The point of LOLBAS is not to identify exploitable programs but to identify useful programs for attackers. There is no issue of privilege here - if you are an attacker and you meet the privilege requirements, there you go, you can do these things. The LOLBAS github has good definitions: https://github.com/api0cradle/LOLBAS https://github.com/api0cradle/LOLBAS > LOLBAS candidates must be present on the system by default or introduced by application/software "installation" from a "reputable" vendor or open-source entity. Otherwise, LOLBAS determination is subject to scrutiny by the (security) community and agreed upon standards. > Can be used as an attacker tool directly or can perform other actions than what it was intended to do (Ex: regsvr32 - execute code from SCT online) Essentially, what programs on the operating system can an attacker abuse to do things that a defender will have a hard time monitoring for. The idea is that "bring your own binary" is dead (it isn't, but that's the idea) because it's too detectable/ preventable - software whitelisting, detecting unsigned apps, etc, make it hard. But if you can just leverage what's already on the system you can avoid detection more easily.

kelnos 7y ago
> There is no issue of privilege here - if you are an attacker and you meet the privilege requirements, there you go, you can do these things. It still doesn't really make sense to me. The SUID examples all show you -- as root, via sudo -- copying a binary into the current directory, and then marking it u+s. If you can do that, then you don't need your new SUID binary... you already somehow have root access, so you can do whatever you want. > But if you can just leverage what's already on the system you can avoid detection more easily. Outside of a heavily-contrived CTF type situation, what system is going to have a SUID `cat` lying around? Or really, a SUID anything-that-isn't-normally-SUID?
- caf 7y ago
  The SUID ones are for cases like "something you have exploited gives you the opportunity to execute one command as root; how can you leverage that for persistent access?". So the idea is you make it SUID yourself, which gives you a partial way back in later.
  - jcelerier 7y ago
    but if at some point you were root, you can most certainly install something in your victim's bootloader which is muuuch more effective
    - caf 7y ago
      Not certainly - perhaps there's no device node available to you to open the device that contains the bootloader, and no mknod to create one?
      - schoen 7y ago
        Perhaps then python -c 'import os; os.mknod("/tmp/yow", 0060000, 2048); os.chmod("/tmp/yow", 0777)' But clearly your point is right that a Unix environment could still prevent someone with root access from accessing the raw disk device, including at the kernel level.
    - staticassertion 7y ago
      That's not really something I expect from an attacker at all.

kelnos 7y ago

> There is no issue of privilege here - if you are an attacker and you meet the privilege requirements, there you go, you can do these things. It still doesn't really make sense to me. The SUID examples all show you -- as root, via sudo -- copying a binary into the current directory, and then marking it u+s. If you can do that, then you don't need your new SUID binary... you already somehow have root access, so you can do whatever you want. > But if you can just leverage what's already on the system you can avoid detection more easily. Outside of a heavily-contrived CTF type situation, what system is going to have a SUID `cat` lying around? Or really, a SUID anything-that-isn't-normally-SUID?

caf 7y ago
The SUID ones are for cases like "something you have exploited gives you the opportunity to execute one command as root; how can you leverage that for persistent access?". So the idea is you make it SUID yourself, which gives you a partial way back in later.
- jcelerier 7y ago
  but if at some point you were root, you can most certainly install something in your victim's bootloader which is muuuch more effective
  - caf 7y ago
    Not certainly - perhaps there's no device node available to you to open the device that contains the bootloader, and no mknod to create one?
    - schoen 7y ago
      Perhaps then python -c 'import os; os.mknod("/tmp/yow", 0060000, 2048); os.chmod("/tmp/yow", 0777)' But clearly your point is right that a Unix environment could still prevent someone with root access from accessing the raw disk device, including at the kernel level.
  - staticassertion 7y ago
    That's not really something I expect from an attacker at all.