Subject: [Model-t] Details on the Malware Lifecycle Model

From: Joachim Fabini <[email-masked]>
Date: Fri, 22 Nov 2019 12:16:58 +0800

Hi all,

some context on this email: at IETF104 in Prague I talked briefly to
Kirsty and Kathleen at the end of the (proposed) SmartRG meeting.
Mentioning that some of our group's earlier work [1] fits quite nicely
within their proposed charter we agreed that I should focus rather on
the network part than on the host part. I detailed on these and some
additional threats in a private email to Colin mid of June 2019 thinking
that this work is IRTF focus and subsequently summarized relevant,
generic parts of our earlier-developed malware lifecycle model in a
draft [2]. I presented the draft in detail in the Smart side-meeting on
Tuesday afternoon and later a brief version in secdispatch (slide deck:
[3]). At secdispatch Ted (thanks!) finally referred me to the model-t
project that unfortunately already met the same morning. In subsequent
meetings I received some context I was missing before (thanks Ali,
Kirsty, Dominique and Stephen). I agree with earlier opinions on the
list that structuring the existing material is difficult until we decide
on the scope. So imo it makes sense to delay the merging of drafts until
later to identify potential alternatives.

For now I plan to tackle two main aspects with our research group
(CommNets group at TU  Wien, Institute of Telecommunications): malware
life cycle model and protocol threat. In more detail:

1. Malware lifecycle model: As first step we believe the malware
lifecycle model that we developed to map well to the term "compromised"
in RFC 3552, representing it at a much finer granularity. That is,
"compromised" may be equivalent to any of the states of the lifecycle
model. It is to be decided, when a system is considered compromised. Is
access to the system sufficient? Is there a need for an earlier
privilege escalation to trigger infection? The response may differ from
malware to malware.

The model becomes actionable by capturing external "behavior" of the
(potentially compromised) system. On this behalf an external observer
monitors all of the system's network connections and activities.
Transitions between malware states shown in the diagram should be
typically associated with sending/receiving of packets that the external
observer can detect. Some challenges in this context
- observers can infer on the causality (packet -> malware action) on
occurrence of a malware action but the chronology is not clear (action
may have been triggered by timers or any earlier packet).
- malware obfuscates and encrypts communications (monitors protocols and
patterns of benign communications on the link and uses them to hide).
- The sheer amount of data (higher-layer aggregations like flows and
features help).

Some states (in particular propagation, scanning) also generate "noise"
that can be monitored. The amount of data that is exchanged for various
transitions may hints on the specific action (a ...

2. Second, we suspect some of the existing security protocols to support
hidden communications (covert or subliminal channels). Common signature
schemes have been proven already to (ECDSA, EDDSA,...) . Background is
one of our group's experiments that implemented a C&C channel that uses
the bitcoin chain [4]. Global reach at the cost of a one transaction.
I fully agree with Eric (comment at Smart side-meeting and secdispatch)
that detecting such channels may be impossible but we may be able to
characterize and recommend/prefer classes of protocols over others.
That's what slide #6 and #11 of [3] are about.

Today's discussion with Stephen revealed that subliminal channels
(exploiting signatures, encryption) may offer benefits over covert
communication channels. The latter ones are easier to implement but the
former ones carry end-to-end semantics, which increases their reach.
Covert channels may be canceled by intermediate buffers (timing c.c.) or
layer 3/4 middleboxes (IP & transport headers). Tam

The initial paper on the malware lifecycle [1] includes more material
that I intentionally did not include yet into the draft. The plan is to
summarize and structure the results of tables 1-6 of [2] in a future
revision of the draft and to complement with some more information
depending on the feedback on the list. There may be some overlap with
work planned by Ali, I'll coordinate with him in advance to avoid
duplicate work.

Finally, I've a funded project that will start soon, focusing (among
others) on the threat model for ICT in power networks. Depending on the
discussions on the mailing list I can propose to extend the threat model
analysis and feed it back into model-t. Obviously this depends on
consent of the project partners but we've agreed already that public
dissemination to be one of our main targets. As a rough timescale I'd
estimate first feedback before IETF107.

Feedback warmly welcome, please ask if there are any open issues.
Joachim

[1]: Eder-Neuhauser, P., Zseby, T., Fabini, J., and G. Vormayr, "Cyber
Attack Models for Smart Grid Environments“ Elsevier Sustainable Energy,
Grids and Networks Volume 12, 2017, pp 10-29. Pre-published version at
https://publik.tuwien.ac.at/files/publik_261089.pdf
[2]:  Draft:
https://datatracker.ietf.org/doc/draft-fabini-smartmalware-lifecycle/
[3]: Presentation at secdispatch:
https://datatracker.ietf.org/meeting/106/materials/slides-106-secdispatch-communication-network-perspective-on-malware-lifecycle-00
[4]: Bitcoin C&C: D. Frkat, R. Annessi, T. Zseby: "ChainChannels:
Private Botnet Communication Over Public Blockchains"; 2018 IEEE
International Conference on Blockchain, ISBN: 978-1-5386-7975-3; pp
1244-1252. Pre-published version at
https://www.annessi.net/data/2018-subliminalblockchain_preprint.pdf

-- 
---------------------------------------
DI. Mag. Dr. Joachim Fabini
Senior Scientist
Institute of Telecommunications
TU Wien
Gusshausstrasse 25/E389
A-1040 Vienna, Austria
Tel: +43 1 58801-38813
Fax: +43 1 58801-38898
mailto: [email-masked]
---------------------------------------