Ogenstad.net

Security Stories and Help with Network Documentation

Once upon a time this used to be my blog. For current updates head over to Networklore.

About / Stories / Contact

How to Document Servers with SYDI – Part 3 of 3

by

Wasn’t There an Option for Html?

I might have said there was at some time, but it was a white lie. What you can do is to convert the XML file into a Html document. It’s quite easy and it’s used in this way:

cscript.exe sydi-transform.vbs -xServer.xml -sServerhtml.xsl -oServer.html

Running this script will require that Server.xml and Serverhtml.xsl and sydi-html-stylex.xsl are located in the same directory. If you have created private xsl files you can use the sydi-transform to convert it.

Hey, Wasn’t This about Documentation?

It sure was, most of what we’ve looked at up until now has been more geared against Inventory instead of Network Documentation. I saved the best for last, a new tool in sydi-server 2.0 is the ss-xml2word.vbs script (or SYDI-Server XML to Word).

What the script does is that it takes an XML file and converts it to a Word document. You might be thinking that SYDI already wrote to Word, which is true, however there are situations where that isn’t possible. For example in environments where you don’t have Word installed, may it be in a DMZ or as a scheduled task on a server.

The good part though is the options you specify when creating the Word document. To view these options run:

cscript.exe ss-xml2word.vbs -h

Here you can see that there are two arguments that are required -x and -l.

cscript.exe ss-xml2word.vbs -xServer1.xml -llang_english.xml

This line will create a Word document based on the information in the Server1.xml file, it will then use the English language file which describes what it writes to the Word document. This means that you can have the documentation in your native language. When I released SYDI-Server 2.0 there was support for English and Swedish. Later people have contributed with there own language files which you can download; Italian, Norwegian, Portuguese and Dutch.

One issue that causes the ss-xml2word.vbs script to fail for many people is a path problem. If you run the script and it just writes out a few pages without any information from the xml file and the script crashes, this is happening to you. Either put all the files in the same directory or specify the path after -x -l or -s. I will fix this in future versions so the error message is a bit more user-friendly.

The most exciting feature as I see it is the optional -s argument. This is the reason I created SYDI in the first place. The -s option specifies an XML file which contains the written documentation about the server. That is the documentation you have created, this differs from the data that SYDI-Server has gathered from the machine.

Let’s take it for a spin.

Writing Your Documentation

To get you started I’ve included three files in the Examples directory (of sydi-server), copy the howto.xml and rename it to Server1_docs.xml. This will be where you will write the documentation. Open the Server1_docs.xml file in Notepad. Scrolling up and down you will see different XML tags. You’ll recognize the sections and subsections from the Word documents previously created.

Inside the sections and subsections you will se prenotes and postnotes, inside these there are a few tags. The only thing you have to do in this file is to create and edit tags. Scroll down to the section called toc (Tables of Contents), here you will se the difference between prenotes and postnotes. It has to do where they appear in the final document. Just run a few tests and you’ll se what I mean. So let’s start to document.

In the system info section change this:
In this version you are only able to use text tags, more could be availible in later versions of SYDI.To:

Physical Location: Server Room in Stockholm
System Owner: BOFH
Support Agreement: 3Y Next Business Day (Expires 2007-10-16)
Save the file and create the final document.

cscript.exe ss-xml2word.vbs -xServer1.xml -llang_english.xml -sServer1_docs.xml

The above was just an example, you are of course free to write and include whatever you want in the documentation. If you fail to create the documents it’s good to know that XML parsers are very unforgiving if there’s an error in any of the files. Make sure all tags are closed correctly by opening them in a browser. If you fail to open Server1_docs.xml in a browser the problem is there. Fix it and try again.

I’ve also created a batch file, writedoc.cmd which looks like this:
cscript tools\ss-xml2word.vbs -x\\serverr\net$\sydi\output\%1.xml -llanguage\lang_english.xml -s\\server\itsupport$\documentation-source\%1-written.xml -o\\server\itsupport$\documentation-binder\Server-%1.doc -d -b”Table Contemporary”

