Jump to content

tzuzut

Members
  • Posts

    28
  • Joined

  • Last visited

Posts posted by tzuzut

  1. I can see that the root cert in the browser is ESET, so I assume its working. I thought I recalled years earlier that when enabling this feature, one could view the log and watch the list of https connections and files being scanned... or is this only active during a detection?

    I am seeing "allowed" status white listed domains showing up under 'filtered websites', and thats about it when it comes to internet activity.

  2. On 1/10/2024 at 4:49 AM, constexpr said:

    ESET Browser Privacy & Security extension doesn't work without ESET product and for now there are some technical reasons in the background, why another Chromium/Firefox based browsers are not supported. We know about it and we're working on it so I believe you will see the extension working on Brave soon.

    Any logs I can pull?

  3. I get the following error in eventviewer, with both the Invoke-WmiMethod -Class Win32_Process -Name Create -ArgumentList notepad.exe and wmic process call create "notepad.exe" commands. They only open notepad one time on an a clean boot, then the error persists each consecutive execution from then on. Initially when it works, it appears to load the legacy notepad, with an option to open the 'updated' version.
     

    0x80070005: Cannot create the process for package Microsoft.WindowsNotepad_11.2306.15.0_x64__8wekyb3d8bbwe because an error was encountered while adjusting the token. [GetPackageToken]



    image.png.ddbf442d8512e6d31bd8641bdae6ff19.png

  4. So, oddly, I am getting inconsistent results with windows. I've disabled exploit protections for wmic, and restarted the service, and though it claims notepad launch was successful, it does not appear, not even temporarily, according to task manager.  At times it does; perhaps on a fresh boot of windows. I had strange issues like this before... and other issues, where exploit protection child process blocking for wmic would work on one windows system and only partially on another. On one system it worked for wmic.exe only, but not the powershell command. In the other system, it blocked both. I tried disabling the following attack surface reduction rule as well, but the same issue (if it is one) persists. I'm not sure if attack surface reduction rules actually work when using a third party av.

    https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/attack-surface-reduction-rules-reference?view=o365-worldwide

    image.png.bf8aa7ba8e3bbaf9365cf7c9b66cdd16.png

  5. another tip, add audits via exploit protections; event id 3, 2, 12, 1, 

     

    Quote

    Process '\Device\HarddiskVolume7\Windows\System32\wbem\WMIC.exe' (PID 16968) would have been blocked from creating a child process '\??\C:\WINDOWS\system32\conhost.exe' with command line '\??\C:\WINDOWS\system32\conhost.exe 0xffffffff -ForceV1'.

     

  6.  

     

    Quote

    monitoring child process startup from wmiprvse.exe will;

    Time;Application;Operation;Target;Action;Rule;Additional information
    8/23/2023 3:04:21 PM;C:\Windows\System32\wbem\WmiPrvSE.exe;Start new application;C:\WINDOWS\system32\notepad.exe;Blocked;Deny child processes started from WmiPrvSE.exe;

    I wasn't able to get this effect for some reason... eset is not blocking it.

  7. Thanks for the excellent tips!

    I originally created a scheduled task that monitored for wmic implants based on eventviewer ids, which executed a batch script (see comment) upon detection that scanned the wmic repository for consistency, and stopped the service.  The method I used previously was blocking child process of wmic.exe and wmiprvse.exe via windows exploit protections, in part because they can be used to easily bypass constrained language mode, but it doesn't offer the granularity of a hips setup, and caused compatibility issues with certain applications.   

    I had months ago created a hips for both processes in eset, but neither worked when spawning a processes from cmd or powershell. I don't understand why eset can't detect this. But I guess blocking CMD and Powershell from running wmic would go a long way.

    Id prefer blocking to logging... a hips/whitelist approach would be most useful in my circumstance; to immediately stop it in its tracks.  Attached is my scripts.
    wmi.zip

  8. No matter what I do with custom hips, eset will not ask to block wmi from creating child process via the following commands:

    Powershell:

    Invoke-WmiMethod -Class Win32_Process -Name Create -ArgumentList notepad.exe 


    CMD:

    wmic process call create "notepad.exe"

     

    It had only some success, for example, when loading Adobe After Effects, hips asked if wmi should call up 'conhost.exe'. Why is this not working as intended via the aforementioned commandlines? System Informer clearly shows that notepad is a child process of wmi.

×
×
  • Create New...