In this diary, I will talk about KAPE by SANS Instructor Eric Zimmerman. 

 

What is KAPE?

Kroll Artifact Parser and Extractor (KAPE) is primarily a triage program that will target a device or storage location, find the most forensically relevant artifacts (based on your needs), and parse them within a few minutes.

Because of its speed, KAPE allows investigators to find and prioritize the more critical systems to their case. Additionally, KAPE can be used to collect the most critical artifacts prior to the start of the imaging process.

While the imaging completes, the data generated by KAPE can be reviewed for leads, building timelines, etc.

Install

KAPE can be downloaded from the following link:

https://learn.duffandphelps.com/kape?utm_campaign=2019_cyberitbn-KAPE-launch&utm_source=kroll&utm_medium=referral&utm_term=kape-launch-blog-post

Once you download and unzip KAPE you can find two executables:

One is kape.exe which is the command line version and the other one is gkape.exe which is the GUI version.

Usage

For this diary, I am going to use the GUI version. Like most of forensics acquisition tools, KAPE needs an administrative privilege to do its job.

To collect data first click on the “Use Target Options” checkbox then choose what do you want to collect. In this example, I am going to select the C drive as a target source and I am going to choose the following “EvidenceOfExecution, RegistryHives, and FilSystem. 

This step will just collect the evidence file. To parse these files, you need to choose it from the modules, For this example, I will choose “JLECmd,MFTECmd_$MFT,RegRipper-sam and RegRipper-security “.

Unfortunately, some of the modules do not come by default with KAPE. One of these modules is reg.exe. but that’s not the end of the world, you can just go kape\modules and open the yaml of the specific module. In this example, I am going to open RegRipper-sam.mkape and check which additional module does it need. 

 

Now just follow the instructions in the file. You need to specify the output directory for both Target and Modules.Now back to the gkape and click “Execute”.   Or if you would like to run it from a command line you can just copy the command line version of the same selection from current command line section 

 

 

Late last week, news emerged about a potential new vulnerability in WebLogic [1]. The vulnerability was first reported to the Chinese National Vulnerability Database (CNVD). A proof of concept exploit labeled "CVE-2018-2628" was made available at the same time. The name of the exploit caused some confusion.  CVE-2018-2628 refers to a WebLogic vulnerability that was fixed last year in Oracle's April critical patch update.

On Friday, Oracle released a statement clarifying the issue [2]. The vulnerability is new and was not patched by any critical patch update, including the last one released this month. Oracle assigned CVE-2019-2725 to identify this new vulnerability. On Friday, Oracle released a patch for WebLogic 10.3.6. A patch for WebLogic 12.1.3 should be released on Monday (today) April 29th.

We already see active exploits of the vulnerability to install crypto coin miners in our honeypot. The proof of concept exploit released last week allows the trivial install of a shell on a WebLogic server. However, remember that our honeypots are not "special" in the sense that they are only seeing random exploits. We have to assume that at the same time, targeted attacks are underway to wreak more havoc.

[pcap file of some test runs of one of the exploits against a vulnerable server]

If you find a vulnerable server in your environment, assume that it has been compromised. Do not just remove the coin miner. There may have been additional attacks.

CVE-2019-2725 is yet another deserializing vulnerability affecting WebLogic. WebLogic's design makes it particularly prone to these types of vulnerabilities. Do not expose WebLogic to the Internet if you can help it. I doubt that this was the last such vulnerability.

A quick look at the patch shows that it includes the "validate" function that was added and later enhanced in response to similar flaws. But a quick look didn't show any obvious additions. NSFocus had a great discussion of this function following prior vulnerabilities [3]. 

On our test server, we only saw logs indicating an attack if the script the attacker attempted to execute failed. For example, in the sample below, the attacker tried to execute "wget", but "wget" was not installed on the system:

####<Apr 28, 2019 10:47:02 PM UTC> <Error> <HTTP> <0aa00a61ebfc> <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1556491622309> <BEA-101019> <[ServletContext@2141998910[app:bea_wls_internal module:bea_wls_internal.war path:/bea_wls_internal spec-version:null]] Servlet failed with IOException
java.io.IOException: Cannot run program "wget": java.io.IOException: error=2, No such file or directory

I will try to update this post on Monday as we learn more.

(thanks to our handler Renato Marino to significantly contribute to this post)

[1] https://isc.sans.edu/forums/diary/Unpatched+Vulnerability+Alert+WebLogic+Zero+Day/24880/
[2] https://www.oracle.com/technetwork/security-advisory/alert-cve-2019-2725-5466295.html
[3] https://blog.nsfocusglobal.com/threats/vulnerability-analysis/technical-analysis-and-solution-of-weblogic-server-wls-component-vulnerability/

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
Twitter|

In diary entry "Dissecting a CVE-2017-11882 Exploit" I analyze an equation editor exploit. These kind of exploits have become prevalent, I often see malware exploiting this vulnerability.

In my diary entry, I use my tool format-bytes.py to dissect the exploit using a long string of format specifiers. This is not practical if you have to do this often:

That's why I have now added a library of format strings to my tool format-bytes.py, eqn1 is the format string to use for this exploit:

So in stead of typing "-f "<HIHIIIIIBBBBBBBBBB40s..." ", you can now just type: "-f name=eqn1".

 

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

In our "pretend pentest" that we've been running these last few days, we've now got all the domain admins listed, all the service accounts found and listed, and the intersection of those two things - the service accounts that are either local admin or domain admin.
So what's the obvious next step?  Let's recover the passwords for those target service accounts!  Because once we have the full credentials, we have admin rights that no SEIM or systems admin will be tracking the use of - these accounts are almost universally ignored, since they login every time those services start (say during a system restart).  So if this is for instance a service account with domain or local admin rights that's on every server and workstation, you are now "better than domain admin".  You have all the rights, but no system controls are watching you!

Let's get on with the job at hand.

First of all, credentials for service accounts are stored in the local registry, as what's called "LSA Secrets" in the registry key HKEY_LOCAL_MACHINE/Security/Policy/Secrets.  Because the service needs to read the actual password to login as the service account, that password is in the registry in clear-text.  Yup, you read that right - this is why service accounts are such a great target.  LSA Secrets are well protected however, you can't just fire up regedt32 and read them - only the SYSTEM account has rights.  So you need ... yes, some powershell!  Not only that, many of today's tools are based on some powershell posted way back in the day on microsoft.com!
https://gallery.technet.microsoft.com/scriptcenter/Enable-TSDuplicateToken-6f485980
https://gallery.technet.microsoft.com/scriptcenter/Get-TSLSASecret-9bf94965
(Thanks TrueSec!!  In fact, thanks from all of us! )

Or if you're not in the mood for PowerShell, you could use some Python tools, or Metasploit or Mimikatz works too - choose your own adventure!  Often you'll need to try a few different methods, and then maybe wrap one in some "AV evasion" code to make it work for you, but the results are worth it in the end!!

Nishang

Those original scripts from microsoft don't work on modern hosts with any patches applied at all, but of course there's a toolkit that's improved on these scripts over time.  I generally use Nishang for the PowerShell-centric "I'm on the box" approach to LSA Secret recovery
Nishang can run locally on the Windows host being targetted, or you can of course use PSRemoting.  The problem with this tool is that if there's an AV product in play anywhere in the chain, it will very likely have a problem with you running Nishang.  In fact, even downloading this on a Windows host with a default install (ie - with W10 Windows Defender in play) can be a problem.

Anyway, once it's installed, the execution if pretty straightforward:

> Import-Module .\nishang\Gather\Get-LSASecret.ps1 > Import-Module ./nishang/Escalation/Enable-DuplicateToken.ps1 > Enable-DuplicateToken > Get-LSASecret Name                                Account        Secret                ComputerName ----                                -------        ------                ------------ ... ... _SC_Service Name Being Targeted    .\SVCAccount    Passw0rd123           ComputerName

Metasploit

Metasploit of course has a module for this. You can run it locally or (more likely) remotely.  The module is post/windows/gather/lsa_secrets.
Because endpoint protection programs tend to focus so much on Metasploit (which of course tells us just how good this tool is), you need to be careful where and how you run it if the goal is to get this job done with any degree of stealth.  You'll want to put some up-front work into evading whatever your client has for AV - this work pays off in all kinds of ways if the pentest you're running is longer than a few days.  This method does a great job though, even though (depending on the module you're running) it'll tend to scream at the AV solutions "Look! Look at me! I'm running Metasploit!"
The MetaSploit method is a simple as "run post/windows/gather/lsa_secrets"

For me the most attractive thing about using Metasploit is that you can script the exploits.  So if you need to, you can run 4-5-6 exploits against hundreds of machines in one go.

Dumping LSASS

You can dump the LSASS process memory and recover service passwords (and a ton of other stuff too) from that, but that becomes less and less reliable over time as Microsoft puts more fences and protections around LSASS.  I've never had to go this way on a real engagement.  The easier method is to run the MimiKatz PowerShell Module and just watch the magic happen.  That is if you put the work into evasion against your endpoint protection solution to allow MimiKatz to run.

Impacket

Impacket makes a great little python based tool to accomplish the same thing.  This is my first, go-to, it almost always works method - mainly because all you run on the target host is standard windows commands, then the rest of the attack is on the attacker's host.  This makes it the least likely of these methods to trigger any AV alerts or other security measures.

First, from the local host we dump the 3 registry hives that are in play:

reg save hklm\sam sam.out reg save hklm\security security.out reg save hklm\system system.out

Now take those files and get thee to your Kali VM!   If you don't have impacket installed yet (it's not in the default install), there's no time like the present.  To install:

$ sudo apt-get install python-dev python-pip -y $ pip install --upgrade pip $ sudo pip install pycrypto pyasn1 pyOpenSSL ldapdomaindump $ git clone https://github.com/CoreSecurity/impacket.git $ cd impacket $ sudo python setup.py install

