Blog

Archive for April, 2019

Introduction to KAPE, (Tue, Apr 30th)

 

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 kapemodules 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 

 

 

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

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Update about Weblogic CVE-2019-2725 (Exploits Used in the Wild, Patch Status), (Sun, Apr 28th)

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:

#### <> <[[email protected][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|

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

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Quick Tip for Dissecting CVE-2017-11882 Exploits, (Sat, Apr 27th)

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

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

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Pillaging Passwords from Service Accounts, (Fri, Apr 26th)

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 .nishangGatherGet-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 hklmsam sam.out

reg save hklmsecurity security.out

reg save hklmsystem 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

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

Reposted from SANS. View original.

Posted in: SANS

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