You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The idea would be to add a field for each LOLBAS use case that would have the parameters and/or switches involved in using it in a certain way (Download, ADS, Encode, etc.).
The goal here is less about making this available through the website, but more about making that information available in the downloadable CSV.
In certain SIEMs, like Microsoft Sentinel, this would allow to ingest the CSV and lookup LOLBAS not only by their function (e.g.: Download) but by their command line parameters directly.
Right now, if you ingest the CSV and lookup let's say DeviceProcessEvents using only the LOLBAS name, you may get a lot of non-relevant results as you would be the targeting every execution of that process and not the ones that have the "related" parameters or switches.
It may be too complicated to be implemented and/or some LOLBAS may have parameters/switches that are too generic (e.g.: msiexec.exe) but I wanted to at least suggest it in case it may actually help improve the project and people consuming that data in a programmatic fashion :)
The text was updated successfully, but these errors were encountered:
Good evening!
tl;dr: This idea came up following a discussion under Nathan McNulty's thread on Twitter here:
https://twitter.com/SecurityAura/status/1763049357597634923
The idea would be to add a field for each LOLBAS use case that would have the parameters and/or switches involved in using it in a certain way (Download, ADS, Encode, etc.).
Taking certutil.exe has an example: https://lolbas-project.github.io/lolbas/Binaries/Certutil/
You could end up with:
Download: -urlcache, -split, -f, -verifyctl
ADS: -urlcache, -split -f
Encode: -encode
Decode: -decode, -decodehex
The goal here is less about making this available through the website, but more about making that information available in the downloadable CSV.
In certain SIEMs, like Microsoft Sentinel, this would allow to ingest the CSV and lookup LOLBAS not only by their function (e.g.: Download) but by their command line parameters directly.
Right now, if you ingest the CSV and lookup let's say DeviceProcessEvents using only the LOLBAS name, you may get a lot of non-relevant results as you would be the targeting every execution of that process and not the ones that have the "related" parameters or switches.
It may be too complicated to be implemented and/or some LOLBAS may have parameters/switches that are too generic (e.g.: msiexec.exe) but I wanted to at least suggest it in case it may actually help improve the project and people consuming that data in a programmatic fashion :)
The text was updated successfully, but these errors were encountered: