Latest Alerts

Syndicate content SANS Internet Storm Center, InfoCON: green
Updated: 3 days 22 hours ago

ISC StormCast for Friday, August 29th 2014 http://isc.sans.edu/podcastdetail.html?id=4127, (Fri, Aug 29th)

Thu, 08/28/2014 - 17:12
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

False Positive or Not? Difficult to Analyze Javascript, (Fri, Aug 29th)

Thu, 08/28/2014 - 16:36

Our reader Travis sent us the following message:

We have had 2 users this morning hit a Forbes page: hxxp://www.forbes.com/sites/jimblasingame/2013/05/07/success-or-achievement/

And then after being referred from there to: hxxp://ml314.com/tag.aspx?2772014

They are setting off our FireEye web appliance. It is advising that this is an "Infection Match" which I am not entirely familiar with their systems determinations as it is fairly new to us. I called down the source of the link they went to and can submit that as well if you would like it, but I haven't had a chance to look at it yet just beautified it and saved it.

I went ahead and downloaded the "ml314.com" URL using wget, and what comes back is heavily obfuscated Javascript. I am just quoting some excerpts of it below:

(function(a){var g=window.document;var h=[];var e=[];var f=(g.readyState=="complete"||g.readyState=="loaded"||g.readyState=="interactive");var d=null;var j=function(k){try{k.apply(this,e)}catch(l){if(d!==null){d.call(this,l)}}};var c=functi...36);F=p(F,D,B,G,E[1],12,-389564586);G=p(G,F,D,B,E[2],17,606105819);B=p(B,G,F,D,E[3],22,-1044525330);D=p(D,B,G,F,E[4],7,-176418897);F=p(F,D,B,G,E[5],12,1200080426);G=p(G,F,D,B,E[6],17,-1473231341);B=p(B,G,F,D,E[7],22,-45705983);D=p(D,B,G,F,E[8],7,1770035416);F=p(F,D,B,G,E[9],12,-1958414417);G=p(G,F,D,B,E[10],17,-42063);B=p(B,G,F,D,E[11],22,-1990404162);D=p(D,B,G,F,E[12],7,1804603682);F=p(F,D,B,G,E[13],12,-40341101);G=p(G,F,D, ... function f(o){o.preventDefault();o.stopPropagation()}function i(o){if(g){return g}if(o.matches){g=o.matches}if(o.webkitMatchesSelector){g=o.webkitMatchesSelector}if(o.mozMatchesSelector){g=o.mozMatchesSelector}if(o.msMatchesSelector){g=o.msMatchesSelector}if(o.oMat ... try{s=new ActiveXObject("ShockwaveFlash.ShockwaveFlash");p=s.GetVariable("$version").substring(4);p=p.split(",");p=p[0]+"."+p[1]}catch(r){}if(s){q="Flash"}return{name:q,version:

In short: Very obfuscated (not just "minimized"), and a lot of keywords that point to detecting plugin versions. Something that you would certainly find in your average exploit kit. But overall, it didn't quite "add up". Not having a ton of time, I ran it through a couple Javascript de-obfuscators without much luck. The domain "ml314.com" also looked a bit "odd", but lets see when it was registered:

$ whois ml314.com​

   Domain Name: ML314.COM
   Name Server: NS.RACKSPACE.COM
   Name Server: NS2.RACKSPACE.COM
   Updated Date: 22-apr-2013
   Creation Date: 22-apr-2013
   Expiration Date: 22-apr-2018

​Admin Organization: Madison Logic
Admin Street: 257 Park Ave South
Admin Street: 5th Floor

The domain name isn't new, and hosted in what I would call a "decent" neighborhood on the Internet. The owner information doesn't look outright fake, and indeed gives us a bit more information to solve the puzzle. Turns out that "Madison Logic" is in the web advertisement / click through business, so what you are seeing is likely their proprietary Javascript to track users better. 

In the end, I call this a "false positive", but then again, feel free to correct me. This is just one example how sometimes things are not simple "black/white" when it comes to odd Javascript.

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

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

ISC StormCast for Thursday, August 28th 2014 http://isc.sans.edu/podcastdetail.html?id=4125, (Thu, Aug 28th)

Wed, 08/27/2014 - 17:44
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

One More Day of Trolling in POS Memory, (Wed, Aug 27th)

Wed, 08/27/2014 - 15:36

Further to the recent story on Memory Trolling for PCI data, I was able to spend one more day fishing in memory, I dug a bit deeper and come up with more fun Credit Card / Memory goodness with our friend the Point of Sale application.

First of all, just searching for credit card numbers returns a lot of duplicates, as indicated in yesterday's story.  In the station and POS application I was working with, it turns out that if you search for the card number string plus the word "Approved", a single line was returned per transaction, with the credit card and PIN.  For instance, to find all Visa card transactions (one record per transaction):

strings memdump.img | grep VISA | grep -i APPROVED  | wc -l         
     323       

In addition, I was able to find several hundred debit card numbers, simply by using those same search concept, but using the term "INTERAC" instead.  Note that this search gets you both the approved and not approved transactions.

strings memdump.img | grep INTERAC | grep -i APPROVED | wc -l
     200

With that done, I started looking at the duplicate data, and realized that some of the duplicate "records" I was tossing out looked interesting - sort of XML-like.   Upon closer inspection, it turns out that they were fully formed MS SQL posts (and no, just as the credit card numbers themselves, I won't be sharing the text of any of those)

Interestingly, the SQL post formatted the credit card numbers as 123456******1234, such that the first 6 and last 4 digits are in clear text,but the middle digits are masked out.  

This lines right up with the PCI 2.0 spec, section 3.3, which indicates that if you mask a PAN (Primary Account Number) that way, it is no longer considered sensitive. (https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf).  I'm not sure how keen I am on 3.3 -  - I can see that storing this info allows the merchant to use that as a "pseudo customer number", so that they can track repeat purchases and so on, but I'm not sure that the benefits outweigh the risks in this case.   I'd much prefer encrypting on the reader itself, so that the merchant and POS software never sees the card number at all - it's encrypted right from the reader to the payment processor (or gateway).

As I said when I started this, I'm not the expert memory carver that some of our readers are - please, use our comment section and tell us what interesting things you've found in a memory image!

===============
Rob VandenBrink
Metafore

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

Microsoft has modified and re-released MS14-045 - http://support.microsoft.com/kb/2993651 / https://technet.microsoft.com/en-us/library/security/ms14-045.aspx, (Wed, Aug 27th)

Wed, 08/27/2014 - 14:59
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Wednesday, August 27th 2014 http://isc.sans.edu/podcastdetail.html?id=4123, (Wed, Aug 27th)

Tue, 08/26/2014 - 18:40
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Tuesday, August 26th 2014 http://isc.sans.edu/podcastdetail.html?id=4121, (Tue, Aug 26th)

Mon, 08/25/2014 - 17:33
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Point of Sale Terminal Protection - "Fortress PCI at the Mall", (Tue, Aug 26th)

Mon, 08/25/2014 - 17:13

This is a very broad topic, but over the last few months I've seen some really nicly protected PCI termainls.  Especially since many POS environments are still running Windows XP, this is an important topic to discuss.

Things that I've seen done very well:

First of all, only allow access to the POS app - retail staff generally don't require access to email or the internet, at least not from the sales terminal.  Most POS systems I've seen are running kiosk setups, which removes explorer, the start button and kills all hotkeys.  I'm often able to break out of windows kiosk applications from the keyboard by using a hotkey combination that's been missed.  For instance, Windows+U calls utilman.exe in XP, if you replace utilman with cmd.exe you are in.  Be sure to account for hot-keys!

If you lock down the POS terminals such that a CMD prompt / start menu and so on are not accessible, then the classic "usb rubber ducky" or "teensy" keyboard as a usb key type attack - where you drop a usb key into and exposed port while making a purchase - is that much tougher.  If you can't get a cmd prompt or some field to enter commands, a malicious keyboard attack of this type isn't likely to succeed.

On that same note, use GPO or your endpoint protection product to lock down USB access.  Even if (or maybe especially if) a repair tech needs USB access, inserting a USB device should need a call to head office.

Use network protections:
The local router generally establishes a VPN to head office
The POS terminal should not have internet access
The POS terminal should have only limited access to head office resources (typically a small DMZ for data collection)
Similarly, only required head office resources should have access to the POS terminal
The POS terminal should not  be on the same network as or have access to the rest of the store.  For instance, guest wireless, security cameras, alarm systems and so on should all be in VLANs other than the POS VLAN, and none of those should have access to the POS (and vice versa)

For goodness sake, harden your store's firewall/router, and use a template (that you audit) so that you know that they are all configured correctly!  Hardening guides are available for most platforms, the Center for Internet Security's hardening guide for Cisco is a solid one to use as a guide if your perimeter device doesn't have a vendor supplied document.  Though if your firewall/router vendor doesn't have security guidance, maybe you should look at a different solution ...

If your POS terminal tries to connect to an IP that isn't yours, that's an IOC (Indicator of Compromise) - even a simple DNS query to a "different" server can be a giveaway.  If you see unexplained traffic, it's worth investigating - whitelisting stuff like this to make the alert go away is a BAD IDEA!

Use endpoint protections to your advantage.  That means AV, whitelisting and every other EP feature.  Don't install an AV product and leave it at the defaults, tune it for your POS systems.  While you can certainly circumvent AV using SET, Metasploit, VEIL and so on, that's a moving target.  What might work today to evade one AV vendor might very well not work tomorrow.  PLus you'll find that getting a generic application to evade AV is tough - most of the Metasploit evasion techniques top out at a fairly small memory footprint (4K in a lot of cases)

A distributed IPS is the way to go. With hundreds or in some cases thousands of terminals, you need an IPS local to each terminal to detect IOCs as early in the process as possible.  

Secure your passwords, have a good password policy in the OS, and / or use 2 factor
Don't re-use admin passwords.  If an attacker can get mimikatz on your system, or use procdump to get an lsass memory image, then (on XP), you've likely given up most of the passwords on that system.  Even without that, once you get password hashes, anyone who's serious can use GPUs and crack all the local passwords within a few minutes (or a few days if they have to go with brute force).  
Don't store passwords under the keyboard.  In almost every POS engagement, I can lift up the keyboard and have immediate access.  It's to the point that I include that photo in my reports.  Granted, in most stores getting to the keyboard can be a challenge, but if you show up with a laptop bag and say "I'm with IT, Joe (or whoever the IT Director is) sent me", you'd be surprised how much help you'll get from the sales folks.

Keep on top of current POS malware, especially the IOCs for each (the recent backoff malware is a good example).   This week's alert from the US CERT no the new backoff variants is a good read for instance (https://www.us-cert.gov/ncas/alerts/TA14-212A).  The copious amount of discussion on the Target breach (and the associated BlackPOS malware) is another place to look.

Each of these protections in themselves can be circumvented.  But the more you layer on, the better  The harder you make your attacker work to penetrate your environment, the more likely they will target someone else.  Your goal is to make things as difficult for the attacker as possible, to force them to make as much "noise" - ie generate as many alarms- as possible as they work their way in, to give you a chance at blocking them at one point or another

This is just a start at protecting a POS system or netowrk.  This is meant as the start of a disucssion - I'd be very interested to know what else folks are doing to secure their terminals.  Please use our comment form to share your approaches!

==============
Rob VandenBrink, Metafore

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

Trolling Memory for Credit Cards in POS / PCI Environments, (Tue, Aug 26th)

Mon, 08/25/2014 - 17:06

In a recent penetration test, I was able to parlay a network oversight into access to a point of sale terminal.  Given the discussions these days, the next step for me was an obvious one - memory analysis.

My first step was to drive to the store I had compromised and purchase an item.

I'm not a memory analysis guru, but the memory capture and analysis was surprisingly easy.  First, dump memory:
dumpit
Yup, it's that simple, I had the dumpit executable locally by that point (more info here https://isc.sans.edu/diary/Acquiring+Memory+Images+with+Dumpit/17216)
or, if you don't have keyboard access (dumpit requires a physical "enter" key, I/O redirection won't work for this):
win32dd /f memdump.img
(from the SANS Forensics Cheat Sheet at https://blogs.sans.org/computer-forensics/files/2012/04/Memory-Forensics-Cheat-Sheet-v1_2.pdf )

Next, I'll dig for my credit card number specifically:

strings memdump.img | grep [mycardnumbergoeshere] | wc -l
     171

Yup, that's 171 occurences in memory, unencrypted.  So far, we're still PCI complaint - PCI 2.0 doesn't mention cardholder data in memory, and 3.0 only mentions it in passing.  The PCI standard mainly cares about data at rest - which to most auditors means "on disk or in database", or data in transit - which means on the wire, capturable by tcpdump or wireshark.  Anything in memory, no matter how much of a target in today's malware landscape, is not an impact on PCI compliance.

The search above was done in windows, using strings from SysInternals - by default this detects strings in both ASCII and Unicode.  If I repeat this in linux (which by default is ASCII only), the results change:
strings memdump.img | grep [mycardnumbergoeshere] | wc -l
     32

To get the rest of the occurences, I also need to search for the Unicode representations,  which "strings" calls out as "little-endian" numbers:
strings -el memdump.img | grep [mycardnumbergoeshere] | wc -l
     139

Which gives me the same total of 171.

Back over to windows, let's dig a little deeper - how about my CC number and my name tied together?
strings memdump.img | grep [myccnumbergoeshere] | grep -i vandenbrink | wc -l
     1

or my CC number plus my PIN  (we're CHIP+PIN in Canada)
strings memdump.img | grep [mycardnumbergoeshere] | grep [myPINnumber]
     12

Why exactly the POS needs my PIN is beyond me!

Next, let's search this image for a number of *other* credit cards - rather than dig by number, I'll search for issuer name so there's no mistake.  These searches are all using the Sysinternals "strings" since the defaults for that command lend itself better to our search:

CAPITAL ONE       85
VISA             565
MASTERCARD      1335
AMERICAN EXPRESS  20

and for kicks, I also searched for debit card prefixes (I only search for a couple with longer IIN numbers):
Bank of Montreal   500766     245
TD CAnada Trust    589297    165

Looking for my number + my CC issuer in the same line gives me:
strings memdump.img | grep [myccnumbergoeshere] | grep [MASTERCARD] | wc -l
gives me a result of "5"

So, assuming that this holds true for others (it might not, even though the patterns are all divisible by 5), this POS terminal has hundreds, but more likely thousands of valid numbers in memory, along with names, PIN numbers and other informaiton

Finally, looking for a full magstripe in memory:

The search for a full stripe:
grep -aoE "(((%?[Bb]?)[0-9]{13,19}\^[A-Za-z\s]{0,26}\/[A-Za-z\s]{0,26}\^(1[2-9]|2[0-9])(0[1-9]|1[0-2])[0-9\s]{3,50}\?)[;\s]{1,3}([0-9]{13,19}=(1[2-9]|2[0-9])(0[1-9]|1[0-2])[0-9]{3,50}\?))" memdump.img  | wc -l
    0

where:

    -a = Processes a binary file as text
    -o = Shows only the matched text
    -E = Treats the pattern as an extended regular expression

or using this regex to find Track strings only:

((%?[Bb]?)[0-9]{13,19}\^[A-Za-z\s]{0,26}\/[A-Za-z\s]{0,26}\^(1[2-9]|2[0-9])(0[1-9]|1[0-2])[0-9\s]{3,50}\?)
gives us 0 results.

or this regex to find Track 2 strings only:

([0-9]{13,19}=(1[2-9]|2[0-9])(0[1-9]|1[0-2])[0-9]{3,50}\?)  
Gives us 162  (I'm not sure how much I trust this number)

Anyway, what this tells me is that this store isn't seeing very many folks swipe their cards, it's all CHIP+PIN (which you'd expect)

(Thanks to the folks at bromium for the original regular expressions and breakdown: http://labs.bromium.com/2014/01/13/understanding-malware-targeting-point-of-sale-systems/)

Getting system uptime (from the system itself) wraps up this simple analysis - the point of this being "how long does it take to collect this much info?"

net statistics server | find "since""
shows us that we had been up for just under 4 days.

Other ways to find uptime?
from the CLI:
systeminfo " find "Boot Time"
or, in powershell:
PS C:\> Get-WmiObject win32_operatingsystem | select csname, @{LABEL='LastBootUpTime';EXPRESSION={$_.ConverttoDateTime($_.lastbootuptime)}}
or, in wmic:
wmic get os last bootuptime
or, if you have sysinternals available, you can just run "uptime"


What does this mean for folks concerned with PCI compliance?
Today, not so much.  Lots of environments are still operating under PCI 2.0.  PCI 3.0 simply calls for education on the topic of good coding practices to combat memory scraping.  Requirement 6.5 phrases this as "Train developers in secure coding techniques, including how to avoid common coding vulnerabilities, and understanding how sensitive data is handled in memory.  Develop applications based on secure coding guidelines."

Personally (and this is just my opinion), I would expect/hope that the next version of PCI will call out encryption of card and personal information in memory specifically as a requirement.  If things play out that way, What this will mean to the industry is that either:
a/ folks will need to move to card readers that encrypt before the information is on the POS terminal
or
b/ if they are using this info to collect sales / demographic information, they might instead tokenize the CC data for the database, and scrub it from memory immediately after.  All  I can say to that approach is "good luck".  Memory management is usually abstracted from the programming language, so I'm not sure how successful you'd be in trying to scrub artifacts of this type from memory.

===============
Rob VandenBrink, Metafore

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

UDP port 1900 DDoS traffic, (Mon, Aug 25th)

Mon, 08/25/2014 - 11:26

I guess this is my day for asking for feedback from our readers.  Again, I'm going to ask "Got packets?"  On 22 Aug, one of our readers (Paul) commented on the Port 1900 page that he was seeing a DDoS on port 1900, with packet sizes of 300 bytes.  This is a development we've been watching at $dayjob, too, but I was wondering if anyone (including Paul) has packets so we can try to figure out what the amplification mechanism might actually be (if you have the packets, please share via the contact page).  What we're seeing in Dshield data is a little odd and different from what I'm seeing at $dayjob.  You'll note below that there were a more targets until they suddenly dropped off on 18 Jun.  On the other hand, the sources seem to be trending upward (at least, peaking higher).  Unfortunately, we only have source and target counts in the Dshield data, not byte volumes.  Compare that with what we're seeing at the $dayjob as shown in the webcast we do weekly there (from 39:55 in this video -- watch to about 47:00 if you want to see our discussion of all the reflective DoS ports we're watching).

References:
[1] https://isc.sans.edu/port.html?port=1900
[2] http://techchannel.att.com/play-video.cfm/2014/8/14/AT&T-ThreatTraq-1-Billion-Accounts-Hacked

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

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

Unusual CRL traffic?, (Mon, Aug 25th)

Mon, 08/25/2014 - 06:51

One of our readers, Brian, wrote in this morning saying that he was seeing an unusually high volume of traffic attempting to check certificate revocation lists (CRLs) from lots of different IPs (so it doesn't look like a denial of service attack, there are lots of both sources and destinations).  I haven't heard of anything that going on that would cause this behavior, but thought I'd ask our readers if they were seeing anything similar.  Could a patch have caused it?  Microsoft did patch IE 10 days ago, but that would be quite a lag time.  If anyone else is seeing this and could grab a sample of the traffic (so we could look at User-Agents, etc.) please respond below or through our contact page.  Thanx in advance for your assistance.

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

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

ISC StormCast for Monday, August 25th 2014 http://isc.sans.edu/podcastdetail.html?id=4119, (Mon, Aug 25th)

Sun, 08/24/2014 - 18:52
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

NSS Labs Cyber Resilience Report, (Sat, Aug 23rd)

Fri, 08/22/2014 - 16:36

Bob Walder and Chris Morales of NSS Labs published an interesting brief. Based on last year IPS, firewall and endpoint protection tests, the effectiveness of the best device scored was 98.5%. While this is considered excellent, there is still ~2 percent of attacks that make it through the perimeter and host layer defences. Two of their proposals is to attempt to control the attacker by redirecting the attack against a target you can watch and control (i.e. tarpit the attacker) and to regularly test your network to detect problems before someone else does and exploit that system.

They have listed several recommendations but one that I think is worth focussing is be "Prepare to operate at 60 percent capacity in order to withstand a breach, which will reduce, but not eliminate, critical services." [1]

It is very likely the impact will be affecting users, customers and business. Who is prepared to continue to operate at 60% capacity without affecting business or the bottom line?

The eleven page report can be downloaded here.

[1] https://www.nsslabs.com/system/files/public-report/files/Cyber%20Resilience_0.pdf
[2] https://www.nsslabs.com/blog/cyber-resilience-%E2%80%93-it%E2%80%99s-not-98-you-catch-matters-it%E2%80%99s-2-you-miss

-----------

Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot edu

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

NSS Labs Cyber Resilience Report, (Sat, Aug 23rd)

Fri, 08/22/2014 - 16:36

Bob Walder and Chris Morales of NSS Labs published an interesting brief. Based on last year IPS, firewall and endpoint protection tests, the effectiveness of the best device scored was 98.5%. While this is considered excellent, there is still ~2 percent of attacks that make it through the perimeter and host layer defences. Two of their proposals is to attempt to control the attacker by redirecting the attack against a target you can watch and control (i.e. tarpit the attacker) and to regularly test your network to detect problems before someone else does and exploit that system.

They have listed several recommendations but one that I think is worth focussing is be "Prepare to operate at 60 percent capacity in order to withstand a breach, which will reduce, but not eliminate, critical services." [1]

It is very likely the impact will be affecting users, customers and business. Who is prepared to continue to operate at 60% capacity without affecting business or the bottom line?

The eleven page report can be downloaded here.

[1] https://www.nsslabs.com/system/files/public-report/files/Cyber%20Resilience_0.pdf
[2] https://www.nsslabs.com/blog/cyber-resilience-%E2%80%93-it%E2%80%99s-not-98-you-catch-matters-it%E2%80%99s-2-you-miss

-----------

Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot edu

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

PHP 5.5.16 is available http://www.php.net/ChangeLog-5.php#5.5.16, (Fri, Aug 22nd)

Fri, 08/22/2014 - 10:25

Richard Porter --- ISC Handler on Duty

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

PHP 5.4.32 Released http://www.php.net/ChangeLog-5.php#5.4.32, (Fri, Aug 22nd)

Fri, 08/22/2014 - 06:14

Richard Porter --- ISC Handler on Duty

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

OCLHashCat 1.30 Released, (Fri, Aug 22nd)

Fri, 08/22/2014 - 05:55

For those of us who are using GPUs to turn hashes into passwords and other useful info, the folks at hashcat.net have released a new version of OCLHashCat.

What's new?
Performance increases in almost every algorithm

New hashing algorithms:
md5($salt.md5($pass))  (added just for  Mediawiki B)
Mediawiki B type
Kerberos 5 AS-REQ Pre-Auth etype 23 as fast algorithm (reimplementation)
Android FDE
scrypt
Password Safe v2
Lotus Notes/Domino 8

New parsers
Skype
PeopleSoft

Full release notes here: https://hashcat.net/forum/thread-3627.html
Download here:  http://hashcat.net/oclhashcat/

Posted on Behalf of Rob.

~Richard

--Handler on Duty

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

ISC StormCast for Friday, August 22nd 2014 http://isc.sans.edu/podcastdetail.html?id=4117, (Fri, Aug 22nd)

Thu, 08/21/2014 - 18:59
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Now supporting OpenIOC via our API!, (Thu, Aug 21st)

Thu, 08/21/2014 - 16:25
The SANS Internet Storm Center is proud to announce the release of our first OpenIOC format API call. We have been hard at work writing a method that serves our firewall logs as OpenIOC XML content dynamically from a RESTful HTTP request. This is a critical step in expanding our service offerings to you, our readers, members and contributors.   You can use tools that ISC handler Russ McRee mentioned in a previous diary to convert output from this new method into STIX format. This is just the beginning however; the development roadmap includes the addition of another API method with the same data served in STIX format!   Ready to get started? View the documentation here: https://isc.sans.edu/api/#openiocsources   Please share your feedback as well as use cases and success stories as they unfold in the comments below.   A big thanks to Russ McRee for his assistance with testing and the writing of this announcement!

-- 
Alex Stanford - GIAC GWEB & GSEC
Research Operations Manager,
SANS Internet Storm Center

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

ISC StormCast for Thursday, August 21st 2014 http://isc.sans.edu/podcastdetail.html?id=4115, (Thu, Aug 21st)

Wed, 08/20/2014 - 18:02
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts