Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question regarding EventData attribute names clashing Output Runtimes #4956

Open
nflexfo opened this issue Mar 4, 2025 · 0 comments
Open

Comments

@nflexfo
Copy link
Contributor

nflexfo commented Mar 4, 2025

Hi,

While reviewing the new data types introduced in version 20240826, I've noticed that some of them had attributes names that might clash with output runtime fields. For instance, teamviewer:connections_incoming:entry re-defines display_name, or cri:container:log:entry re-defines tag.

Based on the documentation, I expect this field to be a "Human readable representation of the path specification". It is true for almost any data type but a few (see below). In this particular case, the pydoc says "The display name of the incoming connection source. Usually the computer name or the TeamViewer user name.".

During investigation, it is common to rely on this field to retrieve the original artifact path and starts searching from here. Now, since the parser overwrite it with something else, we need to find another way to get the same information. This issue actually strikes me back some years ago with windows:registry:usbstor:instance but then I forgot about it.

Curious about what other clashes might exist, I've wrote this small scripts.

Here is the result of output runtime fields to data type being clashed:

{
    "description": [
        "android:twitter:contact",
        "av:symantec:scanlog",
        "ios:twitter:contact",
        "mackeeper:cache",
        "macos:startup_item:entry",
        "opera:history:entry",
        "windows:lnk:link",
        "windows:pca_log:entry",
        "windows:registry:network",
        "windows:restore_point:info",
        "windows:timeline:generic"
    ],
    "display_name": [
        "fs:stat",
        "fs:stat:ntfs",
        "skype:event:account",
        "spotlight_searched_terms:entry",
        "teamviewer:connections_incoming:entry",
        "windows:registry:usbstor:instance"
    ],
    "filename": [
        "av:defender:detection_history",
        "av:mcafee:accessprotectionlog",
        "av:trendmicro:scan",
        "fs:bodyfile:entry",
        "fs:ntfs:usn_change",
        "fs:stat",
        "fs:stat:ntfs",
        "gcp:log:entry",
        "kodi:videos:viewing",
        "networkminer:fileinfos:file",
        "viminfo:history"
    ],
    "host": [
        "android:webview:cookie",
        "azure:application_gateway_access:entry",
        "chrome:cookie:entry",
        "firefox:cookie:entry",
        "firefox:places:bookmark",
        "firefox:places:page_visited",
        "safari:history:visit_sqlite"
    ],
    "hostname": [
        "linux:utmp:event",
        "macos:utmpx:entry",
        "olecf:dest_list:entry",
        "syslog:cron:task_run",
        "syslog:line",
        "syslog:ssh:failed_connection",
        "syslog:ssh:login",
        "syslog:ssh:opened_connection",
        "systemd:journal",
        "windows:user_access_logging:dns"
    ],
    "inode": [
        "fs:bodyfile:entry",
        "fs:stat"
    ],
    "message": [
        "android:logcat",
        "chrome:preferences:extensions_autoupdater",
        "gcp:log:entry",
        "google_drive_sync_log:entry",
        "googlelog:log",
        "macos:asl:entry",
        "macos:securityd_log:entry",
        "snort:fastlog:alert"
    ],
    "source": [
        "skype:event:transferfile"
    ],
    "tag": [
        "cri:container:log:entry"
    ],
    "time": [
        "av:symantec:scanlog"
    ],
    "type": [
        "firefox:downloads:download",
        "firefox:places:bookmark",
        "linux:utmp:event",
        "macos:utmpx:entry",
        "windows:registry:mount_points2"
    ],
    "user": [
        "av:symantec:scanlog",
        "cups:ipp:event",
        "gcp:log:entry",
        "postgresql:application_log:entry",
        "santa:execution",
        "santa:file_system_event"
    ],
    "username": [
        "android:twitter:contact",
        "android:twitter:status",
        "av:mcafee:accessprotectionlog",
        "ios:kik:messaging",
        "linux:utmp:event",
        "macos:user:entry",
        "macos:utmpx:entry",
        "pls_recall:entry",
        "powershell:transcript_log:entry",
        "skype:event:account",
        "syslog:cron:task_run",
        "syslog:line",
        "syslog:ssh:failed_connection",
        "syslog:ssh:login",
        "syslog:ssh:opened_connection",
        "windows:registry:mstsc:connection",
        "windows:registry:sam_users",
        "windows:tasks:job",
        "windows:tasks:trigger"
    ]
}

If you prefer a data type to runtime type view, here it is. Note that most of those clashes come from the "Dynamic Runtime Fields" which is what I'm stuck with for now (will transition to json eventually).

In some cases, it totally makes sense. For instance inode in fs:stat. On the other hand, it is more questionable like display_name, tag, type, user or username.

What's your though about it? Is "reserved attribute names" a thing in Plaso? Should we expect field to have a consistent meaning across several data types? At least, those defines by output runtime. Or is it an overlook that should be addressed?

Thanks,

Nicolas.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant