In the previous article https://8ksec.io/dissecting-windows-malware-series-risc-vs-cisc-architectures-part-4/, we took a little detour and learnt more about CPU architectures, in order to understand the underlying mechanisms assembly code analysis is build upon.
We mostly talked about:
The differences between CISC and RISC architectures.
Where are we heading in the future
How is it related to Malware Analysis
Without further a due, let’s start learning how create malware-focused network signatures.
Table of Contents
What's In It For Me
In this article we’ll:
Learn what OPSEC is and how to safely investigate a malware sample.
Explore various methods malware uses to disguise its objectives, focusing on manipulation of network-related components.
Discover how to create malware network signatures based on real malware samples.
Already familiar with creating malware network signatures?
Feel free to scroll down to the ‘Creating Malware-Focused Network Signature Checklist‘.
How To Safely Investigate Malware Network Components 
When discussing the network functionality of malware, we’ll mainly focus on the following attributes:
IP addresses
Network Protocols: TCP, UDP, HTTP(S), etc.
Ports
Domain Names
Traffic Content
<a href="https://www.amazon.com/Practical-Malware-Analysis-Hands-Dissecting/dp/1593272901" rel="noreferrer" target="_blank">
<img alt="" height="223" src="https://i0.wp.com/8ksec.io/wp-content/uploads/2024/03/network_attributes.png?fit=675%2C223&ssl=1" width="675" /> </a>
Image Reference: <a href="https://www.amazon.com/Practical-Malware-Analysis-Hands-Dissecting/dp/1593272901" rel="noreferrer" target="_blank">https://www.amazon.com/Practical-Malware-Analysis-Hands-Dissecting/dp/1593272901</a>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>Given the objective of understanding the network component of a handed malware sample, we might be tempted to run the malware and observe its behavior.</p><p><strong>This would be a mistake</strong>.</p><p>Instead, we should review the data we already have, including:</p><ol start=""><li><p>Logs</p></li><li><p>Alerts</p></li><li><p>Packet captures</p></li><li><p>Any other data already generated by the malware.</p></li></ol><p>By running the malware as our first step, we risk leaking our analysis actions to the attacker, leading us to the next important concept.</p> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<h3>What Is OPSEC and Why is It Important<img alt="❓" src="https://s.w.org/images/core/emoji/15.0.3/72x72/2753.png" style="height: 1em;" /></h3> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>When using the Internet for research, understanding operation security (OPSEC) is crucial.</p><p>While performing investigations, certain actions we take can alert the malware author that we’ve identified the malware or even reveal personal information to the attacker.</p><p>For example:</p><ol start=""><li><p>Analyzing the malware from home, if it was initially sent to your corporate network via email, can lead to a DNS request being made from an IP address space outside the one normally used by your corporation.</p></li><li><p>If the malware was sent to a specific individual as a spear-phishing email containing a link, any access attempts to that link from outside the geographical area of the IP address space can alert the attacker.</p></li><li><p>Monitoring for attempts to resolve an unused domain included in the malware can indicate investigation activities.</p></li><li><p>Designing an exploit with an encoded link on an Internet-accessible, editable site (e.g., blog comments) can create a private, publicly accessible infection audit trail.</p></li></ol><p><strong>Awareness of an ongoing investigation may prompt attackers to change tactics and vanish.</strong></p> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<h3>So How Can We Safely Investigate a Malware Sample<img alt="" src="https://s.w.org/images/core/emoji/15.0.3/72x72/1f6a6.png" style="height: 1em;" /></h3> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<h3>Indirect Tactics</h3> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<ol start=""><li><p>The most known one is to use services or mechanisms that provide anonymity, such as: Tor, Open Proxy, etc…</p></li><li><p>Another method is using a dedicated machine for research and hiding it’s location:</p></li></ol><ul><li><p>Using only cellular connection</p></li><li><p>Tunneling the connection through a remote infrastructure using SSH or VPN.</p></li><li><p>Using an ephemeral remote machine on a Cloud service, like Amazon EC2.</p></li></ul> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<h3>Direct Tactics</h3> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>These core tactics are crucial for every malware analyst investigating a malware sample. Basic indicators, such as IP addresses and domain names, are mostly valuable for defending against a specific version of malware. </p><p>Malware authors are adept at quickly changing addresses or domains, so the solution involves:</p><p>So what’s the solution?</p><ol start=""><li><p>Defining <strong>Behavior</strong> Based Countermeasures.</p></li><li><p>Defining <strong>Content</strong> Based Countermeasures.</p></li></ol><p>When talking about <em>Behavior based countermeasures</em> – EDRs, XDRs, FWs, WAFs, NACs and similar security solutions are the way to go.</p><p>This realm of solutions deserves a separate article.</p><p>When talking about <em>Content based countermeasures</em> – IDSs and IPSs are the first things that pops to mind – This is the aspect we’ll focus on in this article.</p> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<img alt="" height="800" src="https://i0.wp.com/8ksec.io/wp-content/uploads/2024/03/ids_ips_monitoring.webp?fit=800%2C800&ssl=1" width="800" /> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<h3>Content-Based Network Countermeasures<img alt="" src="https://s.w.org/images/core/emoji/15.0.3/72x72/1f4c3.png" style="height: 1em;" /></h3> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>Signature-based IDSs & IPSs are the oldest deployed systems for detecting malicious activity via network traffic.</p><p>Signature based detection depends on knowing the characteristics of the malicious activity, and how does it look like.</p><p>A good signature will send an alert every time a malicious activity happens (true positive), but will not create an alert for anything that looks like malware but actually legitimate (false-positive).</p> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<h3>Good Old Snort IDS</h3> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>One of the most popular IDSs out there is Snort. It is used to create a signature or a rule that links together a series of elements (called rule options).</p><p>Only if the rule options are true – The rule will fire.</p><p>We’ll want to create a signature – <em>Generic as Possible</em>. Preferably detecting a malware family as a whole and not just a specific version of a certain malware type.</p><p>Malware will try to blend in the legitimate network traffic (HTTP, DNS, etc…) as much as possible – This in turn makes it more challenging to detect.</p><p>1. So what mechanisms malware will try to leverage for that purpose?</p><p>2. How will they try to impose challenges on the analyst’s efforts to<br />create a precise signature?</p> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>Next, we’ll see 2 malware samples that showcase and answer those questions.</p> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<h3>A Little Bit of Snort Basics<img alt="" src="https://s.w.org/images/core/emoji/15.0.3/72x72/1f4da.png" style="height: 1em;" /></h3> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>But before we dive deep, let’s understand the attributes of Snort signatures:</p> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<pre>
<code>
alert tcp $EXTERNAL_NET any -&gt; $HTTP_SERVERS $HTTP_PORTS (msg:"SQL Injection Attempt Detected"; flow:to_server,established; content:"SELECT"; nocase; content:"FROM"; distance:0; within:40;content:"WHERE"; distance:0; within:40; pcre:"/(\%27)|(\')|(\-\-)|(\%23)|(#)/i"; classtype:web-application-attack; sid:1000001; rev:1;)
</code>
</pre>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<ul><li><p><strong>alert tcp</strong> – Specifies that the rule if for TCP traffic.</p></li><li><p><strong>$EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS</strong> – Defines the traffic flow direction – from any external network using HTTP on defined HTTP ports.</p></li><li><p><strong>msg:”SQL Injection Attempt Detected”</strong> – The message that will be logged or shown when the rule triggers.</p></li><li><p><strong>flow:to_server,established</strong> – Specifies that this rule applies to established connections heading towards the HTTP server.</p></li><li><p><strong>content</strong> – This specifies the specific content to look for in the packet payload.</p><p>In this case, it looks for common SQL keywords like “SELECT”, “FROM”, and “WHERE”, indicating a potential SQL injection attempt.</p></li><li><p><strong>nocase</strong> – Makes the content match case insensitive. distance and within: These keywords are used to specify content location constraints relative to the previous match.</p></li></ul><ul><li><p><strong>pcre</strong> – Perl Compatible Regular Expressions for more complex pattern matching. Here, it’s used to detect common SQL injection characters and patterns.</p></li><li><p><strong>classtype:web-application-attack</strong> – This categorizes the type of attack the rule is designed to detect.</p></li><li><p><strong>sid</strong> – The Snort ID for the rule. This should be unique.</p></li><li><p><strong>rev</strong> – The revision number of the rule, useful for keeping track of updates to your signatures.</p></li></ul> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<h3>An Important Side Note</h3> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>Before deploying, it’s crucial to test your signatures thoroughly to ensure they do not generate an excessive number of false positives or negatives.</p> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<h3>Let's Start Reversing<img alt="" src="https://s.w.org/images/core/emoji/15.0.3/72x72/1f60e.png" style="height: 1em;" /></h3> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<h3>1. Network Content Signature Based on Endpoint's Unique Data</h3> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>Given the malware sample, we see there is no associated packet capture. This forces us to start with Basic Dynamic Analysis to help us understand how the malware operates.</p><p>Running the malware with FakeNet running in the background, we observe the following beacon:</p> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<img alt="" height="123" src="https://i0.wp.com/8ksec.io/wp-content/uploads/2024/03/fakenet_beacon.png?fit=641%2C123&ssl=1" width="641" /> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>It appears the HTTP GET request contains encoded data and downloads an image file from a certain domain (obfuscated in the picture).</p><p>Our goal, as stated, is to find hard-coded data or ephemeral coded data we could use in creating our Snort signature.</p><p>Running the malware a couple more times produces the same beacon.</p><p>Let’s then continue to analyze the assembly code.</p><p>Usually, we would scroll through the import address table (if there is one, and the malware is not packed) and look for network-related API calls. </p><p>But, as the main function opens in IDA Pro (after automatically determining the entry point), we cannot help but see and analyze the following assembly code snippets:</p><p> </p> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<img alt="" height="733" src="https://i0.wp.com/8ksec.io/wp-content/uploads/2024/03/querying_host_data.png?fit=800%2C733&ssl=1" width="800" /> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>It appears the data passed to the function sub_4010BB is ephemeral data gathered from the endpoint profile data (this includes username, MAC address, etc.).</p><p>Analyzing the function sub_4010BB, we observe the following assembly code:</p> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<img alt="" height="459" src="https://i0.wp.com/8ksec.io/wp-content/uploads/2024/03/http_get_assembly.png?fit=660%2C459&ssl=1" width="660" /> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>It appears the endpoint queried information is used as the data to be sent in the HTTP GET request using the API call: <em>URLDownloadToCacheFileA</em>.</p><p>Since we observed the network generated content data is based on the host information, our guess is to try and run the malware on a different host.</p><p>This time, the beacon the malware sends has different GET request data (also Base64 encoded) and uses a different User-Agent:</p> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<img alt="" height="184" src="https://i0.wp.com/8ksec.io/wp-content/uploads/2024/03/fakenet_beacon_2.png?fit=800%2C184&ssl=1" width="800" /> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>Following the data we gathered, we can conclude what the hard-coded data is and create the network signature.</p><p>The key static elements to target when analyzing a network signature are the colons and the dash that provide padding among the hardware profile bytes and the username.</p><p>Targeting these elements is challenging because the malware applies a layer of Base64 encoding before sending this content onto the network.</p><p>However, inspecting the Base64 strings we gathered, we can infer the following:</p><ul><li><p>Each colon in the original string is the third character of each triple.</p></li><li><p>In Base64, all the bits in the fourth character of each quad come from the third character.</p></li></ul><p>And that’s why:</p><ol start=""><li><p>Every fourth character under the colon is a 6.</p></li><li><p>Because of the dash, the sixth quad will always end with a t.</p></li></ol><p>This leads us to the following final conclusions:</p><p>1. The URI that will be used will always be at least 24 characters long with specific locations for the four 6 characters and the ‘t’.</p><p>2. We know the character set that may be used to represent the rest of the URI.</p><p>3. We also know the download name is a single character that is the same as the end of the path.</p> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<a href="https://www.amazon.com/Practical-Malware-Analysis-Hands-Dissecting/dp/1593272901" rel="noreferrer" target="_blank">
<img alt="" height="81" src="https://i0.wp.com/8ksec.io/wp-content/uploads/2024/03/base_64_static_pattern.png?fit=664%2C81&ssl=1" width="664" /> </a>
Image Reference: <a href="https://www.amazon.com/Practical-Malware-Analysis-Hands-Dissecting/dp/1593272901" rel="noreferrer" target="_blank">https://www.amazon.com/Practical-Malware-Analysis-Hands-Dissecting/dp/1593272901</a>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>All this information allows us to create the following two Snort signatures:</p> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<img alt="" height="116" src="https://i0.wp.com/8ksec.io/wp-content/uploads/2024/03/snort_rule_1.png?fit=800%2C116&ssl=1" width="800" /> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>It’s in the form of:</p> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<pre>
<code>
/\/XXX6XXX6XXX6XXX6XXX6XXXt(XXXX){1,}\//
</code>
</pre>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>Where:</p><ol start=""><li><p>X represents the character set: [A-Z0-9a-z+\/]</p></li><li><p>It captures blocks of four characters ending in 6 and t.</p></li><li><p>It targets the first segment if the URI with static characters.</p></li></ol><div></div><p>The second Snort rule will be based on the following pattern:</p> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<pre>
<code>
/\/[A-Z0-9a-z+\/]{24,}\([A-Z0-9a-z+\/]\)\/\1.png/
</code>
</pre>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>And can created in a similar manner.</p> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<h3>2. Network Content Signature - Leveraging HTML Attributes</h3> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>Given the malware sample, and since we don’t have a packet capture, we’ll start with <em>Basic Dynamic Analysis</em>.</p><p>Running the malware with FakeNet in the background, we observe the following request:</p> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<img alt="" height="138" src="https://i0.wp.com/8ksec.io/wp-content/uploads/2024/03/hard_coded_user_agent.png?fit=642%2C138&ssl=1" width="642" /> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>We notice the attacker has mistakenly hard-coded the keyword ‘User-Agent’, which can later be used in our Snort signature.</p><p>We also observe the file requests an HTML file named ‘start.htm’.</p><p>Inspecting the relevant Windows API calls, we see there is heavy use of the WinINet DLL library and the Windows COM object model.</p><p>Cross-referencing these functions in the assembly code, we get to the following code snippet:</p> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<img alt="" height="831" src="https://i0.wp.com/8ksec.io/wp-content/uploads/2024/03/wininet_com_functions.png?fit=800%2C831&ssl=1" width="800" /> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<h3>First Goal - Identify the Beacon Content<img alt="" src="https://s.w.org/images/core/emoji/15.0.3/72x72/1f170.png" style="height: 1em;" /></h3> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>Doing some backtracking, we find out this function is called from <em>Winmain</em> with two arguments.</p><p>The one used before the call to <em>InternetOpenUrlA</em> is the URL and defines the beacon destination.</p><p>This URL is set in another function in <em>Winmain</em>, which contains the following code:</p> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<img alt="" height="280" src="https://i0.wp.com/8ksec.io/wp-content/uploads/2024/03/failover_read_file.png?fit=800%2C280&ssl=1" width="800" /> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>In case the .exe file doesn’t exist, a call will be made to the static URL, requesting the <em>start.htm</em> we saw earlier.</p><p>Further analysis reveals that the <em>ReadFile</em> function takes a buffer as an argument, which is eventually passed all the way back to the <em>InternetOpenUrlA</em> function.</p><p>Thus, we can conclude that <em>autobat.exe</em> is a configuration file that stores the URL in plaintext.</p> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<h3>Second Goal - Identify How The Malware Responds<img alt="" src="https://s.w.org/images/core/emoji/15.0.3/72x72/1f171.png" style="height: 1em;" /></h3> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>Following the <em>InternetReadFile</em> call, we notice the following code snippet:</p> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<img alt="" height="480" src="https://i0.wp.com/8ksec.io/wp-content/uploads/2024/03/tag_response.png?fit=800%2C480&ssl=1" width="800" /> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>The <em>strstr</em> function (returns a pointer to the first occurrence of a search string in a string) is placed within two loops—the outer one containing the call to <em>InternetReadFile</em>, and the inner one containing <em>strstr</em> and a call to another function, <em>sub_401000</em>.</p><p><em>sub_401000</em> is called when the string <em>‘<no’</em> is found and a comparison to validate whether we found the correct content.</p><p>Moving forward we find out that:</p><ol start=""><li><p>The attacker tried to mix up the comparisons to the keyword <em>< noscript ></em> to avoid producing an obvious pattern.</p></li><li><p>The content the malware expects for a valid comparison are:</p><ul><li><p>The file read from the Internet.</p></li><li><p>The URL that originally came from the configuration file.</p></li></ul></li></ol> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<img alt="" height="627" src="https://i0.wp.com/8ksec.io/wp-content/uploads/2024/03/no_script_comparison.png?fit=262%2C627&ssl=1" width="262" /> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>After that, there is a jump table based on the value of the register: ‘d’, ‘s’, ‘r’, ‘n’.</p><p>Analyzing the ‘d’ case, we find out calls to <em>CreateFile</em> and <em>WriteFile</em> altering the configuration file.</p><p>The malware then:</p><ol start=""><li><p>Creates a process.</p></li><li><p>Overwrites the configuration file in order to redirect the malware to beacon to a different site.</p></li><li><p>And generally, serving as a client in a C2 server allowing lots of other functionalities.</p></li></ol> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<h3>Generating The Snort Rules<img alt="" src="https://s.w.org/images/core/emoji/15.0.3/72x72/1f523.png" style="height: 1em;" /></h3> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>Since the malware has a beacon component and a response component – we need to create multiple Snort rules to achieve full coverage.</p> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<h3>The Beacon<img alt="➡" src="https://s.w.org/images/core/emoji/15.0.3/72x72/27a1.png" style="height: 1em;" /></h3> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<pre>
<code>
alert tcp $HOME_NET any -&gt; $EXTERNAL_NET $HTTP_PORTS (msg:"PM14.3.1 Specific
User-Agent with duplicate header"; content:“User-Agent|3a20|User-Agent|3a20|
Mozilla/4.0|20|(compatible;|20|MSIE|20|7.0;|20|Windows|20|NT|20|5.1;|20|
.NET|20|CLR|20|3.0.4506.2152;|20|.NET|20|CLR|20|3.5.30729)”; http_header;
sid:20001431; rev:1;)
We marked elements (below) are static and come from two different strings in the code. The rest, are ephemeral since they are defined by the URL.
As we mentioned, since the attacker made a mistake with hard coding the User-Agent, it is a strong indicator, and the rule should include it.
The Response
The responses will be in the following format:
… truncated_url/cmd_char…/arg96’
The malware searches for several static elements in the web page, including the noscript tag, the first characters of the URL (http://), and the trailing 96′.
Since the parsing function that reads the cmd_char structure is in a different area of the code and may be changed independently, it should be targeted separately. Thus, the following is the signature for targeting just the static elements expected by the malware:
alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:“PM14.3.2 Noscript
tag with ending”; content:“”; content:“http://”; distance:0;
within:512; content:“96’”; distance:0; within:512; sid:20001432; rev:1;)
The download and redirect functions both share the same routine to decode the URL, so we will target these two commands together:
alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:“PM14.3.3 Download
or Redirect Command”; content:“/08202016370000”; pcre:"//[dr][^/]/
08202016370000/"; sid:20001433; rev:1;)
This signature uses the string 08202016370000, which we previously identified as the encoded representation of http://.
The PCRE rule option includes this string and forward slashes, and the ‘d’ and ‘r’ that indicate the download and redirect commands.
The / is an escaped forward slash, the [dr] represents either the character ‘d’ or ‘r’, the / matches zero or more characters that are not a forward slash, and the / is another escaped slash.
In a similar way, we would create the signatures for the quit and sleep commands.
So What Have We Seen
We talked about:
What is OPSEC and how an analyst should safely investigate a malware online (indirect & direct).
Content based countermeasures – What are they, and how they differ from behavior based counter measures.
We analyzed two malware samples – Each one having a different network characteristic.
As expected, our ability to create a precise content based signature will be determined by our ability to dissect the malware and leverage our knowledge of network internals.
Tips To Creating Accurate Snort Signatures
As a rule of thumb, we’ll want to create multiple signatures — each one targeting a different mechanism of the malicious code.
This approach makes detection more resilient to attacker modifications.
Attackers may try to slightly change their software to avoid detection by a specific signature.
By creating multiple signatures that key off different aspects of the communication, you can still successfully detect the malware, even if the attacker has updated a portion of the code.
Here are three additional key notes to remember when creating the signatures:
Focus on elements of the protocol that apply to both the client and server sides From the attacker’s perspective, changing code related to both the client and the server is much harder.
Look for elements of the protocol that use code on both the client and the server sides, and create a signature based on these elements.
The attacker will need to do a lot of extra work to render such a signature obsolete.
Focus on elements of the protocol known to be part of a key.
Often, some hard-coded components of a protocol are used as a key.
For example, an attacker may use a specific User-Agent string as an authentication key so that illegitimate probing can be detected (and possibly rerouted).
To bypass such a signature, an attacker would need to change code at both endpoints.
Identify elements of the protocol that are not immediately apparent in traffic.
Sometimes, the actions of multiple defenders can impede the detection of malware.
If another defender creates a signature that achieves sufficient success against an attacker, the attacker may be compelled to adjust his malware to avoid the signature.
If you rely on the same signature, or a signature that targets the same aspects of the attacker’s communication protocol, the attacker’s adjustment will affect your signature as well.
To avoid being rendered obsolete by the attacker’s response to another defender, try to identify aspects of malicious operations that other defenders might not have focused on.
Knowledge gained from carefully observing the malware will help you develop a more robust signature.
As a general conclusion, signatures based on malware analysis are more precise, reducing the trial and error needed to produce low false positive signatures.
Additionally, they have a higher likelihood of identifying new strains of the same malware.
So, What’s Next
So far, we’ve acquired an impressive skill set of analyzing and reverse engineering malware samples. We’ve discussed major objectives malware will try to achieve: Persistance, Evasion and Stealth and saw various use cases where each one is being implemented.
Now we’re in the major league.
The next articles will focus on more advanced topics, such as:
Analyzing Rootkits
Unpacking Malware Samples
Identifying and Analyzing Shellcode
And much more
References
The following resources are taken from an amazing book called:
Practical Malware Analysis By Michael Sikorski and Andrew Honig
The two malware samples
The network attributes image
The Base64 image comparing decoded and encoded data
Tips and tricks regarding creating snort signatures
All other resources were generated through the analysis process
GET IN TOUCH
Excited to learn more about Windows Malware Analysis? We just released our latest training on Windows Malware Analysis And Memory Forensics! You can find more information about it here. Please don’t hesitate to reach out to us through our Contact Us page if you have any questions.
Visit our training page if you’re interested in learning more about our other course offerings and want to develop your abilities further. Additionally, you may look through our Events page and sign up for our upcoming Public trainings.
The post Dissecting Windows Malware Series – Creating Malware-Focused Network Signature – Part 5 first appeared on 8kSec.
Article Link: https://8ksec.io/dissecting-windows-malware-series-creating-malware-focused-network-signature-part-5/