<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Example to Detect Malicious ELF Binaries (Linux Encoder Ransomware) in Custom Signatures</title>
    <link>https://live.paloaltonetworks.com/t5/custom-signatures/example-to-detect-malicious-elf-binaries-linux-encoder/m-p/67908#M7</link>
    <description>&lt;P&gt;Good afternoon!&lt;/P&gt;
&lt;P&gt;&lt;BR /&gt;We've got another sample of what can be accomplished using our custom signature engine today. Please note before continuing that:&lt;BR /&gt;&lt;BR /&gt;A) This signature exists as a sample to show what is possible, and has not been properly QA'd/soak tested to ensure no false positives. The hex values from the binaries were arbitrarily chosen simply to show how the process works, and were not analyzed against known legitimate ELF binaries for collision testing.&lt;/P&gt;
&lt;P&gt;B) Please read A! Please. &lt;span class="lia-unicode-emoji" title=":slightly_smiling_face:"&gt;🙂&lt;/span&gt;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;The purpose of this signature is to detect malicious ELF binaries that belong to a family of ransomware dubbed "Linux Encoder," which is targeting web servers, encrypting their files, and shaking down the owners for money.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Intelligence showed five known samples of the malware in the wild, with SHA1 hashes of:&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&lt;EM&gt;a5054babc853ec280f70a06cb090e05259ca1aa7 &lt;/EM&gt;&lt;BR /&gt;&lt;EM&gt;98e057a4755e89fbfda043eaca1ab072674a3154 &lt;/EM&gt;&lt;BR /&gt;&lt;EM&gt;810806c3967e03f2fa2b9223d24ee0e3d42209d3 &lt;/EM&gt;&lt;BR /&gt;&lt;EM&gt;12df5d886d43236582b57d036f84f078c15a14b0&lt;/EM&gt;&lt;BR /&gt;&lt;EM&gt;5bd6b41aa29bd5ea1424a31dadd7c1cfb3e09616&lt;/EM&gt;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Grabbing these samples and doing a hex dump, we look for (what we hope) are unique values in the hex dump. We grab those values, and we head into our lab firewall to make a signature.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;A single AND condition with five nested OR conditions, using pattern matching within the file-elf-body context, and a pattern containig \x(hexhere)\x.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;We set the action to reset-both, and we commit the signature.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;We attempt to transfer the files, and watch the signature trigger, denying the transfer.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;I've attached the sample signature for review.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&lt;STRONG&gt;To be more accurate in the future&lt;/STRONG&gt;, one thing that could be done would be ensure that the values pulled from the hex dumps are unique to the samples, and don't contain values that may be shared with other ELF binaries that are not malicious. This requires a bit more finesse and a good understanding of the ELF file structure/unique qualities of the malicious samples. Those who would like to enjoy a journey into RFCs/Wiki articles to ensure their signature is fail proof are welcomed to do so!&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;I will attempt to get more detailed in my next description, but the above should suffice as a simple framework for how signatures can be created to stop transfer of file types over the wire.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Note that we also have file contexts for (not all inclusive, see the document in the sticky):&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;FLV, HTML, Java, MOV, Office, PDF, RIFF, SWF, TIFF, and "unknown."&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;The signature has been attached for your perusal.&lt;/P&gt;</description>
    <pubDate>Tue, 10 Nov 2015 18:49:38 GMT</pubDate>
    <dc:creator>rcole</dc:creator>
    <dc:date>2015-11-10T18:49:38Z</dc:date>
    <item>
      <title>Example to Detect Malicious ELF Binaries (Linux Encoder Ransomware)</title>
      <link>https://live.paloaltonetworks.com/t5/custom-signatures/example-to-detect-malicious-elf-binaries-linux-encoder/m-p/67908#M7</link>
      <description>&lt;P&gt;Good afternoon!&lt;/P&gt;
&lt;P&gt;&lt;BR /&gt;We've got another sample of what can be accomplished using our custom signature engine today. Please note before continuing that:&lt;BR /&gt;&lt;BR /&gt;A) This signature exists as a sample to show what is possible, and has not been properly QA'd/soak tested to ensure no false positives. The hex values from the binaries were arbitrarily chosen simply to show how the process works, and were not analyzed against known legitimate ELF binaries for collision testing.&lt;/P&gt;
&lt;P&gt;B) Please read A! Please. &lt;span class="lia-unicode-emoji" title=":slightly_smiling_face:"&gt;🙂&lt;/span&gt;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;The purpose of this signature is to detect malicious ELF binaries that belong to a family of ransomware dubbed "Linux Encoder," which is targeting web servers, encrypting their files, and shaking down the owners for money.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Intelligence showed five known samples of the malware in the wild, with SHA1 hashes of:&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&lt;EM&gt;a5054babc853ec280f70a06cb090e05259ca1aa7 &lt;/EM&gt;&lt;BR /&gt;&lt;EM&gt;98e057a4755e89fbfda043eaca1ab072674a3154 &lt;/EM&gt;&lt;BR /&gt;&lt;EM&gt;810806c3967e03f2fa2b9223d24ee0e3d42209d3 &lt;/EM&gt;&lt;BR /&gt;&lt;EM&gt;12df5d886d43236582b57d036f84f078c15a14b0&lt;/EM&gt;&lt;BR /&gt;&lt;EM&gt;5bd6b41aa29bd5ea1424a31dadd7c1cfb3e09616&lt;/EM&gt;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Grabbing these samples and doing a hex dump, we look for (what we hope) are unique values in the hex dump. We grab those values, and we head into our lab firewall to make a signature.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;A single AND condition with five nested OR conditions, using pattern matching within the file-elf-body context, and a pattern containig \x(hexhere)\x.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;We set the action to reset-both, and we commit the signature.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;We attempt to transfer the files, and watch the signature trigger, denying the transfer.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;I've attached the sample signature for review.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&lt;STRONG&gt;To be more accurate in the future&lt;/STRONG&gt;, one thing that could be done would be ensure that the values pulled from the hex dumps are unique to the samples, and don't contain values that may be shared with other ELF binaries that are not malicious. This requires a bit more finesse and a good understanding of the ELF file structure/unique qualities of the malicious samples. Those who would like to enjoy a journey into RFCs/Wiki articles to ensure their signature is fail proof are welcomed to do so!&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;I will attempt to get more detailed in my next description, but the above should suffice as a simple framework for how signatures can be created to stop transfer of file types over the wire.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Note that we also have file contexts for (not all inclusive, see the document in the sticky):&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;FLV, HTML, Java, MOV, Office, PDF, RIFF, SWF, TIFF, and "unknown."&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;The signature has been attached for your perusal.&lt;/P&gt;</description>
      <pubDate>Tue, 10 Nov 2015 18:49:38 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/custom-signatures/example-to-detect-malicious-elf-binaries-linux-encoder/m-p/67908#M7</guid>
      <dc:creator>rcole</dc:creator>
      <dc:date>2015-11-10T18:49:38Z</dc:date>
    </item>
  </channel>
</rss>

