SCoE Malware Analysis Support

Requests SOP

//Secureworks/Confidential - Limited External Distribution

 SCoE Malware Analysis Support Requests SOP

Contents
1. Background ......................................................................................................................................... 2
1.1. Types of request .................................................................................................................................. 2
1.2. Hazmat Safe Transfer Procedures ...................................................................................................... 3
1.3. Baseline Analysis ................................................................................................................................ 4
1.4. SCOE Malware Analysis Support Escalations .................................................................................... 5
1.5. Process refinement ............................................................................................................................. 6
Appendix A. Malware Analysis Techniques ..................................................................................................... 7
Appendix A.1. Surface Analysis (SCOE) ...................................................................................................... 7
Appendix A.2. Automated Dynamic Analysis (SCOE) .................................................................................. 7
Appendix A.3. Deep Static Analysis / Reverse Engineering (CTU) .............................................................. 8
Appendix A.4. Interactive Dynamic Analysis / Debugging (CTU) ................................................................. 8

1. Background
There is a requirement within SCOE to understand aspects of identified malicious code and proper handling
procedures in order to protect clients. There has been agreement between SCOE and the CTU that where
understanding cannot be derived from static analysis (e.g. analysis of file properties and strings) and basic
dynamic analysis (e.g. automated sandbox examination), analysis requests will be escalated to the CTU.

1.1. Types of request

Before any malicious code analysis is undertaken, analysts should consider what client question(s) they are
attempting to answer when examining a piece of malicious code, along with what level of analysis is
appropriate to answer the question(s). As there is risk in both handling malicious code and conducting
malicious code analysis, only the required level needed to answer the question(s) should be undertaken.

Requests should be identified as one or more of the following:

• Indicator extraction:

o Network IOC extraction (Domains, IPs, URLs)

o Host IOC extraction (Created/touched files, persistence mechanisms, mutexes)

• Behavioral context:

o What malware is this/does this thing drop (family classification, any association to a known
threat groups)

• Capability statement:

o What functionally can/does this malware do (file upload/download, keylogging etc)

o How does it do these things (packing, encryption, loading)

//Secureworks/Confidential - Limited External Distribution

 SCoE Malware Analysis Support Requests SOP

o How does this functionality relate to previously known samples of the same family (if
known)

• Countermeasure Coverage Check

o Do existing network/host countermeasures detect/prevent this malware

It is not expected that more prolonged analysis would be requested from SCOE; however, CTU have other
categories of “malware analysis” which are included below for completeness. Requests requiring the
following categories of analysis should be escalated to the CTU using the process described in Section 1.4:

• Full static reverse

o Comprehensive analysis of malware, structure and capabilities, annotated IDB as output

• Threat Analysis

o Customer facing Threat Analysis

• Longitudinal Threat Analysis

o Temporal or campaign analysis considering how the malware has evolved over time

Analysts should apply the principle of deriving information that is relevant and actionable for their client and
avoid the temptation to submit a request for information that is not necessary or relevant. Doing so will
unnecessarily use up resources and will ultimately delay the final response to the client.

1.2. Hazmat Safe Transfer Procedures

Hazardous material (HAZMAT) is any malware or artifact, which if not handled correctly, can cause harm.
The most important principle is to minimize contact time with HAZMAT by moving it to safe repositories
where it can be worked on at arm’s length at the soonest possible juncture.

This process has been designed to remove the possibility of “live” malware being passed through jump
servers which can contact client infrastructure. The risks posed through inadvertent execution of malware in
such an environment are significant.

Today, the proposed HAZMAT handling infrastructure consists of CASE, which serves as a frontend for the
sandboxing, sample archival and sharing / transfer functions pertaining to this SOP and SDDC REMNUX,
the SDDC-hosted, standardized configuration REMNUX VM.

1.2.1. CASE Submission

The initial step is for the analyst to upload the sample into CASE (CASE access from the client
environment is a hard dependency / prerequisite) where sandbox detonation takes place with the results
being made available to the analyst, as well as being automatically ingested into TIMS IS.

Using the CASE web interface, the analyst will upload and submit the sample, considering the specific
parameters and options required in the submission form.

A detailed guide for submitting samples in CASE is presented in Appendix B.

1.2.2. SDDC REMnux VM

//Secureworks/Confidential - Limited External Distribution

 SCoE Malware Analysis Support Requests SOP

Following submission to CASE, if further assessment of the suspicious sample is required, the analyst has
the option to use the SDDC-hosted REMnux VM. This allow SCOE analysts to leverage specialized
tools/scripts against the sample in a non-executable way (for example, running pdf-parser.py against a PDF
file, or oletools against OLE objects),

There are two main prerequisites for this latter stage:

