Host-based anomaly detection event (rootcheck)

[redparham]

I get these alerts periodically. There's very little guidance in the docs or forum on what to do to investigate and conclude whether the alert is a false positive.

What's an ossec user to do?

I have posted to the forum and received no response... Could someone knowledgeable add to the docs the steps to follow to make a decision about whether a system is compromised? Or is there a way for ossec to capture more about the process when it's encountered to make a compromise determination easier?

Thank you.

{
    "rule": {
        "level": 7,
        "comment": "Host-based anomaly detection event (rootcheck).",
        "sidid": 510
    },
    "location": "(i-0747b50906723111c) any->rootcheck",
    "full_log": "Process '29317' hidden from /proc. Possible kernel level rootkit."
}

[ddpbsd]

What information do you want captured? I haven't looked at the code, but I think it just goes through a ps type output, and compares the pids to what is in /proc. So there are races inherent in the process.

As for writing up a triage guide for system compromises, I don't know if I could make a "one size fits all" sort of document. At least not with the time and electrons available to me.

[redparham]

@ddpbsd

What information do you want captured?

I guess capturing ps with "-f" output would be helpful (if that's too much, the User ID, PPID, Command fields).

As for writing up a triage guide for system compromises, I don't know if I could make a "one size fits all" sort of document. At least not with the time and electrons available to me.

Understood. If it were possible to capture more process details as mentioned above, then I suppose it makes it possible for folks to figure out where to go next for themselves.

Without any improvements, this alert just becomes noise that cannot be acted upon... thanks.

[pdxdoughnut]

Almost every check in rootcheck ignores the possibility of a race condition. This code hasn't been touched (except for formatting) in 11 years. It really needs an update to check for race conditions so that we don't all just assume everything coming out of it is garbage.

For example, in check_rc_pids:

        } else if (_proc_read != _proc_stat  ||
                   _proc_read != _proc_chdir ||
                   _proc_stat != _kill1) {
            /* Check if the pid is a thread (not showing in /proc */
            if (!noproc && !check_rc_readproc((int)i)) {
                char op_msg[OS_SIZE_1024 + 1];

                snprintf(op_msg, OS_SIZE_1024, "Process '%d' hidden from "
                         "/proc. Possible kernel level rootkit.", (int)i);
                notify_rk(ALERT_ROOTKIT_FOUND, op_msg);
                (*_errors)++;
            }

In this block, _proc_read and/or _proc_stat should be verified.

In check_rc_sys.c:

    if (lstat(file_name, &statbuf) < 0) {
#ifndef WIN32
        char op_msg[OS_SIZE_1024 + 1];
        snprintf(op_msg, OS_SIZE_1024, "Anomaly detected in file '%s'. "
                 "Hidden from stats, but showing up on readdir. "
                 "Possible kernel level rootkit.",
                 file_name);
        notify_rk(ALERT_ROOTKIT_FOUND, op_msg);
        _sys_errors++;
#endif
        return (-1);
    }

The "file_name" might actually have been removed during that time for good reason. This often happens with temp files that programs can put anywhere they have access.

[ddpbsd]

@pdxdoughnut Yep, that would be great.

[pdxdoughnut]

@ddpbsd I'm not sure if you're blowing us off or what you mean by this?

@pdxdoughnut Yep, that would be great.

If I were a decent C programmer I'd have submitted a patch, but I can really only read it.

[ddpbsd]

I'm not blowing anybody off, but my free time is much too limited to work on everything that needs to be done (and have time for family and an actual job as well).

[imran210-khan]

Has there been any update on this issue. As we are also facing the same noise from this rule id. Thnx

[Nono-m0le]

I'm really interested about this topic (and also, do not have the knowledge to push any modification/patch in my own), but on my case for the rootcheck 'link count does not match' issue: Rule: 510 (level 7) -> 'Host-based anomaly detection event (rootcheck).' Files hidden inside directory '/tmp'. Link count does not match number of files (72000,1).

Understanding there will be no patch in the recent future, is there a way to manually check what happens and if it could be a false positive ?