Sometimes you come across or are introduced to a tool that makes your life so much easier that you have to share it with anyone you come across. The tool in question for this article is Zackary Scholl’s “Croc”.
I wont discuss in too much detail about the tool of than briefly its use as I would just be referencing Scholl’s own writing on the topic. My only intention is to spread the word on it.
To quote Scholl’s in their own blog post….
Croc = fast + secure + easy
Install
Windows
choco install croc
^ Will need the Chocolatey package manager
To install Chocolatey run the following in an administrative Powershell terminal
I use this on a daily basis to transfer files from everywhere. It’s incredibly rare to come across a network that will have the required ports (TCP ports 9009-9013) blocked.
For more information about Croc, I recommend checking out the author’s blog post on this very topic.
A few days ago I was working on AWL (Application Whitelisting) bypassing techniques, looking through LOLBAS, and researching some that I had yet to use or learn- enter aspnet_compiler. This is a native Windows utility for compiling ASP.NET web application, naturally. The researcher who initially wrote about using this tool for AWL bypassing is cplsec on ijustwannared.team where you can find their write up on the subject. I will leave all references down below or in hyperlinks.
The purpose of this post is for people like myself who admittedly have zero knowledge of .NET and may struggle a bit in reading between the lines on cplsec’s post on the topic, and how you can play around with AWL bypassing (for fun and profit). I will also touch on setting up AppLocker, Windows native AWL tool, for proper testing of this technique.
First, I recommend reading through the original work by cplsec before reading on to this write up as all my work is based on theirs. With that said let’s go over how to prepare our attack. As a reminder, this will cover more of the how rather than the why on this attack. Additionally, I would recommend getting relevant files on the target machine before enabling security controls simply for the sake of your sanity. Obviously there are ways to bypass security controls to get these files on the target machine, but that is a write up for another day.
Building the Project
We’re are first going to pull down cpl3h’s “BringYourOwnBuilder” github repo and open the project in Visual Studio. This is as simple as opening Visual Studio -> File -> Open -> Project/Solution and selecting the BringYourOwnBuilder.csproj file.
The important file of note here is the Class1.cs file which will hold our payload. Here cplsec has simply used a MessageBox.Show() WinAPI method for proof of concept. We will keep with the MessageBox.Show() to keep things easy, but this is where you could place your malware (shellcode injection, DLL injection, etc.).
Once the project has been built the two files that will be of the most interest to us later will be the BringYourOwnbuilder.dll file, and the Class1.cs file.
Additionally, we need the web.config file which will look like this:
The important line to note here is the <add extension=".cs" line which we have changed from xml.
Project File Structure Setup
Next, we need to setup the appropriate file structure. For simplicity sake I will be nearly recreating the same file structure that cplsec uses.
I would also recommend using croc for file transfers. Probably the easiest way to install it would be via the Chocolatey package manager for Powershell.
Now that the project is ready for execution we need to setup our defenses for proper bypassing. Let’s get started with the AppLocker setup. This requires either an Enterprise, Education, or Professional version of Windows. For this test I will be using Windows 10 Education 21H2 (build 19044.2486).
First, start the Application Identity service which is required for AppLocker to enforce policies. In an elevated Powershell run the following to start the service:
sc.exe config appidsvc start= auto
Open the Group Policy Editor and locate AppLocker:
Computer Configuration -> Windows Settings -> Security Settings -> Application Control Policies
The only category of applications we need to set policies for is Executable Rules as that is what we are testing.
Right-click Executable Rules and Create New Rule…
For Permissions- Deny Everyone.
Select Path for Conditions, Browse Folders, and select the C: drive (%OSDRIVE%*).
For Exceptions we are going to go with any Microsoft signed executable. Otherwise this rule would make the workstation near unusable. Select Publisher, Add a Reference File, and I just selected ConfigSecurityPolicy within the Windows Defender Folder. Next, widen the rule scope to the Publisher (Microsoft), select Open, and Create the rule.
A warning box will pop up asking to create default rules. Select yes.
Your Executable Rules Policy should look like this:
Now, lets test our policy enforcement and attempt to execute an application. Here I have a simple C# application/executable called messageBox_test.exe that simply pops a message box. We can see when I attempt to execute it AppLocker blocks it from running. Perfect.
Execution
Finally, the fun part. We’ve set up the proper file structure, gotten the required files and payload on the machine, and setup our defenses. Now to execute the bypass, and pop our message box.
The aspnet_compiler can be found within the Windows .NET Framework directory located at:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\
Note: Your Framework version may differ slightly so best to go to the Framework64 directory and cd into the appropriate directory for your machine.
We’re going to pretty much lift the exact syntax used by cplsec and only changing the project/application name from none to NWG as well as the User directory from which the project code resides.
cd C:\Windows\Microsoft.NET\Framework64\v4.0.30319\
I hope this helped others like myself who read cplsec’s write up and struggled to understand the mechanism of the bypass. Please let me know if you believe I have made any sort of technical error in this write up, or have any further questions for me regarding this subject. This will be a companion post to one I will be submitting for NetWorksGroup in the coming days so stay tuned for that and I will add it to the below references when posted. Thanks again to cplsec for the work they did on this topic, and thanks to everyone else for checking mine out.
Your first IT job can be one of the most exciting and nerve racking experiences of your professional career, at least that is how it was for me- up to the day I was terminated nine months later. In this article I want to share some of my experiences, mistakes, and advice I would like to share with others starting their first job in this awesome field of work and how I hope yours will be much better than my own.
I’ll provide a key takeaways section near the bottom for those that want to save themselves from my internet ramblings.
The before time
First I’ll give a quick background of my knowledge and skill set entering my first position. I was never one of those people in this industry you hear so often who was fascinated with computers and had been tinkering with them from an early age. I always had a passing interest in them watching some of the things my older brother of nine years would do with them, but the passing part would come anytime I would pass by or think of the stacks of massive C++ or Windows administration books he would have scattered around his room and desk. My brother was a very intelligent person and I was had the mindset of, “Well I could never be smart enough to work with computers or understand those books of his.”. Obviously I know now how silly this thought was and still is when talking to other curious people like I was, but I digress. It wouldn’t be until around 2014/2015 when I would begin seriously considering IT as a career path.
This consideration began after a discussion one evening with a close friend of mine whom was approaching the completion of their associates degree in Networking Technology from our local community college. Hearing them talk about how much they enjoyed working in IT was very enlightening, especially in contrast to many people I would hear mention their job with dread and melancholy. This really piqued my interest since I currently had no long term career aspirations or plans at the time, and was still trying to determine what I wanted to do with my life. The following semester I enrolled in the same program my friend was just finishing. I performed quite well in the program despite having little to no in-depth understanding of computers or networks (I didn’t even know what a router was beyond-the box that gives you internet). I made up for this lack of knowledge with a very high commitment to understand these concepts, a trait that I feel describes my entire professional experience. In those earlier intro courses I would stay late very often to ask for further elaboration or clarification on the previously discussed topic (Shout out David Pope). This resulted in me completing my program with quite high grades overall, at least for me, in the fall of 2017 where my next challenge awaited me.
Foot in the door
Near the end of my last semester a different friend of mine whom at this point was well established and respected within the industry got me in connection with my first IT job.
Shortly after my friend putting me in connection with the IT manager and following a short phone call with him I was invited into their office for a formal interview. This interview was made up of the manager and both system admins. This has been about five years as of writing this so my memory may be a bit fuzzy on the details, but I will try and highlight a few aspects of the interview to help others in this position. I was asked about some of my college courses, which are my favorite, what challenges I faced, how I overcame said challenges, and if I had any personal technology related projects. After the interview I was given a short written exam to test my technical knowledge. I want to say there were about twenty questions almost all of which I felt confident in my answers. These were relatively simple questions one would learn in an introductory course such as- “What protocol would you expect to see running on TCP port 445?”, or “What is DNS short for?”.
This should go without saying, but do not lie or exaggerate your knowledge or experience, certainty not in an entry level position. They are aware you have no “real world” experience and are usually just looking to see that you are professional, have some basic knowledge, and an interest in the field.
Later that week I was extended an official offer from the company for the position. The salary for the position was around $28,000 and this was late 2017. I feel it’s important to share our salaries, at least past salaries to help others know what they should expect and what is fair. At the time, I believe this was very fair and although it was about what I was making bartending and serving I was still ecstatic to get my first salaried position.
Not a great start…. Not a great end
So my first week felt like I was drinking from a fire hose. This being my first experience seeing anything and learning about a network of this size was very daunting, but exciting. I felt like the sysadmin that was walking me through various things would think less of me or possibly even laugh if I asked what I perceived as dumb questions. This leads into two major mistakes I made going into this job of which I am sure you are already noticing. Failing to ask questions when appropriate, and not adequately taking note of the different concepts and techniques being taught to me. I’ll go a little bit more into detail on each of these and how I would recommend to my successors how to avoid these pitfalls in their first IT job.
When starting any new job, not just an entry level one, you should never worry about asking someone what you may consider dumb questions. It is always better to clarify and understand a topic rather than just pretending you know it because you feel you should. If your colleague or supervisor scoffs at these questions I would recommend immediately looking for a new position because it is not going to get any better for you, unfortunately.
This leads into the next issue I previously mentioned- not taking proper notes. When I started and one of my colleagues would demonstrate the process for a particular task and I would think to myself, “Okay, that wasn’t too much or too complex; I’m sure I’ll be able to remember that.”. The issue would arise though when I would be shown dozens of process or procedures throughout the work week. When I would need to execute one of these procedures that I had observed possibly weeks prior I would only have a slight idea of how to go through the process and need to ask someone for assistance. In this line of work, or any technical field this is just not a sustainable form of working and learning for the vast majority of the population. I have learned from my mistakes and now will write out detailed steps of the process if it has more than one or two steps in its entirety if there was not already documentation made by a coworker.
It’s at this point in this article I was debating on how far I should go into detail on the slow steady decline of my performance (or rather perceived performance) at this position that lead to my eventual termination. Although I have decided I will forgo this details for the sake of both brevity and professionalism.
Ultimately my short comings and issues were my responsibility. I made mistakes. Some I learned from immediately and made the appropriate corrections, while others may have taken quite a few mistakes before making those corrections. Though I would be remiss if I did not also bring up issues with the team/management. As mentioned previously, my intention is not to write up this entire autopsy and criticize those that helped start my career and taught my many foundational knowledge that I still carry into my job to this day. Although I do believe there was a disconnect in what was expected of me in terms of knowledge and skill and what I was able to bring to the team at that time.
I had this help desk position for about nine months before I was terminated. I was both incredibly upset as one could imagine, but also incredibly relieved as the stress and anxiety this position caused was becoming nearly unbearable near the end. Thankfully just a few months later I was able to land a great opportunity to work on my first blue team with an incredible team and management.
Looking back at this help desk position, at the end of the day it just wasn’t a good fit for either me nor the company. Sometimes that happens and that’s alright. You will find yourself in a position or company that isn’t going to make you or them totally satisfied. My only advice is to try to determine this early and not waste the time and effort for either party. With remote work in the field of IT and cyber security becoming more common there are hundreds of incredible teams and companies out there that will make a perfect professional relationship- don’t settle.
Key Takeaways & Suggestions
It’s okay to not know something or to have questions. Ask questions and clarify topics early and often. If senior admins or managers treat you poorly for this- immediately begin looking for a new position.
Take extensive notes. You won’t be able to remember everything you are taught in any technical job. Take good notes and document processes and procedures. Not only will it make your job much easier, but it will also instill confidence in your supervisors/coworkers that you are truly listening and understanding the topics they are demonstrating to you.
On note taking: I would highly suggest using an hierarchical note taking application such as Evernote, OneNote, Obsidian, or even CherryTree. I may also just have a note pulled up to use as a daily “scratch pad” for quick and simple notes on something I’m doing at that very moment.
Problem solving and escalation: I did not touch on this during the article but I feel it’s important to mention for anyone starting out in IT. Before trying to immediately escalating a ticket to a more senior person always check internal documentation, Google (an invaluable tool), and vendor documentation. This will all depend on both the structure of your organization and when you are to escalate tickets and the severity of the issue.