• The SDDC REMnux VM needs to have connectivity to CASE for accessing / downloading the
respective sample on the VM, for further assessment.

• As most analysts use WS1 M3 profile machines, a pathway from these assets into the SDDC
REMnux VM needs to be provisioned. The currently agreed approach is to use a FLEX CORP VM
that sits on the WS1 M3 machine.

For client-facing communication, should this need arise, we can provide a high-level overview of the CASE
< - > SDDC REMnux ecosystem, emphasizing both the various access control mechanisms in place, and
the strictly private nature of this malware analysis platform that we make available to our analysts, in
support of malware analysts request types.

It should be noted that the CASE replacement project is underway, codenamed Atlas, and this will provide
an improved “hands free” environment for malware inspection and analysis which will include:

• An internet accessible web form for capturing HAZMAT

• Improved surface analysis of documents, URLs to minimize the occasions when malware is
handled directly in SDDC REMNUX

1.3. Baseline Analysis

Once a sample is transferred from the client to the SCOE using the process defined in Section 1.2, baseline
analysis can be conducted by following the below process:

1. Before beginning any analysis process, SCOE analysts should ensure they are clear on what
question(s) from Section 1.1 need answering on behalf of their client. The expectation is that most of
the time, requests will be limited to extracting any indicators for further pivoting and analysis in client
telemetry, but in certain cases additional information may be required.

2. Initially SCOE analysts should attempt to answer the question(s) by:

2.1. Gathering information about the file (for example the hash values) and searching for the file or file
attributes in OSINT data sources (but not uploading any content to those external sources).

2.2. Checking existing internal data repositories (e.g. TIMS, CASE) to see whether a file and any
associated threat indicators are already known.

2.3. Running strings on a file.

2.4. Looking at file imports/exports.

2.5. Running tools/scripts against it in a non-executable way (for example, running pdf-parser.py
against a PDF file, or oletools against OLE objects).

//Secureworks/Confidential - Limited External Distribution

 SCoE Malware Analysis Support Requests SOP

2.6. Submit the file or URL to CASE to check whether any Yara rules or IDS signatures match on the
sample or its network activity, or the file matches on a CASE malware classifier to identify the
family it belongs to. CASE detonations can also identify threat indicators, such as any network C2,
created files, and information on any subsequent files that were downloaded.

3. The expectation is that in the majority of cases these steps will provide sufficient information to answer
the analysis question(s).

1.4. SCOE Malware Analysis Support Escalations

Where insufficient information is returned from SCOE analysis, a request should be escalated to CTU for
more in depth analysis via the TI-Support ticketing mechanism. SCOE analysts can open a ticket by:

• First and foremost, submitting the file(s) to CASE

• Sending an email to ctu-ti-tickets@secureworks.com, including the CASE URLs along with

the results of any surface analysis, informative context and questions seeking to be
answered by analyzing the files

The request should clearly identify which of the above questions need to be answered and the urgency,
taking into account that basic requests to derive threat indicators will be answered significantly quicker
(normally within a day) than requests for detailed capability statements (days or weeks).

The relevant CTU malware analyst will decide on what depth of analysis (see below) is required to answer
the question(s). The level of required analysis, coupled with the complexity of the sample, will determine
how long the work is likely to take.

A CTU malware analyst will conduct an initial review of the ticket and submitted file(s) and estimate the
likely level of effort required to service the ticket. If the request is straightforward, they will proceed to
answer the question(s) posed. If the request appears on initial glance to be more complex, or the request is
for a deep level of analysis (e.g. a detailed capability statement) the CTU malware analyst will contact the
submitter to discuss expectations and priorities, and/or seek any additional clarification.

If at any point during the analysis it becomes clear that the work involved is more complex than initially
thought, the CTU malware analyst can contact the ticket submitter to discuss. Active dialogue is
encouraged between SCOE and CTU analysts to ensure sufficient levels of information are available on
both sides, and the effort spent answering escalation requests is proportionate.

The CTU may decide, at its own discretion, to conduct additional work above and beyond that requested in
the ticket, for the purposes of understanding and tracking current threats. Examples might include:

• Pivoting off the threat indicators for intelligence gain

• Creating CASE malware pages

• Developing additional countermeasures

Carefully consider the OPSEC sensitivities when deciding what network profile to use for the CASE detonation. Allowing the sample
to communicate with the internet may generate better detonation results, but if the sample is derived from IR or is sensitive in some
other way, this might also tip off the adversary. If in doubt, use a limited/fakenet network profile.

//Secureworks/Confidential - Limited External Distribution

 SCoE Malware Analysis Support Requests SOP

• Decoders or emulators

• Producing written threat intelligence products off the back of the analysis.

