Minutes later, one of the security techs met me at Lynn’s cube with a box that we quickly filled with the contents of her desk: files, CDs, DVDs, notedpads, books, etc. The other help desk analysts in adjacent cubes looked at us with silent questions on their faces.
I noticed that one of them was a new employee that had attended my security presentation in employee orientation last week, so he knew who I was. That meant rumors would spread quickly. While I never enjoyed walkouts, they reminded the staff that security incidents have consequences.
This is a multi-part series. See Internal Attacker Detected: Part 1, Internal Attacker Detected: Part 2, and Internal Attacker Detected: Part 3.
Others on my team had already imaged the old computer and had started imaging the new one across the network as soon as my meeting with Lynn began (by design, she was not told of the meeting beforehand). Both images would be sent off to the Forensics team.
Reviewing the Evidence
After everything in the box from Lynn’s desk was cataloged, the security tech and I started reviewing it. The most interesting thing I noticed was the number of Linux distribution CDs she had, including Backtrack and Auditor (a older version that predated Backtrack). Those definitely weren’t required for her job, and as an contractor, when would she have time to play with them at work? And what targets would she use?
I checked the badge logs has shown that Lynn had only entered and left the building at expected times. She’d never attempted to come in on a weekend or holiday. And she had never logged in remotely even though she had the capability.
Nothing suspicious turned up in her files or other belongings, other than a number of UNIX books that she’d brought to work– even though she’d never touch any UNIX boxes in her position.
A day later, I was granted access to a copy of her email. Not much there–regular business items, and way too much personal stuff, which is usually the case. I frowned and thought that no matter how much you mention this in training and at other times throughout the year, people continue to trust their most intimate details to their hard disk, emails, internal chats, web site comments, all of which either are considered company property or pass through the company network.
In the end, no evidence that Lynn did anything malicious was discovered, which was a relief. We probably caught her in time, but only by a fluke. What if we hadn’t refreshed her computer when we did?
I had already asked the malware team to file a report as to why they weren’t alerted that her antivirus service was disabled, and to determine how many other computers attached to the network had the same issue. Other types of alerts probably weren’t configured either, but I’ll have to tackle that later.
Lynn’s email box did contain one interesting item, an email containing a URL that granted administrative access to an internal system without any authentication, which also meant that you couldn’t trace the access back to an account or any individual. A dangerous situation and a critical internal control problem.
The email had been sent by another help desk tech to all the techs, and Sue, the help desk manager, had been CC’d on it. She later told me that the URL had existed since the application was created (internally) and that’s how ALL administrative work was performed on that application.
I shook my head, trying to understand how a system that impacted the company’s financials remained under the covers this long, and no one had called it out, including the manager.
“It just never occurred to me,” Sue told me. “But now that you brought it to my attention, I’ll put in a request to have it changed.”
“Please make that a priority request, and I’ll talk to a couple people to ensure it gets the attention it needs,” I said. “Especially since the URL works from the Internet, right through the firewall.”
Please leave a Comment regarding what you liked/disliked about the series…
9 responses to “Internal Attacker Detected: Conclusion”
I was expecting a climax but the it died. Good for the company though that they didn’t have to go through a catastrophic event. But, it goes to show that regardless of how many controls you put in place, a common human action can lead to bypass all these controls; this is regarding the unprotected application link. It makes me wonder how internal audit missed on this?
You are correct. Humans are always the weakest link. Not sure how audit missed this, as I wasn’t in audit at that time.
I think this story emphasizes that having a good response strategy is so key, as not matter what you do, you won’t be able to plug all the holes.
We got lucky on 2 counts (as far as we could tell):
1) Lynn hadn’t done any damage.
2) No one had found the URL.
Agreed on both, you can never cover all the holes and it definitely helps to have an effective response strategy in place. I was thinking of another approach you may have taken, after getting alarmed on policy violations by Lynn, to sort of contain behaviour and watch for any malicious activities she may have carried out. This could have become a good learner of user behaviour. Not sure to level you could afford this risk.
That definitely would have been interesting, but too risky. She was a scripter who knew her way around, and she was studying to get better. I wouldn’t want to take the responsibility if she did something, but we didn’t prevent it even though we were watching. Then I’d have to explain why I didn’t follow policy by walking her out.
And as I said, the word spreads when people are walked out, and it serves as a reminder that we take security matters seriously. Again, this time we were lucky. A couple other times, we weren’t.
Agree, it could have been good to contain the ongoing activities of the user if you had very strong technical expertise in house, who could fight the risk, and yes, it would only be possible if you had the buy from management. Either way, it appears that you guys took the right approach and not violate, probably your own developed, policy.
Nice series about an internal attacker. One thing I liked was how you kept stressing throughout the posts that the tools she had wasn’t required for her job. For some those tools may be the nature of their work but for others there should be no reason to have them. Context is so important for investigations and thanks for providing it.
Thanks for your input. Yes, if you use these tools in your work, you should have a GOOJ card. Don’t hack your workplace without it.
Excellent! This post can be a good case study for incident management.
I want more!
Glad you liked it. As the old Dragnet series said, “The story you have seen is true. The names were changed to protect the innocent.”
Someday I’ll try to remember to write up some of the other incidents. The rouge server, and the cash register system that always had an open drawer….