I use it by running
Writedoc.cmd Servername

So there you have it, that’s how I use SYDI-Server. If you have any questions just post a comment or contact me.

Read Part 1
Read Part 2

[tags]network documentation, server documentation, sydi, how to, tutorial[/tags]

How to Document Servers with SYDI – Part 2 of 3

by

The Output Options

SYDI has two output options; one for saving the report and another to choose which format to use.

-o Output to file, specify a path and filename and use quotation marks if there’s a space in the path. Remember to give your file an .xml extension if you’re using the XML format and a .doc extension for the Word format.

-e This is to choose the export format, the default is -ew (Word), to change to XML use -ex.

To create an XML report you would use:

cscript.exe sydi-server.vbs -oServer1.xml -ex [enter]

This will create an XML file that you can open in a browser.

XML Options

You might have noticed that the XML file you created didn’t look that great when viewed in your favorite browser. The reason is that you’re just looking at the raw XML file.

To view a style sheet, use the -s option. I generally use the -sh option which uses the html style sheet included in SYDI. For advanced users there is a -st option where you can specify a style sheet you have created on your own.

Lets test it again:

cscript.exe sydi-server.vbs -oServer1.xml -ex -sh [enter]

In order to view this file with a browser you will need the serverhtml.xsl and sydi-html-styles.xsl to be located in the same directory. These files are in the XML subdirectory of SYDI-Server. Copy the Server1.xml file you just created to that directory and open the file in a browser. Alternatively you can copy all of these files to another directory.

What Other Options do you have?

To be honest, you don’t have that many. The options that are left are -v to check the version of your script; this will check the SYDI website and see if a later version is available (I might remove this option).

The last option is -d for debug, if something fails to run as you expect it might be because of a bug in SYDI. The -d option is useful to troubleshoot these scenarios.

What if You Have More Than One computer?

So you want to run SYDI against multiple computers, it’s easy enough to write a batch file that does it for you. However, in the Tools directory there is a script called sydi-wrapper.vbs. A little “gotcha” is that you have to edit the script for it to work, but don’t panic; there isn’t any voodoo involved. Just open the script in notepad and scroll down to this section:

‘ Gathering Options
‘ WMI – Everything enabled by default
WMIOPTIONS=”-wabefghipPqrsSu”
‘ Registry – Everything enabled by default
REGISTRYOPTIONS=”-racdlp”

‘ Export Options
‘EXPORTFORMAT=”word” ‘ For Microsoft Word
EXPORTFORMAT=”xml” ‘ For XML

‘ Location Options
‘ Location of SYDI-Server.vbs
SYDISERVER=”C:\scripts\sydi-server.vbs”
OUTPUTDIRECTORY=”C:\scripts\Output files\”
LOGDIRECTORY=”C:\Scripts\Log Files\”
TIMEOUT=”600″ ‘ How many seconds you have to wait until a computer-scan is aborted hasn’t been tested.

‘ Other options, check sydi-server.vbs -h for help
‘ Uncoment/Change One of the below
OTHEROPTIONS=”-sh” ‘ For HTML Stylesheet on XML output
‘OTHEROPTIONS=”-b10″ ‘ Base Font size of 12
‘ End Of Settings

You will recognize the -w and -r options, unlike SYDI-Server this script defaults to XML (as it should). What you must change in order to get this to work are the values for SYDISERVER, OUTPUTDIRECTORY and LOGDIRECTORY. If you want to you can change the TIMEOUT value too, however it might not do you any good. That feature seems to have taken time out.

I wasn’t sure this was a good way to implement the script. The reason you have to edit the script is so that you won’t have to write such long commands later on in order to get it working.

Anyway, the remaining options are -u and -p for username and password when you connect to the machines. Then there are the gathering options or source options.

-t Reads from a text file, the computers listed in the text file should be separated by line or comma. To use this option:

cscript.exe sydi-wrapper.vbs -tAllMyComputers.txt

