Security Anomaly: Active Evolution API Session with No Entry in login.log

[ViAdCk]

Hi everyone,

I am investigating a security incident on a Shared Hosting server (CloudLinux + DirectAdmin Evolution Skin) where a user's web content was deleted. During the audit, I found a major discrepancy between access.log and login.log that I cannot explain and would like to see if this is a known behavior or a potential security gap.

The Situation:

• Unauthorized Activity: A specific IP (referred to as [INTRUDER_IP]) was active for over 7 hours during the incident window.
• The Logs: The access.log is filled with thousands of entries showing this IP interacting with the File Manager and Session profiles for a specific User account ([TARGET_USER]).
• Example Log Entry:2026-02-07T20:08:07 ... [INTRUDER_IP] ... GET /api/session/state ... [TARGET_USER] session-native -
• The Anomaly: Despite the constant activity, there is zero record of [INTRUDER_IP] in login.log for over a year—neither for the [TARGET_USER] nor for their parent [RESELLER] account.

Technical Context:

• Skin: Evolution (JSON API based).
• Persistence: The intruder was polling /api/session/state every 20-30 seconds.
• No Login Keys: I confirmed that no Login Keys were active for this user during this period.
• Account Hierarchy: The target user is owned by a Reseller account.

Questions for the Community:

1. Login-As Logging: If a Reseller uses the "Login as User" feature, is the authentication event only logged for the Reseller's initial login? If the User session is later accessed from a different IP (via session hijacking or a persistent tab), does DirectAdmin record the new IP in login.log?
2. Session Resumption: How does the Evolution API handle session persistence? Is it possible for a session to remain valid for months without re-authentication if it is kept alive by a script or an open browser tab?
3. Log Bypass: Is there any scenario where session-native API calls can bypass the standard authentication logging in login.log?

I am trying to determine if this is a case of session hijacking or if the "Login-as" feature effectively masks the secondary IP from the authentication logs.

Any insights into how DA handles session persistence and IP changes for active API sessions would be greatly appreciated.

 

[zEitEr]

Hello,

I believe there used to a security feature which controlled changing of IP and port within a single session. If IP changed, then a session got dropped. I did not find such an option in the current Directadmin version. And now the session keeps active even if the user's IP changes. Thus a reseller can connect with one IP and then change it and proceed working in DirectAdmin under another IP.

But when a reseller or admin uses a connect-as function, then this action is logged in /var/log/directadmin/login.log:

2026:02:09-00:15:53: '195.bb.cc.dd' successful login to 'admin'
2026:02:09-00:16:25: '178.bb.cc.dd' successful login to 'userbob' via 'admin'

There is a Session Timeout. It is an amount of time the user will stay logged in if no requests are being sent to the server. After this time, the user will get automatically logged out.

Potentially a session might keep active for a long time if at least one request is done to the directadmin within time less than a Session Timeout.

 

[ViAdCk]

Thanks for your reply. The thing is that this intruder IP is from a hosting provider, not a normal isp. It doesn't really seam plausible that there was an ip change during the session.

For some reason I don't understand this IP appears all over the access.log but has no appearance in the login.log

 

[zEitEr]

Logins via login-keys and API are also logged:

2026:02:08-19:08:00: '195.bb.cc.dd' successful login to 'admin'

check /var/log/directadmin/access.log for more details.

 

[ViAdCk]

I'm sorry but I don't understand your answer.

This intruder ip has hundreds of lines in the access.log, but not in any other directadmin log. It should be logged in the login.log as all other users that access directadmin but in this case, there are no entries regarding this IP.