[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-cybox] CybOX 3.0: File Object Refactoring
There are all kinds of masquerading CTI use cases from weaponization, to exploit delivery, to exfiltration. These can be analytic artifacts as well as actionable IOCs. The only argument I'm making is that we ensure we have the ability to fully and unambiguously
describe non-sequiturs as such.
One of the interesting challenges is conveying to engineers that people are intentionally breaking the rules (my first experience was "bad guys/gals" that intentionally violated 10Mbs Ethernet's 9.6 microsecond inter-frame gap to create an undetectable
Layer 1/2 covert channel. (For those keeping score on the timestamp precision discourse: that's .96 nanoseconds for 100Gbs Ethernet ;-). https://en.m.wikipedia.org/wiki/Interpacket_gap
Patrick Maroney
I think “is_packed” will likely be included in the next release, perhaps as part of the metadata extension.
I’m on the fence as far as explicitly capturing that a file is masqueraded – as John pointed out below, this can already be done implicitly by capturing the file name/extension and MIME type. If the two do not match, then it is likely a case of masquerading.
I know that we have this property in the existing File Object, but I’ve always considered it a product of analysis rather than pure observation. IMO, we should leave analytical findings to other places where they make more sense (probably STIX), and leave
CybOX to “just the facts”.
Regards,
Ivan
From: John Wunder <jwunder@mitre.org>
Date: Tuesday, December 15, 2015 at 9:48 AM To: Jerome Athias <athiasjerome@gmail.com> Cc: Patrick Maroney <Pmaroney@specere.org>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>, Sean Barnum <sbarnum@mitre.org>, Ivan Kirillov <ikirillov@mitre.org>, John Anderson <janderson@soltra.com>, Paul Patrick <ppatrick@isightpartners.com>, Bret Jordan <bret.jordan@bluecoat.com>, "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>, Terry MacDonald <terry@soltra.com> Subject: Re: [cti-cybox] CybOX 3.0: File Object Refactoring Yep, that’s one mechanism. Are there others?
I’m just suggesting that we should be precise and encode these specific mechanisms rather than some generic field. In the case of a mis-named file, I think we’re all set (the content type will not match the extension in the file name) so maybe there’s
nothing to add.
From: Jerome Athias <athiasjerome@gmail.com>
Date: Tuesday, December 15, 2015 at 11:44 AM To: "Wunder, John A." <jwunder@mitre.org> Cc: Patrick Maroney <Pmaroney@specere.org>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>, Sean Barnum <sbarnum@mitre.org>, Ivan Kirillov <ikirillov@mitre.org>, John Anderson <janderson@soltra.com>, Paul Patrick <ppatrick@isightpartners.com>, "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>, Terry MacDonald <terry@soltra.com> Subject: Re: [cti-cybox] CybOX 3.0: File Object Refactoring e.g. (maybe not applicable use case):
I am uploading a nicepic.jpg file to a website via an upload form accepting only the extension .jpg
But, I renamed webshell.php to picture.jpg just before uploading
My .php pretended to be a .jpg
2015-12-15 19:41 GMT+03:00 Wunder, John A.
<jwunder@mitre.org>:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]