-d This is to get computers from a flat domain (NT4 style) to connect to all the computers in the domain you specify. A word of warning though, I’m told Heaven will be closing the gates for people who use NT4 much longer (you might have to break in as it is).

-a Active Directory, if you just run the script with -a it will connect to the active directory domain where you’re machine is located. Your other option is to specify an LDAP container. SYDI-Server will then scan all computers under this container (except for the ones with disabled computer accounts).

A few examples:

cscript sydi-wrapper.vbs -aDC=exibice,DC=com
cscript sydi-wrapper.vbs -a”OU=Member Servers,DC=exibice,DC=com”

[Self Promotion Mode]
If you haven’t heard of Exibice there’s a whole story about the company, read the first part here and you’ll find the other parts here.
[/Self Promotion Mode]

An Eagles View

After running sydi-wrapper you might have ended up with a whole lot of XML files. To give you a quick overview I’ve included a script for just this purpose. Also in the Tools directory is the sydi-overview.vbs script. It accepts one argument, -x, you will want to point this to the output directory you specified in sydi-wrapper. I have created a batch file which reads:

cscript.exe sydi-overview.vbs -x\\fileserver\net$\sydi\output

Running the script requires that you have Microsoft Excel installed on your machine. The script will parse all the XML files and start to populate the cells in Excel. The script will create six sheets. Computers with basic information about all your computers, WMI Programs is a list of all software installed by Windows Installer, Reg Programs are the ones found in the Uninstall registry key, Processes tells you what every computer is running. All these can be good to detect rouge programs or processes.

Finally there is the OS distribution pie chart and data source.

Read Part 1
Read Part 3

[tags]network documentation, server documentation, sydi, how to, tutorial[/tags]

How to Document Servers with SYDI – Part 1 of 3

by

Having written SYDI from scratch, I know it inside and out. Unfortunately I don’t think I’ve managed to communicate how SYDI works in an efficient way. The readme file included in SYDI is far from perfect. While people in this line of business can usually figure out how it works, others will just ignore reading the manual anyway. In this how-to I will go through the basics of how SYDI-Server works and then describe how I use SYDI-Server.

Getting the Software

You probably have the software already, but just in case. Download it from the SYDI website, or if you love this site and don’t want to leave it no matter what: you can download it from here. This guide is written for SYDI-Server 2.0, if there is a newer version when you read this, don’t worry; it should be useful anyway. Just be sure to check the changelog.txt file for new features.

Unzip the file to your target directory.

Running SYDI in default mode

To see what the software does, open a command prompt and navigate to your sydi directory. This step requires you to have Microsoft Word installed on your computer. Type the command:

cscript.exe sydi-server.vbs [enter]

A message box appears and asks you which host you want to target, the default is localhost. You can select another host if you have administrative access on that machine. Though for now, just press enter.

In the command prompt window you will now see that SYDI starts to gather information about your machine. Soon a Word document is created and SYDI writes the information gathered into the document.

Take a look at the document. Not all this information will be relevant to you and you can remove the parts you don’t want by reading further. Close Word, or save the file it if you want to.

The Options

To view the available options use the help command (-h):

cscript.exe sydi-server.vbs -h [enter]

Options in five categories will be listed; Gathering, Output, Word, XML and Other. In reality there are only two, Gathering and Output.

Gathering the Information

Breaking down the gathering option we have five different arguments -w for WMI options, -r for Registry options and -u and -p for username and password if you want to connect to a different user. Finally we have the -t option where you specify which host you want to target against.

Looking closer at the -w argument from the help menu (-h) you could see that SYDI defaults to using -wabefghipPqrsSu, meaning everything gathered from the WMI providers will be included.

You cannot remove everything from the report, but let’s create a document without all the extra information. Run:

cscript.exe sydi-server.vbs -w [enter]

As you can see the report created is much shorter than the previous one. We have removed the optional WMI providers, but we still have the basic ones and the information coming from the Registry.

To choose which options you want, just check the help menu and see what they mean. If we want to add Bios Information, Printers and Services we would run:

cscript.exe sydi-server.vbs -wbps [enter]

This way you can pick and choose the options you want. The Registry switch works the same way. For an even smaller report you can run:

cscript.exe sydi-server.vbs -w -r [enter]

Now you can add the registry options that you want. Please note though that a lot of the “Computer Roles” are gathered from the Windows Components, so if you want these roles you must have the Windows Components in your report (-rc).

Using the -t option removes the message box asking you which host you want to target. A few examples of using the -t switch:

cscript.exe sydi-server.vbs -tServer1
cscript.exe sydi-server.vbs -tDC1
cscript.exe sydi-server.vbs -tWebServer
cscript.exe sydi-server.vbs -t192.168.0.10

The user and password options should work as you would expect them to, if they don’t: report the bug to me 🙂

Word Options

As you’ve seen, sydi-server defaults to writing output to Word. The reason for this is so that you can get a quick overview of what the script can collect without having to do any tricks. Having said that, I only use the Word option to get a quick view of a machine, later I throw away the document. I always use the XML format which I later convert to a Word document, more on that later. Even though you won’t use the Word options much we’ll just take a quick look at them to see what you can do, it won’t be a total waste as a few of the options are used by another script called ss-xml2word.vbs.

-b is for the border of the tables created in the document. As you might have noticed there isn’t any borders by default (when you print the document). You can use all borders you have installed in Word. To test it, type:

cscript.exe sydi-server.vbs -b”Table Contemporary” [enter]

-f is if you want different font sizes, the default font size for the text is 12. To change it, use:

cscript.exe sydi-server.vbs -f8

-d tells SYDI not to display Word until the entire report is written. Using the -d option makes the process go faster. Also if you want to save the file (-o option, more on that later), you might not want to see Word at all. For example if you are running a scheduled task you don’t want a GUI to be loaded.

-n will remove all the text inside the brackets, such as “Logical location: [provide info: Server VLAN 2]”. This way you won’t have a bad conscience about not completing the documentation. 🙂 But as I have already stated, the whole idea of sydi-server writing directly to word is obsolete. If you start changing the document after it is created and want to run SYDI again your changes will be lost, or you will have to cut and paste them to the new document. There is a way around this though (hint: continue reading!).

-T This is if you want to specify a corporate Word Template file (.dot), which enables you to choose which fonts you want to have as well as their size. This way you can get your “look and feel” in the document.

Read Part 2
Read Part 3

[tags]network documentation, server documentation, sydi, how to, tutorial[/tags]

Breaking out of Jail with Microsoft Word

by

“Can you really break out of jail with just Microsoft Word, or are you just pulling my leg?”

No I would never do that, Word is really powerful, it can take you places!

Intended audience

If you are a convicted felon and reading this from prison; sorry but you are not the target audience. However, don’t despair: there’s something in here for you too!

This article is for people who care about security. If you don’t fall into this second category you really are in the first group, i.e. not the intended audience. When I’m talking about “jail”, I’m referring to a restricted Windows environment. What I mean with this is a locked down Terminal Services session, or a public Windows XP box in “kiosk” mode.

Administrators who have locked down their terminal services sessions care about what the users can do on the machine. They only want users to run the programs that are approved by the security policy. This means no cmd.exe, no freecell and no poking around in the system.

So why isn’t this article for people who haven’t locked down their environments? Because of the good ol’ “Security is a Weakest Link Problem”, meaning if you haven’t even tried to lock down your environment, you have other issues to take care of before you read this article.

Operation Lockdown

For the environment that I have set up to test this, I’ve installed a Windows Server 2003 machine and set it up to run Terminal Services. I’ve also installed Office, the goal here is to only allow a user to run Microsoft Word and nothing else.
The user’s desktop is then redirected to a share where the user doesn’t have write access. The desktop contains one item; a link to Word. Logging in to the terminal server, everything looks good; the user can basically run Word and change his password.

Apart from the above setting the rest of the GPO settings are located at the end of this article. It’s basically a few lockdown settings and a software restriction policy defaulting to “disallowed”, with an additional path rule allowing Microsoft Word.

