[Watson1978]

parse_desc builds record keys out of the event Description, which carries text the reporting process controls: PowerShell script blocks, process command lines, service paths.
Those keys land in the same hash as the event's own metadata, so a description holding the right delimiters could replace fields the collector filled in or overwrite a field parsed from an earlier group, and separately a field whose value was empty got mistaken for a group heading and re-rooted every key after it.
This refuses KEY_MAP names, keeps the first value when a key repeats, and makes previous_key track the key actually written, so continuation lines land where they belong; with the default downcase_description_keys nothing changes for well-formed descriptions, since KEY_MAP names are CamelCase while parsed keys are downcased.

[kenhys]

Channel might be spoofed:

desc = [
      "Creating Scriptblock text (1 of 1):",
      "",
      "Channel:",
      "\t\t\tspoofed",
    ].join("\r\n")

h = {"Channel" => "Microsoft-Windows-PowerShell/Operational",
     "Description" => desc
    }

[Watson1978]

Good catch, thanks.
Reproduced with downcase_description_keys false the continuation line lands on Channel and turns it into ["Microsoft-Windows-PowerShell/Operational", "spoofed"].

[kenhys]

desc = [
  "A service was installed in the system.",
  "",
  "Subject:",
  "\t",
  "\tLogon ID:\t\t0x3E7",
].join("\r\n")
h = {"Channel" => "Microsoft-Windows-PowerShell/Operational",
     "Description" => desc
    }
parse_desc(h)
pp h
{"Channel" => "Microsoft-Windows-PowerShell/Operational",
 "DescriptionTitle" => "A service was installed in the system.",
 ".Logon_ID" => "0x3E7"}

Does it intended?

[Watson1978]

Fixed.

Not intended, thanks for digging. That one predates this PR: master produces .Logon_ID for your input too

[Watson1978]

Thanks