(in most cases you don't need all of those pre-reqs, I put them all in just in case).  Now you're good to go:

impacket-secretsdump -sam ./sam.out -security ./security.out -system ./system.out LOCAL

(you'll find a bunch of other interesting security stuff in this tool's output - all the local account password hashes for one thing!)

At the bottom of the output, you'll see what we're looking for, the locally stored password for that service account!!  In this case I put a "fake" account on my SFTP server service (Solarwinds SFTP doesn't have a service account by default).

That's it - no fuss, no muss, and best of all, nothing to trigger AV or any similar "endpoint next-gen machine-learning AI user behavioural analysis security" product on the target host.

 

Other tools like CrackMapExec do a good job as well - I haven't used that one specifically yet, really the impacket method has done the job for me so far.  While I tend to have a "try one or two new things" or "write one new tool" rule for each test, I haven't gotten around to using any other tools for this particular thing.  

Do you use a different tool to dump service passwords?  Does your tool collect more useful information than just that particular thing?  Or maybe you've got a cool AV evasion that relates to this?   Please, use our comment form and share your experiences on this!

=============
Rob VandenBrink
Compugen

Back in 2015 I wrote up a "find the service accounts" story  - https://isc.sans.edu/forums/diary/Windows+Service+Accounts+Why+Theyre+Evil+and+Why+Pentesters+Love+them/20029/ (yes, it really has been that long).  The approach I wrote up then used WMIC.  Those scripts saw a lot of use back in the day, but don't reflect the fastest or most efficient way to collect this information - I thought today was a good day to cover how to do this much quicker in PowerShell.

Why would you need to do this?  In a penetration test or an internal security assessment, you normally want to enumerate any services that don't use the built-in Microsoft Service Accounts.  This is because actual service accounts almost never see a password change, and almost always are given local administrator or domain administrator rights.  Mainly because if you're going to be a software vendor that's dumb enough to still use Windows XP era service accounts, you might as well go all the way and make those accounts Domain Admin for any malware that wants to collect those passwords (stay tuned, we'll be doing this tomorrow!).  Microsoft's current recommended approach is to use the various built-in service accounts for services.  These don't have passwords, and can't be used for lateral movement to other workstations or servers.

That being said, let's pretend to be malware and collect those service accounts across an AD domain!

$targets =get-adcomputer -filter * -Property DNSHostName $vallist = @() $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) {     $vallist += Get-WmiObject Win32_service -Computer $targethost.DNSHostName | select-object systemname, displayname, startname, state     ++$i     }   } $vallist | export-csv all-services.csv

A few things to discuss.
First of all, $i, $count, and the "write-host" line are there just so that if you have several thousand hosts to enumerate, you can ensure that your script isn't hung, and how far along it might be at any given time.

The "Test-connection" check is there so that you don't wait several seconds trying to connect up to remote hosts that might not be up.

Also, this can only enumerate hosts that are actually up and accept a connection - you likely want to run this script during the day.  If you start your script and see that it's going to take longer than a business day to complete (for a larger domain for instance), you might want to pause it towards the end of the business day, and restart it the next morning after everyone is back at their desks.

OK - so now that the script has run, what have we found?  What we have is the list of **all** services that are installed on all hosts in the domain, along with the account that's used to start the service.

This is great for system admins looking for one thing or another, but for most security purposes you don't want the ones that are using the built-in service accounts.  To filter those out, you want to remove any service that is started by these accounts:

• NT AUTHORITY\LocalService
• LocalSystem
• NT AUTHORITY\NetworkService
• or an empty field

To do this, add these lines to the bottom of your script

$filtlist = @("LocalService", "LocalSystem", "NetworkService", "NT AUTHORITY\LocalService", "NT AUTHORITY\NetworkService", "NT AUTHORITY\NETWORK SERVICE", "NT AUTHORITY\LOCAL SERVICE") $TargetServices = $vallist | Where-Object { $filtlist -notcontains $_.startname } $TargetServices | export-csv bad-services.csv

Things to note in this bit of code?  the "contains" and "notcontains" operators are case-insensitive, so you upper / lower case doesn't matter in your filter.

So, what can we do with this list if we're attacking a domain?  We can use the domain admin and local admin lists that we sleuthed yesterday, and see which of these service passwords are domain admins!

Let's take that list of $TargetServices, and list the offending accounts:

$TargetSVCAccounts = $TargetServices.startname | Sort-Object -Unique AD\biztalkhost ad\AppService AD\BizRuleEngine AD\SSOService AD\SQLService ServiceAccount@ad.com

In a different domain it's common to also see service accounts that are local to the machine being enumerated, often those will have local admin rights, and often you'll find that those same (local admin) service userid and password are used on all workstations and often on all servers - which gets you almost the same access as domain admin rights (oops).

Normally the lists that come out of these scripts are short enough that I can compare them by eye to the list of local and domain admins we collected in yesterday's story.  But if you have one of those unfortunate domains where dozens or hundreds of people have domain or local admin rights, you might want to add a bit more code:

$SVCDomAdmins = @() $Admins = $DomainAdmins.SAMAccountName.toupper() Foreach ($Acct in $TargetSVCAccounts) {     $a = $Acct.toUpper().Trim("AD\").Trim("@AD.COM")     if ($Admins.Contains($a)) {$SVCDomAdmins += $a}     } $SVCDomAdmins | Sort-Object -Unique | export-csv Service-DomainAdmins.csv

To find Service Accounts that are local admins, it's the exact same code, but replace line 2 with "$Admins += $localadmins.AdminID.toupper()"

If you have a minute today, try this on your domain - use our comment form to let us know if you find anything interesting!

What will we do with this list of accounts next?  Stay tuned for the next installment tomorrow :-)

 

===============
Rob VandenBrink
Compugen

The news today is full of a new deserialization vulnerability in Oracle WebLogic.  This affects all current versions of the product (the POC is against 10.3, but 12.x versions are also affected).  The vulnerability affects the wls9_async_response package (which is not included by default in all builds), so the workaround is to either ACL the Z/_async/* and /wls-wsat/* paths, or delete wls9_async_response.war.  A successful attack gets the attacker remote code exec on the vulnerable server.

The root cause here seems to be that the affected WAR components ingest and process all serialized data, and have a blocklist of "bad" content.  What this means to me is that we're likely to see a number of similar vulnerabilities / attacks crop up over the next while, until Oracle changes this approach.

Indications are that this is in the "tens of thousands" of affected sites, not hundreds or thousands or millions (not yet at least).

The vulnerability is posted as CNVD-2018-07811 (China National Vulnerability Database) at http://www.cnvd.org.cn/flaw/show/CNVD-2018-07811.  We don't have a CVE yet.

This bug was originally disclosed by the China Minsheng Banking Co.  There's a good write-up by the KnownSec 404 Team with  a bit more detail here: https://medium.com/@knownseczoomeye/knownsec-404-team-oracle-weblogic-deserialization-rce-vulnerability-0day-alert-90dd9a79ae93

This comes just one week after Oracle's "Patch Everything" Critical Patch Update (CPU) last week.  The next CPU isn't due for 3 months, so it'll be interesting to see what the out-of-band response patch or patches (if any) to this might be.

Stay tuned - we'll udpate this story as we get more information - in particular if we see attacks in the wild we'll post IoC's as we get them.

======= Update 1 =======

Thanks to our reader who commented below!

The matching CVE number for this is CVE-2018-2628, which was identified as patched last year (Oracle's CPU - Critical Patch Updates found here https://www.oracle.com/technetwork/security-advisory/cpuapr2018-3678067.html ).  However the POC mentioned was against a patched server, so I guess the patch isn't complete - nor can it be given Oracle's approach against this issue.

======= Update 2 =======

POC posts are at:
https://twitter.com/jas502n/status/1121120045617176576
https://twitter.com/jas502n/status/1120911506785230848

POC code is here (we have not tested this, so use this at your own risk):
https://github.com/jas502n/CVE-2018-2628

======== Update 3 ==============

Thanks to one of our readers ("anonymous" in the comment section :-) ) who gave us the heads-up that Oracle gave this a new CVE and has released a patch for it.

https://www.oracle.com/technetwork/security-advisory/alert-cve-2019-2725-5466295.html
https://blogs.oracle.com/security/security-alert-cve-2019-2725-released

Note though that the underlying vulnerability for all of these problems is how the associated attacks are detected - with a blocklist of "known badness" for deserialization.  What this means is that while this specific case has been patched for, we should look for similar, perhaps even nearly-identical issues to continue to crop up on this product.  Even with the patch out, for this reason I'd still suggest that WebLogic admins disable or ACL the affected WAR components if at all possible.  If not, be sure that your server is virtualized and you have an image backup, you might need it

Now that we've got a list of domain admins ( https://isc.sans.edu/forums/diary/Where+have+all+the+Domain+Admins+gone+Rooting+out+Unwanted+Domain+Administrators/24874 ), lets find all the accounts that have local Administrator rights.
Local Admin used to be a common thing, back in the early XP days when Windows Security was new.  It was common back then to see everyone's AD account have local admin on their own machine, so that they could do things like update the clock, install printer drivers, or install games when they took their laptop home.

Sound familiar?  Well, those days are gone (or they should be).  In 99% of cases, you absolutely, positively do NOT need local admin for anything on a domain member computer (especially if it's not a server) that's administered by IT staff.  You might need an extra right here or there, but even then, it's very likely that you don't.  Windows 10 and even Windows 7 both do a good job without giving folks admin rights.  (We won't talk about that dark Windows 8 detour that nobody took, but W8 does just as good a job on this score)

What local admin does give you is rights that you shouldn't have, to perhaps install malware that might then access system files that nobody wants changed.  And if you don't use LAPS, local admin on one station will likely give you local admin on ALL the stations, which from a malware point of view is as good as domain admin in lots of organizations.

So let's get on with it - to find local admins across the board, you'll want something that looks like this:

import-module ActiveDirectory function get-localadmin {   param ($strcomputer)   $admins = Gwmi win32_groupuser –computer $strcomputer     $admins = $admins |? {$_.groupcomponent –like '*"Administrators"'}   $admins |% {     $_.partcomponent –match “.+Domain\=(.+)\,Name\=(.+)$” > $nul     $matches[1].trim('"') + “\” + $matches[2].trim('"')   } } $i = 1 $localadmins = @() $targets = Get-ADComputer -Filter * -Property DNSHostName foreach ($targethost in $targets) {   write-host "Testing" $targethost.DNSHostName "," $i "hosts completed"   if (Test-Connection -ComputerName $targethost.DNSHostName -count 2 -Quiet) {     $admins = get-localadmin $targethost.DNSHostName     foreach ($a in $admins) {       $val = new-object psobject       $val | add-member -membertype NoteProperty -name Hostname -value $targethost.name       $val | add-member -membertype NoteProperty -name AdminID -value $a       $localadmins += $val       }   ++$i   } } $localadmins | export-csv -append localadminusers.csv

Note that this code will grab everything, so when it hits the domain controllers it'll enumerate domain admins (which is the honest truth when you think about it).  Note also that if a station is not on the network when you run this script, of course you won't be able to enumerate any user information from it.

Run this on your own domain, user our comment form let us know if you find anything unexpected!

===============
Rob VandenBrink
Compugen

Ever been in an internal security assessment or penetration test, and need to list all domain admins?
First of all, why would you need to do that?  All to often, you'll find that way too many people have domain admins - you know, "just in case"
People like:

• developers - who needed local admin on that one server, that one time, but we gave them domain admin and then forgot
• or developers, because don't all devs need domain admin?
• IT VP's and dev managers, because they used to be admins
• the CEO, because they insisted
• Steve, because Steve needed to update the timezone or install a printer at home, and the helpdesk mistakenly gave Steve domain admin rights for that

You get the idea.

So, aside from the people that are actual members of "Domain Admins", there are lots of groups that have elevated privileges in a domain, so we'll need to enumerate all of those too.  And you can put groups into groups, so we'll have to recurse through that mess to get the full list of users.  This can take quite a while in the GUI, but it's only a few lines of code in PowerShell:

This will list all the Admin users, and the group membership that put them there.  So you might find the same person on this list a few times (but that's a good thing in most cases).

If you just want the de-dup'd list of unique userids (without how they got there), add this snip to your code:

When you run this against your domain, what is your percentage?  Did you find any surprises?  Please, use our comment form and let us know!

A couple of years ago, we posted diary entry "VBA and P-code": we featured a VBA P-code disassembler developed by Dr. Bontchev. VBA source code is compiled into P-code, which is stored alongside the compressed source code into the ole file with VBA macros.

Dr. Bontchev also published a PoC Word document with VBA code: it contained just the P-code, and no VBA source code. Hence to analyze the document, you could not extract the source code, but you had to disassemble the P-code with pcodedmp.py.

Yesterday, I was pointed towards a malicious Word document found in-the-wild that was hard to analyze. It turned out the VBA source code had been wiped (recently, this method has also been referred to as VBA stomping).

Here's how I analyzed this document. First, I get this output with oledump.py:

With this output and the context I was given, I can already conclude that this is a malicious document: the recipient received an unexpected .docm file from an unknown sender -> maldoc.

Remark also that stream A3 has no M indicator, while its name (Module1) indicates it should contain VBA code. That's why I use option -i to get more info:

For every stream with VBA code, option -i will display 2 numbers: the size of the compiled code (P-code) and the size of the compressed VBA source code.

For stream A3, I see that the compressed VBA code is 1280 bytes in size. So why is there no M indicator?

Decompressing the VBA code throws an error:

I take a look at the raw, compressed VBA code (using suffix s for source code):

It has been wiped: the compressed VBA code has been overwritten with 0x00 bytes!

If you were still unsure if this document was malicious or not: now you can cast aside any doubt. Microsoft Office applications do not produce documents like this. This document has been tampered with to try to bypass AV detection.

And if your job is to determine if a document like this is malicious or not, you can report your findings now: this is a maldoc.

But if you need to figure out what this maldoc does, there's a bit more to analyze.

Using suffix c (compiled), I select all bytes that make up the P-code:

Notice strings Winmgts and Win32_Process (reversed): it looks like this maldoc creates a new process via WMI.

Now I'm using pcodedmp.py to look at the disassembly:

Here is the disassembled P-code. P-code is executed by a stack machine: first arguments are put on the stack, and then functions are called that pop arguments from the stack and push results to the stack.

Here I see a string constant (consisting of digits) assigned to variable E_MO, and then passed as argument to function B_RA, who's output is used as argument to CreateObject. The result is assigned to variable F_DC. Thus the string is an obfuscated object name, and function B_RA does the deobfuscation.

In the following screenshot, I see a variable (SP_LL) of the Word document (ActiveDocument) that is passed to function B_RA, to be deobfuscated, and then executed (F_DC.Exec).

And here is function B_RA:

It contains a For loop, function Mid is used to select substrings of 3 characters long, which are then converted to an integer and then have 0x1A (26) subtracted from them, to be finally converted to a character. With this information, I can make an educated guess on how to decode the obfuscated string.

But first, I need to find the value of variable SP_LL. Since this is a .docm file, I need to search into XML files contained in a ZIP file. zipdump.py with its YARA functionality is what I need here:

File settings.xml contains variable SP_LL:

With re-search.py and a regular expression to match strings of 10 digits or longer, I extract the value for SP_LL (a long string of digits):

Next I need to break this string up in substrings of 3 digits. I can do this too with re-search.py, and a regular expression for 3 digits:

Now I need to convert these numbers to characters. numbers-to-string.py was designed to do just this. I use option -n 1 to process one number per line (by default, numbers-to-string.py expects at least 3 numbers per line):

This is not yet the decoded string we want: I need to subtract 26 from each number, like this:

Here I recognize cmd.exe ... Finally, I use option -j to join all lines into a single line:

And this is a command that launches PowerShell with a downloader script.

 

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

Reader Carlos submitted an email with attached RAR file.

In the past, when you received a RAR file as attachment in an unexpected email, it often contained a single malicious Windows executable. For the infection to occur, one would have to open the attachment and double-click the executable.

Nowadays, a RAR file can also be an ACE exploit, like the popular %%cve:2018-20250%%. Infection typically occurs by opening the attachment, and then restarting the computer or performing a logoff/logon cycle.

With oledump.py and plugin plugin_msg.py, one can inspect .msg files:

There's an attachment with extension .rar:

And it is indeed a RAR file containing an executable.

If it would be an ACE file masquerading as a RAR file (.rar extension in stead of .ace), one would see the following:

The binary data does not start with "Rar!", instead, one will see "**ACE**" a few bytes into the binary data.

The example above is a normal ACE file. ACE files with a path traversal exploit will have an abnormal path stored in the ACE file:

 

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

Yesterday, Xavier wrote a diary entry about malicious UDF files.

I wrote about the analysis of .ISO files before, and it turns out the same techniques work for UDF files too.

Python module isoparser can also parse UDF files:

We can retrieve the content:

And calculate the hash of the contained EXE:

 

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

I found an interesting phishing email which was delivered with a malicious attachment: an UDF image (.img). UDF means “Universal Disk Format” and, as said by Wikipedia[1], is an open vendor-neutral file system for computer data storage. It has supplented the well-known ISO 9660 format (used for burning CD & DVD) that was also used in previous campaign to deliver malicious files[2].

Here is a copy of the mail:

From: <redacted>
To: <redacted>
Subject: Overdue Invoice
Valued customer,
Attached is your invoice as scheduled, your credit/debit card will be charged. Your bill will be delivered along with your ordered items(s).
Please review the receipt at your earliest convenience and get back to us in case of anomalies.

Thank you for your continued patronage.

Warm regards.

The attached files was called "invoice#003.img" with the SHA256 hash: 886338ebc04e728338874b07365d4fd337998e1786893b680065358e815a6d02. At the moment, the file is flagged by 23 AV on Virustotal[3]. To read the content of the archive safely, you can use the ‘loop’ driver on a Linux system:

# mount -o loop /tmp/invoice\#003.img /mnt/malicious/
# ls -l /mnt/malicious
total 1296
-r-xr-xr-x 1 nobody nogroup 1325568 Apr 14 23:45 invoice#003.exe
# shasum -a 256 /tmp/malicious/invoice*
b3aef0e1d7a71edbc858a81e66f354be1974aafdd4449f2972e4dae1c82f2b8a  /mnt/malicious/invoice#003.exe

Here, the VT score is 35[4], it’s a classic malware written in AutoIT, nothing special. It tries to connect to kingdevil[.]ddns[.]net:4156.
Let’s have a look at the UDF image:

00008220: 2020 2020 2020 2020 2020 2020 2020 2020
00008230: 2020 2020 2020 2020 2020 2020 2020 494d                IM
00008240: 4742 5552 4e20 5632 2e35 2e38 2e30 202d  GBURN V2.5.8.0 -
00008250: 2054 4845 2055 4c54 494d 4154 4520 494d   THE ULTIMATE IM
00008260: 4147 4520 4255 524e 4552 2120 2020 2020  AGE BURNER!
00008270: 2020 2020 2020 2020 2020 2020 2020 2020
00008280: 2020 2020 2020 2020 2020 2020 2020 2020
00008290: 2020 2020 2020 2020 2020 2020 2020 2020
000082a0: 2020 2020 2020 2020 2020 2020 2020 2020
000082b0: 2020 2020 2020 2020 2020 2020 2020 2020
000082c0: 2020 2020 2020 2020 2020 2020 2020 2020
000082d0: 2020 2020 2020 2020 2020 2020 2020 2020
000082e0: 2020 2020 2020 2020 2020 2020 2020 2020
000082f0: 2020 2020 2020 2020 2020 2020 2020 2020
00008300: 2020 2020 2020 2020 2020 2020 2020 2020
00008310: 2020 2020 2020 2020 2020 2020 2020 2020
00008320: 2020 2020 2020 2020 2020 2020 2032 3031               201
00008330: 3930 3431 3530 3034 3635 3430 300c 3230  9041500465400.20
00008340: 3139 3034 3135 3030 3436 3534 3030 0c30  19041500465400.0
00008350: 3030 3030 3030 3030 3030 3030 3030 3000  000000000000000.
00008360: 3030 3030 3030 3030 3030 3030 3030 3030  0000000000000000
00008370: 0001 0049 6d67 4275 726e 2076 322e 352e  ...ImgBurn v2.5.
00008380: 382e 3000 0000 0000 0000 0000 0000 0000  8.0.............

ImgBurn is a well-known Windows tool used to create CD/DVD images[5] and guess what? A stock Windows handle this type of file without any extra tool:

So be careful with .img files! They should also be added to the list of prohibited file extensions in your mail relays or change the file association in your Windows environments to NOT open them Windowd Explorer.

[1] https://en.wikipedia.org/wiki/Universal_Disk_Format
[2] https://isc.sans.edu/forums/diary/Malicious+iso+Attachments/22636
[3] https://www.virustotal.com/#/file/886338ebc04e728338874b07365d4fd337998e1786893b680065358e815a6d02/relations
[4] https://www.virustotal.com/#/file/b3aef0e1d7a71edbc858a81e66f354be1974aafdd4449f2972e4dae1c82f2b8a/detection
[5] https://www.imgburn.com

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

Continuing with my preliminary exploration of Ghidra. If we continue with the call to RegOpenKeyExA from last time (yes, I know this code is unreachable as we discussed last time, but let's keep going anyway).

If we look back up at the first parameter, we see 0x80000001. Off the top of my head, I don't remember which key that is (well, actually, I've been doing this long enough that I do, but let's pretend that I don't). In IDA, I'd right-click on that hex value and choose 'Use standard symbolic constant' to replace that with the constant definition from one of the Windows header files that defines those. It turns out, Ghidra lets us do this, too. In Ghidra, right click and choose 'Set Equate' and it pops up a dialog box similar to IDA's from which you can choose the proper constant to use in place of the hex value.

Just like in IDA, if you know the constants for registry keys start with 'HKEY_' (or you looked it up on MSDN, now known as, docs.microsoft.com) you could start typing that and it would narrow down the choices. In this case, it is easily visible. So, double-click on 'HKEY_CURRENT_USER' or click and choose OK and the constant is replaced. Notice that you have the option here to just do the substitution for this one instance or across the entire program. I'm going to leave this at the default, but there may be times when you want to replace the hex value with the symbolic constant everywhere (nearly every time I teach FOR610 a student will ask me if IDA has that capability and, if it does, I'm not aware of it).

Looking above that at the second parameter, I usually want to know which particular subkey is being opened. In IDA, I just hover over the label for the string and it shows me the entire string. In Ghidra, if I hover over it, it shows me part of the string, but not the whole thing. Hmm... That is a bit of a problem. If I double-click on the label, both IDA and Ghidra take me to the place in memory where the string is located, but again, Ghidra doesn't show me the entire string. In the hex column it only shows me the first 9 bytes in hex and then gives me the ellipsis, but in the string part, it still doesn't show the whole thing. It shows the first 40-something characters and then the ellipsis.

In hunting around, I was not able to find a setting to increase that, though I'm sure there must be a way somewhere. If not in a setting, then in the code itself (which is now available on github). You can see the entire string though, if you go through the Search menu (choosing 'For Strings...' option). In this case, since I could see the CurrentVersion substring, I just searched for that and found the following.

In the end, though, I realized I didn't need to go to that much effort, there was a much easier way to see the string. Just go back to the decompiler window. As I mentioned in the previous diary, one way that the decompiler makes our lives as malware analysts much easier is it saves us the effort of having to try to match up the PUSHes or MOVes to figure out which parameter is which. This is especially true when you get into 64-bit malware on Windows which uses a lot more fastcall and the MOVes into registers may not appear in the order you expect. So, when I glance over into the decompiler window, I see this.

Very nice, it has my symbolic constant, it shows the entire string. That's just about everything I think I need to know about that API call.

I think that's enough for this diary, I have at least one more to come (probably next week). Again, as I mentioned in the first 2 entries in this series, this is all just from a very brief time playing with Ghidra. I haven't had a lot of time to dig deep yet, but so far, I'm liking what I'm finding. If you have any thoughts, comments, corrections, or tips of your own, please e-mail me or use the comments below.

---------------
Jim Clausing, GIAC GSE #26
jclausing --at-- isc [dot] sans (dot) edu

If you ever heard me talk about DNS, you will know that I am a big fan of monitoring DNS queries, and I think DNS query logs are the best "band for the buck" log source to detect anomalous behavior. Everything that happens on your network, good or bad, tends to be reflected in DNS.

But there are a couple common "odd" DNS request types that are often mistaken for malicious, or unusual but are actually quite normal. Here are my favorite once:

- Anti Malware Checks:

I got an example from Sophos Anti Virus here, but other vendors use a similar technique:

0.0.3.0.0.0.0.0.0.2.0.0.0.0.1.01.00.sfi_unknown.f.01.mac.sophosxl.net
0.0.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.sfi_unknown.b.f.01.mac.sophosxl.net
3.1o19sr00s2s17s4qp3759pn9ro30n2n4n941on29s3s35qppp742380s6487np3.poqp0r741pn37393648s20n65203rn4o44387s5831o276q6s5rqsr16n809qp4.86752ss34q9sns005o.35n2s0s521p9rn7o75q0r479rpqq7o0oq6r6o20p.i.01.mac.sophosxl.net
3.1o18sr00s2s17s4qp3759pn9ro30n2n4n941on29s3s35qppp742380s6487np3.poqp0r741pn37393648s2779qp6or2108n4o66o276n931p8287709r73q098rp.86752ss34q9sns005o3pp76q83qr6344r79q7rpns9.485n1675n4750q4n.i.01.mac.sophosxl.net
0.0.3.0.0.0.0.0.0.2.0.0.0.0.1.01.00.sfi_unknown.f.01.mac.sophosxl.net
0.0.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.sfi_unknown.b.f.01.mac.sophosxl.net
3.1o19sr00s2s17s4qp3759pn9ro30n2n4n941on29s3s35qppp742380s6487np3.poqp0r741pn37393648s20n65203rn4o44387s5831o276q6s5rqsr16n809qp4.86752ss34q9sns005o.35n2s0s521p9rn7o75q0r479rpqq7o0oq6r6o20p.i.01.mac.sophosxl.net
3.1o18sr00s2s17s4qp3759pn9ro30n2n4n941on29s3s35qppp742380s6487np3.poqp0r741pn37393648s2779qp6or2108n4o66o276n931p8287709r73q098rp.86752ss34q9sns005o3pp76q83qr6344r79q7rpns9.485n1675n4750q4n.i.01.mac.sophosxl.net

At first sight, you may mistake these requests for typical DNS covert channels. But they are actually associated with Sophos Antivirus. The reason for these queries is that Anti-Malware uses DNS to check if certain files are malicious. The software will send a hash of the file to the vendor and receive back an indication if the file is malicious or not. This will also allow the vendor to compile statistics on the popularity of certain software which will then often be used to compile risk scores (sorry... feed a machine learning AI engine that will protect you from 0-day attacks... or something like this if you read the vendor ads for various products like this). In some ways, this is an exfiltration activity. Just not malicious.

- Mail Servers

We all know that clients usually try to resolve A or AAAA records. But let's take a look at the snapshot below of the records types from a quick query log sample (collected via bro in this case):

The high percentage of PTR records may appear odd. In this case, however, the network includes a busy mail server. Mail servers, for anti-spam filtering, often resolve IP addresses to match forward and reverse resolution.

- Other .arpa hostnames

Talking about PTR records. Pretty much everybody reading this, probably knows about in-addr.arpa and ipv6.arpa and how it is used for reverse resolution. But these are not the only ".arpa" records you see. One record I see more and more is ipv4only.arpa. This record is used to detect if the host is on an IPv6 only network, and DNS64 is used to map IPv4 addresses to IPv6. This record should resolve to 192.0.0.170/171. Only the A record exists. For a AAAA query, you will not get an answer unless your name servers (do to DNS64), is making one up. There are actually a few more .arpa hostnames but this is the one I usually see quite frequently.

- develooper.com

When I saw this first, it looked like a typosquatting domain to me. But the company behind this domain is an active contributor to a number of open source projects, and in my case, it was their contribution of resources to perl.org that triggered the DNS requests.

Any odd DNS requests that you ran down to only find them to be harmless?

 

 

 

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
Twitter|

Currently, the majority of HTTP traffic uses TLS (HTTPS) [1]. This is in part due to free and easy to manage certificates from Let's Encrypt, but also due to HTTP Strict Transport Security, an HTTP header that will tell browsers to only connect to your site via HTTPS [2].

For email, we typically use TLS to connect from our mail client to our mail server. But for email, the weak link is connections between mail servers as they forward email. Years ago, STARTTLS became a popular feature. It does allow servers to discover that the other server supports TLS, and upgrades can happen "on the fly". The system is very simple and efficient, but suffers a major shortcoming: The initial connection is in the clear without TLS, and an adversary may easily alter the content, removing the TLS header, so users will never know that their server sent the email in the clear [3].

More recently, two new standards emerged: MTA-STS (SMTP MTA Strict Transport Security) which can be used to advertise that your mail server supports STARTTLS [5], and SMTP TLS Reporting which allows other mail servers to send you reports about whether or not your mail server responded properly to TLS.

Implementing these standards for your domain is a bit tricky. In this post, I will talk about implementing MTA-STS and TLS Reporting for your domain. I will not talk about how to tell your mail server to verify MTA-STS as it sends email, or how to send TLS reports.

There are two parts to these standards: DNS TXT records that advertise that you are supporting them, and a policy file with details that is served via HTTPS.

Step 1:

First of all, make sure your systems are configured correctly and are using proper TLS certificates. In particular mail servers often use bad certificates as you can get away with it. But once you have MTA STS enabled, all these checks need to pass. As a quick check, I recommend hardenize.com (I found the cache doesn't always get cleared if you re-test, so you may wait a while or do some manual checks after the initial check with hardenize). Hardenize was created by Ivan Ristic who also created the famous ssllabs test. But unlike ssllabs, hardenize goes beyond just https and beyond just basic TLS issues.

After you pass all the tests, it is time to get started on MTA-STS

Step 2: 

Setup a virtual host at "mta-sts.example.com". The hostname has to be "mta-sts". You could add this host name to your existing web server, but it may be cleaner to set up a distinct server (virtual host) for this hostname. It has to support TLS, so make sure to setup TLS and probably a Let's Encrypt certificate with it.

Step 3:

Create the policy file. The policy file has to live in mta-sts.example.com/.well-known/mta-sts.txt . The file is a simple text file. For example:

version: STSv1
mode: testing
mx: isc.sans.edu
mx: mail.dshield.org
max_age: 600

The version should always be "STSv1". The mode can be "testing" (do not enforce the policy), "enforce" or "none". Starting with "testing" is recommended. Next, you list your mail servers. The max_age indicates how many seconds the policy is cashed. Start with something short like 10 minutes until you got it all right.

Test that the policy can be retrieved and it should be returned with a Content-Type of "text/plain".

Step 4:

Next, you need to add two DNS entries. One for MTA-STS and one for SMTP TLS Reporting:

_mta-sts.example.com TXT "v=STSv1; id=201904131609"

Again, the version is always STSv1. The ID can be any string. It is used to detect if the policy changed.

_smtp._tls.example.com TXT "v=TLSRPTv1; rua=mailto:postmaster@example.com"

The version is again fixed. the "rua" part indicates where to send the reports. you may list multiple email addresses separated by a comma. It is also possible to specify an http(s) URI to receive the reports. The reports are small JSON files like (thanks to "S J" for sharing this report received from Google):

{"organization-name":"Google Inc.","date-range":{"start-datetime":"2019-04-12T00:00:00Z","end-datetime":"2019-04-12T23:59:59Z"},"contact-info":"smtp-tls-reporting@google.com","report-id":"2019-04-12T00:00:00Z_domain.com","policies":[{"policy":{"policy-type":"no-policy-found"},"summary":{"total-successful-session-count":1}}]}

And that should be it. Let me know how it goes or add a comment with any additional tips you have. Check Hardenize.com after you are done to make sure all of this works nicely.

[1] https://letsencrypt.org/stats/
[2] https://tools.ietf.org/html/rfc6797
[3] https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks
[4] https://tools.ietf.org/html/rfc8561
[5] https://tools.ietf.org/html/rfc8560

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
Twitter|

We often get emails from readers stating that they feel their system is compromised, even though they "do nothing". Most of the time, our response is "that's normal". Indeed, most modern operating systems, not just Windows, will trigger lots of network traffic without user activity. But I found little documentation about what exactly to expect from a "normal" Windows 10 system. So I ran a quick experiment:

Microsoft offers a number of free virtual machines. I picked the "Microsoft Edge Windows 10 (x64) Stable 1809" system. The reason I went this route is that it first of all made things more reproducible, and secondly, these virtual machines do not include additional software, so you only get the default Windows 10 behavior. These systems are also in a default configuration.

The initial plan was to only record the first boot. But I discard this quickly. After 5 minutes, I had a few hundred MBytes of traffic as Windows first downloaded a lot of updates (including VMware Tools). So I modified my plan: I let the system run for about an hour, until all updates were applied, then I rebooted it a couple of times again making sure that it didn't download additional updates. Finally, I recorded the first few minutes after a reboot.

You can find the raw packet capture at https://isc.sans.edu/diaryimages/WindowsStartup.pcapng . I am using the PCAPNG format as I started to add comments to some of the packets. But here are the basic features:

I recorded 87 seconds. During that time, I captured 531 packets and 196kBytes. 20 DNS requests and responses, 18 TCP connections and 30 UDP connections. My host communicated with 18 other IPv4 hosts (there is no significant IPv6 traffic as the network didn't support IPv6).

Here is the short summary of the pcap:

IP address of the system: 172.16.29.198
MAC Address: 00:0c:29:1f:55:7b
Hostname: MSEDGEWIN10

The system was configured to log in automatically. I did not open a browser window and did not interact with the system beyond powering it on.

Here are some of the main features of the pcap:

• initially, the operating system configures itself (IPv6 router solicitations, DHCPv6 and DHCPv4). 
• The operating system is trying to configure a proxy via WPAD a couple of times
• Content for tiles is downloaded (e.g. Weather) in the clear.
• There are TLS connections to Bing and events.data.microsoft.com, likely for more content.
• connections to canonicalizer.ucsuri.tcs which is part of Microsofts "Smartscreen" anti-malware.
• inference.location.live.net: Microsoft's geolocation
• additional Live.com systems for things like Microsoft's login features.

There was also a DNS lookup for puppet.localdomain. Not sure if Windows is looking for a Puppet server here for configuration files.

See anything I missed? 

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
Twitter|

Recently, there have been a number of stories about hidden cameras found in Airbnb rentals [1][2]. Of course, these cameras are likely not limited to vacation rentals, and there have also been reports about cameras installed in hotels [3]. When considering defenses for any threat, it is important to keep in mind the adversary. In this case, I am assuming that the owner of the apartment you are renting is not a sophisticated network engineer but pretty much buying cheap off the shelf cameras and connecting them to the local network.

You typically end up with your normal "home network" in an Airbnb. A single wireless router/access point connected to a consumer DSL or cable modem. The guest has access to the wireless network but usually does not have access to the admin console of the router.

The very first thing you can do is a simple visual inspection of the rooms. Is anything out of place? Cameras often need power. Are there any devices that have power running to them that usually do not? Are any devices out of place. 

Popular devices used to hide cameras:

• USB chargers. They are typically plugged into the wall, and it would not be considered suspect to have them connected to power. Most popular USB charger cameras I have seen are black to hide the lens better. But the lens will be visible if you look closer. They also tend to be quite a bit larger. Below I have a picture of a normal Apple USB charger and one with a camera. If you unplug it, you may see a slot for a memory card.

• iPhone and iPad chargers compared to "USB Spy Cam Charger"

• Digital clocks. These are difficult to spot. If you are worried, then unplug it and place it inside a drawer.
• Fire alarms. Again, this can be difficult to identify, and unlike for a digital clock, you should probably not just remove fire alarms. But is there a fire alarm out of place? For example, there should not be a fire alarm in the bathroom (but you often do have them in bedrooms). Is there more than one fire alarm in a particular room?

Do a quick search on Amazon for "hidden camera" to get a decent list of possible devices you may encounter. Not all of them require power cords. Some run on batteries.

Next, it may be a good idea to check the local network for odd devices. Most of these cameras will allow remote access via WiFi. As a very first step, see what networks are available (in addition to the one provided by the host). But this scan is likely going to show dozens of neighbor networks, and I do not recommend trying to connect to networks you are not authorized to connect. Watch for any networks with a surprisingly good signal.

Once you are connected to the host's Wifi network, it is time to launch a quick Nmap scan. Most of these spy cameras offer a web server. So a simple scan like:

nmap -Ap 80,8000,8080,443,8443,7443,7070,7000,22,23,21 10.5.1.0/24

is a good start. Here are some of the innocent devices you may find:

• The router/modem should respond, and it often uses a web-based admin interface
• Smart TVs, cable boxes and similar equipment will likely respond
• Printers

For any devices found, connect to them to see if you can identify them. If nothing is found, or if you find devices that do not respond on any of the ports above: run a more exhaustive scan. You will not find devices segmented into a different VLAN, or that are properly firewalled on to respond. If you want, you can be more intrusive. Reboot the router (unplug/plug it back in) and collect ARP messages with tcpdump to see if you missed any devices.

Finally, try to figure out the public IP address of the network you are on ( https://dshield.org/api/myip ) and either run a port scan from the outside to see if you find any odd open ports, or look it up in Shodan to see if Shodan found cameras on this IP in the past (but you likely will have a dynamic IP address).

If you do have access to the router's admin console, you may want to check if it has a list of connected devices or additional networks it is offering, which may be used for these devices. Some home routers have two SSIDs, one typically used for "Guest" access, with a second SSID used for a more protected subnet. Cameras could be connected to this second network.

More advanced techniques:

• An infrared camera can help (like a phone attachment). Cameras and devices like it will give off heat. But this will not identify cameras inside electronic devices, and the scans can be difficult to interpret (e.g. mirrors will reflect IR, so a hot spot on a mirror may be from a ceiling light not from a camera behind it)
• Battery operated cameras are almost always motion activated to save power. You could either try to correlate wireless traffic with motion, or you could set up fake motion (paper towel tied to a ceiling fan, blinking light) to drain the batteries.
• There are "spy cameras" that use non-WiFi RF transmissions. They are a bit more difficult to find. There are some special detectors for them, that will alert on RF signals on frequencies typically used by these cameras. I have no idea how well they work but assume that they will (a) not get anything as some cameras may use odd frequencies and (b) lead to false positives as some of these frequencies may be used by other devices as well. I do not have any first-hand experience with these detectors (and do not keep them in your hotel room if you are trying to sneak into Maro-Lago).

The same techniques can apply to a normal hotel as well. But hotel networks tend to be more complex, so a Nmap scan is likely to lead to ambiguous results. Hotels for example often have cameras in hallways and other public areas (hopefully your Nmap scan will not find them).

[1] https://nakedsecurity.sophos.com/2019/04/09/airbnb-says-sorry-after-man-detects-hidden-camera-with-network-scan/
[2] https://www.airbnb.com/help/article/887/what-are-airbnb-s-rules-about-electronic-surveillance-devices-in-listings
[3] https://www.desertsun.com/story/news/crime_courts/2017/05/09/hidden-camera-hotel-bathroom/314480001/

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
Twitter|

Introduction

Pyramids provide a good image of tiered activity.  In 2015, I wrote a diary about a Security Operations Center (SOC) analyst pyramid of activity SOC analysts will encounter when monitoring their networks for malicious network traffic.

But in recent months, I've used a pyramid to show tiered responsibilities under a mature information security (infosec) program.  Today's diary provides my view of infosec as a tiered purple pyramid.

Blue + red = purple

Conventional wisdom divides infosec into defensive and offensive roles.  Defensive roles fall under a blue team responsible for monitoring network assets and responding to incidents.  Offensive roles fall under a red team responsible for detecting any weaknesses in our infrastructure.  This presents a rather misleading view of red team as attackers and blue team as defenders.

In recent years, the phrase "purple team" has appeared with various meanings.  Some sources describe purple team as a combination of blue and red team functions.  Other sources define purple as a separate team that coordinates the efforts of blue and red team members.

However, blue and red teams both serve the same objective: protecting our information technology (IT) assets.  We can view blue and red team functions within the combined model of a purple infosec pyramid.

Shown above:  An infosec purple pyramid.

Managing Assets

The base of this pyramid covers all tasks for managing your IT assets.  These functions include:

• Inventory management
• Access controls
• Software patching and updates
• Hardware refreshes

These basic IT functions are essential to supporting the remaining tiers of an infosec pyramid.  Without inventory management, we cannot properly secure our infrastructure, because we don't fully understand everything on our network.  Access controls are also critical to ensure only properly-authorized people are utilizing our IT assets.  Some of these roles may not be handled by security personnel, but they directly affect the security of our network.

Assess and Monitor

This tier of the pyramid involves both blue and red team functions.  Red team members assess network security through vulnerability scans, while blue team members monitor the network for intrusions or other malicious activity.  These assessments should be periodic and relatively frequent.  Monitoring should be constant, with near-real-time detection and analysis of suspicious activity.

Probe and Respond

When vulnerabilities are discovered through assessments, red team members probe to determine how easy they are to exploit.  If blue team monitoring reveals malicious activity, security personnel must respond.  This tier consists of activity like penetration tests and incident response procedures.

Report

The top tier of the purple pyramid is based on reporting.  Red team members send the results of assessments and penetration tests to managers and other decision makers.  Blue team members report on malicious activity and how the issues were resolved.  Decision makers use this data to adjust processes and procedures in lower tiers of the pyramid.  This should provide a continual cycle of feedback designed to improve an organization's security.

Final words

Blue and red team functions can mislead people into thinking they are opposing roles working against each other.  However, these functions are better seen as a combined color with the same objective of protecting our IT assets.  When viewed within the tiered model of a purple infosec pyramid, we can better understand how blue and red teams work together to provide an effective defense.

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

This month we got patches for 74 vulnerabilities total. From those, 16 are critical and 2 have been exploited in the wild.

Both exploited vulnerabilities (CVE-2019-0859 and CVE-2019-0803) are related to Win32k component which fails to properly handle objects in memory and may permit a local attacker to elevate privileges and execute arbitrary code in kernel mode. 

It is also worth mentioning a remote code execution vulnerability in GDI+ (Windows Graphics Device Interface) which affects the EMF (Enhanced MetaFile) parser. An attacker could exploit this vulnerability by convincing users to open specially crafted EML files in scenarios such as a file hosted on a web server or an e-mail attachment. Multiple Microsoft programs, especially Office suite, uses GDI+ component.

We got 5 vulnerabilities in the Jet Database Engine. Jet Database vulnerabilities are often exploitable via Office documents. But none of the vulnerabilities are labeled as critical. 

See Renato's dashboard for a more detailed breakout: https://patchtuesdaydashboard.com

Description
CVE	Disclosed	Exploited	Exploitability (old versions)	current version	Severity	CVSS Base (AVG)	CVSS Temporal (AVG)
ASP.NET Core Denial of Service Vulnerability
%%cve:2019-0815%%	No	No	Less Likely	Less Likely	Important
April 2019 Adobe Flash Security Update
ADV190011	No	No	-	-	Critical
Azure DevOps Server Elevation of Privilege Vulnerability
%%cve:2019-0875%%	No	No	Less Likely	Less Likely	Important
Chakra Scripting Engine Memory Corruption Vulnerability
%%cve:2019-0812%%	No	No	-	-	Critical	4.2	3.8
%%cve:2019-0829%%	No	No	-	-	Critical	4.2	3.8
%%cve:2019-0806%%	No	No	-	-	Critical	4.2	3.8
%%cve:2019-0810%%	No	No	-	-	Critical	4.2	3.8
%%cve:2019-0860%%	No	No	-	-	Critical	4.2	3.8
%%cve:2019-0861%%	No	No	-	-	Critical	4.2	3.8
DirectX Information Disclosure Vulnerability
%%cve:2019-0837%%	No	No	Less Likely	Less Likely	Important	5.5	5.0
GDI+ Remote Code Execution Vulnerability
%%cve:2019-0853%%	No	No	Less Likely	Less Likely	Critical	7.8	7.8
Jet Database Engine Remote Code Execution Vulnerability
%%cve:2019-0846%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2019-0847%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2019-0851%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2019-0877%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2019-0879%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Latest Servicing Stack Updates
ADV990001	No	No	-	-	Critical
MS XML Remote Code Execution Vulnerability
%%cve:2019-0790%%	No	No	Less Likely	Less Likely	Critical	7.8	7.0
%%cve:2019-0791%%	No	No	Less Likely	Less Likely	Critical	7.8	7.0
%%cve:2019-0792%%	No	No	Less Likely	Less Likely	Critical	7.8	7.0
%%cve:2019-0793%%	No	No	More Likely	More Likely	Critical	7.8	7.0
%%cve:2019-0795%%	No	No	Less Likely	Less Likely	Critical	7.8	7.0
Microsoft Browsers Tampering Vulnerability
%%cve:2019-0764%%	No	No	Less Likely	Less Likely	Important	2.4	2.2
Microsoft Edge Information Disclosure Vulnerability
%%cve:2019-0833%%	No	No	-	-	Important	4.3	3.9
Microsoft Excel Remote Code Execution Vulnerability
%%cve:2019-0828%%	No	No	Less Likely	Less Likely	Important
Microsoft Exchange Spoofing Vulnerability
%%cve:2019-0858%%	No	No	Less Likely	Less Likely	Important
%%cve:2019-0817%%	No	No	Less Likely	Less Likely	Important
Microsoft Graphics Components Remote Code Execution Vulnerability
%%cve:2019-0822%%	No	No	More Likely	More Likely	Important
Microsoft Office Access Connectivity Engine Remote Code Execution Vulnerability
%%cve:2019-0823%%	No	No	-	-	Important
%%cve:2019-0824%%	No	No	Less Likely	Less Likely	Important
%%cve:2019-0825%%	No	No	Less Likely	Less Likely	Important
%%cve:2019-0826%%	No	No	Less Likely	Less Likely	Important
%%cve:2019-0827%%	No	No	Less Likely	Less Likely	Important
Microsoft Office SharePoint XSS Vulnerability
%%cve:2019-0830%%	No	No	Less Likely	Less Likely	Important
%%cve:2019-0831%%	No	No	Less Likely	Less Likely	Important
Microsoft Scripting Engine Information Disclosure Vulnerability
%%cve:2019-0835%%	No	No	Less Likely	Less Likely	Important	4.3	3.9
OLE Automation Remote Code Execution Vulnerability
%%cve:2019-0794%%	No	No	More Likely	More Likely	Important	7.8	7.0
Office Remote Code Execution Vulnerability
%%cve:2019-0801%%	No	No	More Likely	More Likely	Important
Open Enclave SDK Information Disclosure Vulnerability
%%cve:2019-0876%%	No	No	-	-	Important
SMB Server Elevation of Privilege Vulnerability
%%cve:2019-0786%%	No	No	Less Likely	Less Likely	Critical	7.8	7.0
Scripting Engine Memory Corruption Vulnerability
%%cve:2019-0739%%	No	No	-	-	Critical	4.2	3.8
%%cve:2019-0752%%	No	No	More Likely	More Likely	Important	6.4	5.8
%%cve:2019-0753%%	No	No	More Likely	More Likely	Critical	6.4	5.8
%%cve:2019-0862%%	No	No	More Likely	More Likely	Important
Team Foundation Server Cross-site Scripting Vulnerability
%%cve:2019-0866%%	No	No	Less Likely	Less Likely	Important
%%cve:2019-0867%%	No	No	Less Likely	Less Likely	Important
%%cve:2019-0868%%	No	No	Less Likely	Less Likely	Important
%%cve:2019-0870%%	No	No	Less Likely	Less Likely	Important
%%cve:2019-0871%%	No	No	Less Likely	Less Likely	Important
%%cve:2019-0874%%	No	No	-	-	Important
Team Foundation Server HTML Injection Vulnerability
%%cve:2019-0869%%	No	No	Less Likely	Less Likely	Important
Team Foundation Server Spoofing Vulnerability
%%cve:2019-0857%%	No	No	-	-	Important
Win32k Elevation of Privilege Vulnerability
%%cve:2019-0803%%	No	Yes	Detected	More Likely	Important	7.0	6.3
%%cve:2019-0685%%	No	No	More Likely	More Likely	Important	7.8	7.0
%%cve:2019-0859%%	No	Yes	Detected	More Likely	Important	7.8	7.0
Win32k Information Disclosure Vulnerability
%%cve:2019-0848%%	No	No	Less Likely	Less Likely	Important	4.7	4.2
%%cve:2019-0814%%	No	No	More Likely	More Likely	Important	4.7	4.2
Windows Admin Center Elevation of Privilege Vulnerability
%%cve:2019-0813%%	No	No	-	-	Important
Windows CSRSS Elevation of Privilege Vulnerability
%%cve:2019-0735%%	No	No	More Likely	More Likely	Important	7.0	6.3
Windows Elevation of Privilege Vulnerability
%%cve:2019-0805%%	No	No	More Likely	More Likely	Important	6.7	6.0
%%cve:2019-0841%%	No	No	Less Likely	Less Likely	Important	6.8	6.1
%%cve:2019-0730%%	No	No	More Likely	More Likely	Important	6.7	6.0
%%cve:2019-0731%%	No	No	More Likely	More Likely	Important	6.8	6.1
%%cve:2019-0796%%	No	No	More Likely	More Likely	Important	6.3	5.7
%%cve:2019-0836%%	No	No	More Likely	More Likely	Important	7.0	6.3
Windows GDI Information Disclosure Vulnerability
%%cve:2019-0802%%	No	No	Less Likely	Less Likely	Important	4.7	4.2
%%cve:2019-0849%%	No	No	Less Likely	Less Likely	Important	4.7	4.2
Windows IOleCvt Interface Remote Code Execution Vulnerability
%%cve:2019-0845%%	No	No	Less Likely	Less Likely	Critical	7.5	6.7
Windows Information Disclosure Vulnerability
%%cve:2019-0838%%	No	No	Less Likely	Less Likely	Important	6.6	5.9
%%cve:2019-0839%%	No	No	Less Likely	Less Likely	Important	4.4	4.0
Windows Kernel Information Disclosure Vulnerability
%%cve:2019-0840%%	No	No	More Likely	More Likely	Important	5.5	5.0
%%cve:2019-0844%%	No	No	More Likely	More Likely	Important	5.5	5.0
Windows Remote Code Execution Vulnerability
%%cve:2019-0856%%	No	No	Less Likely	Less Likely	Important	7.3	6.6
Windows Security Feature Bypass Vulnerability
%%cve:2019-0732%%	No	No	More Likely	More Likely	Important	5.3	4.8
Windows TCP/IP Information Disclosure Vulnerability
%%cve:2019-0688%%	No	No	Less Likely	Less Likely	Important	5.3	4.9
Windows VBScript Engine Remote Code Execution Vulnerability
%%cve:2019-0842%%	No	No	Less Likely	Less Likely	Important	6.4	5.8

 

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter

As I continue to explore NSA's new reversing tool, Ghidra, one of the features that I heard about and was excited to see in action was the decompiler. So, in this entry in the series, I'll start to delve into that some. In particular, I'll look at one particular option that turned out to be more useful than I originally thought, though I'm still not entirely certain how I'll use it going forward. I've long been a user of the Hex-Rays decompiler at $dayjob and I really like it, but I can't afford it for use in my personal/Storm Center research and we don't use it in FOR610, so I was really looking forward to giving the Ghidra one a try. I have to say, so far, I'm pretty impressed. As I explain to my FOR610 students, decompiling is a hard problem. A lot of context is lost during optimization, so except for very simple programs you shouldn't expect the decompiler to give you C code that looks like the original source. Having said that, for someone like me who has been programming on-and-off for a very long time, I can usually grasp the purpose of a function much more quickly in a (pseudo-)high level language than I can in assembler. One place decompiling is extremely useful for, is showing the parameters to function calls (especially Windows API calls) in a way that isn't as tedious (and potentially error prone) as scrolling up and counting the PUSH instructions (cdecl or stdcall) or trying to trace the contents of certain registers (fastcall). More on that in my next installment.

The way the user interface in the Ghidra CodeBrowser works by default, in the center of the screen you have the disassembler window and immediately to the right of that is the decompiler window. When you are looking at code within a function in the disassembler, you'll see the corresponding decompiled code right next to it. If you click on an instruction in one, it highlights the corresponding code in the other in yellow. Very nice. But this also led to some confusion on one of the first samples I looked at in Ghidra.

In my normal workflow in IDA, I'll often begin by looking at the imports. In IDA, that means going to the imports tab where all of the imports are listed together. In Ghidra, the imports are all listed under the DLL from which they are imported. If I want to search through all of them, that requires clicking the + next to 'Imports' and then the + next to each of the DLLs. That is kind of a pain, but doable. If I have a particular API call that I want to look at (perhaps based on behavioral analysis), you can type that in the Filter box, just like you can type the API call name in the IDA imports window, so that's good. So when I took one of the samples we examine in FOR610 and examined it in Ghidra, I looked for one of the API calls (in this case, RegOpenKeyExA), and just like in IDA, I right-clicked on the name and looked for references (I'm half-tempted to change the key binding so that I can use 'x' just like in IDA, rather than the 'ctrl-shift-F' that is the Ghidra default, since I'm so used to it, but maybe I'll adjust). I clicked on one of the calls and I see the call in the disassembler window, but when I look over at the decompiler window, I can't find it. I try clicking on other instructions around the call and nothing is getting highlighted in the decompiler window. What the ****?

So, while I was poking around at the options, I happened across 'Eliminate unreachable code' as an option for decompiler analysis.

Unchecking that box and now I could see the API call I was looking for.

As I mentioned above, I don't know exactly how I'll use this going forward. If I leave it unchecked then the code simply doesn't show up in the decompiler window, but it still shows up in the disassembler, so that is a disconnect. But it also makes it clear that this is code I don't need to waste too much time analyzing because the decompilation process concluded that the code was unreachable. In a normal program, the programmer would probably instruct the optimizer to remove dead (unreachable) code, but malware authors are going to make our jobs as analysts harder by including code like this to waste our time. I'm not sure if the complete absence of the code in the decompiler window will help me more or whether seeing a big block of code enclosed in if (false) { ... } will be the more useful display. I guess we'll see as I spend more time playing with Ghidra. For now, I'm leaving it unchecked.

Again, if you have any tips or thoughts, feel free to e-mail me (see below), or use our contact page, or comment below.

---------------
Jim Clausing, GIAC GSE #26
jclausing --at-- isc [dot] sans (dot) edu

 

If you currently have Office 365, watch out for fake request with a Subject of "Action required: Update your payment information now" and with sender: "Microsoft Online Services Team no-replay@support.onmicrosoft.com". Over the past few weeks I have received several of these emails which looks quite legitimate. Here is an example:

However, a quick review of the embedded URL shows this is spam if your email program didn't already categorize it as such [1]. The URL is no longer active but domain offene-tueren.net (81.169.145.148) tracked by ransomware tracker is associated with Locky malware.

Refer to a recent posting from Microsoft [3] that describes how Office 365 mitigates against phishing attacks. A valid message from Microsoft would look like item #2 "Microsoft account security code".

1. http://login.live.com.login.offene-tueren.net/?Z289MSZzMT0zODYwMjkmczI9OTU3MzE5MTAmczM9R0xC
2. https://ransomwaretracker.abuse.ch/ip/81.169.145.148/
3. https://docs.microsoft.com/en-us/office365/securitycompliance/anti-spoofing-protection

-----------
Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

From About Beagle:
“Beagle is an incident response and digital forensics tool which transforms data sources and logs into graphs. Supported data sources include FireEye HX Triages, Windows EVTX files, SysMon logs and Raw Windows memory images. The resulting Graphs can be sent to graph databases such as Neo4J or DGraph, or they can be kept locally as Python NetworkX objects.
Beagle can be used directly as a Python library, or through a provided Web interface.”
Our use here will be through the Web interface running from Docker.

Beagle is beautifully documented, among the best I’ve ever seen, I strongly suggest reading it in its entirety before proceeding here. Well done, on so many fronts, to Omer Yampel, @yampelo, the project lead. I’m going to limit reprinting that content here and focus almost exclusively on specific use cases.
I did reach out to Omer for his insights on Beagle and received a plentiful response.
Per Omer, “Even though a lot of the work that I did with Beagle involved transforming the data into graphs, I think what you can do with it is the really cool part. I tried to capture that by showing how quickly you can pivot/investigate through incidents while retaining your context from the previous action (something that’s extremely hard to do in Splunk/ELK). I also tried to show what you might be able to do through the context menu on the web UI, showing how you can abuse the structure to quickly answer some common questions. For example, answering What happened after? by doing a depth first search from a node. I have more concrete examples in the slides from my Black Hat Asia Arsenal presentation.”

Omer’s Beagle Roadmap:

1. “Allow users to stream/send arbitrary data to Beagle. The goal is to specify a schema which people follow (for example, the process ID field must be called “process_id” rather than “pid” or “processid”). Once the data is received, Beagle identifies entities, builds relationships, and returns the graph.
2. Add more datasources!
3. Integrate @cyb3rops’s sigma (https://github.com/Neo23x0/sigma). I really think graphs allow us to identify behaviors rather than signatures for specific actions. The fact that a node is a child of another node implies that the child node could not have occurred without the parent node, which is a really strong property in detection I think. Similarly, the subgraph of a node is everything that happened because of that node, which again, I think can make for way better signatures.
4. Add support for functions to run on the graphs themselves. Similar to the context menu in the web interface, I want to support the same kind of thing in the Python library. That way people can develop analysis functions themselves, and potentially contribute them back.”

Thanks to Omer for all the detail!

Readying Docker

A quick primer on creating the Beagle Docker instance and running it with ease. I found it easiest to operate from a regular command prompt.

docker pull yampelo/beagle
mkdir data\beagle
docker run -v "/data/beagle":"/data/beagle" -p 8000:8000 yampelo/beagle

Browse to http://localhost:8000 and your Beagle instance will be waiting for, ready to ingest and graph. In terms of said ingestion, Beagle stands ready to consume:

• Windows Memory
• Procmon CSV
• Sysmon EVTX
• Windows EVTX
• VirusTotal v3 API Sandbox Reports
• FireEye HX Triage files

Uploading is as simple as select and click. Choose the file type, select the appropriately matched file, click Upload Data, wait a few seconds, then Submit as seen in Figure 1.

Figure 1: Beagle upload

For purposes of our toolsmith experiments I choose some select samples from my historical archive, including a number of memory images, Procmon files, and an exemplary Windows security event log. Don’t let the fact that I didn’t test VT, FireEye, or Sysmon samples limit you from doing so. Ease of use is substantial here, the only limiting factor is the potential for bloating your Docker image with logs or images ingested. If you’re going to turn Beagle into to a workhorse for your blue team and DFIR workloads, I strongly recommend you make use of Beagle’s Python API on a dedicated system with fairly beefy resources to enhance performance.
I selected these samples because they each tell interesting stories that have also been explored with other tools to further validate our assertions established here. I’ll start us off with two related file types from similar compromise scenarios. The attacks were classic phishing scenarios inclusive of an email with an attached invoice spreadsheet.
When experimenting with the malware sample, I did so as part of a toolsmith test for ProcDot, a somewhat related tool to Beagle in its visualization initiatives, but limited to Procmon and Pcap ingestion. As part of the initial analysis I generated a Procmon file and a memory image.
After you’ve uploaded your preferred log and memory samples, you’ll be greeted with a simple menu per category. You’ll find it helpful to add an identifying note during upload so you have sample context when you’re analyzing later. My Procmon selections are represented in Figure 2.

Figure 2: Procmon menu

I’ll begin with a graph for the Procmon CSV file generated from the above mentioned invoice malware analysis. Beagle includes an excellent Node Search feature; given that the opening graph is not particularly revealing I thought it best to try to zoom to a featured node. Rather than create static images that fail to do Beagle justice representing its usefullness, I’ve created video captures of the click-throughs, similar to those on Omer’s GitHub site. I first searched the keyword invoice and immediately landed on the sample execution process labeled Invoice_Trailcore_100355038.exe. I selected that process entity in the search results, then double-clicked the node in the graph. Figure 3 speaks for itself at this point.

Figure 3: Malicious invoice process actions

Don’t forget to drill in to Tree, Timeline, and Table views in addition to the Graph. They’re equally revealing dependent on your goals. Forensicators will truly appreciate Timeline in particular.
I then moved to the related memory image to see what consistencies or correlation might be identified. Again, using the invoice keyword to pivot, I found that both samples, albeit different but related, access and/or write to msvbvm60.dll, the Visual Basic 6.0 Runtime library, behavior consistent with Office-related files and macro malware. I then searched nodes across the Procmon log and the memory image for msvbvm60.dll to exemplify related behavior. The Procmon graph is far deeper, the memory image is limited in related artifacts but nonetheless correlates behaviorally. Note these are not the same malware samples, but related sample types acquired in the wild between June and August of 2013. Figure 4, is video of running through both graphs to render what I’m describing.

Figure 4: Invoice malware similarities across Procmon and memory samples

I noted that in the Procman graph we also see clear evidence of the sample execution causing a crash dump. You can see the node representing drwtsn32.exe, for the Dr. Watson crash dump service. There are also related calls to dwwin.exe, the Watson client.

One of favorite memory images is one from years ago taken from a system compromised with Trojan.APT.9002, the last version before the adversary went completely diskless, one of the very first to run in memory only. As we observe the graph in its opening state, we don’t note much of merit. I used Beagle’s node search to hunt for a known suspect process in this memory image, specifically 3176. It was an extremely easy pivot from there. In this case, 3176 turned out to be associated with rundll32.exe, which, in addition to reading nework connection-related registry keys, immediately tapped Internet history via index.dat. Experience the drill-down in Figure 5.

Figure 5: PID 3176 up to no good

My final example is another of my favorites, exhibiting malicious behavior captured in a Windows security event log from a log grabbed via a Red Team server as they were popping off with some of their typical mayhem. The Red Team we partner with, and I do mean partner (Go, Purple Team, go!), are artistic and advanced the majority of the time. I condsider them 2-3 years ahead of the industry and peer teams in mindset and tactics. Given the Purple Team approach we embraced years ago, their methods and approach serve both their customer and the Blue Team. We are definitely better for their efforts. But once in awhile they’ll go loud, and it visulizes gloriously. This graph represents one of the Red Team’s special multifunction payloads, I’ll give you no more detail than that, but enjoy the ride in Figure 6.

Figure 6: Red Team goes loud

Seems to me that said payload gets busy quickly, you likely noted that it launched numerous processes instantly, including cmd.exe, schtasks.exe, and taskeng.exe. Clearly, they’re establishing a swift foothold and seeking to persist. I love how Beagle represents processes in red, and the Red Team’s payload spawns yet more processes. Visual Red Team love for sure. Want a quick, dynamic graph, or would you prefer to hunt out those same spawned processes in a security event log without visual aid?

This is another case where I have not given an excellent tool its full due, but it’s so robustly documented, and well received by the community via significant infosec social media presences, as well as the likes Black Hat Asia Arsenal (shout out to @ToolsWatch. Again, please read the GitHub documentation in its entirety and consider leveraging the Python library after experimenting with the Docker image.
I haven’t been this excited by a new-to-me security tool in quite a while. I’ll go so far as to say that this is a real powerhouse, on par with my level of excitement for the likes of Volatility and Sysmon.
Congratulations to Omer for a job well done.
Cheers…until next time.

Russ McRee | @holisticinfosec

Who remembers the famous ShellShock (%%cve:2014-6271%%)? This bug affected the bash shell in 2014 and was critical due to the facts that it was easy to exploit and that bash is a widespread shell used in many tools/applications. So, at this time, I created an OSSEC alerts to report ShellShock exploitation attempts against my servers. Still today, I'm getting a hit on this rule from time to time.

But, for 15 days, I started to get more alerts like this one:

Received From: (xxxx) x.x.x.x->/www/log/xxxxxxx.access
Rule: 100705 fired (level 10) -> "Shellshock Attempt"
Src IP: x.x.x.x
Portion of the log(s):

x.x.x.x - - [04/Apr/2019:07:31:19 +0200] "GET /type.php?template=tag_(){};@unlink(_FILE_);assert($_POST[T00ls]);{//../rss HTTP/1.1" 301 604 "http://xxxxxxx" "Mozilla/5.0 (compatible; Baiduspider/2.0; +http://www.baidu.com/search/spider.html\xa3\xa9"

This rule fired 34 times since mid-March and I'm still getting, at least, one per day. This query is related to %%cve:2018-19127%% which affects phpcms[1]. By exploiting the vulnerability, the attackers get a webshell on the server (details are available on a Github page[2]). Some details about the hits I found:

Three different User-Agents have been used:

Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1)                                            24
Mozilla/5.0 (compatible; Baiduspider/2.0; +http://www.baidu.com/search/spider.html\xa3\xa9    2
python-requests/2.21.0                                                                        8

Scan sources are clearly identifiable: 

The scan in itself is not critical (except if you're still running a vulnerable version of phpcms of course) but what's interesting here? An alert created in your SIEM or log management solution a long time ago can still be relevant!

[1] http://www.cmsmatrix.org/matrix/cms-matrix/phpcms#
[2] https://github.com/ab1gale/phpcms-2008-CVE-2018-19127

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

If you haven't been living under a rock, you probably heard that the NSA released its reverse-engineering tool, Ghidra, at RSA last month. I've been an IDA user for years (it's the primary disassembler we use when I teach FOR610), but I've been trying out Ghidra over the last few days since it is free and other malware analysts have been talking about it. This is the first of several diaries I plan to write with suggestions on how to get Ghidra to do things I've come to rely on in IDA. And, being a good computer scientist, I start counting a 0, hence part 0.

Let me state, right up front, I have only spent a couple of hours using Ghidra, so this is very preliminary. On first glance, one feature I missed from IDA was the comments where IDA gave me the names of parameters for Windows API calls (e.g., the first parameter to RegOpenKeyExA in MSDN is listed as hKey with a type HKEY). It turns out Ghidra can do this to. It requires changing one of the defaults in the AutoAnalysis settings (you see this when you first open a file for analysis or when you choose AutoAnalysis from the Analysis menu). The option WindowsPE x86 Propagate External Parameters is disabled by default, if you enable this option then you get the comments you expect.

If you forget to do it in the opening dialog or don't change the default, you can apply the analysis later from the Analysis menu, using the One Shot option (or rerunning AutoAnalysis, which will give you the same dialog above).

The last thing that I wanted to change about Ghidra's defaults is probably just a personal thing that I could get over, but it annoyed me at first and I found it was easy to fix. I was used to writing comments in assembly by prefacing them with a semicolon (;) and I was used to IDA (and x64dbg) showing comments with a semicolon in front of them, but Ghidra by default wasn't. It turns out that behavior is simple to change, too.  In this case, you can choose Tool Options from the Edit menu.

And then turn on 'Show Semicolon at Start of Each Line' in Listing Fields>EOL Comments.

And with that, I can now see the comments showing parameter names and types for Windows API calls.

That's enough for one diary. I'll post a few more of these tips as I figure Ghidra out. If you have other thoughts or useful tips, e-mail me or leave your comments below.

---------------
Jim Clausing, GIAC GSE #26
jclausing --at-- isc [dot] sans (dot) edu

I have not seen much Fake AntiVirus lately. Maybe I haven't been looking for it. But this weekend, I received a few identical spam messages with slightly different subjects advertising that I had won a licensed copy of ESET's NOD32 Anti Virus. Many anti-malware products are offering free or highly discounted initial licenses to lure buyers, so this email may seem legitimate to some, even though it wasn't done terribly convincing (I am using a script to defang HTML in all email I receive which may account for some of the formatting issues):

The link, went down the folling redirect chain:

https://clck.ru/FSkJV
https://sba.yandex.net/redirect?url=ftp://[IP Address]/LaCie/Tirel/eav_1year.exe&client=clck&sign=[hex hash]
ftp://[IP Address]/LaCie/Tirel/eav_1year.exe

The FTP URL is typical for a LaCie network connected drive. It isn't clear how the attacker obtained access to this drive, but typically, these drives are compromised via weak passwords or vulnerable applications installed on the drive. 

The binary does result in a mixed Virustotal picture, but oddly enough, it looks like I was the first one uploading it, about two days after I saw the email:

https://www.virustotal.com/#/file/d503a3874e43031530e35138cf219dcc590be6df907a983114386f4856d23e0b/detection

ESET's product did not recognize the file as malicious. This being an FTP URL made it easy to get a directory listing:

The executables in this folder are triggering various malware signatures. Other files appear to include simple password brute force utilities supporting the guess that this drive was compromised using a simple password.

The first directory contains a number of password protected zip files with various tools (based on the ZIP file listing) including openvpn configuration files.

Oracle.rar includes the obligatory xmrig miner which is still part of pretty much any compromised system I am running into.

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
Twitter|

From time to time, I get a question about PDFs that have an /OpenAction, but don't seem to contain (malicious) code.

When you look at such a PDF with pdfid.py, everything looks OK, except that there is an /OpenAction:

You can also find search keywords like /OpenAction using pdf-parser.py's statistics option (-a). Best is to combine this with option -O to look inside stream objects, should they be present:

The /OpenAction is in object 12:

This /OpenAction is typically added by OpenOffice and LibreOffice when creating a PDF document. Its purpose is to present the first page when you open the document for the first time. This is called an Explicit Destination.

/OpenAction here is not used to execute JavaScript code upon opening of the PDF (as is often the case with malicious PDFs), but it is used to present the first page with the desired position and zoom. This is explained in the PDF reference documents:

This explicit destination refers to object 1: this is a page:

When you encounter a document like this, it's most likely not malicious. Should you suspect that this is targeted, then you could continue your analysis as explained in diary entry series "It is a resume", for example. A targeted attack might use a more sofisticated exploit, without any of the signs reported by pdfid or pdf-parser's statistics. But it's very unlikely to find this in common maldocs.

Here is a video for this quick analysis:

 

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