Jump to content

KAMIRAN Support

Members
  • Posts

    34
  • Joined

  • Last visited

Posts posted by KAMIRAN Support

  1. 22 minutes ago, MartinK said:

    ERA 6.5 appliance (based on CentOS7) uses apache http proxy available from official CentOS repositories. Configuration file enabling http proxy with ERA specifics is located in file /etc/httpd/conf.d/proxy.conf. It should be possible to enable authentication as is described in Apache 2.4 documentation but it was not tested, nor it is documented by ESET.

    Could you also ask customer for his reason to require authentication? Apache proxy distributed in ERA appliance is configured so that it forwards requests only to ESET servers. This significantly reduces risk of proxy misuse.

    We test it and it work, We don't know why they want to use authenticating , they are a government and they want maximum security. We told them that this is a limited proxy just for ESET servers.

  2. Yes you are right, We saw firewall rules that block 445 in the infected servers !

    It seems that they enter the server using eternalBlue and then block 445 to avoiding others enter the server !

    We are working with ESET support to detect this WMIrun.a in memory sacanner.

    Right now no success.

    I am not sure that eset can detect WMIRun.A in memory. Are you agree with me ?

  3. Still KVRT can detect this type of infections But ESET cann't.

    Memory Scan log :

    Log
    Scan Log
    Version of virus signature database: 15549 (20170608)
    Date: 6/8/2017  Time: 3:03:34 AM
    Scanned disks, folders and files: Operating memory
    Operating memory » C:\Windows\System32\apisetschema.dll - is OK
    Operating memory » C:\Users\Administrator\Desktop\tools\Autoruns\autoruns.exe - is OK
    Operating memory » C:\Windows\System32\msyuv.dll - is OK
    Operating memory » C:\Windows\System32\userinit.exe - is OK
    Operating memory » C:\Windows\System32\WcsPlugInService.dll - is OK
    Operating memory » C:\Windows\SysWOW64\en-US\sechost.dll.mui - is OK
    Operating memory » C:\Windows\SysWOW64\en-US\shlwapi.dll.mui - is OK
    Operating memory » C:\Windows\SysWOW64\oleacc.dll - is OK
    Operating memory » C:\Windows\SysWOW64\ieframe.dll - is OK
    Operating memory » C:\Windows\SysWOW64\shdocvw.dll - is OK
    Operating memory » C:\Windows\SysWOW64\WindowsCodecs.dll - is OK
    Operating memory » C:\Windows\SysWOW64\propsys.dll - is OK
    Operating memory » C:\Windows\SysWOW64\xmllite.dll - is OK
    Operating memory » C:\Windows\SysWOW64\uxtheme.dll - is OK
    Operating memory » C:\Windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\comctl32.dll - is OK
    Operating memory » C:\Windows\SysWOW64\taskschd.dll - is OK
    Operating memory » C:\Windows\SysWOW64\ntdsapi.dll - is OK
    Operating memory » C:\Windows\SysWOW64\wbem\fastprox.dll - is OK
    Operating memory » C:\Windows\SysWOW64\wbem\wbemsvc.dll - is OK
    Operating memory » C:\Windows\SysWOW64\wbemcomn.dll - is OK
    Operating memory » C:\Windows\SysWOW64\wbem\wbemprox.dll - is OK
    Operating memory » C:\Windows\SysWOW64\rsaenh.dll - is OK
    Operating memory » C:\Windows\SysWOW64\cryptsp.dll - is OK
    Operating memory » C:\Windows\SysWOW64\RpcRtRemote.dll - is OK
    Operating memory » C:\Windows\SysWOW64\apphelp.dll - is OK
    Operating memory » C:\Windows\SysWOW64\ntmarta.dll - is OK
    Operating memory » C:\Windows\SysWOW64\version.dll - is OK
    Operating memory » C:\Windows\SysWOW64\profapi.dll - is OK
    Operating memory » C:\Windows\System32\wow64cpu.dll - is OK
    Operating memory » C:\Windows\System32\wow64win.dll - is OK
    Operating memory » C:\Windows\System32\wow64.dll - is OK
    Operating memory » C:\Windows\SysWOW64\cryptbase.dll - is OK
    Operating memory » C:\Windows\SysWOW64\sspicli.dll - is OK
    Operating memory » C:\Windows\SysWOW64\advapi32.dll - is OK
    Operating memory » C:\Windows\SysWOW64\sechost.dll - is OK
    Operating memory » C:\Windows\SysWOW64\msasn1.dll - is OK
    Operating memory » C:\Windows\SysWOW64\comdlg32.dll - is OK
    Operating memory » C:\Windows\SysWOW64\crypt32.dll - is OK
    Operating memory » C:\Windows\SysWOW64\KernelBase.dll - is OK
    Operating memory » C:\Windows\SysWOW64\wintrust.dll - is OK
    Operating memory » C:\Windows\SysWOW64\nsi.dll - is OK
    Operating memory » C:\Windows\SysWOW64\ws2_32.dll - is OK
    Operating memory » C:\Windows\SysWOW64\psapi.dll - is OK
    Operating memory » C:\Windows\SysWOW64\shlwapi.dll - is OK
    Operating memory » C:\Windows\SysWOW64\rpcrt4.dll - is OK
    Operating memory » C:\Windows\SysWOW64\user32.dll - is OK
    Operating memory » C:\Windows\SysWOW64\usp10.dll - is OK
    Operating memory » C:\Windows\SysWOW64\msvcrt.dll - is OK
    Operating memory » C:\Windows\SysWOW64\setupapi.dll - is OK
    Operating memory » C:\Windows\SysWOW64\gdi32.dll - is OK
    Operating memory » C:\Windows\SysWOW64\Wldap32.dll - is OK
    Operating memory » C:\Windows\SysWOW64\devobj.dll - is OK
    Operating memory » C:\Windows\SysWOW64\msctf.dll - is OK
    Operating memory » C:\Windows\SysWOW64\iertutil.dll - is OK
    Operating memory » C:\Windows\SysWOW64\cfgmgr32.dll - is OK
    Operating memory » C:\Windows\SysWOW64\kernel32.dll - is OK
    Operating memory » C:\Windows\SysWOW64\clbcatq.dll - is OK
    Operating memory » C:\Windows\SysWOW64\shell32.dll - is OK
    Operating memory » C:\Windows\SysWOW64\oleaut32.dll - is OK
    Operating memory » C:\Windows\SysWOW64\ole32.dll - is OK
    Operating memory » C:\Windows\SysWOW64\imm32.dll - is OK
    Operating memory » C:\Windows\System32\ntdll.dll - is OK
    Operating memory » C:\Windows\SysWOW64\lpk.dll - is OK
    Operating memory » C:\Windows\SysWOW64\ntdll.dll - is OK
    Number of scanned objects: 64
    Number of threats found: 0
    Time of completion: 3:03:37 AM  Total scanning time: 3 sec (00:00:03)

     

    KVRT scan result is attached .

    Any idea ?

    We must use manual cleaning in this kind of threats ?

     

    KDetection.jpg

  4. 20 hours ago, itman said:

    Interesting.

    For starters, did you create an Eset HIPS rule to monitor the startup of scrcons.exe as I posted previously?

    So that prior HIPS rule I posted which I since deleted should be modified for "Sources" - All Applications and "Targets" - C:\Windows\System32\wbem\scrcons.exe. This should detect any script startup from an WMI ActiveScriptEventConsumer event.

    This should have detected the startup of the malicious ActiveScriptEventConsumer event script. 

    Yes , Even We can block them by HIPS.

    This is the HIPS rules when Svchost.exe run scrcons.exe :

    Time;Application;Operation;Target;Action;Rule;Additional information
    6/7/2017 3:58:11 AM;C:\Windows\System32\svchost.exe;Start new application;C:\Windows\System32\wbem\scrcons.exe;blocked;Block Scrones;


    look at KVRT new detection for this type of threats ( Picture that is attached )

    KDetection.jpg

  5. Right now we find 6 new threats in this server that ESET lab detect them today :

    item.dat - Win32/Agent.WTF trojan
    Autorun_Script.txt - JS/Agent.NUN trojan
    Chr0me.exe - Win64/BitCoinMiner.AX application
    ms697A.exe - Win32/Agent.YWQ trojan
    mscorsvw_v3.0.0.6.1.exe - Win32/Agent.YWQ trojan
    regedit32.vbs - VBS/CoinMiner.DU trojan

     

    Autorun_Script.txt is containing the scrips in ActiveScriptEventConsumer.

    We will check the result in infected servers.

  6. No this threat is popular because we see this variant in many servers.

    Yes We can stop it with HIPS rules but we are working to help ESET to detect it.

    Right now no detection. Just When an EXE file is downloaded by Scrone.exe ESET will detect it. But we want to add this to memory detection , S.th like kaspersky.

  7. Today we find another server that is infected by WMI infections and ESET did not detect it. We are working on samples with ESET virus lab and ESET support to see how ESET will Detect and clean it.

    You can see the attached picture of this infections.

    This WMI insfections is called "Fish" that KVRT detect it as WMIRun.a

    If any one need samples i can share it via Private Messages.

     

    1.jpg

    2.jpg

     

    KDetection.jpg

  8. 17 hours ago, itman said:

    Please post back if the wmiprvse.exe detected your malware starting one of the reference script engines.

    As we said in previous post in this case we clean the infection by deleting  ActiveScriptEventConsumer  class using wbemtest.exe .

    But in these case we must customize because it will download threats by

    scrcons.exe

    or may be run windows script using that process.

     

    We will check them in next case that Happened .

     

  9. Yes as you mentioned Creating a WMI permanent event subscription requires administrative privileges on a system.

    But in these cases we don't know how it can inject WMI database because all ports is secure , WINDOWS was updated and patched and RDP , 1433 and ... are secured.

    in these cases, threat just try to download a file that ESET detect it and from these alert Administrators find that WMI is infected.

    We are working in this case and we will inform if repeated.

    The interesting think for us is how kaspersky can detect it as a memory infection and my question is " Can ESET detect such these WMI infection in memory and how can we send samples to ESET while no files are exist.

    And any idea about how these infections will enter the administrator in inject to WMI ?

     

  10. Hi dear ESET moderators.

    in these days we are facing a new threats family that use WMI and run under it's processes.

    as these infections is file-less we try to stop them by deleting  ActiveScriptEventConsumer  class , But ESET did not detect them in memory.

    We test Kaspersky Removal tools and it show that memory is infected with WMI infections and cure it.

    I want to know how can we collect and send these samples to ESET lab and will ESET detect these infections in memories ?

     

    We think that abusing WMI in these day may cause another ransomware to born.

     

     

  11. 34 minutes ago, MartinK said:

    I don't think this has been reported as a bug. To localize cause of this issue, please:

    1. check UTC time/date of your server machine as time of connection is reported as UTC time. Please check also date/timestamps in ERA trace log on server machine, whether they are correct.
    2. check local time & date of you browser (= machine where you are running browser with ERA Webconsole). As all times are stored internaly in UTC format, they are automatically re-calculated to local time reported by browser (this behavioir may be slightly modified in User Settings).

    We check these all and all were correct but the problem is not 12H or 1 day , it is about 3 months difference !!! 

    And not 3 month ago ! 3 month later , Also ERA did not show any error that it seems it did not feel any problems, just last connected date is 3 month later. in one case it was AUG 2017.

    Right now upgrading to v6.5 solved the problem.

  12. Hi dears,

    In these days we have problems with ERA 6.4 and we must upgrade all our customers to 6.5 and in most cases it will be fixed.

    In ERA console 6.4 last connected date in incorrect while every thing is OK , Agent is connecting , Policies will apply , Even last connected time is updated but with wrong date ( about 3 month difference ) For example right now it show that last connect time is in 2017 Aug !!!

    Server And Client time is right .

    is it a Bug in 6.4 ?

×
×
  • Create New...