I was so pleased to read this Tweet yesterday from Greg Rattray:

"Back in 2007, I coined the term “Advanced Persistent Threat” to characterize emerging adversaries that we needed to work with the defense industrial base to deal with... Since then both the APT term and the nature of our adversaries have evolved. What hasn’t changed is that in cyberspace, advanced attackers will persistently go after targets with assets they want, no matter the strength of defenses."

Background


First, some background. Who is Greg Rattray?

First, you could call him Colonel or Doctor. I will use Col as that was the last title I used with him, although these days when we chat I call him Greg. 

Col Rattray served 21 years in the Air Force and also earned his PhD in international security from Tufts University. His thesis formed the content for his 2001 book Strategic Warfare in Cyberspace, which I reviewed in 2002 and rated 4 stars. (Ouch -- I was a bit stingy with the stars back then. I was more of an operator and less of a theorist or historian in those days. Such was my bias I suppose.)

Col Rattray is also a 1984 graduate of the Air Force Academy. He studied history and political science there and returned as an assistant professor in the early 1990s. He was one of my instructors when I was a cadet there. (I graduated in 1994 with degrees in history and political science.) Col Rattray then earned a master of public policy degree at Harvard Kennedy School. (I did the same, in 1996.) 

Do you see a pattern here? He is clearly a role model. Of course, I did not stay in the Air Force as long, earn the same rank, or survive my PhD program!

After the Academy, Col Rattray served as commander of the 23rd Information Operations Squadrons on Security Hill in San Antonio, Texas. I was working in the AFCERT at the time. 

One of the last duties I had in uniform was to travel to Nellis AFB outside Las Vegas and participate in a doctrine writing project for information warfare. At the time I was not a fan of the idea, but Col Rattray convinced me someone needed to write down how we did computer network defense in the AFCERT. 

He didn't order me to participate, which I always appreciated. Years later I told him it was a good idea to organize that project and that I was probably just grumpy because of the way the Air Force personnel system had treated me at the end of my military career.

Why The Tweet Matters


For years I've had to dance around the issue of who invented the term "APT." In most narratives I say that an Air Force colonel invented the term in 2006. I based this on discussions I had with colleagues in the defense industrial base who were working with said colonel and his team from the Air Force. I did not know back then that it was Col Rattray and his team from the Air Force Information Warfare Center. 

Years later I learned of Rattray's role, but not directly from him. Only this year did Col Rattray confirm to me that he had invented the term, and that 2007 was the correct year. I encouraged him to say something, because as an historian I appreciate the value of facts and narrative. As I Tweeted after seeing Greg's Tweet:

"Security, like any other field, has HISTORY, which means there are beginnings, and stories, and discoveries, and innovators, and leaders, and first steps, and pioneers. I'm so pleased to see people like @GregRattray_ feel comfortable enough after all these years to say something."

I don't think many people in the security field think about history. Security tends to be obsessed with the "new" and the "shiny." Not enough people wonder how we got to this point, or what decisions led to the current situation. The security scene in 2020 is very different from the scene in 1960, or 1970, or 1980, or 1990, or 2000, or even 2010. This is not the time to describe how or why that is the case. I'm just glad a very important piece of the puzzle is now public.

More on the APT



If you'd like to learn more about this history of the APT, check out my newest book -- The Best of TaoSecurity Blog, Volume 2. I devote an entire chapter to blog posts and new commentary on the APT. Volume 1 arrived a few months before this new book, and I'm working on Volume 3 now.

The FBI intrusion notification program is one of the most important developments in cyber security during the last 15 years. 

This program achieved mainstream recognition on 24 March 2014 when Ellen Nakashima reported on it for the Washington Post in her story U.S. notified 3,000 companies in 2013 about cyberattacks

The story noted the following:

"Federal agents notified more than 3,000 U.S. companies last year that their computer systems had been hacked, White House officials have told industry executives, marking the first time the government has revealed how often it tipped off the private sector to cyberintrusions...

About 2,000 of the notifications were made in person or by phone by the FBI, which has 1,000 people dedicated to cybersecurity investigations among 56 field offices and its headquarters. Some of the notifications were made to the same company for separate intrusions, officials said. Although in-person visits are preferred, resource constraints limit the bureau’s ability to do them all that way, former officials said...

Officials with the Secret Service, an agency of the Department of Homeland Security that investigates financially motivated cybercrimes, said that they notified companies in 590 criminal cases opened last year, officials said. Some cases involved more than one company."

The reason this program is so important is that it shattered the delusion that some executives used to reassure themselves. When the FBI visits your headquarters to tell you that you are compromised, you can't pretend that intrusions are "someone else's problem."

It may be difficult for some readers to appreciate how prevalent this mindset was, from the beginnings of IT to about the year 2010.