The expectation is that where this occurs, all clients, and in turn SCOE analysts, will benefit from new or
improved scaled protections and intelligence products. CTU researchers will endeavor to notify SCOE
where client facing content is derived from analysis initially done by SCOE.

1.5. Process refinement

This process will be kept under ongoing review, and refined where necessary, using management
information from the support tickets as well as sample reviews of the content of both the requests and the
associated response.

//Secureworks/Confidential - Limited External Distribution

 SCoE Malware Analysis Support Requests SOP

Appendix A. Malware Analysis Techniques

The SCOE analyst should focus on what question(s) they need to answer to support their client. If initial
triage does not do that sufficiently, and a request is escalated to the CTU, the malware analyst who picks
up the ticket will decide based on their own experience what level of analysis is required to answer the
question. These categories are therefore included only to aid understanding, not as a menu of options for
SCOE analysts to reference in their request.

Figure 1. Malware Analysis Categories

Below are further descriptions of each category.

Appendix A.1. Surface Analysis (SCOE)

This generally means gathering information about the file (for example obtaining the file hash values),
searching for the file or file attributes in OSINT data sources (but not uploading it to external sources),
interacting with it from a high level (for example, running strings against it, looking at the imports/exports),
and running tools/scripts against it in a non-executable way (for example, running pdf-parser.py against a
PDF file, or oletools against OLE objects).

Much information about a particular file or sample for analysis can be gathered this way. Often times this is
enough to determine whether the sample is malicious or not and, if so, what malware family it is and any
applicable IOCs.

The specifics of this activity type are included in the accompanying document: Surface Analysis
and SDDC REMnux Technical Documentation.

Appendix A.2. Automated Dynamic Analysis (SCOE)

This fundamentally involves submitting the sample to CASE, or similar dynamic analysis sandboxes that do
not share samples externally and interpreting the results of the detonation. Once a file is submitted to
CASE, an analyst can check whether any Yara rules or IDS signatures matched on the sample or its
network activity. CASE also contains malware classifiers that can help determine what malware family the
sample belongs to. Finally, the output of CASE can help provide additional IoCs, such as any network
command-and-control IPs or URLs, and information on any subsequent files that were downloaded.

//Secureworks/Confidential - Limited External Distribution

 SCoE Malware Analysis Support Requests SOP

Appendix A.3. Deep Static Analysis / Reverse Engineering (CTU)

This is generally undertaken by experienced software and reverse engineers who have a deep
understanding of software, operating systems, and the APIs which enable software to interact with the
operating system. Also possess experience with advanced tools such as IDA Pro.

Appendix A.4. Interactive Dynamic Analysis / Debugging (CTU)

This refers to a malware analyst running the sample interactively in a virtual machine and/or executing it in
a debugger, such as OllyDbg. Performing this type of analysis is usually the responsibility of experienced
malware analysts since a significant amount of care must be taken to either prevent the malware from
spreading to the host operating system, other resources on the network connecting outside of the host to its
command and control servers. Additionally, no client data or items that may be tied back to Secureworks
must be present on the analysis machine.

//Secureworks/Confidential - Limited External Distribution

 SCoE Malware Analysis Support Requests SOP

Appendix B. Submitting samples to CASE

Requesting an Account

• Go to Swim (in the SCWX environment) -> SRSMAN and request a CASE- account.

• Search for CASE-Submitter and submit your request in order to be able to read reports and Submit
Malware.

To submit a sample into CASE, analysts will use the CASE web interface,
https://case.counterthreatunit.net/submit_sample, browse locally in their client's corporate / work environment
for the sample in question in the “Select File” section, and submit it using the “Submit” button located at the
bottom of the web page.

When submitting a sample, the analyst will have to consider the following parameters for configuration: TLP (Traffic
Light Protocol), Priority, Profile, Firewall Policy, Skip if Detonation Exists, Disable collecting dropped files, Execution
Timeout, Execution Arguments, and Override file extension.

TLP Explanation:

//Secureworks/Confidential - Limited External Distribution

 SCoE Malware Analysis Support Requests SOP

TLP Rule

Red Personal for named recipients only

Amber Limited distribution (within org)

Green Community wide (not via publicly accessible channels)

White Distributed without restriction

Choose Priority

Priority Reason

High Hand-Submitted Samples

Medium Small scripts, bulk submit (<500)

Low Larger long-running bulk submit scripts

Choose Profile

These are profiles on the Norman Sandbox. Each profile has different configurations.

Firewall Policy

Policy Definition

Isolated No network connectivity

Limited Prevents port 25(mail), 139 (NetBIOS), and 445 (SMB)

Unlimited All traffic allowed

Execution Timeout

This is how long to wait for program to finish.

Execution Arguments

Arguments to pass with the sample.

//Secureworks/Confidential - Limited External Distribution