Blog

Archive for June, 2019

Maldoc: Payloads in User Forms, (Mon, Jul 1st)

When malicious Office documents leveraging VBA code became popular again with malware authors, they soon started to look for different places to hide their payload (URLs, commands, shellcode, EXEs, …). User Forms were one of the first components they turned to.

In this example, I add a user form (UserForm1) with a text box (TextBox1). And I “hide” a URL inside the text box.

This results in 4 extra streams under storage UserForm1. Here is the output of oledump.py:

Here is the content of these streams:

When you take a close look, you’ll notice that stream f contains the names of the components (TextBox1) and stream o contains the property values (the URL in our case).

Plugin plugin_stream_o can extract values of textboxes:

When you encounter optional streams in Office documents, make sure to take a look inside: they might contain payloads.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Verifying Running Processes against VirusTotal – Domain-Wide, (Fri, Jun 28th)

Over the last few days we’ve:

What to do next?  Well, with a pool of suspect file hashes, a logical next step would be to compare them against what’s in VirusTotal.  Let’s see how we can automate this process.

Let’s use the Posh-SSH module from the Powershell Gallery -thanks to Carlos Perez for writing this one (docs are here: https://www.powershellgallery.com/packages/Posh-VirusTotal/1.3)

To install:
install-module -name Posh-VirusTotal

Now, we can take that next step and check all of the hashes we collected in yesterday’s story (or maybe just the “most interesting” ones – the ones-ies and two-sies) against VirusTotal, to see if we’re harboring any known malwer.  We’ll use the Get-VTFileReport commandlet, which can take an MD5, SHA1 or a SHA256 Checksum, or a ScanID as input.  We’ll use the SHA1 checksums that we’ve generated in the last two stories to check.

Really you could do this as a simple web request, as documented at https://developers.virustotal.com/reference#file-report, the request (using curl) would look like:
curl –request GET –url ‘https://www.virustotal.com/vtapi/v2/file/report?apikey=&resource=’

So before you can do anything, create a VT account and get an API key if you don’t already have one (of each).

Looking at one hash, we’ll run an assessment using get-VTFileReport:

The value that we’re looking for is “positives”.  There are a large number of AV vendors that participate on VirusTotal (66 as of today), so a score of zero indicates that they all agree that the file is benign, a score of 66 indicates that they all agree that it’s malicious.  For our purposes, we’ll agree that any score of 1 or greater means that we should do some research on that file and make a determination.

So let’s add a member to our “InterestingHashes” object, then Loop through all of our collected “hashes of interest”:

# add the VTScore member to the object, pre-populate it as an empty string
$InterestingHashes | add-member -membertype noteproperty -name VTScore -value “”
# Look through all of the hashes of interest, and see how they score on VT
ForEach-Object ($InterestingHashes) {
    $VTReport = Get-VTFileReport -APIKey -Resource _$.filehash
    $_.VTScore = $VTReport.positives
    }

Note that a public API key with VT is rate-limited to:
Request rate: 4 requests/minute
Daily quota: 5760 requests/day
Monthly quota: 172800 requests/month

Private keys don’t have these limits (though I’m sure you can still exceed a counter with those as well).  So if you don’t have a private API Key, add a “sleep(16)” in that loop to ensure that your rate of queries stays below 4, and keep track of your total queries.  Microsoft keeps count for you at https://www.virustotal.com/gui/user/YourUseridGoesHere/apikey.
Private API keys can be requested here: https://www.virustotal.com/gui/contact-us/premium-services

$inter

 

So when all is said and done, $InterestingHashes should have a new field called “VTScore”, and the results should look like this (one listing chosen at random).

$InterestingHashes[12] | Select-Object FileHash, VTScore

FileHash                                 VTScore
——–                                 ——-
BEFA5CF53D4C698FEFBB707F23D9C17D742BF0C6       0

 

You can of course sort these, let’s do a reverse sort so any suspect files will go to the top:
$InterestingHashes | Select FileHash, VTScore | sort-Object -Property VTScore -descending

If you’ve gone through this exercise, did you find anything that VT flagged as possibly malicious?  If so, did that turn out to be a real piece of evil, or was it a false positive?  Please share any details that you can in our comment form .

Have a good weekend all, thanks for supporting the Internet Storm Center!

===============
Rob VandenBrink
Coherent Security

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Finding the Gold in a Pile of Pennies – Long Tail Analysis in PowerShell, (Thu, Jun 27th)

It is said that one piece of Information is like a penny, it’s value is small until it is combined with thousands of other pennies (or nickles, dimes or whatever).  This is certainly true when we collect the windows process list or the output of netstat -naob across a domain (the last two stories I’ve written up) – any single line is of limited value.  But once you combine everthing together, it’s easy to find trends, or in the case of the Windows process list, outliers – items that only occur on a few stations.

Luckily it is fairly easy in PowerShell to sort this information so that the outliers are easily seen – in a large domain for instance, you might be looking for the windows process hash value that only exists on 1,2 or maybe up to 5 hosts.

This is pretty easy to do – we’ll use the Powershell Group-Object command.  Working with the domain task list from yesterday, first “group” the list by the hash value:
$DomainTaskList | select pscomputername,filehash,name | Group-Object -Property filehash

Then, sort by “count”  (with no arguments, the sort is ascending:
$DomainTaskList | select pscomputername,filehash,name | Group-Object -Property filehash | sort count

Then, select processes that occur on “less than or equal to 2” hosts:
$InterestingHashes = $DomainTaskList | select pscomputername,filehash,name | Group-Object -Property filehash | sort count | where-object {$_.count -le 2}

Or, alternatively, “pick the first 10 in the list”
$InterestingHashes = $DomainTaskList | select pscomputername,filehash,name | Group-Object -Property filehash | sort count | select-object -first 10

Verify that the output looks good:
$InterestingHashes | ft -AutoSize

 

 

 

 

 

Finally, output to CSV – even in a small domain, on a “first run and clean-up” situation there’s usually just too many of these one-offs to list on the screen and deal with.
$InterestingHashes | output-csv “HashesToInvestigate.csv”

Now you can see the value of saving up pennies – what falls out of this exercise is often pure gold!

What did we find?  Looking at our output, we can see a few things off the bat that we should look closer at:

  • Multiple versions of TeamViewer.  This is generally OK if IT knows about it, but most instances were in other business units.
  • Every server “thing”, which for this client meant some BAAN stuff, a SQL Server and one old Domino server that hadn’t been retired yet
  • A few ancient versions of Word and PowerPoint – the hashes across the board for these should match if everything is at the same version and are patched up.  So finding multiple hashes for WinWord, each as a singleton is a bad sign.
  • Multiple windows machines that weren’t up to date on patching – several one-off versions of igfxEM, ZeroWireless_Config, wlanext and “IntelCp” processes on desktops with the same OS for instance indicates this
  • A few people still running the Domino client (these were all supposed to be retired)
  • JavaWS was installed and actually running on a Domnain Controller (oops)

So some things to fix, but no malware – great news!!

If you have a chance to run something like this scan (or if you already have), please use our comment form and let us know if you found anything interesting (good, bad or ugly, let us know!)

===============
Rob VandenBrink
Coherent Security

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

The Other Side of CIS Critical Control 2 – Inventorying *Unwanted* Software, (Wed, Jun 26th)

When I work with clients and we discuss CIS Critical Control 2, their focus is often on inventorying their installed software.  Today we’ll talk about inventorying software that you didn’t install.  Malware is typically the primary target in that “we didn’t install that software” list.

The method we’re looking at today will inventory the running processes across the enterprise, and we’ll look at how to “sift” that information to find outliers – applications that are running only one or two (or 5 or 10%, whatever your cutoff is) of hosts.  Note that this is hunting for *running* software, not software that was installed with a traditional MSI file, so this does a good job of finding malware, especially malware that hasn’t spread too far past its initial infection hosts yet.

OK, let’s look at the base code.  We’re basically running get-process, getting the path on disk for that process, then hashing that file on disk.  If the hash operation errors out (which it will for file-less malware for instance), that file is saved to an error log.  The hash is the key item, it uniquely identifies each file, even if malware has replaced a known filename the hash will be different on that station.  You can then use this hash to reference back to malware IOCs if that’s helpful.  Note that the hash in this case is SHA1 – you can change this to meet whatever your hashing requirements are, or add a few different hashing algorithms if that works better for you.

# collect the process list, then loop through the list
$proc = @()
Foreach ($proc in get-process)
    {
    try
        {
        # hash the executable file on disk
        $hash = Get-FileHash $proc.path -Algorithm SHA1 -ErrorAction stop
        }
    catch
        {
         # error handling.  If the file can’t be hashed – either it’s not there or we don’t have rights to it
        $proc.name, $proc.path | out-file c:tempproc_hash_error.log -Append
        }
    }

We’ll then run our script across the entire organization, and save both the process data and the errors in one set of files. Because we’re hashing the files, its likely better (and certainly much faster) to run this operation on the remote systems rather than opening all the files over the network to hash them.

Note that when we do this we’ll be logging the error information out to a remote share.

function RemoteTaskList {
# collect the process list, then loop through the list

$proc = @()
$wsproclist = @()
Foreach ($proc in get-process)
    {
    try
        {
        # hash the executable file on disk
        $hash = Get-FileHash $proc.path -Algorithm SHA1 -ErrorAction stop
        $p = $proc
        $p | add-member -membertype noteproperty -name FileHash -value $hash.hash
        $p | add-member -membertype noteproperty -name HashAlgo -value $hash.Algorithm
        $wsproclist += $p
        }
    catch
        {
         # error handling.  If the file can’t be hashed – either it’s not there or we don’t have rights to it
         # note that you will need to edit the host and share for your environment
        $env:ComputerName,$proc.name,$proc.path | out-file \loghostlogsharehash_error.log -Append
        }
    }
    $wsproclist
}

$targets =get-adcomputer -filter * -Property DNSHostName
$DomainTaskList = @()
$i = 1
$count = $targets.count

foreach ($targethost in $targets) {
   write-host $i of $count –  $targethost.DNSHostName
   if (Test-Connection -ComputerName $targethost.DNSHostName -count 2 -Quiet) {
       $DomainTaskList += invoke-command -ComputerName $targethost ${function:RemoteTaskList}
       ++$i
       }
   }

$DomainTaskList | select nselect-object PSComputerName, Id, ProcessName, Path,FileHash,FileVersion,Product,ProductVersion, HashAlgo | export-csv domain-wide-tasks.csv

With that CSV file exported, you can now look at the domain-wide list in Excel or any tool of your choice that will read a CSV file.

===============
Rob VandenBrink
Coherent Security

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Rig Exploit Kit sends Pitou.B Trojan, (Tue, Jun 25th)

Introduction

As I mentioned last week, Rig exploit kit (EK) is one of a handful of EKs still active in the wild.  Today’s diary examines another recent example of an infection caused by Rig EK on Monday 2019-06-24.


Shown above:  Traffic from the infection filtered in Wireshark.


Shown above:  Some of the alerts generated by this infection using Security Onion with Suricata and the EmergingThreats Pro ruleset viewed in Sguil.

Malvertising campaign redirect domain

EK-based malvertising campaigns have “gate” domains that redirect to an EK.  In this case, the gate domain was makemoneyeasywith[.]me.  According to Domaintools, this domain was registered on 2019-06-19, and indicators of this domain redirecting to Rig EK were reported as early as 2019-06-21.


Shown above:  makemoneyeasywith[.]me redirecting to Rig EK landing page on 2019-06-24.

Rig EK

The Rig EK activity I saw on 2019-06-24 was similar to Rig EK traffic I documented in an ISC diary last week.  See the images below for details.


Shown above:  Rig EK landing page.


Shown above:  Rig EK sends a Flash exploit.


Shown above:  Rig EK sends a malware payload.

The malware payload

The malware payload sent by this example of Rig EK appears to be Pitou.B.  In my post-infection activity, I saw several attempts at malspam, but I didn’t find DNS queries for any of the mail servers associated with this spam traffic.

Prior to the spam activity, I saw traffic over TCP port 2287 which matched a signature for ETPRO TROJAN Win32/Pitou.B, and it also fit the description for Pitou.B provided by Symantec from 2016.  I didn’t let my infected Windows host run long enough to generate DNS queries for remote locations described in Symantec’s Technical Description for this Trojan.  However, Any.Run’s sandbox analysis of this malware shows DNS queries similar to the Symantec description that happened approximately 9 to 10 minutes after the initial infection activity.


Shown above:  Post-infection traffic over TCP port 2287.


Shown above:  Filtering for indications of SMTP traffic in the pcap.


Shown above:  Using the Export Objects function in Wireshark to see successfully sent spam.


Shown above:  An example of spam sent from my infected Windows host.


Shown above:  DNS queries seen from the Any.Run analysis of this Pitou.B sample.

Indicators of Compromise (IoCs)

The following are IP addresses and domains associated with this infection:

  • 185.254.190[.]200 port 80 – makemoneyeasywith[.]me – Gate domain that redirected to Rig EK
  • 188.225.26[.]48 port 80 – 188.225.26[.]48 – Rig EK traffic
  • 195.154.255[.]65 port 2287 – Encoded/encrypted traffic caused by the Pitou.B Trojan
  • various IP addresses over TCP port 25 – spam traffic from the infected Windows host
  • various domains in DNS queries seen from the Any.Run analysis of this Pitou.B sample

The following are files associated with this infection:

SHA256 hash: 9c569f5e6dc2dd3cf1618588f8937513669b967f52b3c19993237c4aa4ac58ea

  • File size: 9,203 bytes
  • File description: Flash exploit sent by Rig EK on 2019-06-24

SHA256 hash: 835873504fdaa37c7a6a2df33828a3dcfc95ef0a2ee7d2a078194fd23d37cf64

  • File size: 827,904 bytes
  • File description: Pitou.B malware sent by Rig EK on 2019-06-24

Final words

A pcap of the infection traffic along with the associated malware and artifacts can be found here.


Brad Duncan
brad [at] malware-traffic-analysis.net

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →
Page 1 of 6 12345...»