Cuckoo’s Egg – Week 2 Notes

Session Recording: (Available 11/17-11/30)

Next Week’s Registration:

This week, we reviewed chapters 4-8.

After setting up his monitoring system, Cliff observes another suspicious login using the Sventek account. Now, Cliff is better equipped to figure out what is going on and monitor every command issued by the potential attacker. He reads the logs showing the activities taken by the attacker over a three hour span. First of all, he notices that the attacker is logged in from Tymnet. This means the attacker could be coming from anywhere as Tymnet was a global network. Cliff digs into the meat of the log and is alarmed the find that Sventek is operating as a superuser. That shouldn’t be possible!

The Principle of Least Privilege

In security, we operate under the principle of least privilege. The means that users on a system should only be allowed to do the bare minimum required to complete their task and for only as long as they are required to complete it. This means users should not have administrative privileges to change the system, and applications should be installed with limited user accounts. This speaks to the concept of the attack surface. Any access an attacker has on a system provides points of interaction. Generally speaking, the more points of interaction the attacker has, the more opportunities they have to force applications or systems to respond in ways that might allow compromise. This characterizes the attack surface. The fewer interaction points we give users, the smaller the attack surface is when an attacker compromises a user’s account.

In class, we completed an exercise where we mapped the privileges of various roles in a bank setting and analyzed the attack surface of roles controlled by an attacker. I also discussed mechanisms meant to ease the burden of PLP, just as Windows User Account Control (UAC) and Linux sudo.  We are all sysadmins on our own mobile devices, and I discuss how these vendors have taken the approach of forcing us to consent applications into specific access based on their feature needs. Facebook was given as an example along with screenshots showing all the things it needs to access in order to provide its full array of features.

More Reading:

Dig Deeper Exercises:

  • Level 1:  Look at the permissions granted to a social media app on your phone. Try to map each permission to a specific function.
  • Level 2: On a Windows system, use a limited user account and attempt to perform an administrative action. Find an event log that indicates you took this action.
  • Level 3: On a Linux system, create a limited user account. Give it sudo privileges to perform administrative actions. Test this out, and find an event log indicating you took this action.


Cliff continues to dig around and discovers how the attacker became a superuser. It turns out that the attacker found a bug in the gnu-emacs application related to how it assigns ownership of files mailed between users on the system. The application simply changes the ownership of a file without respect to privilege assignments. Since the application was installed as an admin user, this allowed the attacker to trick it into copying a file such that it became owned by a privileged account. The attacker used this big to replace a systems ATRUN file, which executes every 5 minutes to conduct system administration tasks. When the attacker’s version of this file ran, it added the Sventek user to an administrative users group.

As a superuser, the attacker begins pillaging the network. They read sensitive files and e-mails, and look for passwords. The attacker also appears to be very paranoid and constantly looking over their shoulders. They enumerate who the system operators are and constantly look to see who is logged into the system and what processes are running.

Cliff presents these findings to his boss, who tells him to keep watching the attacker but not to take action yet. The monitoring system is refined to alert only when known compromised accounts login.

Process Monitoring

We use this opportunity to talk about process monitoring. The concept of a process is easy to understand, but we should give attention to the tools we can use to monitor running processes and their limitations. Active process monitoring is something done by defenders to look for suspicious or malicious processes. It is also something done by attackers to look for processes that might detect them or prevent them from accomplishing a goal.

In class, I demonstrated the PS command on Linux and discussed different ways to use it to look for running processes. I also demonstrated Process Explorer on a Windows system, as well as TASKLIST for command-line and remote process monitoring.

More Reading:

Dig Deeper Exercises:

  • Level 1: Choose three processes you use on a daily basis. Use the tools here to locate them and trace their parent processes as far as you can. Research what each parent process does.
  • Level 2: Compare your system to a clean system with no software installed (you may need to set up a virtual machine in a lab to do this). Identify what processes are unique to your system and those that are standard with the operating system.


