FYI
http://www.crn.com/news/security/300073406/doj-cryptolocker-trojan-is-now-out-of-commission.htm?cid=nl_sec#
On Jul 10, 2014, at 5:17 PM, Joe Acquisto-j4 wrote:
On 7/10/2014 at 3:35 PM, "David F. Skoll" wrote:
>> On Thu, 10 Jul 2014 12:25:50 -0700
>> Ted Mittelstaedt wrote:
>>
>>> Fundamentally I think the problem is with attachments.
>>
>> No, the problem is not with attachments. An attachme
>>> On 7/10/2014 at 3:35 PM, "David F. Skoll" wrote:
> On Thu, 10 Jul 2014 12:25:50 -0700
> Ted Mittelstaedt wrote:
>
>> Fundamentally I think the problem is with attachments.
>
> No, the problem is not with attachments. An attachment actually included
> in an email is no more dangerous than a
On Thu, 10 Jul 2014 12:25:50 -0700
Ted Mittelstaedt wrote:
> Fundamentally I think the problem is with attachments.
No, the problem is not with attachments. An attachment actually included
in an email is no more dangerous than an attachment downloaded via a link.
Email attachments are far too c
On 7/10/2014 12:12 PM, John Hardin wrote:
On Thu, 10 Jul 2014, Ted Mittelstaedt wrote:
On 7/10/2014 8:26 AM, David F. Skoll wrote:
On Wed, 9 Jul 2014 17:44:26 -0700 (PDT)
John Hardin wrote:
> I'm not excusing their approach, but I'm saying there are a lot of
> sources of real-world friction
On Thu, 10 Jul 2014, Ted Mittelstaedt wrote:
On 7/10/2014 8:26 AM, David F. Skoll wrote:
On Wed, 9 Jul 2014 17:44:26 -0700 (PDT)
John Hardin wrote:
> I'm not excusing their approach, but I'm saying there are a lot of
> sources of real-world friction that lead to suboptimal solutions like
On 7/10/14, 1:43 PM, "Ted Mittelstaedt" wrote:
>And when victim of the phish clicks on the SSL link then the browser
>sends out alarm bells that the SSL certificate is compromised and not to
>go there, eh?
If we could rely on users to not click right through that SSL warning, we
would be living
On Thu, 10 Jul 2014 11:43:21 -0700
Ted Mittelstaedt wrote:
> SO I think that using PGP was the right course of action here.
Yes, of course. But they should supply the PGP *software* using a
separate delivery mechanism from the PGP-encrypted *payload*.
Encouraging people to rename and run execut
On 7/10/2014 8:26 AM, David F. Skoll wrote:
On Wed, 9 Jul 2014 17:44:26 -0700 (PDT)
John Hardin wrote:
I'm not excusing their approach, but I'm saying there are a lot of
sources of real-world friction that lead to suboptimal solutions like
this. I expect the desire to avoid requiring install
On Thu, 10 Jul 2014, Ted Mittelstaedt wrote:
Although from the pro-gunners out there now we will hear the "software
doesn't kill people, users kill people" arguments claiming it's not
Symantec's fault
Please do not go there.
--
John Hardin KA7OHZhttp://www.impsec.org/~jh
On 7/10/2014 12:31 PM, Ted Mittelstaedt wrote:
You didn't read your own code of ethics.
It states if you have a bias, you disclose it. David HAD a bias in his
original post and DID NOT disclose it. He DID subsequently disclose
that bias AFTER I had called him on it and I commend him for it.
T
You didn't read your own code of ethics.
It states if you have a bias, you disclose it. David HAD a bias in his
original post and DID NOT disclose it. He DID subsequently disclose
that bias AFTER I had called him on it and I commend him for it.
This is the problem with codes of ethics - it's e
On 7/9/2014 5:18 PM, David F. Skoll wrote:
On Wed, 09 Jul 2014 14:44:27 -0700
Ted Mittelstaedt wrote:
David DID NOT say that. He said that "he was shocked to discover"
Why are you assuming he is under NDA or he is an employee of this
company?
Let me clarify the situation:
1) I'm the owne
I believe strongly that ALL IT admins would be well guided by reading
the SAGE ethics guide
http://www.pccc.com/base.cgim?template=sage_code_of_ethics
Can't recommend it highly enough and I think it would guide well in this
gray areas on how to handle things.
I didn't like that a poster wi
On Wed, 9 Jul 2014 17:44:26 -0700 (PDT)
John Hardin wrote:
> I'm not excusing their approach, but I'm saying there are a lot of
> sources of real-world friction that lead to suboptimal solutions like
> this. I expect the desire to avoid requiring installation (and
> maintenance!) of PGP/GPG by th
On 7/8/2014 10:41 PM, David F. Skoll wrote:
On Tue, 08 Jul 2014 21:03:35 -0400
"Kevin A. McGrail" wrote:
So this sounds like you are searching the entire email for this
string which just sounds inefficient especially if they use some big
attachments.
It's not too bad because the regex is simp
On Wed, Jul 9, 2014 at 5:44 PM, Ted Mittelstaedt wrote:
>
>
> On 7/9/2014 11:37 AM, Mauricio Tavares wrote:
>>
>> On Wed, Jul 9, 2014 at 2:23 PM, Ted Mittelstaedt wrote:
>>>
>>>
>>> First of all why do people insist on hiding names of companies that
>>> do stuff like this? It just makes it look
On Wed, 9 Jul 2014, Ted Mittelstaedt wrote:
You are an administrator. YOU ARE PAID BY CLUELESS USERS TO PROTECT
THEM AND THEIR DATA, DAMMIT.
...unless it involves some actual, you know, effort on their part.
And in this instance, Large DP Company *is* doing something proactive to
protec
On Wed, 09 Jul 2014 14:44:27 -0700
Ted Mittelstaedt wrote:
> David DID NOT say that. He said that "he was shocked to discover"
> Why are you assuming he is under NDA or he is an employee of this
> company?
Let me clarify the situation:
1) I'm the owner of Roaring Penguin, so my boss is unlikel
On 7/9/2014 11:37 AM, Mauricio Tavares wrote:
On Wed, Jul 9, 2014 at 2:23 PM, Ted Mittelstaedt wrote:
First of all why do people insist on hiding names of companies that
do stuff like this? It just makes it look like your manufacturing
an event that doesn't exist, it destroys your credibili
On Wed, Jul 9, 2014 at 2:23 PM, Ted Mittelstaedt wrote:
>
> First of all why do people insist on hiding names of companies that
> do stuff like this? It just makes it look like your manufacturing
> an event that doesn't exist, it destroys your credibility.
>
You mean besides NDAs and polici
First of all why do people insist on hiding names of companies that
do stuff like this? It just makes it look like your manufacturing
an event that doesn't exist, it destroys your credibility.
Secondly, if you think that this is an example of "badness" on Windows
security best practices you sim
On Wed, 09 Jul 2014 05:44:34 +0200
Karsten Bräckelmann wrote:
> If you deliberately try to sneak past sensible security measures, you
> should not be surprised to be blocked. The attempt by an honest user
> to disguise any $file (he did it on purpose, so he knows there's
> issues with that) is in
On Tue, 2014-07-08 at 22:41 -0400, David F. Skoll wrote:
> On Tue, 08 Jul 2014 21:03:35 -0400, Kevin A. McGrail wrote:
>
> > So this sounds like you are searching the entire email for this
> > string which just sounds inefficient especially if they use some big
> > attachments.
>
> It's not too b
On Tue, 08 Jul 2014 21:03:35 -0400
"Kevin A. McGrail" wrote:
> So this sounds like you are searching the entire email for this
> string which just sounds inefficient especially if they use some big
> attachments.
It's not too bad because the regex is simple.
> Since I'm guessing you are using M
On 7/7/2014 5:34 PM, David F. Skoll wrote:
Replying to myself...
full MSDOGEXE /\n\nTV[opqr]/
Seems to work. :)
So this sounds like you are searching the entire email for this string
which just sounds inefficient especially if they use some big attachments.
Since I'm guessing you are usin
Replying to myself...
> full MSDOGEXE /\n\nTV[opqr]/
Seems to work. :)
Regards,
David.
So, the inevitable had to happen. The cryptolocker folks are getting
around extension blocking with this:
==
PLEASE NOTE!
In case you are not able to open the attached document, please save it
to your computer and manually a
28 matches
Mail list logo