Given this configuration let’s see what we can do.

Where does Word enter into it?

I guess the title says it all; Yes, Word is the application we are going to use to break out of the locked down jail. If you’ve tried my SYDI project, you’ve probably realized that I like Office automation. This concept would work in any Office application but I have chosen Word. If you don’t have Office installed in your locked down environment, I still think you should continue reading. Hopefully you’ll enjoy the article anyway.

What I’ve done is to write a Word macro which allows me to run shell commands or code of my choice.

You might object and say, “So? I have Macro Security set to Very High. You’d have to digitally sign the macro first.”

I most certainly would not! The Macro setting in the Office suite is to protect you against an entirely different threat. In that scenario the threat is that an attacker can send us (or our users) a Word document with an evil macro inside which is run when we open the document.

This setting does not disallow developers to create macros, run them while developing and then sign them when they are in a state where they can be shared with others.

What does this mean for us? It means that we cannot use a pre-created Word document which contains the macro. We have to create the macro ourselves on the fly each time we want to run macros. See the difference? The security setting in Word doesn’t disallow you to create and run your own macros. If we would save the document and open it again, then the security setting would kick in and disallow the macro. If we had signed it before saving then we would be allowed to run it.

In order to prevent this we would have to have a setting in office called “Don’t Allow Users to Develop Macros”.

VBA-PrisonBreak

I named the macro I created VBA-PrisonBreak (I must have been watching too much TV). You can download the VBA-PrisonBreak from here. To test it in your environment open up Microsoft Word and press [Alt]+[F11] to enter the VBA editor. Double click on “This Document”. This will give you a code Window on the right side. Copy the contents from the VBA-PrisonBreak.txt file and paste it in the Window. The file contains different subroutines, or programs if you will.

To run one of these programs you set the cursor somewhere after the Sub [Program] and before the End statement. To execute the program you press Play or [F5].

To give it a try and test something harmless, start the routine called RunCommand() and enter.

ping 127.0.0.1

When the command is completed, go back to the Word document. If everything worked out as it should you will see which command you tried to run and the results.

Let’s see if we can poke around a bit:

cmd /c dir

Hm, this won’t work unless we have command prompt scripting allowed. Then again we can create scripts of our own and run them instead. Another sub routine of VBA-PrisonBreak is called ListFilesinFolder() and takes a directory as an argument. This is just a simple example but a lot can be accomplished by scripting.

So we haven’t done anything terribly exiting. The commands we can run by using the RunCommand() routine depend on a few factors, we will look at the Software Restriction Policies. We know we can run Word, but what about the default additional ones? Among others this includes commands under c:\windows and c:\windows\system32.

“net view” and “net user /domain” might be interesting and could give us some information. After looking around we might come to the conclusion that we want to run a command which isn’t allowed by the software restriction policy.

As a normal unprivileged user we will not have write access to c:\windows or c:\windows\system32, so we can’t place any files in those directories. But in our configuration we have write access to c:\windows\temp, and even better CREATOR_OWNER has Full Control. If we can place a file in this directory we will be able to run it with RunCommand() by entering:

C:\windows\temp\mycommand.exe

Now how would we place a file there? We can’t just use copy since cmd.exe is blocked. We might be able to use xcopy or tftp. If tftp isn’t available we might still be able to expand (.exe) it from c:\windows\i386\tftp.ex_. There is also a function in VBA-PrisonBreak which lets you download files through http (HTTPDownload()). It takes source url and target file as arguments.

From here we can download netcat and gain shell access to the server. Note that cmd.exe is still restricted; unfortunately an attacker can use another file or edit a version of cmd.exe. This edited shell file can then be placed under c:\windows\temp.

It is important to realize that the credentials used in this shell will be that of the unprivileged user account.

How to Protect Yourself

It’s really easy to protect yourself against this feature, remember this is not a vulnerability or an exploit in Windows or Word. We are trying to remove features from Windows (such as disabling cmd.exe), since the features we want to remove can be used in harmful ways.