In discussion with one of Cliff’s colleagues, the attacker’s use of the PS command is brought up. The attacker uses a flag (-g) that is supported on AT&T Unix, but not Berkeley Unix that is run at LBL. Someone wagers that the hacker is not from the west coast or he would be well versed in their flavor of Linux.

The attacker dials back in but doesn’t stay on LBL systems for long. Instead, they use LBL as a hop point to connect to a DoD server as the user Hunter. Cliff queries the NIC and finds that this IP belongs to Anniston Army Depot in Alabama. He calls the system operator and explains what he observed. The operator is aware of the attacker having been there, but thought he had been eradicated. It turns out that the attacker was using the same emacs bug but is coming in through LBL and not the front door anymore. Cliff ponders the thought that the attacker might be southern, as it would explain the familiarity with AT&T Unix which was run on the Anniston systems.


Next Session

November 30th 7:30PM ET

Read Chapters 9-14

Register/Attend Here:


Source Code S2: Episode 3 – Haroon Meer

Haroon Meer joins us this week to talk about his journey from running South African flea market booths to founding one of the most innovative companies in information security. We discuss the differences between South African and US education, common pitfalls made by security product vendors, and the use of honeypots for detection.

Harron chose to support the United for Puerto Rico with his appearance. These funds will go to support hurricane relief from the recent weather events that occurred there.

You can find Haroon on Twitter @haroonmeer.

Listen Now:

You can also subscribe to it using your favorite podcasting platform:


If you like what you hear, I’d sincerely appreciate you subscribing, “liking”, or giving a positive review of the podcast on whatever platform you use. If you like what you hear, make sure to let Haroon know by tweeting at him @haroonmeer. As always, I love hearing your feedback as well and you can reach me @chrissanders88.

Special thanks to our title sponsor, Ninja Jobs!



Cuckoo’s Egg – Week 1 Notes

Session Recording: (Available until 11/16)

Next Week’s Registration:

This week, we reviewed chapters 1-3.

We met Cliff Stoll, an astronomer turned computer wizard at Lawrence Berkeley Lab in California. Once of Cliff’s first tasks is to figure out an accounting error that amounted to $0.75 of CPU time. He investigates and finds the error is tied to a mysterious user account named Hunter. He can’t find the source of the account so he deletes it.

Locard’s Exchange Principle

We use this opportunity to discuss Locard’s Exchange Principle. Edmund Locard is considered by many to be the father of modern forensic science. His principle states, “The perpetrator of a crime will bring something into the crime scene and leave with something from it.” This is the basis for all forensic investigations. Locard has a particularly nice quote on the subject:

“Wherever he steps, whatever he touches, whatever he leaves, even unconsciously, will serve as a silent witness against him. Not only his fingerprints or his footprints, but his hair, the fibers from his clothes, the glass he breaks, the tool mark he leaves, the paint he scratches, the blood or semen he deposits or collects. All of these and more, bear mute witness against him. This is evidence that does not forget. It is not confused by the excitement of the moment. It is not absent because human witnesses are. It is factual evidence. Physical evidence cannot be wrong, it cannot perjure itself, it cannot be wholly absent. Only human failure to find it, study and understand it, can diminish its value.”

In class, we discussed the principle as the basis for computer forensic investigations as well. We did a couple activities to exercise our minds and think about things taken and left behind. One in relation to a physical theft, another in relation to the 2017 Equifax breach.

More Reading:

Dig Deeper Exercises:

  • Level 1: Pick a crime in your local newspaper and break down what could have been left behind.
  • Level 2: Pick an attack time from this list: Consider your network or make up a fictional network. Research the attack and determine what might be left behind and how you might gain visibility into it.


Cliff gets a weird e-mail from a system called DOCKMASTER. The system owner claims that someone from LBL tried to break into his computer. Eventually, Cliff figures out this system belongs to a Naval Shipyard. He correlates timestamps provided by DOCKMASTER and finds the user Sventek was active at this time. He also discovers two logging systems reporting different timestamps for the activity. While odd at first, this turns out to be related to time drift between two system clocks.