I do not know exactly when the FBI began notifying victims, but I believe the mid-2000's is a safe date. I can personally attest to the program around that time.

I was reminded of the importance of this program by Andy Greenberg's new story The FBI Botched Its DNC Hack Warning in 2016—but Says It Won’t Next Time

I strongly disagree with this "botched" characterization. Andy writes:

"[S]omehow this breach [of the Democratic National Committee] had come as a terrible surprise—despite an FBI agent's warning to [IT staffer Yared] Tamene of potential Russian hacking over a series of phone calls that had begun fully nine months earlier.

The FBI agent's warnings had 'never used alarming language,' Tamene would tell the Senate committee, and never reached higher than the DNC's IT director, who dismissed them after a cursory search of the network for signs of foul play."

As with all intrusions, criminal responsibility lies with the intruder. However, I do not see why the FBI is supposed to carry the blame for how this intrusion unfolded. 

According to investigatory documents and this Crowdstrike blog post on their involvement, at least seven months passed from the time the FBI notified the DNC (sometime in September 2015) and when they contacted Crowdstrike (30 April 2016). That is ridiculous. 

If I received a call from the FBI even hinting at a Russian presence in my network, I would be on the phone with a professional incident response firm right after I briefed the CEO about the call.

I'm glad the FBI continues to improve its victim notification procedures, but it doesn't make much of a difference if the individuals running IT and the organization are negligent, either through incompetence or inaction.

Note: Fixed year typo.


 

I published a new book!

The Best of TaoSecurity Blog, Volume 2: Network Security Monitoring, Technical Notes, Research, and China and the Advanced Persistent Threat

It's in the Kindle Store, and if you're Unlimited it's free. Print edition to follow.

The book lists as having 413 pages (for the Kindle edition at least) at it's almost 95,000 words. I started working on it in June after finishing Volume 1.

Here is the book description:

Since 2003, cybersecurity author Richard Bejtlich has been writing posts on TaoSecurity Blog, a site with 15 million views since 2011. Now, after re-reading over 3,000 posts and approximately one million words, he has selected and republished the very best entries from 17 years of writing. 

In the second volume of the TaoSecurity Blog series, Mr. Bejtlich addresses how to detect and respond to intrusions using third party threat intelligence sources, network data, application and infrastructure data, and endpoint data. He assesses government and private security initiatives and applies counterintelligence and counteradversary mindsets to defend digital assets. He documents the events of the last 20 years of Chinese hacking from the perspective of a defender on the front lines, in the pre- and post-APT era. 

This volume contains some of Mr. Bejtlich’s favorite posts, such as histories of threat hunting, so-called black and white hat budgeting, attribution capabilities and limits, and rating information security incidents. He has written new commentaries to accompany each post, some of which would qualify as blog entries in their own right.  Read how the security industry, defensive methodologies, and strategies to improve national security have evolved in this new book, written by one of the authors who has seen it all and survived to blog about it.

I have a third volume planned. I will publish it by the end of the year. 


If you have any questions about the book, let me know. Currently you can see the table of contents via the "Look Inside" function, and there is a sample that lets you download and read some of the book. Enjoy!
Are you a network security monitoring dinosaur like me? Do you prefer to inspect your Zeek logs using the command line instead of a Web-based SIEM?

If yes, try this one weird trick!

I store my Zeek logs in JSON format. Sometimes I like to view the output using jq.

If I need to search directories of logs for a string, like a UID, I might* use something like zgrep with the following syntax:

$ zgrep "CLkXf2CMo11hD8FQ5" 2020-08-16/*

2020-08-16/conn_20200816_06:00:00-07:00:00+0000.log.gz:{"_path":"conn","_system_name":"ds61","_write_ts":"2020-08-16T06:26:10.266225Z","_node":"worker-01","ts":"2020-08-16T06:26:01.485394Z","uid":"CLkXf2CMo11hD8FQ5","id.orig_h":"192.168.2.76","id.orig_p":53380,"id.resp_h":"196.216.2.24","id.resp_p":21,"proto":"tcp","service":"ftp","duration":3.780829906463623,"orig_bytes":184,"resp_bytes":451,"conn_state":"SF","local_orig":true,"local_resp":false,"missed_bytes":0,"history":"ShAdDafF","orig_pkts":20,"orig_ip_bytes":1232,"resp_pkts":17,"resp_ip_bytes":1343,"community_id":"1:lEESxqaSVYqFZvWNb4OccTa9sTs="}
2020-08-16/ftp_20200816_06:26:04-07:00:00+0000.log.gz:{"_path":"ftp","_system_name":"ds61","_write_ts":"2020-08-16T06:26:04.077276Z","_node":"worker-01","ts":"2020-08-16T06:26:03.553287Z","uid":"CLkXf2CMo11hD8FQ5","id.orig_h":"192.168.2.76","id.orig_p":53380,"id.resp_h":"196.216.2.24","id.resp_p":21,"user":"anonymous","password":"ftp@example.com","command":"EPSV","reply_code":229,"reply_msg":"Entering Extended Passive Mode (|||31746|).","data_channel.passive":true,"data_channel.orig_h":"192.168.2.76","data_channel.resp_h":"196.216.2.24","data_channel.resp_p":31746}
2020-08-16/ftp_20200816_06:26:04-07:00:00+0000.log.gz:{"_path":"ftp","_system_name":"ds61","_write_ts":"2020-08-16T06:26:05.117287Z","_node":"worker-01","ts":"2020-08-16T06:26:04.597290Z","uid":"CLkXf2CMo11hD8FQ5","id.orig_h":"192.168.2.76","id.orig_p":53380,"id.resp_h":"196.216.2.24","id.resp_p":21,"user":"anonymous","password":"ftp@example.com","command":"RETR","arg":"ftp://196.216.2.24/pub/stats/afrinic/delegated-afrinic-extended-latest.md5","file_size":74,"reply_code":226,"reply_msg":"Transfer complete.","fuid":"FueF95uKPrUuDnMc4"}

That is tough on the eyes. I cannot simply pipe that output to Jq however:

$ zgrep "CLkXf2CMo11hD8FQ5" 2020-08-16/* | jq .
parse error: Invalid numeric literal at line 1, column 28

What I need to do is strip out the filename and colon before the JSON. I learned how to use sed to do this thanks to this post

$ zgrep "CLkXf2CMo11hD8FQ5" 2020-08-16/* | sed 's/.*gz://' | jq .

{
  "_path": "conn",
  "_system_name": "ds61",
  "_write_ts": "2020-08-16T06:26:10.266225Z",
  "_node": "worker-01",
  "ts": "2020-08-16T06:26:01.485394Z",
  "uid": "CLkXf2CMo11hD8FQ5",
  "id.orig_h": "192.168.2.76",
  "id.orig_p": 53380,
  "id.resp_h": "196.216.2.24",
  "id.resp_p": 21,
  "proto": "tcp",
  "service": "ftp",
  "duration": 3.780829906463623,
  "orig_bytes": 184,
  "resp_bytes": 451,
  "conn_state": "SF",
  "local_orig": true,
  "local_resp": false,
  "missed_bytes": 0,
  "history": "ShAdDafF",
  "orig_pkts": 20,
  "orig_ip_bytes": 1232,
  "resp_pkts": 17,
  "resp_ip_bytes": 1343,
  "community_id": "1:lEESxqaSVYqFZvWNb4OccTa9sTs="
}
{
  "_path": "ftp",
  "_system_name": "ds61",
  "_write_ts": "2020-08-16T06:26:04.077276Z",
  "_node": "worker-01",
  "ts": "2020-08-16T06:26:03.553287Z",
  "uid": "CLkXf2CMo11hD8FQ5",
  "id.orig_h": "192.168.2.76",
  "id.orig_p": 53380,
  "id.resp_h": "196.216.2.24",
  "id.resp_p": 21,
  "user": "anonymous",
  "password": "ftp@example.com",
  "command": "EPSV",
  "reply_code": 229,
  "reply_msg": "Entering Extended Passive Mode (|||31746|).",
  "data_channel.passive": true,
  "data_channel.orig_h": "192.168.2.76",
  "data_channel.resp_h": "196.216.2.24",
  "data_channel.resp_p": 31746
}
{
  "_path": "ftp",
  "_system_name": "ds61",
  "_write_ts": "2020-08-16T06:26:05.117287Z",
  "_node": "worker-01",
  "ts": "2020-08-16T06:26:04.597290Z",
  "uid": "CLkXf2CMo11hD8FQ5",
  "id.orig_h": "192.168.2.76",
  "id.orig_p": 53380,
  "id.resp_h": "196.216.2.24",
  "id.resp_p": 21,
  "user": "anonymous",
  "password": "ftp@example.com",
  "command": "RETR",
  "arg": "ftp://196.216.2.24/pub/stats/afrinic/delegated-afrinic-extended-latest.md5",
  "file_size": 74,
  "reply_code": 226,
  "reply_msg": "Transfer complete.",
  "fuid": "FueF95uKPrUuDnMc4"
}

Maybe this will help you too.

*I use the find command in other circumstances.

Update: Twitter user @captainGeech42 noted that I could use grep -h and omit the sed pipe, e.g.:

$ zgrep -h "CLkXf2CMo11hD8FQ5" 2020-08-16/* | jq .

Thanks for the tip!


Fake Book
Fake Book 

Someone published a "book" on Amazon and claimed that I wrote it! I had NOTHING to do with this. I am working with Amazon now to remove it, or at least remove my name. Stay away from this garbage!

Update: Thankfully, within a day or so of this post, the true author of this work removed it from Amazon. It has not returned, at least as far as I have seen.
Uncategorized


I'm very pleased to announce that I've published a new book!

It's The Best of TaoSecurity Blog, Volume 1: Milestones, Philosophy and Strategy, Risk, and Advice. It's available now in the Kindle Store, and if you're a member of Kindle Unlimited, it's currently free. I may also publish a print version. If you're interested, please tell me on Twitter.



The book lists at 332 pages and is over 83,000 words. I've been working on it since last year, but I've used the time in isolation to carry the first volume over the finish line.

The Amazon.com description says:

Since 2003, cybersecurity author Richard Bejtlich has been writing posts on TaoSecurity Blog, a site with 15 million views since 2011. Now, after re-reading over 3,000 posts and approximately one million words, he has selected and republished the very best entries from 17 years of writing.

In the first volume of the TaoSecurity Blog series, Bejtlich addresses milestones, philosophy and strategy, risk, and advice. Bejtlich shares his thoughts on leadership, the intruder's dilemma, managing burnout, controls versus assessments, insider versus outsider threats, security return on investment, threats versus vulnerabilities, controls and compliance, the post that got him hired at a Fortune 5 company as their first director of incident response, and much more.

He has written new commentaries to accompany each post, some of which would qualify as blog entries in their own right.  Read how the security industry, defensive methodologies, and strategies to improve career opportunities have evolved in this new book, written by one of the authors who has seen it all and survived to blog about it.

Finally, if you're interested in subsequent volumes, I have two planned.


I may also have a few other book projects in the pipeline. I'll have more to say on that in the coming weeks.

If you have any questions about the book, let me know. Currently you can see the table of contents via the "Look Inside" function, and there is a sample that lets you download and read some of the book. Enjoy!

CVE-2020-0688 Scan Results, per Rapid7

tl;dr -- it's the title of the post: "If You Can't Patch Your Email Server, You Should Not Be Running It."

I read a disturbing story today with the following news:

"Starting March 24, Rapid7 used its Project Sonar internet-wide survey tool to discover all publicly-facing Exchange servers on the Internet and the numbers are grim.

As they found, 'at least 357,629 (82.5%) of the 433,464 Exchange servers' are still vulnerable to attacks that would exploit the CVE-2020-0688 vulnerability.

To make matters even worse, some of the servers that were tagged by Rapid7 as being safe against attacks might still be vulnerable given that 'the related Microsoft update wasn’t always updating the build number.'

Furthermore, 'there are over 31,000 Exchange 2010 servers that have not been updated since 2012,' as the Rapid7 researchers observed. 'There are nearly 800 Exchange 2010 servers that have never been updated.'

They also found 10,731 Exchange 2007 servers and more than 166,321 Exchange 2010 ones, with the former already running End of Support (EoS) software that hasn't received any security updates since 2017 and the latter reaching EoS in October 2020."

In case you were wondering, threat actors have already been exploiting these flaws for weeks, if not months.

Email is one of, if not the most, sensitive and important systems upon which organizations of all shapes and sizes rely. The are, by virtue of their function, inherently exposed to the Internet, meaning they are within the range of every targeted or opportunistic intruder, worldwide.

In this particular case, unpatched servers are also vulnerable to any actor who can download and update Metasploit, which is virtually 100% of them.

It is the height of negligence to run such an important system in an unpatched state, when there are much better alternatives -- namely, outsourcing your email to a competent provider, like Google, Microsoft, or several others.

I expect some readers are saying "I would never put my email in the hands of those big companies!" That's fine, and I know several highly competent individuals who run their own email infrastructure. The problem is that they represent the small fraction of individuals and organizations who can do so. Even being extremely generous with the numbers, it appears that less than 20%, and probably less than 15% according to other estimates, can even keep their Exchange servers patched, let alone properly configured.

If you think it's still worth the risk, and your organization isn't able to patch, because you want to avoid megacorp email providers or government access to your email, you've made a critical miscalculation. You've essentially decided that it's more important for you to keep your email out of megacorp or government hands than it is to keep it from targeted or opportunistic intruders across the Internet.

Incidentally, you've made another mistake. Those same governments you fear, at least many of them, will just leverage Metasploit to break into your janky email server anyway.

The bottom line is that unless your organization is willing to commit the resources, attention, and expertise to maintaining a properly configured and patched email system, you should outsource it. Otherwise you are being negligent with not only your organization's information, but the information of anyone with whom you exchange emails.