When you install Office you don’t have to install all the features, one of these features is vba (Visual Basic for Applications). Without vba this prison break wouldn’t be possible (in the way I’ve described). You can find information about this in the Office Security pages. However as you can see on the page, Microsoft recommends that you don’t disable vba and also lists the reasons why, so you have to decide for yourself. This page also mentions the “very high” macro setting, but remember what I said before: this setting doesn’t apply in this context.

Another option is to disable vba through group policies. You can do this by using the .ADM files for Microsoft Office. This is only an option if you won’t be using any macros.

Even if your business requires you to be able to run vba, I have three words for you; Defense in Depth. If one part of the system fails, this shouldn’t mean that the defense has been breached.

The default Software Restriction Policies obviously didn’t restrict as much as we would have hoped. We will definitely want to explore these settings. If a user has write (and execute) permissions to any location within a SRP Path rule that user can run whatever he wants. You could set up deny rules for these directories or you could tighten the NTFS permissions and remove execute permissions.

It would be nice if the default policies provided some sort of protection, at least since Microsoft has written in several places that they shouldn’t be changed unless you are an “advanced user”. But the Software Restriction Policies can be fixed and in this case that’s not really the problem. Since we can write VBA code we have a lot of options. VBA-PrisonBreak is mostly a proof of concept; it doesn’t really do much.

On a network level if we take the example with tftp, there’s no reason why this should be allowed to or from your machine. If we were only supposed to run Word, allowing http doesn’t make much sense either.

Earlier on I said it would be good if there was a setting in Office called “Don’t Allow Users to Develop Macros”. Unfortunately, as far as I know this kind of setting doesn’t exist. However we can create one of our own. The VBA editor is using vbe6ext.olb which by default is located in this location:

C:\Program Files\Common Files\Microsoft Shared\VBA\VBA6\VBE6EXT.OLB

If we deny the execute permission (NTFS) to this file for the users we want to lock down they won’t be able to launch the vba editor, but will be able to run signed macros. A little word of caution; I don’t know if there are any other issues you should be aware removing execute permissions to this file, but I don’t think there is.

The problem with scripting

The macro RunCommand() creates an object called Wscript.Shell. Is this required by your business? If you remove the NTFS execute permission (for the terminal services users) to the file c:\windows\system32\scrrun.dll, they won’t be able to use the RunCommand().

Is there another library an attacker can use if you deny the features from Wscript.Shell? Disabling scrrun.dll would still allow a malicious user to download files with HTTPDownload() it uses an object called Microsoft.XMLHTTP. There are a lot of scriptable libraries in Windows. Chasing them all down is hard, and it wouldn’t solve the whole problem.

As I said above the problem isn’t related to Software Restriction Policies. Even if the SRPs are set up in a way that would prohibit the user to run a non approved executable, that user would still be able to write vba code. If vba code isn’t scary enough, an attacker could pre compile a dll with a com interface and load the functions from that dll from vba.

The Weakest Link

To find the weakest link you might have to think outside the box. But that is the fun part of security. 🙂

Ask Jesper what he thinks of Security Guides and he will tell you that they won’t make you secure (or in Jesper-/Stevespeak you won’t be Protected).

I think security guides are great but still they are just guides, not a blue print for a secure network. Most guides are fairly generic and you have to decide what parts of it to use in your environment. The security of a network isn’t as strong as the sum of all security settings; it’s as strong as the weakest link. When it comes to SRPs, a guide can’t tell you which applications makes sense in you environment.

Summary

VBA-PrisonBreak in itself won’t allow a malicious user to take control of your server. That user would have to escalate his privileges first, unless the attacker was a “power user” or an administrator to start with.

VBA-PrisonBreak is just a way to gain another foot-hold in your environment. When trying to protect our networks we don’t want to give any more ground than we have to.

If you are a criminal and have been wondering through this article how Word can help you to get out of a real prison: It’s quite easy really; just open up Word and start writing “Dear Congressman”, press [enter] twice and write your plea for pardon. If you’re really lucky a magical paper clip will come to your aid!