The investigation work Cliff is conducting is contingent on logs that contain timestamps, which he uses to perform time-based correlation. It’s easy to think of timestamps as a trivial thing, but they are far from it. Most investigations require examination of multiple data sources to build a clear picture of what events have transpired. To properly query data and sequence events, we need accurate timestamps.

There are multiple challenges between an investigator and reliable, consistent timestamps. We discussed syncing timestamps, time sources, network time protocol (NTP), W32Time, and how Windows domain members sync time. We also discussed the challenges associated with timezones and daylight savings time with plenty of confusing examples (Seriously, Samoa?)

I showed multiple examples of timestamps, and also showed a log collection pipeline and Logstash configuration files used to adjust timing and define timestamps. Finally, I listed a few best practices for dealing with timestamps that include: syncing all systems to the same source, utilizing UTC time in your investigation tools, and using ISO 8601 compliant timestamps.

More Reading:

Dig Deeper Exercises:

  • Level 1: Determine where your system is syncing time from and change it to another source.
  • Level 2: Setup your own NTP server and configure your system to sync from it.
  • Level 3: Capture network traffic while syncing with your own NTP server. Examine each field, and try to determine the function of each one.


Cliff eventually learns that the Sventek user is not on campus and is unlikely to be using his account. Considering the anomalies encountered with the Hunter and Sventek accounts and the report from DOCKMASTER, Cliff begins to suspect someone has broken into his network. He takes matters into his own hands and builds a monitoring system. He writes a program to log keystrokes on his systems and connects them in between the system and the external modems. He connects physical printers to these systems to print out commands as people are entering them while dialed in remotely. He sleeps in his office all weekend to monitoring these connections and awakens one night to find something very interesting…


Next Week

November 16th 7:30PM ET

Read Chapters 4-8

Register/Attend Here:


The AND Student Charitable Profit Sharing Program

When I decided to launch Applied Network Defense, I did so with the intention of using it as a platform for making positive change in the world. We do that through our primary business model of educating people so that they can further their careers and secure their works. We also do that by donating a portion of every course purchase to charity. Thus far, those donations have helped introduce tens of thousands of kids to computer science education and save lives by outfitting entire villages in Africa with mosquito nets.

It’s time for the next evolution of our mission, and that is a student charitable profit sharing program. Now, AND students will have a say in where a portion of their course proceeds go. Periodically, AND students will have the opportunity to submit a charity to receive a donation. After nominations have been received, the collective group will vote and we will select 2-5 winners to receive a donation.

If you are a current or former student of mine, I want you to know that my life is enriched by having been able to interact with you. Now, I’m thrilled to be able to help you contribute to causes that matter to you as well. It’s very important that people who purchases training from AND know that they aren’t just educating themselves by doing so, they are enriching the lives of others too. This is another way for us to do that, together.


Forcing Attacker Decisions

Today I want to talk to you about forcing decisions and how you can use the concept to gain a strategic advantage in your infosec work.

Over the past few years, the Golden State Warriors have revolutionized the game of basketball while winning two NBA championships and putting up record-setting numbers in a variety of statistical categories. They aren’t just winning, they’re dominating and changing how people approach the game at a fundamental level. There are a lot of reasons for this, but none more apparent than their fast-paced offense that is built around passing.

I recently read an article from ESPN describing how Warriors coach Steve Kerr formulated his offense. The article’s worth reading if you care about basketball, but even if you don’t I think there’s one quote in there that’s relevant beyond basketball. The Warriors star player, Steph Curry, had this to say:

“The main goal is to just make the defense make as many decisions as you can so that they’re going to mess up at some point with all that ball movement and body movement and whatnot.”

The concept is simple but powerful. When a player makes a pass to another player, it forces the five defenders to make a decision and react. There are a lot of variables that have to be considered very quickly.

Now, let’s say that as soon as the second player receives a pass, they make another pass. What happened?

