I’m Matt Mathur, lead penetration tester here at Raxis. I recently discovered a cascading style sheet (CSS) injection vulnerability in PRTG Network Monitor.
Summary
PRTG Network Monitor does not prevent custom input for a device’s icon, which can be modified to insert arbitrary content into the style tag for that device. When the device page loads, the arbitrary CSS is inserted into the style tag, loading malicious content. Due to PRTG Network Monitor preventing “ characters, and from modern browsers disabling JavaScript support in style tags, this vulnerability could not be escalated into a Cross-Site Scripting vulnerability.
Proof of Concept
The vulnerability lies in a device’s properties and how they are verified and displayed within PRTG Network Monitor. When editing or creating a device, the device’s icon value is not verified to be one of the icon selections, and any text can be inserted in its place, as shown here:
When the device’s icon is then loaded in any subsequent pages (e.g., the Devices page), the content is loaded unescaped inside of the style tag, as shown below:
This allows malicious users to insert (almost) any CSS they want in place of the icon. A malicious user can cause an HTTP request to an arbitrary domain/IP address by setting a background-image property in the payload, as shown here:
The impact of this vulnerability is less severe due to modern browsers preventing JavaScript in style tags, and from PRTG Network Monitor preventing “ characters in the payload. These steps prevent this vulnerability from being escalated into a Cross-Site Scripting vulnerability.
Affected Versions
Raxis discovered this vulnerability on PRTG Network Monitor version 22.2.77.2204.
Remediation
A fix for CVE-2022-35739 has not been released. When a fix is released, upgrade to the newest version to fully remediate the vulnerability. In the meantime, Raxis recommends keeping a small list of users who can edit devices to limit the impact of the vulnerability. CVE-2022-35739 has minimal damage potential and is difficult to execute, and thus does not warrant additional protections while waiting for a remediation.
Disclosure Timeline
July 7, 2022 – Vulnerability reported to Paessler Technologies.
July 8, 2022 – Paessler Technologies begins investigating vulnerability.
July 14, 2022 – CVE-2022-35739 assigned to this vulnerability.
August 8, 2022 – Outreach to Paessler Technologies without response.
October 4, 2022 – Second outreach to Paessler Technologies without response.
October 7, 2022 – Third outreach to Paessler Technologies without response.
October 21, 2022 – Original blog post detailing CVE-2022-35739 released.
I’m Matt Dunn, lead penetration tester at Raxis, and I’ve uncovered a couple more ManageEngine vulnerabilities you should know about if your company is using the platform.
Summary
I discovered two instances in ManageEngine Remote Access Plus where a user with Guest permissions can access administrative details of the installation. In each case, an authenticated ‘Guest’ user can make a direct request to the /dcapi/ API endpoint to retrieve information. This allows the ‘Guest’ user to discover information about the connected Domains as well as the License information for the installation.
Proof of Concept
The two vulnerabilities are similar in that they allow a user with ‘Guest’ level permissions to access details about the installation. Each CVE refers to a specific piece of information that the user can retrieve, as detailed below:
CVE-2022-26653 – The ‘Guest’ user can retrieve details of connected Domains.
CVE-2022-26777 – The ‘Guest’ user can retrieve details about the installation’s License.
The user with ‘Guest’ permissions can access all the Domain’s details, including the connected Domain Controller, the account used for authentication, and when it was last updated, as shown here:
Similarly, the ‘Guest’ user can access all the License information, including the amount of users, amount of managed systems, who the license is for, and the exact build number, as shown below:
Affected Versions
Raxis discovered these vulnerabilities on ManageEngine Remote Access Plus version 10.1.2137.6.
Remediation
Upgrade ManageEngine Remote Access Plus to Version 10 Build 10.1.2137.15 or later which can be found here:
I’m Matt Dunn, lead penetration tester at Raxis. Recently, I discovered a stored XSS in Support Center Plus. Here’s how a malicious actor might exploit it — and what you can do to prevent it.
Summary
A low-privileged user (e.g., the default guest user) can inject arbitrary JavaScript into the description of a new Request. When another user (including a high privileged user) views that request’s edit history, the payload is executed in the context of that new user’s browser. This can cause privilege escalation or other payload execution from low privileged users to other, possibly higher privileged users.
Proof of Concept
The vulnerability can be triggered by inserting html content in the description field of a new request. The payload I inserted as a guest user was:
"><img src=x onerror="alert(document.cookie)"/>
This payload being inserted is shown here:
When another user (in this case an admin) views that request’s edit history, the JavaScript is executed in the context of the new user’s browser, as shown here:
This vulnerability allows any low privileged user to execute JavaScript on higher privileged or other low privilege user’s browsers once they view a request’s edit history. While the payload used here launches an alert box with the page’s cookie values, more dangerous payloads could be executed in this context as well.
Affected Versions
Raxis discovered this vulnerability on Manage Engine Support Center 11.0 Build 11019.
Remediation
Upgrade ManageEngine AD Support Center Plus to Version 11.0 Build 11020 or later immediately which can be found here:
Pensacola Catholic High School’s “Crubotics” team won MATE’s North Gulf Coast regional remotely operated vehicle (ROV) competition and is headed for the world championship in California. Raxis proudly celebrates this wonderful accomplishment by helping sponsor the journey.
Next week, 14 students and two teachers from Pensacola Catholic High School will travel to Long Beach, California to match their remotely operated vehicle (ROV) – designed to probe the ocean below the arctic ice – against other regional winners from around the world.
The competition is conducted by MATE (Marine Advanced Technology Education) whose mission is to use the development of the ROV to teach students both STEM skills as well as help develop an entrepreneurial mindset so that they develop the technology with an eye toward forming companies and creating jobs around it.
Crubotics – a portmanteau of robotics and the CHS Crusader mascot – has competed in the Northern Gulf Coast regional competition for the past five years, with the exception of a break for COVID. In April, the team bested the field and earned the right to travel to California for the world challenge.
“Of course, I was proud of the victory, but I was even more impressed by how they handled adversity. When things started to go wrong, they pulled together as a team, quickly and calmly developing a solution. It was incredible to watch.”
CHS Science Teacher Dana Lupton, team mentor
The ROV must enter the water through a hole in the ice, navigate to the ocean floor, and monitor and report back conditions in real time. As an added layer of difficulty, the ROV’s software must incorporate artificial intelligence (AI) that can identify schools of fish and estimate their numbers, locate and retrieve any dead fish, and stitch together a composite picture of the surroundings.
From California, the team won’t be testing the ROV in actual arctic conditions, but the challenges are formidable even in the controlled conditions of a swimming pool. For example, the ROV must enter the water through a hole in the ice, navigate to the ocean floor, and monitor and report back conditions in real time. As an added layer of difficulty, the ROV’s software must incorporate artificial intelligence (AI) that can identify schools of fish and estimate their numbers, locate and retrieve any dead fish, and stitch together a composite picture of the surroundings.
“This is a very complex blend of hardware and software that would challenge adults trained in these disciplines,” Lupton said. “To see a group of young people step in and take on the roles that emerged based on needs is a real inspiration.”
The trip to California is being underwritten in part by a sponsorship from Raxis, an Atlanta-based penetration testing firm with strong ties to Pensacola and the CyberCoast.
“It was intense curiosity about how things work that led me to a career in pentesting and ultimately to create a company of like-minded professionals. I’m absolutely thrilled to see high-school students taking on challenges like this because the payoff for them – and for our planet – will be immeasurable.”
I’m Matt Dunn, a lead penetration tester at Raxis. Recently, I discovered an information leakage in ManageEngine Asset Explorer. This is a relatively minor information leakage, as it only leaks the currency that a current vendor uses. Though minor, it could lead to other inferred information such as vendor location based on their currency.
Proof of Concept
The information leakage occurs in the AJaxDomainServlet when given the action of getVendorCurrency. This servlet action does not require authentication, allowing a user to obtain a vendor’s currency with a GET request to a URL similar to the following:
In this example URL, we request the currency for the vendor with the specified vendorId. If the vendor doesn’t have an assigned currency, the dollar symbol is returned. If it does, the vendor’s specific currency identifier is returned, as shown here:
Affected Versions
Raxis discovered this vulnerability on Manage Engine Asset Explorer Plus 6.9 Build 6970.
Remediation
Upgrade ManageEngine Asset Explorer to Version 6.9 Build 6971 or later, which can be found here:
I’m Matt Dunn, a lead penetration tester here at Raxis. Recently, I discovered a stored Cross-Site Scripting vulnerability in Zoho’s ManageEngine AD SelfService Plus.
Summary
The vulnerability exists in the /accounts/authVerify page, which is used for the forgot password, change password, and unlock account functionalities.
Proof of Concept
The vulnerability can be triggered by inserting html content, specifically tags that support JavaScript, into the first or last name of an Active Directory user. The following was inserted as a proof of concept to reflect the user’s cookie in an alert box:
<img src=x onerror=”alert(document.cookie)”/>
An example of this in the Last Name field of one such user is shown here:
The next time that user forgets, attempts to change, or is locked out of their account and they load the authVerify page, their name is presented without being sanitized. The unescaped HTML as loaded can be seen in Figure 2:
After the user attempts to reset their password, the malicious content is executed, as shown in Figure 3:
If the user must change their password on login, the malicious content is executed, as shown in Figure 4:
If the user attempts to unlock their account, the malicious content is executed, as shown in Figure 5:
Affected Versions
Raxis discovered this vulnerability on Manage Engine AD SelfService Plus 6.1 Build 6119.
Remediation
Upgrade ManageEngine AD SelfService Plus to Version 6.1 Build 6121 or later immediately:
A common finding in web applications we test is ‘Application Supports Simultaneous Logins’. This finding occurs when both of the following conditions are met:
The application allows for multiple sessions at the same time, from different devices, browsers, etc.
The application does not alert the user to the multiple sessions through:
Email notification,
Notification inside the application, or
A session management page inside the application.
Essentially, this boils down to the user being allowed to have multiple sessions without a way to manage them or see other active sessions through notifications or otherwise.
What does this look like?
In practice, we look in several locations for the functionality to manage sessions, but the most common place we find it is in profile sections or settings. When these are not available, we’ll log in on two separate browsers — or on two devices — and navigate them both to the settings page, checking for notifications or other session management abilities. An example of multiple sessions without notification to the user in a popular online platform is shown below:
Why does this matter?
Allowing simultaneous sessions seems innocuous at first. I mean, we mostly all have multiple devices that we log in through, right? True, but the lack of insight into your account’s session management becomes a problem if your session is somehow stolen, credentials are obtained, or your account is otherwise compromised through other vulnerabilities. If multiple sessions are allowed without notification to the user, there is no way for the user to know that their account has been compromised or to terminate the active sessions that have been compromised.
Remediations
In today’s world, disallowing multiple sessions is likely not realistic due to business constraints. Most people have several devices themselves, and logging in to an application on multiple is common, so this likely needs to be a feature in your application. However, alerting the user or allowing them to view their active sessions is important so they can maintain control of their account in the event of a breach. There are several ways to do this, with varying functionality, including:
Showing users active sessions with details about the session
Allowing users to terminate specific sessions
Providing functionality to log out the user from all other devices
Combine any of the above when the account password is changed
These are all valid approaches, but the specific one you choose to implement will depend on your application’s use cases, business constraints, and design. In our Raxis One application, we provide the user both with details about their active sessions, functionality for terminating specific sessions, and a session history that includes IP Address and location details, as shown in below:
I’m Jim McClellan, Raxis’ marketing director and newest (full-time) member of the team. Working with the company as a consultant for two years was a great intro to the people and the culture. When the opportunity arose to join them, it was an easy decision. Now, after months of conducting these interviews, our COO Bonnie Smyre turned the tables, and it’s my turn on the other side.
Bonnie: I would normally say, “Welcome aboard,” but I probably should say, “Welcome all the way aboard,” as you’ve been a Raxis consultant for two years now. What’s the biggest change you’ve noticed since joining us full-time?
Jim: Focus. Even though I’ve worked as a cybersecurity marketer for more than a decade, there’s still a very steep learning curve with penetration testing specifically – the tactics involved, the technologies you use, and even the vocabulary. Early on, I thought a CVE was made by Honda and that a Metasploit Module required medical intervention.
Jim: Haha! Yes, we do. Thank you for that, by the way!
Bonnie: You’ve worked in cybersecurity for a while, but that’s almost a second career for you, right?
Jim: At the very least, it’s an entirely different application of my skills from the first one.
Bonnie: You were a speechwriter for one of Florida’s previous governors, weren’t you? How did you get into that line of work?
Jim: This will sound like BS, but one night when I was 15, I heard a US Senator speak at a hometown fish fry, met a guy who said he was majoring in political science, and talked to an older man who told me about the importance of military service. Fast forward 12 years and I was a speechwriter for that former Senator who was now Governor Lawton Chiles. I was also an officer in the Florida National Guard with a political science degree from FSU.
Bonnie: Ha! That does sound like BS . . . or a very fortunate evening for you.
Jim: It would have been more fortunate to meet Bill Gates or Steve Jobs back then, but it certainly set the tone for the weirdness of my adult life. For example, I’ve had formal dinners in the Governor’s Mansion, but I’ve also fried fish on a creek bank. I’ve ridden in the Vice President’s motorcade during the same time I drove a Bronco with a rusted-out floorboard. There were so many times I wondered, “Am I really supposed to be here?”
Bonnie: Don’t worry, you’re in the right place. Do you miss working in politics?
Jim: Not in the least. I miss the people and the politics as they were then, but there was much more civility, respect, and appreciation for the complexities of public policy. Now, there’s a lot of unbridled and sometimes uninformed passion. As Arthur Schlesinger said, there’s “too much pluribus and not enough unum.”
Bonnie: You’ve obviously seen a lot of changes in your field. What do you consider most significant?
Jim: Emojis. I never thought hieroglyphics would make a comeback after all these millennia, but here we are.
Bonnie: You’re joking . . . I hope.
Jim: Really, I think it has been the convergent evolution of PR, marketing, and advertising. Those were very siloed disciplines for decades. Now, they’re just different starting points for conversations that happen mostly over social media.
Bonnie: Has that made it easier or harder to reach customers?
Jim: It’s a lot easier to get a message in front of customers but much harder to get them to notice. There are no more captive audiences listening to monologues from companies. The customers are in control, so businesses have to be ready to provide useful, high-quality information when and where buyers need it. And, of course, trust is everything. Word of poor service or a faulty product can, quite literally, travel around the world in minutes.
Marketing is still about authenticity and creativity, but the canvas is larger, and we have more colors and brushes to work with.
Bonnie: And emojis.
Jim: Yes!
Bonnie: I know one of your favorite tactics in these meet-the-team interviews is to get people to tell you about their hobbies or unusual things they’ve done. So, I’m going to do that with you.
Jim: My hobbies include backpacking, fishing, hunting, and any other reason I can dream up to be outdoors. I also like woodworking and volunteering with Habitat for Humanity. As for unusual? Let’s see: I wrote a book about growing up on the Apalachicola River and the adventures we had in my small hometown. After it was published, my brother (a judge) pointed out that I had confessed in writing to two felonies and multiple misdemeanors.
Bonnie: You’re not in jail, so it must have worked out okay.
Jim: I’m not in jail, and mine is Amazon’s 537th bestselling book . . . in the hunting and fishing humor category. Win, win.
Bonnie: Yes, just a short hop away from the New York Times Bestseller List. Speaking of the Apalachicola River, isn’t that where that delicious tupelo honey comes from? We all look forward to getting that from you during the holidays. Also, don’t feel the need to stop just because you work for us now.
Jim: Noted. And, yes, I even named my company Tupelo Media. The Apalachicola River is one of two places where there are enough tupelo trees to produce the honey commercially. One of the jobs I had growing up was helping a beekeeper during tupelo season. Giving away jars of it is a great way to start conversations about the river — and it reminds me that I never want to be a beekeeper again.
Bonnie: That’s good because you still have work to do here. What’s your favorite part about working with Raxis?
Jim: I’ve worked with lots of different companies as a consultant and employee, so I’ve learned it’s easy to look at the bottom line and know how a business is performing in the short term. But it’s the team, the leadership, and the culture that will tell you whether the company will be successful for the long haul. My favorite part of working for Raxis is the certainty of being on a winning team made up of people I really like.
I’m Matt Dunn, a lead penetration tester at Raxis. This is the second of a two-part series, aimed at explaining the differences between authenticated and unauthenticated web application testing. I’ll also discuss the types of attacks we attempt in each scenario so you can see your app the way a hacker would.
Although some applications allow users to access some or all their functionality without providing credentials – think of simple mortgage or BMI calculators, among many others – most require some form of authentication to ensure you are authorized to use it. If there are multiple user roles, authentication will also determine what privileges you have and/or what features you can access. This is commonly referred to as role-based access control.
As I mentioned in the previous post, Raxis conducts web application testing from the perspectives of both authenticated and unauthenticated users. In authenticated user scenarios, we also test the security and business logic of the app for all user roles. Here’s what that looks like from a customer perspective.
Unauthenticated Testing
As the name suggests, testing as an unauthenticated user involves looking for vulnerabilities that are public-facing. The most obvious is access: Can we use our knowledge and tools to get past the authentication process? If so, that’s a serious problem, but it’s not the only thing we check.
In previous articles and videos, we’ve talked about account enumeration – finding valid usernames based on error messages, response lengths, or response times. We will see what information the app provides after unsuccessful login attempts. If we can get a valid username, then we can use other tools and tactics to determine the password. As an example, see the two different responses from a forgot password API for valid and invalid usernames below:
From an unauthenticated standpoint, we also will try injection attacks, such as SQL Injection, to attempt to break past login mechanisms. We’ll also look for protections using HTTP headers, such as Strict-Transport-Security and X-Frame-Options or Content-Security-Policy, to ensure users are as secure as they can be.
With some applications, we can use a web proxy tool to see which policies are enforced on the client-side interface and which are enforced on the server side. In a future post, we’ll go into more detail about web proxies. For now, it’s only important to know that proxies sometimes reveal vulnerabilities that allow us to bypass security used on the client and allow us to interact with the server directly.
As an example, fields that require specific values, such as an email field, may be verified to be in the proper format on the client-side (i.e. using JavaScript). Without proper safeguards in place, however, the server itself might accept any data, including malicious code, entered directly into that same field. In practice, this can be bypassed, leading to attacks such as Cross-Site Scripting, as shown in my CVE-2021-27956 that bypasses email verification.
Authenticated Testing
During an authenticated web application test, we use many of the same tactics, toward the same ends, as we do with unauthenticated tests. However, we have the added advantage of user access. This vantage point exposes the application to more vulnerabilities due to the expanded surface area of the application. This is why we recommend authenticated testing, to ensure even a malicious user cannot attack the application.
Once authenticated, we attempt is to see if the app restricts users to the level of access that matches its business logic. This might mean we log in with freemium-level credentials and see if we can get to paid-users-only functionality. Or, in the role of a basic user, we may try to gain administrator privileges.
As with an unauthenticated test, we also see how much filtering of data is done at the interface vs. the server. Some apps have very tight server-level controls for authentication but rely on less-restrictive policies once the user is validated.
Though it may seem simple from the outside, one of the hardest things for web app developers to secure is file uploads.
This is another topic we’ll explore further in a future post, however, one good example of the complexity involved is photo uploads. Many apps enable or require users to create profiles that include pictures or avatars. One way to restrict the file type is by accepting only .jpg or .png file extensions. Hackers can sometimes get past this restriction by appending an executable file with a double extension – malware.exe.jpg, for example.
Another problem is that malicious code could be inserted into otherwise legitimate file types such as word documents or spreadsheets. For many apps, however, it’s absolutely necessary to allow these file types. When we encounter such situations, we often work with the customers and recommend other security measures that allow the app to work as advertised but that also detect and block malware.
Conclusion
As a software engineer by training, one advantage I have in testing web applications is understanding the mindset of the developers working on them. People building apps start with the goal of creating something useful for customers. As time goes on, the team changes or users’ needs change, and sometimes vulnerabilities are left behind. This can happen in expected ways, such as outdated libraries, or unexpected ways, such as missing access control on a mostly unused account type.
At Raxis, we employ a group of experts with diverse experiences and skillsets who will intentionally try to break the app and use it improperly. Having testers who have also developed applications gives us empathy for app creators. Even as we attack their work, we know that we are helping them remediate vulnerabilities and making it possible for them to achieve their application’s purpose.
I’m Matt Dunn, a lead penetration tester at Raxis. In this series of posts, I’m going to introduce you to the Raxis method of penetration testing web applications. We’ll start with a look at what a web app test involves and how it differs from the network testing we do.
By their very nature, web apps deserve special scrutiny because they are designed in most cases to be accessible to a broad base of users, often with different roles that convey higher levels of privilege or access. Additionally, they are often used to perform wide ranging functionality, from shopping and banking transactions, to accessing healthcare data. With that accessibility and functionality comes exposure to a wide range of threats from malicious actors who want to exfiltrate data, modify the application, or otherwise disrupt its operation.
When Raxis performs a web application penetration test, we typically approach it from the viewpoint of both unauthenticated and authenticated user roles. In many cases, some of the app’s functionality is going to be behind some form of authentication. We’ll go into greater detail about authenticated and non-authenticated tests in a subsequent post. For now, however, we’ll limit the discussion to tests in which we are given credentials for all user roles.
Armed with the appropriate credentials, we examine all the functionality of the app to find out what features are accessible to users and how the application is intended to work. Can users’ profiles be changed? Are users allowed to upload files? Where can the user input their own content? What is each user supposed to be allowed to do? These are just some of the questions we’re looking to answer in the beginning of the test.
Once we know what the app should do, we’ll test all these features to see if the business logic is correct. For example, an app may allow only administrators to delete uploaded files. So, we’ll attempt to circumvent that restriction and see if we can accomplish that with lower-privileged credentials.
Raxis approaches a web application test from the perspective of unauthenticated users and authenticated users in multiple roles when more than one role exists.
Next, we will try to exploit the app’s features. For instance, we’ll test the various input fields to see if we can insert malicious code. If so, the app may be vulnerable to cross-site scripting (XSS) – a topic I’ve covered extensively on our blog and YouTube channel. In a similar manner, we’ll test areas where we can upload files to see if we can upload malicious content as part of an attack.
One question we get from time to time is whether web application testing is included as part of our network penetration tests. The answer is no, for two reasons: First, it’s unlikely that, within the time of a well-scoped network test, we will be able to find credentials to all roles and parts of your web app. Second, network tests are broader in scope and identify the highest risk vulnerabilities across the entire network (as time allows). Depending on other findings, we often test the accessible pages as well as the authentication features. These include logins and “forgot password” pages, to name just a couple. Our goal is to see if we can gain unauthorized access, perform account enumeration, or attack the application externally. But we won’t test as a verified user unless we’re able to gain authenticated access, and even then, we will not focus on the web app in the same depth as we would in a web app test.
That’s what makes web application testing so important. And with so many companies relying on (or even built around) web apps, it makes sense to conduct these tests regularly and address the findings in order of priority. Even if you are already performing network penetration tests, I strongly recommend that you conduct specific web application tests as well.
“Give a pentester a table, they submit one report. Automate making tables, they can submit reports for life.”
k0pak4
Displaying findings clearly and concisely is key to making a penetration testing report actionable. The proof of concept allows a client to replicate the finding, and a list of affected targets allows them to properly remediate all assets. On large engagements, there are often findings that affect many hosts; when presented concisely, this can be acted on much more easily. There are already amazing tools out there to scan many hosts and report their findings. (Nessus, Nexpose, and Nmap are examples.) The problem is that none were doing what I was looking for — reporting the affected hosts for one finding, concisely.
The first two tools described here quickly create tables showcasing the details behind two common findings on large external pentest reports. Clients can also use these tools to verify remediations without having to manually inspect each host. The last tool can be used to turn any list into a sorted table, which works well when you simply need a large table to display many hosts.
There are several tools that will break down the weak SSL/TLS protocol versions, ciphers, and signature algorithms used in TLS connections. Some of these are web-based, such as SSL Labs, and others are command-line based, such as the SSLScan tool. My mass-sslscan tool runs SSLScan against an entire list of hosts, parses the output of the tool, and creates a table with each host that displays which weak configuration(s) they have. This can also be used in remediation to ensure those servers have had their configurations strengthened. An example of running the tool is shown below:
On penetration tests, it’s common to find the HTTP server header, which can disclose the web server’s software and sometimes its exact version. This information leakage is typically of low severity, but helps an attacker fingerprint the server, which may disclose a vulnerable version. In more targeted attacks, it might tell them what software to build an exploit for. My tool, server-header-scan, retrieves the server header from each target, and inserts the results into a table with each retrieved value, as shown in the following example:
The table-maker is a bit more straightforward. It takes a list, either as a comma-separated list or as a file with one item per line, and turns it into a table with the desired number of columns. This can be useful for extremely large scopes or when discovering many hosts are vulnerable to a specific finding. This results in a csv ready to be opened and pasted as a table, as shown in the illustration below:
If you compile reports for large penetration tests, odds are that you’re going to be pressed for time at some point. My hope is that these tools will make it easier for you to provide more and better information to your customers in a way that helps them understand and act on your findings.
My name is Mark Fabian – but to my friends and colleagues, it’s just Fabian. Today, I’m in the spotlight, discussing what really is my dream job — lead penetration tester here at Raxis. After just a few short months, I can highly recommend that you check our careers page and our YouTube channel to see if this is the career path and company for you.
Jim: Mark, I think it’s important to let folks know that you represent “Raxis West” as the only Californian on the team.
Fabian: That’s right. I’ve spent all but four years of my life in Northern California, here in the Sacramento area. Even the time away was just down south in San Diego.
Jim: You must like it out there.
Fabian: This is a perfect spot for folks who like to spend more time outdoors than indoors. Personally, I enjoy all kinds of activities like hiking, wakeboarding, dirt biking, riding jet skis, going out on houseboats, and just hanging out at the lake with my friends.
Jim: Sounds like you’re definitely in the right place.
Fabian: Yeah, the weather out here is great, though the water levels at the lakes have been down this year. There’s also an amazing number of activities within just a short drive, such as snowboarding or surfing.
Jim: Speaking of activities, I understand you’re a musician.
Fabian: I play guitar and some other instruments . . .
Jim: You should get together with Tim Semchenko. He can sing while you play.
Fabian: I was actually in a band for a few years that played metal and punk. I love all things music. I even used to run the soundboard for my church.
Jim: You have that in common with (VP of Business Development) Brad Herring.
Fabian: That’s interesting because church is also how I got started building websites. I made a remark about how outdated the church’s site was and they invited me to do better. The short version of the story is that I did and that became my duty.
Jim: Is that how you first got into tech?
Fabian: My interest in technology started a lot earlier. When I first started using the internet, we had an old, slow dial-up connection. But my neighbor had a much faster connection and Wi-Fi. As a joke, he said if I cracked the password, then I could use his Wi-Fi. I don’t think he ever expected me to crack it, but I did. Faster internet, here I come!
Jim: Are you really telling me that hacking was one of your first tech achievements?
Fabian: Ha! I guess so.
Jim: Geez. Where do you go from there?
Fabian: For me, it transformed into an interest in the mechanical side. I started repairing smart phones and tablets, adding memory to computers . . . that kind of stuff, mostly for friends and relatives.
Jim: That mechanical interest went beyond computers, though, right?
Fabian: Right. I grew up rebuilding cars and taking them to the track.
Jim: (Raxis CEO) Mark Puckett must have enjoyed your interview.
Fabian: Apparently, since I got the job. When I talked about my interest in cars, (COO) Bonnie Smyre joked, “Well, that’s it. We probably don’t need to know any more.” But I should add that I work on older, slower cars. No Porsches or Lamborghinis. And our track is more for drifting than racing.
Jim: Did you find you had a knack for mechanic work, a greasy thumb or something?
Fabian: Yes, as I kid, I used to rebuild gas powered scooters. Also thought it would be a blast to take a weed-whacker motor and attach it to my bike. It did not disappoint. As I grew, the projects just got bigger. So, I started rebuilding car engines, changing out the suspension, doing custom fab work, and so forth.
Jim: Did you consider making that a career?
Fabian: In a way, yes. When I really focused on what I wanted to do for a living, three possibilities were at the top of the list: helicopter pilot, master mechanic, or a job in the tech field. But helicopter instruction is very expensive, and it would have taken as long to be a master mechanic as it did to develop the same level of skills in the tech field. Plus, technology seemed more versatile.
Jim: Once you decided on technology, how did you decide that penetration testing was going to be your area of focus?
Fabian: That was always my biggest interest. I just didn’t know how to get there at the time. So, I started with building websites, affiliate marketing, landing pages, that kind of stuff.
Jim: College?
Fabian: I did get my A.A. degree in computer science, but then I decided to start working on certifications instead of continuing in college. I got a helpdesk job because I thought that would be a good first step.
Jim: Seems like it was.
Fabian: It was, but there were a lot more steps in between. I went from doing helpdesk work to becoming an IT admin. I moved from there into a security operations center (SOC) analyst role to doing blue and purple team assignments. Finally, I landed at Raxis.
Jim: Is it as good as you thought it would be?
Fabian: Absolutely. This was the dream job, and working with the Raxis team has been an incredible experience. I love offensive security, finding and exploiting new vulnerabilities, and learning more every day. I also appreciate that we get to work independently, but we can reach out when we need help and offer help when it’s needed.
“As others have said, the people are terrific and have a wealth of knowledge. They have high expectations for performance, but they give the team members a lot of flexibility and they encourage creativity.”