Note: We did not lock down the Help Menu in Word, but since we didn’t use it to gain access that way I chose to ignore that and a few other threats in this article.

Credits

I, Patrick Ogenstad, work at Netsafe. I would like to thank John Laerum from Cornerstone for providing feedback on this article.

If you liked this article, please stick around! You can subscribe to the “feed”, or get updates by email. Also be sure to check out my security fiction stories.

If you have any feedback concerning this, please post a comment or contact me.

Appendix

The group policy settings used in the test environment:

  • Hide these specified drives on My Computer – All Drives
  • Prevent Access to Drives on My Computer – All Drives
  • Remove My Computer Icon on the Desktop
  • Remove My Documents icon from Start Menu
  • Remove Help Menu from Start Menu
  • Remove and prevent access to the shutdown command
  • Remove All Programs list from the Start Menu
  • Prohibit Access to Control Panel
  • Removed pinned Program list from Start Menu
  • Remove frequent program list from Start Menu
  • Remove Search Menu from Start Menu
  • Remove Run Menu from Start Menu
  • Remove Recycle Bin icon from Desktop
  • Prevent Access to the Command Prompt – Disable Command prompt scripting also
  • Prevent Access to registry editing tools
  • Run Only Allowed Windows Applications – winword.exe
  • Software Restriction Policies – Default Security Level – Disallowed

I have left the default additional path rules as unrestricted:

  • %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%
  • %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%*.exe
  • %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%System32\*.exe
  • %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir%

Office in installed on D:\ so I added one path rule:

  • D:\Program Files\Microsoft Office\OFFICE11\winword.exe

[tags]Security, Locked Down, Software Restriction Policies, Terminal Services, VBA[/tags]

The Tale of the Disgruntled Employee – Part 13 – Conclusion

by

Two weeks later a server from Exibice connected to a box under n3m0’s control. Show time, I wonder if Mark can say ‘Schema Admin’.

At Beateval

“Hello, this is Thomas how may I help you?”
“Hi, my computer just went all blue. I tried turning off the power but now it doesn’t start.”
“Did you change anything on your computer?”
“No, and my colleagues have the same problem.”
“Huh,” suddenly Thomas saw the counter for incoming calls rising drastically.

Someone shouted behind him when he looked back on his computer screen he saw that the virtual machine he had connected to the Exibice network had crashed. The host machine on the Beateval network was running fine.

At Exibice

“What is happening?” Mark roared.
“We don’t know,” Keith whispered.
“What do you mean don’t know, what have you done?”
“It was just patch Tuesday, one of the updates might have been flawed.” Ben said, his voice not much louder than Keith’s.
“Then remove the damn flaw!”
After a moments silence Keith worked up the courage to answer, “We can’t.”
Mark just stared at him, Ben jumped in.
“We can’t get into the servers, our passwords doesn’t work. Something must be wrong with the AD.”
“The local server passwords don’t work either.”
“Oh, how delightful,” Mark said sarcastically. At least I won’t have to spend a fortune on Christmas bonuses. “Didn’t you write the passwords down somewhere?”
“Yes, but we think someone might have… changed them.” Keith said nervously.
“Thank god it’s Friday then, now you know what to do during the weekend. Let me know when this is fixed, I don’t care what time you call.” Mark walked away.

Ben and Keith exchanged a glance, neither of them looked confident.

Mark called them both several times during the weekend, not once did they have any good news to share with him. When Monday came the network was still a mess, and nobody could work.

Two weeks later the network had been redesigned from scratch. The board of directors wasn’t impressed. Shortly thereafter Mark was sacked and a new CTO was hired along with a separate CIO.

Please note this is a purely fictional story, any names found here are made up. I’ve written this because I like writing, if someone reads it and enjoy it: great. If they get more conscious about security, that’s a bonus. If you have feedback or comments on the story please share them.

Further Reading:

[tags]security, security fiction, fiction, insider threat, disgruntled employee, physical security[/tags]