It forces the defense to consider a new set of variables, probably before they’ve had a chance to fully react to the variables encountered from the first pass. This mental reset causes confusion and slows the ability to react with the correct adjustment. Every quick pass compounds the opportunity for confusion. The Warriors rely on this to succeed, and it’s one of the reasons they track their passes per game statistic aggressively.

Watch the guys in blue. Notice how lost they look after the first few passes? They’re lost! A couple of them have basically given up on the play by the time the shot goes up.

Of course, this concept goes well beyond basketball. It relates to all decision-making.


Forcing Attacker Decisions

Any time you make a decision you are processing all available information. Good decision making is based on understanding every variable and having time to thoughtfully process the data. I believe network defenders are in a unique position to force poor attackers into poor decisions.

Home court advantage matters.

The attacker doesn’t know your network. To learn it, they have to go through a period of iterative discovery. An attacker gains access to something, pokes around, gains access to something else, pokes around more, rinse and repeat. The attacker doesn’t know your network, but they will learn it as they move closer to their objective. Each step of discovery provides an opportunity to force decisions through the strategic introduction of information. When this happens, an attacker might do something aggressive enough that it trips a signature, pivot around rapidly and leave a few extra breadcrumbs in your logs, or withdraw completely. 

Let’s talk about a few ways you can accomplish this.

Honeypots. I’m not talking about traditional external malware-catching honeypots that we’ve all set up and forgotten about. Production honeypots sit inside the network and are designed to mimic systems, processes, and data. Nobody should ever access these things, so any access constitutes an alert worthy event. Beyond detection, internal honeypots can also serve to confuse attackers and waste their time. Security is an economic problem and when defenders can increase the cost of an attack, this can serve to ward off opportunistic or lesser resourced attackers.

Deception Traps. The use of deception tech (beyond honeypots) is on the rise, and I think we’re well behind on leveraging these concepts. I’m not talking hacking back or security through obscurity — I’m talking passive engagement of attackers on your home court through automated traps. These are the traps that, when interacted with, provide information to an attacker that can confuse their understanding of the network itself. For example, IP space that responds to scans, but houses no systems. Perhaps some of those systems respond differently to scans depending on the source or time of day. Another example might be web application directories that when accessed, redirect the user to random pages or create endless redirect loops. One last example might be running processes on a system that appear to be named after multiple antivirus binaries. That would certainly be confusing to see multiple AV tools on a single system. One more — what if an attacker discovered user accounts and logs that indicate they aren’t the only attacker on the system? That might cause them to make a hasty retreat or try an aggressive pivot. These ideas aren’t exclusively about detection (although they could be used in that way). They’re about providing confusing information at inopportune times.

Scheduled Shutdowns and Restricted Logon Hours. It’s insanely easy to configure systems to shut down during off-hours and to limit certain user accounts to specific login hours. Yet, I never see anyone doing it. Sure, you have to account for users who might work late and keep systems up so that they receive important updates. However, forcing these schedules will throw an attacker who is poking around on your network off. They will likely figure it out eventually, but that still gives them a time window wherein decisions could become hastened when they know the deadline is approaching. There’s no better way to force decisions than to put a time limit on them. As an added bonus, limiting login times can help workers maintain a healthier work/life balance, and shutting systems down lowers your electric bill and is good for the environment.



These strategies won’t completely stop the attacker, but they do have the potential to slow them down enough so that you may detect them before they reach their goal and you’re dealing with a larger breach. Furthermore, it increases the attacker’s cost and effort to reach their goal, and this might just be enough to ward off opportunistic attackers or attacks based on automated processes.

While these techniques aren’t appropriate for every security program maturity level, they provide an opportunity for innovation in the open source and commercial product space.

The Warriors succeed because they tried something different using the skillful talent they had. You can do the same, but like Steve Kerr and Steph Curry, you may need to think differently and apply a unique strategy. The fundamentals matter, but so does being different.

My challenge to you: Think of a way you can force an attacker into making a bad decision. Have some cool ideas? Post them in the comments below.