Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Posts posted by pronto

  1. 16 minutes ago, Marcos said:

    Please check https://support.eset.com/en/kb141 for instructions how to submit undetected spam.

    Additionally you can send the emails in the eml or msg format to me as well.

    I attached a Zip-File with some sample emails. There is now only one email with an invitation but a few others that somehow have to do with it, because the name of the sender is the same everywhere. The password for the zip file is infected. I'm still sending the files following the instructions you posted above.

    Thanks for your attention


  2. Servus Community,

    we currently receive very frequent e-mails with calendar invitations, which are not recognized as spam. Since the sender address is different, it is difficult for me to create a filter for it myself. Can I send a few of these emails to samples[at]eset.com with a request to review them for inclusion in a spam pattern or is this email address only for malware? Is there another way to send an email to Eset for review?

    Thx & Bye Tom


  3. I am not sure if this is the right place. It reads that way but as soon as I edit this notification it ends up asking me if I want an email, use a syslog server or send an SNMP trap. Actually, none of them. I was only referring to the colored background in the 'Last Connected' column in the Protect console and that doesn't seem to be what I'm looking for. But it would be close....

    Thx & Bye Tom


  4. Servus Community,

    is it possible to change the time period for triggering a warning of the last connection date? We have it set to around three to four days, which causes quite a number of warning messages, especially after the weekend. Since we have quite a few part-time employees, the majority of the computers are constantly displayed with a warning. To me, one week as a warning and four weeks as an error would be more suitable. I have not found a corresponding setting in the policy. Can someone tell me where to set this?

    Thx & Bye Tom

  5. Servus Marcos,

    I already don't have half of the paths on my system that were excluded in the other thread. I could only add the /System/Application path. But I noticed something else, I wrote the path to the Time Machine volume with a wildcard character but I didn't define any files with it ( -> /Volumes/Time* ) I have now rewritten the path as shown in the screenshot. Probably that alone was the reason.

    If this works will take a while to find out, the detections came very irregularly. i'll watch this now for a few days and then give feedback at the end of the week.

    Thx & Bye Tom


  6. Servus Community,

    I created a path exclusion for the volume belonging to the local Time Machine backup but I get many of detections on this volume on my personal Mac (10.15). ESET is apparently unable to delete the files it finds, which is why it repeatedly issues a plenty of Popus warnings at irregular intervals. I created the exclusion with a wildcard character (/Volumes/Time*) but according to the manual this should work. Can anyone see an error in the configuration?

    Thx in advance & Bye Tom

    Bildschirmfoto 2021-04-16 um 12.01.35.png

    Bildschirmfoto 2021-04-16 um 12.00.11.png

    Bildschirmfoto 2021-04-16 um 11.59.57.png

  7. Hi Marcos,

    the audit log says that the task was modified on 26.03 in the afternoon. On this day we have reinstalled our two Exchange servers with a service provider. Afterwards, we could not activate the two mail security instances, but this was simply due to the fact that the mail security license was not checked in the activation task. Probably the task was modified by mistake while searching for the problem. When installing system updates, the server was restarted and the problem took its course...

    Thx & Bye Tom

  8. I have now contacted the ESET hotline about this issue. The reason for the disappearance of the clients was an unplanned execution of the Static Group Synchronization server task. This task moved all AD clients into the AD Organisation Unit folder structure. Why this task was executed is unclear. I then had to manually move the clients back into the groups created for them, now hopefully everything is back in the place where it is supposed to be.

    Summary: In principle no software error, so also magically no fix available.

    Thx & Bye Tom

  9. Hi Community,

    today all the static groups we created are suddenly empty. Except for two groups, the Apple macOS devices are apparently still there and two Windows devices are still there but all others are not displayed in the ESET Protect console. I still see all computers in the dynamic group where all machines are and when I look at the properties of my workstation for example, none of our policies are applied.

    What happened?

    Thx & Bye Tom

  10. 2 hours ago, Nightowl said:

    I wonder what Microsoft was doing all the time since January when the exploit was first reported , do they wait till all the world start exploiting and stealing data so they will start reacting ? Or is it part of the idea to let them do so ?

    In my opinion, they tried to attach importance to their cloud products, but probably underestimated the dynamics of the situation. It seems like they have lost control in the meantime. With the implementation of Windows 10 and their Windows as a Service update strategy, one update after another is blowing up. Either they came too early or too late. The customer has not been the king anymore, rather they are being forced towards in the direction where Microsoft wants them to go.  The other global players like Apple and Google are no exception. If Google decides that any standard is no longer useful, a new standard will be introduced and the world will have to follow. You just stand by shaking your head and get the feeling that they're making fun of it, also. Sorry but I had to vent a bit...

    Bye Tom


  11. On 3/13/2021 at 5:06 PM, schuetzdentalCB said:

    @pronto only thing i can tell you is that the file:

    06.03.2021  03:37            92.032 owaauth.dll

    hasn't been changed (in my environment) since initial exchange installation. but yours did. maybe you check that file and also run this scan which is quite good:


    This is a pretty good tool, easy to use and each warning is commented with a link to an explanation. Really very good. I'm thinking about adding something like this to our general monitoring. 

    Only the attacked server had anomalies, but those were the things we already knew. One issue with a compromised web.conf.bak is still open but there I remember darkly that I once created a backup of the file before I made changes to it. The file extension bak is typical for me. After that the exchange server will not have been interested in this file anymore and after a few updates the content does not match the running config. This is my personal explanation for this. All other tested servers like the other Exchange and the two domain controllers were completely unsuspicious in the analysis. According to this, we could have been really lucky.

    Is there something similar that looks for potential vulnerabilities without any attempt to use them?

    Thanks again for the suggestion. I don't know where I ended up when I looked at it. I found something similar but it requires having sensors or agents installed on each machine to detect the lateral movements of the intruders. That would only made sense if I already had that set it up beforehand. Therefore I discarded it.

    Thx & Bye Tom

  12. 5 hours ago, itman said:

    You might try the Thor-Light product noted previously with link provided. It does include a YARA Win log component noted here:  https://github.com/Neo23x0/signature-base/blob/master/yara/apt_hafnium_log_sigs.yar

    Hm, I thought I followed the link but the site looks quite different from the ones I remember. Somewhere I took apparently a wrong turn. Thanks for bringing this up again, I'll take a closer look tomorrow.

    Thx & Bye Tom

  13. 6 hours ago, Marcos said:

    Was ESET installed on the mail server? Wasn't the malware detected?

    ESET Mail Security is installed on our Exchange servers and we found evidence of two backdoors. On 10.03, we ran Microsoft's detection tool with a service provider and found evidence of an infection. The service provider had already opened the directory where the backdoor was installed and we could see the file. We then scanned the system with Windows Defender and exact at that point, ESET's real-time protection jumped in and detected and removed the file. Not a good sign, the file had a timestamp of 05.03. There was a second incident on 06.03 according to ESET, though here the file was detected by ESET and removed as soon as it was created.

    The first file on 05.03 was not detected as malware by ESET, that's the bad news but depending on receiving the detection pattern it could also mean that the backdoor was not used either. At least not after ESET integrated this threat into an antivirus pattern. Probably between 05.03 and 06.03 ESET has configured the antivirus pattern to the threat. If the backdoor was not used immediately, it could be that it was not used at all. In that case, we might have been lucky.

    Do you know when exactly the pattern for this threat was released and what version number it had? Do you have any information on how the intruders proceeded after installing the backdoor in the wild? We are not a top target for the intruders, we think that we are a victim of the mass infection.

    We have now installed ESET File Security on all servers in the domain, including those that are not connected to the Internet, and enabled Live Grid and HIPS on all of them to have as many sensors as possible that could report anomalies, and hopefully we are better protected against possible post exploit attacks. Tomorrow we will start installing Sysmon on the servers and hope to get more data about unusual activity. A little bit late but we can't be more in the dust than we are now.

    Thx & Bye Tom

    Bildschirmfoto 2021-03-14 um 23.32.04.png

    Bildschirmfoto 2021-03-14 um 23.31.03.png

  14. 8 hours ago, itman said:

    I  will also add that attackers targeting owaauth.dll is not unique to this current Exchange vulnerability:


    Thanks for the list of patched files and the further information. My learning curve has increased rapidly over the last few days. I could have come up with the idea of looking at the file properties in the GUI earlier. Sorry for that but having the list is more valuable.

    The files have a valid signature and e.g. the owaauth.dll is also shown in the list with the exact size in bytes and version number, only the timestamp is exactly 8 hours before ours, which is probably due to the time zones.

    Tommorow I compare the other files but that helps to fall asleep.

    @schuetzdentalCB  Have you not patched your server? You should see a similar result.

    Thx & Bye Tom


  15. Servus Community,

    I am investigating the post exploit activity of the Hafnium attack and have come across several DDLs that have a creation date a few hours after the installation of the backdoor (05/06.03.21).

    I uploaded some of these DDLs to Virustotal and they were found to be unsuspicious. However, the temporal context makes me wonder. The creation date is (a few days) before the time when ESET detected and removed the backdoor. However, a manual scan of the files with ESET Mail Security, is also unsuspicious.

    Can anyone compare these files on their system?

    C:\Windows\system32>cd C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa\auth
    C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa\auth>dir
     Volume in Laufwerk C: hat keine Bezeichnung.
     Volumeseriennummer: ACE3-7FD2
     Verzeichnis von C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa\auth
    10.03.2021  12:12    <DIR>          .
    10.03.2021  12:12    <DIR>          ..
    16.08.2018  16:53             8.398 error.aspx
    22.02.2019  02:28             1.856 error2.aspx
    22.02.2019  04:16             7.239 expiredpassword.aspx
    06.03.2021  03:37            83.328 exppw.dll
    16.08.2018  16:53             6.104 logoff.aspx
    06.03.2021  03:37            92.032 owaauth.dll
    16.08.2018  16:53             1.106 signout.aspx
                   7 Datei(en),        200.063 Bytes
                   2 Verzeichnis(se), 148.422.361.088 Bytes frei
    C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa\auth>cd ..\bin
    C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa\Bin>dir *.dll
     Volume in Laufwerk C: hat keine Bezeichnung.
     Volumeseriennummer: ACE3-7FD2
     Verzeichnis von C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa\Bin
    20.08.2019  23:03           346.848 Microsoft.AspNet.SignalR.Core.dll
    20.08.2019  23:03            23.264 Microsoft.AspNet.SignalR.SystemWeb.dll
    06.03.2021  03:37            83.832 Microsoft.Exchange.Clients.EventLogs.dll
    06.03.2021  03:38         2.970.520 Microsoft.Exchange.Clients.Owa.dll
    06.03.2021  03:37         5.029.248 Microsoft.Exchange.Clients.Owa2.Server.dll
    06.03.2021  03:37           924.544 Microsoft.Exchange.Clients.Strings.dll
    06.03.2021  03:37            45.952 Microsoft.Exchange.InstantMessaging.dll
    06.03.2021  03:37            77.208 Microsoft.Exchange.WopiClient.dll
    01.05.2018  16:36           101.032 Microsoft.Owin.dll
    01.05.2018  16:36           133.288 Microsoft.Owin.Host.SystemWeb.dll
    01.05.2018  16:36            53.416 Microsoft.Owin.Security.dll
    01.05.2018  16:36             4.608 Owin.dll
                  12 Datei(en),      9.793.760 Bytes
                   0 Verzeichnis(se), 148.435.795.968 Bytes frei
    C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa\Bin>

    Thx in advance & Bye Tom

  16. Hi Guys,

    well, the upgrade process was really straight forward. The web console took a little longer, I could still log in to the old one, which generated some error messages, but after a few minutes that was done also.

    Upgrading the agents also went through without a problem on about 25 clients in an evaluation group (Windows 10 and Mac OSX). The Anti Virus application on Windows (EEA) was also updated to version 8 without any problems in this group.

    That the EEA application on Mac is still on version 6.x is intended?

    Summary: As far as I can see, everything seems to work without problems.

    Thx & Bye Tom

  17. Servus Community,

    I'm lost in the jungle of the thousands of different modules which ESET offers. I'm doing some updates of the ESET infrastructure, including the server components and thought that I've running the latest version of ESMC. I took the version from the the help menu in the about section. There is a version 7.2.1278.0 shown. But when I compare this with the website of ESET where the current releases are listet, the current version of ESMC there is I'm confused.

    My question is, if I'm lokking on the wrong place to determine the current running version or is the ESET website outdated?

    Thanks in advance & Bye Tom

    Bildschirmfoto 2021-03-01 um 13.07.18.png

    Bildschirmfoto 2021-03-01 um 13.02.22.png

  18. Servus Community,

    I created a new client task today to update the ESET product and it ran correctly on 12 test machines, but not on two. The task terminated there with the error:

    Repository package checksum verification failed

    While searching for the cause I came across several post that specified a different update source in the task. I tried that as well and the task terminated successfully on the other two machines as well.

    In the process I noticed that a latest version is specified in the URL[1]. My question would be, is this URL permanent? So I wouldn't have to create a new task for every version I want to upgrade to, but could simply configure a task with Upgrade to latest and run it over and over again. If that then makes sense in the long run in the history of updates as well.

    Another question follows, is there somewhere a list of all these URLs? When I only modify the URL to enter an above located folder, I get an 404 error.

    [1] https://download.eset.com/com/eset/apps/business/eea/windows/latest/eea_nt64.msi

    Thx & Bye Tom

  19. Servus Community,

    I am trying to determine the mail flow in our Exchange 2016 infrastructure. I have found a flowchart from both Microsoft and ESET, but I can't get the two together. The transport agents are resolved on the Exchange Server as follows:

    [PS] C:\Windows\system32>Get-TransportAgent
    Identity                                           Enabled         Priority
    --------                                           -------         --------
    ESET Filtering Agent                               True            1
    ESET Filtering AV Agent                            True            2
    Transport Rule Agent                               True            3
    DLP Policy Agent                                   True            4
    Retention Policy Agent                             True            5
    Supervisory Review Agent                           True            6
    Malware Agent                                      True            7
    Text Messaging Routing Agent                       True            8
    Text Messaging Delivery Agent                      True            9
    System Probe Drop Smtp Agent                       True            10
    System Probe Drop Routing Agent                    True            11

    Exchange Server also has a number of filters that are processed in a different order and logged in different log files. I would like to find out which logfiles are written before the ESET filter? Regardless of what happens to a mail afterwards.

    Thx in advance & Bye Tom

    Bildschirmfoto 2020-11-30 um 15.51.34.png

    Bildschirmfoto 2020-11-26 um 11.16.28.png

  • Create New...