Login Failures

Good morning,
I am extending and splitting on Debbie’s post: Where do I find Web Browser Logon Failures - not seeing them on Ice.SysActivityLog - Kinetic ERP - Epicor User Help Forum (epiusers.help)

When I opened my pilot DB to try to answer her question, I found a lot of usernames and passwords listed in the SysActivityLog table. I assume someone accidentally typed their passwords into the username field. I had not reviewed the records in this table before. Now I am worried about what is stored.

I would like to notify my users about these saved values so that they can update their passwords. Most of them are old records from years ago, so are not likely relevant. However some are from more recently. I see at least a few user names in there that are not users on my system. Should I worry about these invalid login attempts? Is there anything else I can do to look into or mitigate this? Is there any way to tell if these invalid login attempts are coming from outside the company?

What do you all do with your SysActivityLog data?
Thanks!
Nate

1 Like

Nate - We use the “Logon Failure Audit Report” on a monthly basis as an IT Audit. This report uses data from the Ice.SysActivityLog table. We are looking for any strange logon attempts that might indicate someone outside our company is trying to log in. We do see logon failures from time to time that appear a user used their password as the user name.

The last couple of months we have noticed one user id that had multiple entries in the Ice.SysActivityLog table that were seconds apart. This morning while trying figure out why we were seeing the multiple entries I discovered the logon failures from the browser were not showing up in the table.

I have since run across a problem PRB0217634 that addresses the multiple entries. Epicor development has accepted this problem but it isn’t planned yet.

3 Likes

I see this same thing. I know there is no way my user was logging in and failing that many times. I also know that users get locked out after too many failed login attempts. Could this be evidence of a hacker trying to login and spacing their attempts by a minute to avoid the lockout policy? What if the presumed hacker trying to login with the username somehow gets the password right? I don’t think we would know.

Further research shows the login attempts separated by exactly 30 seconds. For example here is a snapshot:

5/31/2024 8:35:06 AM
5/31/2024 8:35:37 AM
5/31/2024 8:36:07 AM
5/31/2024 8:36:37 AM
5/31/2024 8:37:07 AM
5/31/2024 8:37:37 AM
5/31/2024 8:38:07 AM
5/31/2024 8:38:37 AM
5/31/2024 8:39:07 AM
5/31/2024 8:39:37 AM
5/31/2024 8:40:08 AM
5/31/2024 8:40:38 AM
:thinking:

It also looks like the time reported in the LogonFailureAudit Log is not the same timezone. There is a +5hr difference in the time between the time on the generated report, and the time on the record in the table.

1 Like

I don’t believe the multiples are a sign of a hacker as in our scenarios the user id with the multiples was one I was using for testing and I did in fact get a logon failure that day and approx time. From what I recall I only got one and can’t explain the multiples other than there is an existing problem PRB0217634 for the multiples.

The time on the table is in UTC so would be +5 from EST or +4 from EDT. I did calculated fields in my BAQ to show the time in EST & EDT.

1 Like

Yeah, it’s not great. I don’t ever want to know my user’s passwords. The part I like less is, our SysActivityLog returns records going back nearly four years before we signed with Epicor.

I’ve seen that before. Desktop client sessions can go a little bonkers sometimes. The first one I saw was left open over a server side SaaS update that didn’t boot active users, resulting in the desktop session endlessly pinging for authentication. That client session still mostly worked somehow! Identify the session, close it on the client machine, and check session management to verify that both ends are dead.

The lockout policy should nix naive brute force attempts. It’s more like fail2ban than security, it cuts down the noise and redirects real problems to someone who can help. In regards to the lockout process I worry more about vandalism, like locking out a well known canned admin account with wrong guesses for lulz.

1 Like

Back when we were on MT we would see other peoples reports or BAQ’s occasionally, was always creepy.

1 Like

I have not worked with session management much. How do I do this in Session Management? It looks read only to me, with no actions menu.

I also see all of our users, some consuming a license and some not. I also see our three data collection users. However, only two of them are set with the session type as DataCollection. One of them is set to DefaultUser. Does this matter, and should I fix it?

Those are license types. DefaultUser is the big expensive license, DataCollection is MES users. The license type is selected from your login method and license tracking never checks in again. If one of your data collection users is consuming a DefaultUser license, check their login process, I’d bet they’re launching Epicor-proper instead of MES.

Highlight a row, press delete on the keyboard. Maybe your session, unless you have a coworker in mind…

1 Like

I just checked the PC and it is running MES Menu. I killed the session and relogged in. All looks good now! Thank you!

As an update I have support looking into the login errors.

Support didn’t give me any comfort. They merely started a new task/problem (TASK7333949).
They couldn’t/wouldn’t say if the failed login attempts were due to an epicor process or legitimate attempts.

The task talks about duplication of failed login attempts. Like I said to the support rep, I don’t care that they are duplicated. That is not the point of my support ticket. But I am glad that I pointed out an issue for you all to fix. I wish they would just read the ticket and answer my questions!

1 Like